From nobody Sat Apr 1 04:14:00 2017 Return-Path: <7riw77@gmail.com> 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 24C45126C89 for ; Sat, 1 Apr 2017 04:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 X_lE9Pewprps for ; Sat, 1 Apr 2017 04:13:56 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::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 86C10126BF6 for ; Sat, 1 Apr 2017 04:13:56 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id f84so8068356ioj.0 for ; Sat, 01 Apr 2017 04:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=TvrJn6Dzo3hL5/WqJMwrrORRY4AAmJB5z8LBYtJAHoo=; b=Jx37nd/x+NdxUZrk9X9mldHzSWfAzLTv6vz/THBIkPlC/U7L3JErmPPmIAq2lbXJqC +LWxOs7RwispUafU/X20YBIYSRfJX/6AAoSMKI4J/V21MWkug5idlOEUBPJnAXAggdE7 3Kr241KiIuf+ne1s/xnqBtJC36gN+KuvpUrUfBO5o0iIJAs3a9lWNpRlB8pp7vYGyulQ opgEffZYXC35M81hW5iLi0QW6ynGM51bTTi/fNA82Nhi3A2AFfb+iWq2KdhtBnzOGTRZ aeo6+cpDNkFARb82mz8yfEXAc4Cux8npc9PY8v7Gxr0TmTAX+z4FycbLLbDsx84sj/I8 aUQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=TvrJn6Dzo3hL5/WqJMwrrORRY4AAmJB5z8LBYtJAHoo=; b=umSiYSZ4lMB8YGFy52Ecn9DjzvLtUghVwF1tRE6hwd0TMyE9+SQ6KO+g8HcgO/wQ32 oLZRc8dbX4g7YZnUFzFT7v/8/RKiyG+P2FokRr0jgMxvEmX4ohANY3FNpdODv1u8iNcM PSFDL2B2S98yrKDqMkWnU52Vb5yX+P1cmoudC92jBuk+IMFPOfqukmwu9p462HcoFZ6H 2N70MbGClZPVGy+lLQbDul06K/c/agQpeDqWvGLsyHDIy6msPBOCEvQ78oaqHcja5zKz DC6CTZg8dy8euO/QZP0WUgu937L+RsEudRsKjNQP5TyfJnTtZF/+Y7vZyXQAzPYOa2M7 sLRg== X-Gm-Message-State: AFeK/H2lvz5HXOZtU7XX0A+sY5oEQdaxsLoS3twvM3ptkrqpH4BjX8MJIyke99nVr3MXCA== X-Received: by 10.107.135.105 with SMTP id j102mr7752442iod.90.1491045235946; Sat, 01 Apr 2017 04:13:55 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id w188sm2804944itc.6.2017.04.01.04.13.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 04:13:55 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Lorenzo Colitti'" Cc: "'Brian E Carpenter'" , "'Gert Doering'" , "'Fred Baker'" , "'IPv6 Ops WG'" References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> In-Reply-To: Date: Sat, 1 Apr 2017 07:13:50 -0400 Message-ID: <009901d2aad9$0b14e6b0$213eb410$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGz+X+6yMqyLanOYYGkeqQOG6kIewGg/H8hAjHKp14BkDD4mwK/WuP9Awez7BECWVdYRgGUQrn5AYEPuBwCLehV4ADMPCiCAh5Ix0kCCB4wQwIIi1tnoR+v5pA= Content-Language: en-us Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 11:13:58 -0000 =20 > That was what draft-gont-v6ops-host-configuration proposed, and there = was > strong pushback from major host OS developers against making both of > them a MUST. Examples: For hosts, yes. I don't see how the same objections could apply to = routers, which should--at least from an operator's perspective--be able = to support any host that attaches to them.=20 =F0=9F=98=8A /r From nobody Sat Apr 1 04:26:19 2017 Return-Path: <7riw77@gmail.com> 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 9FB7C127286 for ; Sat, 1 Apr 2017 04:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 GGIhBrvclOZd for ; Sat, 1 Apr 2017 04:26:17 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::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 206821289B5 for ; Sat, 1 Apr 2017 04:26:15 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id 68so8095636ioh.3 for ; Sat, 01 Apr 2017 04:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=rs3FLi8TQ5FJtoH6mZy+WGu4rD43Qe0mRuS++nB7UNQ=; b=a/OI/RheLhHUM1MQKJnqcMZ0dS9tAwgSbi8CK1PWOsZnbpKjFa7x0otu+1LA80kjgX HzJ3qZTWxlXY13EYyFWWhLAsNP7ExmmcsCgCrDrd4rZKsYaY0IosoCVOylKe89LyZz4V Zu6amLLpC1AR69w02buNmFwBi3CskSQKvd8SbW5Fz33Y+bums9owd1qwzQd+hf9kDw5z tNJ9J92WFowvIAi9QODFYvNfJxidr5kncnyuMYz1pfQD0KkDshc9Fld4mD0SS/o+2NXI DmjaBD9mA6NZNRyCIrG14NM+REThoXhle1pne1J/z0Rkg+Lo6FFO6zp3Wqz9QXpqbK1O u1YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=rs3FLi8TQ5FJtoH6mZy+WGu4rD43Qe0mRuS++nB7UNQ=; b=S/17zxorR3Er3i0u9whHxEBFZSFi01WLkM5HQOpfVtEsVbrZKF5nUZje4qLViX8mCY /F11VCH45tdvC9JWe0dZtDV4pddTGis8DOYg0ZdcgSV+OTo+UqJxkVMLk1ALMfXkG4rM aNrD3AowgnjeNYYchn+eb+z0FSE5+buPKTVKEF/Jb8mOCpRSW9G9HcUFWqQFxkvz6nsh djs0I66xtC8q4sPj8TA2Mp1OKNmaOylWMhjMByc2d2I253gLHIhbxb6ofoFTax2NuZf+ AwwVytHWoygTvlYWf6phWskexnIacvqF5P1i7TS+0ab7bXZ5iiBMEdItN7S4uK7ouyk7 kAyQ== X-Gm-Message-State: AFeK/H2Rx3QKiSasIjqlAIK4V7gq28svJa9QNTqGVmy5rvFTEBDtGpZVRatzuSQFOiERpg== X-Received: by 10.107.129.214 with SMTP id l83mr8277594ioi.168.1491045974565; Sat, 01 Apr 2017 04:26:14 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id a68sm320520itd.30.2017.04.01.04.26.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 04:26:13 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Joe Touch'" , "'Ron Bonica'" , "'IPv6 Ops WG'" References: <020401d2a96c$0d320630$27961290$@gmail.com> <03a118c6-e352-6f01-5283-46f4ff54727e@isi.edu> <018501d2aa8a$f1137a40$d33a6ec0$@gmail.com> <7c09ccb9-5971-3f5b-ac07-62622814be4a@isi.edu> In-Reply-To: <7c09ccb9-5971-3f5b-ac07-62622814be4a@isi.edu> Date: Sat, 1 Apr 2017 07:26:09 -0400 Message-ID: <00a401d2aada$c3492970$49db7c50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFgkFfbKlW8X9Jtbc7PQ8zBQIWfBgFZDxLvAgmk6+QBcTOgtgEHQ3mYAj69/b2iU8JPwA== Content-Language: en-us Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 11:26:19 -0000 > I see BCPs as a place where operator advice goes. IMO, requirements = are a > different thing, esp. when we're defining what it means to "be" = something. The eventual status seems to be a useful discussion to have at some = point... I'm pretty ambivalent about it; the other co-authors may have a = stronger opinion.=20 > That's why I saw this as the IPv6 corollary to RFC1812 and why I found = it > lacking in that regard. So -- returning to your earlier comment: >> I see no valid reason to require TELNET vs. any other service over=20 >> which configuration can be achieved. I note that 1812 spends a good deal of time on O&M, including MIBs, = dumping router memory, out-of-band access, TFTP, memory dumps, audit = trails, etc., none of which seem (to me) to be IPv4 specific, and it is = standards track. I do not know if this bit of information applies, = however (?).=20 =F0=9F=98=8A /r From nobody Sat Apr 1 06:04: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 CE5B9127F0E for ; Sat, 1 Apr 2017 06:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 QC1u9kMgFP6B for ; Sat, 1 Apr 2017 06:03:59 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37457126D85 for ; Sat, 1 Apr 2017 06:03:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 1F1EA1BC37 for ; Sat, 1 Apr 2017 13:04:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Sat, 1 Apr 2017 14:03:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49A66D86-D916-475C-B8BC-A35111319275@thehobsons.co.uk> References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 13:04:02 -0000 Lorenzo Colitti wrote: > That was what draft-gont-v6ops-host-configuration proposed, and there = was strong pushback from major host OS developers against making both of = them a MUST. Examples: >=20 > https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html > https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html I noted that neither of those actually gave any reason other than "I = don't like it" ! > On the other hand, there seems to be less opposition to making RDNSS a = MUST. The main objections so far appears to be of the form "if we make = RDNSS a MUST we should make DHCPv6 a MUST as well", but given the = pushback from host OS developers I don't think that's likely. The problem being that we've had feedback here from operators who want = to be able to use DHCP, who are justly worried that if RDNSS is = mandated, then those OS vendors against DHCP will simply not make a = feature they wish to use available at all. From nobody Sat Apr 1 06:06: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 8FF54127F0E for ; Sat, 1 Apr 2017 06:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nCdZE4GvSawW for ; Sat, 1 Apr 2017 06:06:49 -0700 (PDT) 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 32A47126D85 for ; Sat, 1 Apr 2017 06:06:49 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id s16so15860433pfs.0 for ; Sat, 01 Apr 2017 06:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xLmk+REn/xC2dWadGV2hKFyzpunNB+EpKR5l3e8icF0=; b=fw5OTNL3noKYbolPEXSE+K8lvyrO2MRTDUhQa9MZw5vbTBttWAp7FkVNbe2k9NcaTU MrRQea0jz9zlqihxgCdDlBLOniVYAZbmRUrZrvjITJ1D/H+jqJxw+OoBknbq44vOw91i ivx/41Z5CQetctUHvIN02cjNYftfFDzQQwx0pHiE0TpSmtJM88zF8ZNaKjbNnvcC+lI4 rmDQ2Cu/B96P3xQ3aSQ+5V0vxize3eIQLftz9XcpTr/TewBNMRKkNMaRKcHUF5ou45U3 0h7wN6pyKgIWsr4R7gz/SACUi8qOKUcCrr+q2CRy0eydsvtFrqoRjf4z/QJzi8XwG3V6 i7qg== 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=xLmk+REn/xC2dWadGV2hKFyzpunNB+EpKR5l3e8icF0=; b=rHw5LgwJbs/wRHg1jgQgSPIs6C7hpsg45rHDsbqrZLsdsv9Z3DvVhclPAnoEQG/XGQ a+PhJU4PvX3w2QqQFL1cg/aIXxC8S4Al095DVWBkkP0p50e9mmIryXB/Txkf7euwXzD8 OCs1pOkFbsp3upFzlUH2Yw1S6/n6Z/Az+BneHCDu+TyIXz8oa59uwnp79O/C5yIF4QjP Zaz6A7xxGXWwxG8O/CaRz4Ein9OvGQm53wImmM37eRkX2oOvW/xV8Nce6+/ecX5DtuJG IQrrin8V2zrDDvgK10atdbSo0gYXi1rA1hmq6JUcPhGAb6wvTS3zYPub8xqMe0YGJD2Z XIcA== X-Gm-Message-State: AFeK/H1F+MVtY7HLhvnpJKf0Q0pD3R+DMxjWl+rmJhoq3QYgpFsAG/mzAPgZHBKkVp5pTtKS4cTmKak/I5FZCA== X-Received: by 10.99.108.74 with SMTP id h71mr7978956pgc.18.1491052008734; Sat, 01 Apr 2017 06:06:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.203 with HTTP; Sat, 1 Apr 2017 06:06:47 -0700 (PDT) Received: by 10.100.179.203 with HTTP; Sat, 1 Apr 2017 06:06:47 -0700 (PDT) In-Reply-To: <009901d2aad9$0b14e6b0$213eb410$@gmail.com> References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> <009901d2aad9$0b14e6b0$213eb410$@gmail.com> From: Ted Lemon Date: Sat, 1 Apr 2017 08:06:47 -0500 Message-ID: To: Russ White <7riw77@gmail.com> Cc: Lorenzo Colitti , IPv6 Ops WG Content-Type: multipart/alternative; boundary=94eb2c14074252a572054c1a9931 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 13:06:52 -0000 --94eb2c14074252a572054c1a9931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You should read Fernando's draft. It's short. Ask yourself what "must support" means in practice. How is it configured? If the router has a list of DNS servers, must it send both rdnss and DHCP versions of that info? What if there is centralized DHCP service on the network? Your don't have to ask these questions for rdnss. On Apr 1, 2017 6:14 AM, "Russ White" <7riw77@gmail.com> wrote: > > > > That was what draft-gont-v6ops-host-configuration proposed, and there > was > > strong pushback from major host OS developers against making both of > > them a MUST. Examples: > > For hosts, yes. I don't see how the same objections could apply to > routers, which should--at least from an operator's perspective--be able t= o > support any host that attaches to them. > > =F0=9F=98=8A /r > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c14074252a572054c1a9931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You should read Fernando's draft. It's short. Ask= yourself what "must support" means in practice. How is it config= ured?=C2=A0 If the router has a list of DNS servers, must it send both rdns= s and DHCP versions of that info?=C2=A0 What if there is centralized DHCP s= ervice on the network?=C2=A0 Your don't have to ask these questions for= rdnss.=C2=A0

On Apr 1, 2017 6:14 AM, "Russ White" <7riw77@gmail.com> wrote:


> That was what draft-gont-v6ops-host-configuration proposed, and t= here was
> strong pushback from major host OS developers against making both of > them a MUST. Examples:

For hosts, yes. I don't see how the same objections could apply to rout= ers, which should--at least from an operator's perspective--be able to = support any host that attaches to them.

=F0=9F=98=8A /r


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--94eb2c14074252a572054c1a9931-- From nobody Sat Apr 1 06:11: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 05ABF129456 for ; Sat, 1 Apr 2017 06:11:56 -0700 (PDT) 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 Dt9IaTdNeHOU for ; Sat, 1 Apr 2017 06:11:54 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 50B41127F0E for ; Sat, 1 Apr 2017 06:11:54 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id w11so4391687itb.0 for ; Sat, 01 Apr 2017 06:11:54 -0700 (PDT) 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=ctyLykPfyJc54QhmNgBcCTzwVRrYEbQEeNG/iEK/a9c=; b=FvN7XdDng5wYeK0l4WBDJv0LOrUqFj9LLuas5S18nWRmfpSNFvBewYZqONKAQM4PN/ KCuhObyuivpbZU2kT0gbtvFwh6S0GEcdAF+XtaWxQZog1Q2vqomKI/Xr2URIau/yzXkq vvMJfjTO7D/6wFn77hk7FCZlQkF7VI69BrrFpW4FdKymhpcKWQPveB09jt0UduYOD0ib dy00K1j/eoo0hdL8XJUymLHj4YSsqRpG6NJvtuyhrQQsQuwQ0L107/P68GDUAPEhcRUZ ioOqmOfOGs3l0QlOs/AsEJVgY6RX7T7JWLptZUXiGTI5vDa4/i0TfGhhlBAFFPoaYOMb vzjA== 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=ctyLykPfyJc54QhmNgBcCTzwVRrYEbQEeNG/iEK/a9c=; b=FUqUkrVtSuUwLuGDnlldJEB2l81KB/ldR/F7VkRt70/wIJ0sYrVNDzFWypxCB5e/cO QAaciPzHLRzzYSvdaN+BsNwJbmHMRPWaKS2UTgrhHCOt2lN712gjG1Rne1JIGs9ivTjF Zc0Hh8aPhzzfMzw9azZE+BUyAi1bSRBQAE/TtyQJJE0qh6946QpeYZbg/Zku9vh7JylV DYJxxSN63jxUnhWavadabJ11LQlj+XJAYRcPy3Jlq3tH7U6SrSm5XywG7oPorMkjDC5y oTbJuNeMhboT8Epb9x56VDpP86WTfIMjPcdWV8WqFKdMty0YQ4xFGDmKJNI7mzGsa+KC s22A== X-Gm-Message-State: AFeK/H3klcOT/ypbDfz+P4ZUsOEDJfN7vCCkCPu6TaStnumCC6rFc0dl 3RrKXJ5PhjOHxw== X-Received: by 10.36.33.68 with SMTP id e65mr2427373ita.21.1491052313654; Sat, 01 Apr 2017 06:11:53 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 189sm2887083itx.25.2017.04.01.06.11.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 06:11:53 -0700 (PDT) To: Russ White <7riw77@gmail.com>, 'Joe Touch' , 'Ron Bonica' , 'IPv6 Ops WG' References: <020401d2a96c$0d320630$27961290$@gmail.com> <03a118c6-e352-6f01-5283-46f4ff54727e@isi.edu> <018501d2aa8a$f1137a40$d33a6ec0$@gmail.com> <7c09ccb9-5971-3f5b-ac07-62622814be4a@isi.edu> <00a401d2aada$c3492970$49db7c50$@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <00dc02da-0aef-4e38-26af-501b98514ed5@gmail.com> Date: Sun, 2 Apr 2017 02:11:50 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <00a401d2aada$c3492970$49db7c50$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 13:11:56 -0000 On 02/04/2017 00:26, Russ White wrote: > >> I see BCPs as a place where operator advice goes. IMO, requirements are a >> different thing, esp. when we're defining what it means to "be" something. > > The eventual status seems to be a useful discussion to have at some point... I'm pretty ambivalent about it; the other co-authors may have a stronger opinion. > >> That's why I saw this as the IPv6 corollary to RFC1812 and why I found it >> lacking in that regard. > > So -- returning to your earlier comment: > >>> I see no valid reason to require TELNET vs. any other service over >>> which configuration can be achieved. > > I note that 1812 spends a good deal of time on O&M, including MIBs, dumping router memory, out-of-band access, TFTP, memory dumps, audit trails, etc., none of which seem (to me) to be IPv4 specific, and it is standards track. I do not know if this bit of information applies, however (?). I think 1812 was written a long time ago and both solutions and practices for configuring & monitoring routers have changed more than somewhat since then. I also think that they will continue to change, but the draft allows for that by saying "not limited to": To support automated network device configuration, IPv6 routers and network devices SHOULD support YANG and SNMP configuration, including (but not limited to): The only quibble with that sentence is that it seems to recommend SNMP SET. I understood that SNMP was only use for monitoring in practice, as mentioned later under 'Telemetry'. Brian From nobody Sat Apr 1 06:37: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 840E7129462 for ; Sat, 1 Apr 2017 06:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 xYOwoyCsrvPW for ; Sat, 1 Apr 2017 06:37:36 -0700 (PDT) Received: from mta00.svc.cra.dublin.eircom.net (mta00.svc.cra.dublin.eircom.net [159.134.118.55]) by ietfa.amsl.com (Postfix) with SMTP id 575C51270A0 for ; Sat, 1 Apr 2017 06:37:36 -0700 (PDT) Received: (qmail 29497 messnum 11403697 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 1 Apr 2017 13:37:34 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (HELO avas02) (213.94.190.14) by mta00.svc.cra.dublin.eircom.net (qp 29497) with SMTP; 1 Apr 2017 13:37:34 -0000 Received: from [192.168.1.1] ([86.45.37.172]) by Cloudmark Gateway with SMTP id uJDicQ5pzuAvEuJDicmOIe; Sat, 01 Apr 2017 14:37:34 +0100 X-CNFS-Analysis: v=2.2 cv=D6s3ErZj c=1 sm=1 tr=0 a=K7PZQZnhnIzjjF0D3pxPpg==:117 a=K7PZQZnhnIzjjF0D3pxPpg==:17 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=_ICk8x4uPxdmnwBgbl0A:9 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ross Chandler In-Reply-To: <00dc02da-0aef-4e38-26af-501b98514ed5@gmail.com> Date: Sat, 1 Apr 2017 14:35:25 +0100 Cc: IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <0633EBDF-7953-44CF-A78F-FE0BC6DE10D6@eircom.net> References: <020401d2a96c$0d320630$27961290$@gmail.com> <03a118c6-e352-6f01-5283-46f4ff54727e@isi.edu> <018501d2aa8a$f1137a40$d33a6ec0$@gmail.com> <7c09ccb9-5971-3f5b-ac07-62622814be4a@isi.edu> <00a401d2aada$c3492970$49db7c50$@gmail.com> <00dc02da-0aef-4e38-26af-501b98514ed5@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfDFLPnaoOD9DnmMtE/7ik9COlbs/o61HCwNQ4MRVcceY2SHWLT0SYAbBWC40fJo/qa/4cmukhE3uY8Zbh5pRFKenlDKNHq7sFP4DIxCclIxRFUSDUWM6 cwGleBZMBPomEtJOMaT9pyfSa8sRXHE0YW7PoY5pE+aJN4RMmY2O4K82jsnXL89T2v60c+QAN5pEG5hExtGDbxwJ1S9JdE0fgUA= Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 13:37:38 -0000 > On 1 Apr 2017, at 14:11, Brian E Carpenter = wrote: >=20 > To support automated network device configuration, IPv6 routers and > network devices SHOULD support YANG and SNMP configuration, = including > (but not limited to): >=20 > The only quibble with that sentence is that it seems to recommend SNMP = SET. > I understood that SNMP was only use for monitoring in practice, > as mentioned later under 'Telemetry'. If you are talking about the present situation, SNMP is used for = configuration.=20 At least one widely used router vendor=E2=80=99s element manager is = dependent on it. Ross= From nobody Sat Apr 1 07:04: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 3219312947E for ; Sat, 1 Apr 2017 07:04:13 -0700 (PDT) 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 9bwcoZFbscpz for ; Sat, 1 Apr 2017 07:04:10 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 C7100129407 for ; Sat, 1 Apr 2017 07:04:10 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id y18so4475100itc.2 for ; Sat, 01 Apr 2017 07:04:10 -0700 (PDT) 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=4yJ6+2iT9yD5fCm8jgebPU5ochcUOM3qPK4OWYGq+LQ=; b=ICmzGmD4DdFzwDPFzqxPNuuPFK3wVsRBi05PzUX6TZRpQGjJ9utlBbEar22uKXjtjU 0b0zNIYvrbaDIuXqVVgLawR7mXZoStpcktToNjQGSXmbx5jy0tGDUsfnIDt5bzTeqswZ ZkMz7d9y2VoQpO0jJNG9oNeA3PBHN9xFHTaquLfm10sxwBrKZte19DarvrwVcmUg59qD 2pff0dpA/qzxkfbkr1jjiqZoiGVX8kqxo4gzVMHiohcGAwsHA+aDl17xD7aKlOLvMnj+ eDN27R0Ags3rr7kzer2v9upRu5nf+nhzxWHmYrpx8xOYzJf3O5fvRJs0bmgsrh+rakdm G1qA== 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=4yJ6+2iT9yD5fCm8jgebPU5ochcUOM3qPK4OWYGq+LQ=; b=Wkr+pKm8aIxQHnLtJpZcnURHGLfpLkbrFXWR5/Kzq9McPtDwzQ0MKuSdRX1nfKSrCd TkRkPyHQg8Kj+P3LZYLCyOL/bE2aZ3mIYcbVdsIuePaVzDEC2udn37BdKhX5ZoKFMiAB mS6xuc7R6dgaSdL6uzZ9tCpmtTig3sPs/LnfVkogWhEG6Cu4z3/bX3l2WHvJxM7sGuYJ drwBW4WKYNnhzcIl5QtCESitRFum1U8ZpELPgsRf2IIwZe8EEUyfu/XUuxsvTgf8q3Qw Kb4yCsdeZSFnKlBsEDx/aQMsSgub5v1CQS313bYamReolV10+HlPjkqnkIEz0X1Gob0W 53ww== X-Gm-Message-State: AFeK/H27A+tgbQbURNpBm4iAU9zTo8rrSmVldnATcxx/RJwvsZA+tFz0kHlD92YR4T65kQ== X-Received: by 10.36.253.4 with SMTP id m4mr2678623ith.19.1491055449789; Sat, 01 Apr 2017 07:04:09 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id b25sm4822691iod.32.2017.04.01.07.04.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 07:04:07 -0700 (PDT) To: Lorenzo Colitti , Russ White <7riw77@gmail.com> References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> Cc: Gert Doering , Fred Baker , IPv6 Ops WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 2 Apr 2017 02:04:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 14:04:13 -0000 On 01/04/2017 18:16, Lorenzo Colitti wrote: > On Fri, Mar 31, 2017 at 9:15 PM, Russ White <7riw77@gmail.com> wrote: >=20 >> I think the way forward, without continuing to tie ourselves in >> knots--=F0=9F=98=8A--maybe be this -- simply say both MUST be implemen= ted, because: >> >> - some folks prefer one, other folks prefer the other >> - I have not heard a single argument from anyone along the lines of "t= his >> is not important, neither needs to be implemented" >> >=20 > That was what draft-gont-v6ops-host-configuration proposed, and there w= as > strong pushback from major host OS developers against making both of th= em a > MUST. Examples: >=20 > https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html > https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html >=20 > I think that's unlikely to reach consensus. However, it could reach rough consensus, which is sufficient. On 02/04/2017 02:06, Ted Lemon wrote: > You should read Fernando's draft. It's short. Ask yourself what "must > support" means in practice. How is it configured? If the router has a = list > of DNS servers, must it send both rdnss and DHCP versions of that info?= > What if there is centralized DHCP service on the network? Your don't h= ave > to ask these questions for rdnss. No, but you have to answer the question of what tools are available for configuring the appropriate DNS server address into the router, which also varies according to the scenario. Maybe there's already a YANG module that covers this? But in both cases extra guidance is needed. Brian From nobody Sat Apr 1 07:09: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 37CD8129477 for ; Sat, 1 Apr 2017 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 YCQ1AmHTjoYh for ; Sat, 1 Apr 2017 07:09:44 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 AB310129353 for ; Sat, 1 Apr 2017 07:09:44 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id y18so4483879itc.2 for ; Sat, 01 Apr 2017 07:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Ss3SPthKHNvegJtEnfNh0/tH2VDJfIFR9VE9lk02M2Q=; b=YddJVeGglV83xfwtfOAl6txZNSy4LP0ZPHuEHaMZYhN+Prx/5R9IyGOqy5Xs5xqKC0 To2nIsq4q668ilhCKgf/uXbl84lerEwRCMCVA8c4AXaWj+DXCS3fj8/XewkyQri0qw6/ Gr9wP5sIjIhz6CKzjHzT5hs4MEU4W3wSpsc/e+zo9u+6CUrpLigO1orZOKjytQAXvf7o INfLV1qO2a6J2zeUrdSHaCu82qydzfyJQl9+Nz9coQNBcccSFCbtzifbtTnad6idOr66 z1DLm/kpncOQB4i9/xhpoOF6ZB4EnHv1csisJOUZky7DRvaMHAYatdNpVcIdJG+zwVBB N3mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=Ss3SPthKHNvegJtEnfNh0/tH2VDJfIFR9VE9lk02M2Q=; b=Qy5zVmYQJ5Hq8t2FdUXz8sRIA9+pmcn61XXvZY7nvJ4rotxbMMu2jSaGUbKy2Tcbmn ZSDNfaupBF5bOpDJmjY7jO3Xl2GVrKCPfVDb9GhG1lxi/LHMLcLbhR6DXArR3PLVMoVx Ky7dr9zOyuOkgukIHCWsoZV7zLMTQ9LFMBSMr9iwT8REikX1RJUpfH/fgSIAlpc/t/sc mmQY/YAGjxRBq0gAvnNbBzzzC4HPRZqpp0/P/oMwIzv65oH5CbLyF/dH0XLnBGAfbyZI 8WiiU3JSQtVY7LP5nGT6ZGt5bUgz15kxq+biHe29fLrEcyjRJoNEwPrJ4wjkWebZrlOO VsRw== X-Gm-Message-State: AFeK/H04x1Pby+EDGhs33EPyLN9Vd24+GxeQheQG6r+2whf8V7saLBPNQFmaFt7kfmdLnw== X-Received: by 10.36.206.6 with SMTP id v6mr2762202itg.48.1491055783970; Sat, 01 Apr 2017 07:09:43 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id i197sm4842804ioi.7.2017.04.01.07.09.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 07:09:43 -0700 (PDT) To: IPv6 Operations From: Brian E Carpenter Organization: University of Auckland Message-ID: <483cf623-3ac3-2a14-6864-05c8626864cb@gmail.com> Date: Sun, 2 Apr 2017 02:09:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Scope question about draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 14:09:46 -0000 I see nothing, not even placeholders, in the draft about router support for on-link hosts, e.g. the requirements to generate RAs, PIOs, redirects etc. and the ever popular topic of RDNSS. If that's out of scope, fine, but the Introduction should say so. The Abstract is rather concise, too. Brian From nobody Sat Apr 1 07:18: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 6F537129489 for ; Sat, 1 Apr 2017 07:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s6_Kb5KFhJxA for ; Sat, 1 Apr 2017 07:18:02 -0700 (PDT) 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 59EE6129426 for ; Sat, 1 Apr 2017 07:18:02 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id 21so90693588pgg.1 for ; Sat, 01 Apr 2017 07:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iEq5xQ8wUHG70I3+IbluWQJ1nv25uoFrd1p4XMumD2E=; b=O/EcN77OVV+Yx1B0u3CRkY5PMorXa7C8Nrw2OmzlA7F89QxsKmprXpdrV+K35Z+ypj G+6NHSoNGgpDecO7XWtjXHzzuyAqWmZakKN1cBLWt36s4Tqy+m+8/bcFpnZTLPuMYU7y XlOideBhRvEX8JyCy9dffkCugZetlSGxhtIROFYxIVAMrg3hpMwhEBZMEhjcwVSFy2PP pW6cMKV6aMS/uHKqy822ZC24LZ8xGnVXHk8PeDVsVC/myzYq0mveVuZf5jZ9OIXHdRnU g4KiLawSokpBf1yNZDqo2k/X8l5i/ejvqK6MqkxM3cDNGBgMSC/Zqh8ajOsZxithO28Z qoPA== 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=iEq5xQ8wUHG70I3+IbluWQJ1nv25uoFrd1p4XMumD2E=; b=beyTDn2LeC0SpCIQq+PG+lAa/dqu3lex45gYV8BHYUVl1IfA8wyytnnOAdFNyVfZLS 4CIZbOb3b2IBtmCUY2KULD0BsPrxaU1ALpvNooe6f4BoB8qN48fETVpU5XldnsPWgvrN AteqbxfCULWWSEcrAreUlcottgdhVHE2l2vDjvRGtBkIq9w3GgLrlGYteCLbr95C1b38 dcngqCs0GgUsFc3ws2xLkv+nr4pUxsD6a0rnAJmeivZ20136ZBcqyYH8Fyko0CmHtmkl meG2AJ/lg3W2ncDfjwosIxOn4pKI4fhc39D2LeQFrtetJVOWRTwVDX7KbBff3ntxrijK rBdw== X-Gm-Message-State: AFeK/H3SHwc5scRu9WkdlwQ/IWSamMeHBgRd3RnD86aDaTeJRRGmVJulz4+65m2yBk38HFuXaJbjrpcCqB+QPg== X-Received: by 10.98.89.70 with SMTP id n67mr7644173pfb.224.1491056281964; Sat, 01 Apr 2017 07:18:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.203 with HTTP; Sat, 1 Apr 2017 07:18:00 -0700 (PDT) Received: by 10.100.179.203 with HTTP; Sat, 1 Apr 2017 07:18:00 -0700 (PDT) In-Reply-To: References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> From: Ted Lemon Date: Sat, 1 Apr 2017 09:18:00 -0500 Message-ID: To: Brian E Carpenter Cc: Lorenzo Colitti , IPv6 Ops WG , Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=001a114916f806f95b054c1b9847 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 14:18:04 -0000 --001a114916f806f95b054c1b9847 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, that wasn't my point. The concern I was trying to raise is that the behavior of the in-router stateless DHCP server matters. There is more than one possible behavior. So someone has to write a doc that specifies that. Fernando's doesn't. If we make rdnss MTI, that's relatively safe. If we make DHCP MTI, we have more work to do. On Apr 1, 2017 9:04 AM, "Brian E Carpenter" wrote: > On 01/04/2017 18:16, Lorenzo Colitti wrote: > > On Fri, Mar 31, 2017 at 9:15 PM, Russ White <7riw77@gmail.com> wrote: > > > >> I think the way forward, without continuing to tie ourselves in > >> knots--=F0=9F=98=8A--maybe be this -- simply say both MUST be implemen= ted, > because: > >> > >> - some folks prefer one, other folks prefer the other > >> - I have not heard a single argument from anyone along the lines of > "this > >> is not important, neither needs to be implemented" > >> > > > > That was what draft-gont-v6ops-host-configuration proposed, and there > was > > strong pushback from major host OS developers against making both of > them a > > MUST. Examples: > > > > https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html > > https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html > > > > I think that's unlikely to reach consensus. > > However, it could reach rough consensus, which is sufficient. > > On 02/04/2017 02:06, Ted Lemon wrote: > > > You should read Fernando's draft. It's short. Ask yourself what "must > > support" means in practice. How is it configured? If the router has a > list > > of DNS servers, must it send both rdnss and DHCP versions of that info? > > What if there is centralized DHCP service on the network? Your don't > have > > to ask these questions for rdnss. > > No, but you have to answer the question of what tools are available for > configuring the appropriate DNS server address into the router, which > also varies according to the scenario. Maybe there's already a YANG > module that covers this? But in both cases extra guidance is needed. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114916f806f95b054c1b9847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, that wasn't my point. The concern I was trying= to raise is that the behavior of the in-router stateless DHCP server matte= rs. There is more than one possible behavior. So someone has to write a doc= that specifies that. Fernando's doesn't. If we make rdnss MTI, tha= t's relatively safe. If we make DHCP MTI, we have more work to do.=C2= =A0

On Apr 1= , 2017 9:04 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
On 01/04/2017 18:16, Lorenzo C= olitti wrote:
> On Fri, Mar 31, 2017 at 9:15 PM, Russ White <7riw77@gmail.com> wrote:
>
>> I think the way forward, without continuing to tie ourselves in >> knots--=F0=9F=98=8A--maybe be this -- simply say both MUST be impl= emented, because:
>>
>> - some folks prefer one, other folks prefer the other
>> - I have not heard a single argument from anyone along the lines o= f "this
>> is not important, neither needs to be implemented"
>>
>
> That was what draft-gont-v6ops-host-configuration proposed, and t= here was
> strong pushback from major host OS developers against making both of t= hem a
> MUST. Examples:
>
> https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html
> https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html
>
> I think that's unlikely to reach consensus.

However, it could reach rough consensus, which is sufficient.

On 02/04/2017 02:06, Ted Lemon wrote:

> You should read Fernando's draft. It's short. Ask yourself wha= t "must
> support" means in practice. How is it configured?=C2=A0 If the ro= uter has a list
> of DNS servers, must it send both rdnss and DHCP versions of that info= ?
> What if there is centralized DHCP service on the network?=C2=A0 Your d= on't have
> to ask these questions for rdnss.

No, but you have to answer the question of what tools are available for
configuring the appropriate DNS server address into the router, which
also varies according to the scenario. Maybe there's already a YANG
module that covers this? But in both cases extra guidance is needed.

=C2=A0 =C2=A0Brian

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114916f806f95b054c1b9847-- From nobody Sat Apr 1 07:18: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 C61A7129487 for ; Sat, 1 Apr 2017 07:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 v9PSjysiGeQI for ; Sat, 1 Apr 2017 07:18:37 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::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 37463129426 for ; Sat, 1 Apr 2017 07:18:37 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id e75so4498793itd.1 for ; Sat, 01 Apr 2017 07:18:37 -0700 (PDT) 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=ffXiv2hPiM/nBDfWuRSsUFsF0Nd3v3+5xnz1F1vwGjM=; b=N25B4FXQhFTTttWJz5H5Kka9zKIw64PABFvDN0vgS5LqoBFpzvr+P8PyW6b8SceAW+ 6FlkLiWisK4yqUyeHP0oBhfmfIpOCULshDA+18gb4GUVmFqJiMO1MOZ3rmRwqD2ggDqR GJxPMfCAAEo8ag61j13ldjhlvN8uLYxPKYGO30r/nzKi2F9ArT58YnAv8xVpNxq6nbYG 9VK01o0y4DupVIEY7Qq8CY0p65oG1QYfhf+3Tx/BA8FsAWWuW0gSnNnHsUNWaII4Ckee 22ABMA6BOhag7NSwTm8AVxdDFCsCK7xr3Q+Ou8iHb4W6Dj6xWM/jUob0Sv6KY9Ff1xw3 a04g== 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=ffXiv2hPiM/nBDfWuRSsUFsF0Nd3v3+5xnz1F1vwGjM=; b=D1wOadlpsn3+jzMa0RHI0q92TMCV93/vMnTK2p3fIi99TCCxpIRlO2nDGb7G+Mku4Y P0cqsFYyWPrVlSgJSo1CO7IZQZU2QshG2E1cCubrgFk6g9LEjljI9+In8+bRjiyRhzVX n4hUNq5zJ98ZKB0lpvFWjOIBztqSx+bVUfzq6KYVFdPwSuS+ZsRar19LRwGyDQpXq/m3 J39hgE4JT+6IbSVMZ8TN2Y49eQZENhpBUsqzfZYMbvgTEWLEekE60HEvYJrUIIr4HHtS PxE4Ef9GdtCcz+Lxef4daXfDYO0OHCp5hyYAL3WtWiCtV1ApYX3xfBS6Im/XSjyK5Bip l9KA== X-Gm-Message-State: AFeK/H0g6aCdwuI6ugLWJ6dkk3jw0dlUbzTyYtn/lV/ZYgUCCSQqoKLF Nn0P2kR7ZC4+ig== X-Received: by 10.36.215.194 with SMTP id y185mr2781648itg.101.1491056316642; Sat, 01 Apr 2017 07:18:36 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id w188sm2988173itc.6.2017.04.01.07.18.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 07:18:36 -0700 (PDT) To: Ross Chandler References: <020401d2a96c$0d320630$27961290$@gmail.com> <03a118c6-e352-6f01-5283-46f4ff54727e@isi.edu> <018501d2aa8a$f1137a40$d33a6ec0$@gmail.com> <7c09ccb9-5971-3f5b-ac07-62622814be4a@isi.edu> <00a401d2aada$c3492970$49db7c50$@gmail.com> <00dc02da-0aef-4e38-26af-501b98514ed5@gmail.com> <0633EBDF-7953-44CF-A78F-FE0BC6DE10D6@eircom.net> Cc: IPv6 Ops WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <16a088b6-1da4-365f-248d-11334817bb95@gmail.com> Date: Sun, 2 Apr 2017 02:18:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0633EBDF-7953-44CF-A78F-FE0BC6DE10D6@eircom.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 14:18:39 -0000 On 02/04/2017 02:35, Ross Chandler wrote: >=20 >> On 1 Apr 2017, at 14:11, Brian E Carpenter wrote: >> >> To support automated network device configuration, IPv6 routers and >> network devices SHOULD support YANG and SNMP configuration, includin= g >> (but not limited to): >> >> The only quibble with that sentence is that it seems to recommend SNMP= SET. >> I understood that SNMP was only use for monitoring in practice, >> as mentioned later under 'Telemetry'. >=20 > If you are talking about the present situation, SNMP is used for config= uration.=20 > At least one widely used router vendor=E2=80=99s element manager is dep= endent on it. Interesting. But given that SNMP SET is generally not recommended these d= ays, shouldn't the draft indicate that this is a legacy solution rather than a= SHOULD? Brian=20 From nobody Sat Apr 1 07:30: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 600A4129489 for ; Sat, 1 Apr 2017 07:30:04 -0700 (PDT) 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 XpR0WF7nGGhX for ; Sat, 1 Apr 2017 07:30:01 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::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 B7906129353 for ; Sat, 1 Apr 2017 07:30:01 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id e75so4516088itd.1 for ; Sat, 01 Apr 2017 07:30:01 -0700 (PDT) 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=0nZUndsdQ7pRDihy4ZuUjwdAQ2azntX07avPuz4EdxU=; b=nSepnkO94eGJl1ingfXgnT89nWwt5oJMDcu9Kh3PnkkF9AX9DpsXIWyCfcYQh1jroa 4PYeHK/dBmTYhO3UXUHDW9XDWC5LSIKRiRPBV7OwLyNPdg+Hq9Ef68CcHl7fp2DBkbxu 1/Ry9kDGC1l3PwN1B0j4GtYbAH8AA/E1mQBD7quXAoeUWkhynGWlfLDx6Rlp7pRaT/pI Dsd2t1sPPD2R25hsBk7+JT2qmWOkiNRecINua6YXdRfiik3FuATn+fTM0j6F/euy5eVt JsZghFoQJyAZRpi2uGw/ndspf0Cuou2fR9hT0IKGmAEnbreDeEsI6HBG5QOgBFjacI6P FYww== 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=0nZUndsdQ7pRDihy4ZuUjwdAQ2azntX07avPuz4EdxU=; b=GI432KYsSOSgWkxqioE7dJM0lZishGQ/0kAnpYIDR2CAveQ7QI88vHJCh2QISJjbzJ QcjN4TDvdU2WNCDZk9Cqy82+yzf3oblHtkVo93u5zIifcBlYqZ9iuPNTOBr3KaY0zS/j o7d8PHeyw7t83/WL07KvPQchubcVZ2MAoIYSRK+bpPGGGWWokUC0gboNluFSPxDt9SfK fjKOtlBeZqXvdDx17d1FkdMa2tUe89XPr9LZMIeIggUIXtaG/+vkdwc8LC7uE1N/B3VO VBW4P67r7f48LJggYdhQT6SKsvTTHiEAnX4oDtGwQGKK6fUuARD3hdfwUY3uAy5S6AbR xNQQ== X-Gm-Message-State: AFeK/H2sSWMrc59okyWpRLdpdOUE97fuv64Vil2sUPJQhW7k+bLXkNL6 aahWTGv8KB3RuA== X-Received: by 10.36.242.130 with SMTP id j124mr2733022ith.9.1491057001060; Sat, 01 Apr 2017 07:30:01 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id l198sm2995428ita.10.2017.04.01.07.30.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 07:30:00 -0700 (PDT) To: Ted Lemon References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> Cc: Lorenzo Colitti , IPv6 Ops WG , Russ White <7riw77@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 2 Apr 2017 02:29:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 14:30:04 -0000 On 02/04/2017 02:18, Ted Lemon wrote: > Sorry, that wasn't my point. The concern I was trying to raise is that = the > behavior of the in-router stateless DHCP server matters. There is more = than > one possible behavior. So someone has to write a doc that specifies tha= t. > Fernando's doesn't. If we make rdnss MTI, that's relatively safe. If we= > make DHCP MTI, we have more work to do. That sounds like work that needs to be done anyway. Brian >=20 > On Apr 1, 2017 9:04 AM, "Brian E Carpenter" > wrote: >=20 >> On 01/04/2017 18:16, Lorenzo Colitti wrote: >>> On Fri, Mar 31, 2017 at 9:15 PM, Russ White <7riw77@gmail.com> wrote:= >>> >>>> I think the way forward, without continuing to tie ourselves in >>>> knots--=F0=9F=98=8A--maybe be this -- simply say both MUST be implem= ented, >> because: >>>> >>>> - some folks prefer one, other folks prefer the other >>>> - I have not heard a single argument from anyone along the lines of >> "this >>>> is not important, neither needs to be implemented" >>>> >>> >>> That was what draft-gont-v6ops-host-configuration proposed, and there= >> was >>> strong pushback from major host OS developers against making both of >> them a >>> MUST. Examples: >>> >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html >>> >>> I think that's unlikely to reach consensus. >> >> However, it could reach rough consensus, which is sufficient. >> >> On 02/04/2017 02:06, Ted Lemon wrote: >> >>> You should read Fernando's draft. It's short. Ask yourself what "must= >>> support" means in practice. How is it configured? If the router has = a >> list >>> of DNS servers, must it send both rdnss and DHCP versions of that inf= o? >>> What if there is centralized DHCP service on the network? Your don't= >> have >>> to ask these questions for rdnss. >> >> No, but you have to answer the question of what tools are available fo= r >> configuring the appropriate DNS server address into the router, which >> also varies according to the scenario. Maybe there's already a YANG >> module that covers this? But in both cases extra guidance is needed. >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 From nobody Sat Apr 1 07:40: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 86F9A1294D1 for ; Sat, 1 Apr 2017 07:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 KOdB_46cfQyY for ; Sat, 1 Apr 2017 07:40:16 -0700 (PDT) Received: from mta05.svc.cra.dublin.eircom.net (mta05.svc.cra.dublin.eircom.net [159.134.118.221]) by ietfa.amsl.com (Postfix) with SMTP id 399E1129407 for ; Sat, 1 Apr 2017 07:40:14 -0700 (PDT) Received: (qmail 23961 messnum 7340092 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 1 Apr 2017 14:40:13 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (HELO avas02) (213.94.190.14) by mta05.svc.cra.dublin.eircom.net (qp 23961) with SMTP; 1 Apr 2017 14:40:13 -0000 Received: from [192.168.1.2] ([86.45.37.172]) by Cloudmark Gateway with SMTP id uKCLcQP80uAvEuKCLcmW8x; Sat, 01 Apr 2017 15:40:13 +0100 X-CNFS-Analysis: v=2.2 cv=D6s3ErZj c=1 sm=1 tr=0 a=K7PZQZnhnIzjjF0D3pxPpg==:117 a=K7PZQZnhnIzjjF0D3pxPpg==:17 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=NcBwRvjv_QZv6UqQKeIA:9 a=c-K_j-9_zQBej55k:21 a=_W_S_7VecoQA:10 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: text/html; charset=utf-8 X-Apple-Base-Url: x-msg://3/ X-Apple-Mail-Remote-Attachments: YES From: Ross Chandler In-Reply-To: <16a088b6-1da4-365f-248d-11334817bb95@gmail.com> X-Apple-Windows-Friendly: 1 Date: Sat, 1 Apr 2017 15:38:45 +0100 Cc: IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <5BE58B29-1733-4659-A84C-CFD0DF5CCC68@eircom.net> References: <020401d2a96c$0d320630$27961290$@gmail.com> <03a118c6-e352-6f01-5283-46f4ff54727e@isi.edu> <018501d2aa8a$f1137a40$d33a6ec0$@gmail.com> <7c09ccb9-5971-3f5b-ac07-62622814be4a@isi.edu> <00a401d2aada$c3492970$49db7c50$@gmail.com> <00dc02da-0aef-4e38-26af-501b98514ed5@gmail.com> <0633EBDF-7953-44CF-A78F-FE0BC6DE10D6@eircom.net> <16a088b6-1da4-365f-248d-11334817bb95@gmail.com> X-Uniform-Type-Identifier: com.apple.mail-draft To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfGWBRDm3a3lNzzgK25umHrmbaa2YFro5AnI21i2FuHNmp14aA9S9l/uNXt7stKKQIQAyYZKmnUjU9P9+d8wRT2ITKj9uczGBUcAJrG0Jb6KmR02HDlSg raaVDuL4HKq6O76YodFm68QmU7SN0WZ2wMtSQlGDyOb2qMGbONESooUiMuvmJm62CUnUHUHzYCbDwANHneWoWL95rcVCHENh1zw= Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 14:40:17 -0000

On 1 Apr = 2017, at 15:18, Brian E Carpenter <brian.e.carpenter@gmail.com> = wrote:

If you are talking about the = present situation, SNMP is used for configuration.
At least one = widely used router vendor=E2=80=99s element manager is dependent on = it.

Interesting. But given that SNMP SET is = generally not recommended these days,
shouldn=E2=80=99t the draft = indicate that this is a legacy solution rather than a = SHOULD?

In the case of this manager all the SNMP = configuration is done either from manual changes in the gui or via an = XML based API into it.
So I don=E2=80=99t see a problem with SNMP = only being a MAY.  As I understand it the roadmap for the vendor is = to support YANG in router and = manager.

Ross


= From nobody Sat Apr 1 07:45: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 1D831129477 for ; Sat, 1 Apr 2017 07:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 EBElZYS4_uvt for ; Sat, 1 Apr 2017 07:45:08 -0700 (PDT) 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 A964412945B for ; Sat, 1 Apr 2017 07:45:07 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id d64so8940672uad.2 for ; Sat, 01 Apr 2017 07:45:07 -0700 (PDT) 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=X+V3bBU38oJVQSgZ7NDO5Sajeb1uWhVRWZZyaN2Ho7k=; b=MmiedzHCCbg55ZgRzK9/+ar0u3c2SzNabK83EQL6JRhdZwxHDjJLjp9HpVLuyQdcFw d0nBd+ErUayNRkTtPiu5MoIds4mLgMA/PdIOnigLvaAJcAYXxtRC+ce1unH6noTuRqlG ourQB8usR04ItVBzxqBjwlr4tknOZLo9Ga78kb1OSTgVxpbWV2KMIkg+2nkwX656Ta2M ukF0E94gnIGgtZyn40Uq9YashGIfVrzi/ZMPbM5kRm3IEcSPUeJAJnlokTvGKjNQIgAJ jApy22mQlS7C79gACk43822k7/H8Yvru2LILbhPyIVB73F82MUKZOnnTEoZbyPki4NVG 3nJA== 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=X+V3bBU38oJVQSgZ7NDO5Sajeb1uWhVRWZZyaN2Ho7k=; b=FsTH8OrTILxxojBMd4R0jJs7nb/aZck7Qw/aoRCsRE4DxXFtd81h6CjL0hKAYLY1CM 8L44VQ0xUiqLiFZjdXYw3XMo9XY5Nhj3qoUIqO4t3kaWoJIfs8Qe4J1uChloVHZRnbya ir+l3fQKAI7sn84oZPtJLhfN/4b6mjWFWO2D2YwjrX0MXwB4Tbc5b07CJs8vHf4g/+R0 PQMXV4pDMEualTXNT73geMZzAhbmOHFiWabGph1+biAdnhxuLrFJQgbcaJEgkFCCPbht 3ZyBKENSnSRij/FFhMn8Wx52Vh+PVlGR4TLjlYjsz2/Q9T2tV5q3YeWVeo5I6HzJFUWD vhUw== X-Gm-Message-State: AFeK/H2CLChr0sHYrGx8mXLvMQxUK+ta0L4fFDlnkcqrsgKtaj8l+Q0XPQSI4knMsiw6SuW3zJMA59ccQ94iJfbA X-Received: by 10.159.52.198 with SMTP id b6mr3782160uac.155.1491057906369; Sat, 01 Apr 2017 07:45:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Sat, 1 Apr 2017 07:44:45 -0700 (PDT) In-Reply-To: References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> From: Lorenzo Colitti Date: Sat, 1 Apr 2017 09:44:45 -0500 Message-ID: To: Brian E Carpenter Cc: Russ White <7riw77@gmail.com>, Gert Doering , Fred Baker , IPv6 Ops WG Content-Type: multipart/alternative; boundary=f403045e2a5ad9c985054c1bf88e Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 14:45:10 -0000 --f403045e2a5ad9c985054c1bf88e Content-Type: text/plain; charset=UTF-8 On Sat, Apr 1, 2017 at 9:04 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > That was what draft-gont-v6ops-host-configuration proposed, and there > was > > strong pushback from major host OS developers against making both of > them a > > MUST. Examples: > > > > https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html > > https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html > > > > I think that's unlikely to reach consensus. > > However, it could reach rough consensus, which is sufficient. > It's always possible that a document that mandates hosts to implement something is going to reach rough consensus even though a) the developers of major host OS implementations have said they can't live with it, and b) the current state of affairs has persisted for many years. But I don't think that's likely enough to be a good use of the working group's time. Making RDNSS a MUST is an equally valid solution to the problem posed by draft-gont-v6ops-host-configuration ("there is no single protocol that works everywhere"), and seems much more likely to reach rough consensus. --f403045e2a5ad9c985054c1bf88e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 1, 2017 at 9:04 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
> That was = what draft-gont-v6ops-host-configuration proposed, and there was
> strong pushback from major host OS developers against making both of t= hem a
> MUST. Examples:
>
> https://www.ietf.org/mail-arch= ive/web/v6ops/current/msg25536.html
> https://www.ietf.org/mail-arch= ive/web/v6ops/current/msg25583.html
>
> I think that's unlikely to reach consensus.

However, it could reach rough consensus, which is sufficient.

It's always possible that a document that= mandates hosts to implement something is going to reach rough consensus ev= en though a) the developers of major host OS implementations have said they= can't live with it, and b) the current state of affairs has persisted = for many years. But I don't think that's likely enough to be a good= use of the working group's time.

Making RDNSS= a MUST is an equally valid solution to the problem posed by=C2=A0draft-gon= t-v6ops-host-configuration ("there is no single protocol that wor= ks everywhere"),=C2=A0and seems much more likely to reach rough consen= sus.
--f403045e2a5ad9c985054c1bf88e-- From nobody Sat Apr 1 09:08: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 556F5126E3A for ; Sat, 1 Apr 2017 09:08:45 -0700 (PDT) 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 RmNkh_3HooHy for ; Sat, 1 Apr 2017 09:08:43 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::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 B1978126C26 for ; Sat, 1 Apr 2017 09:02:46 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id y18so4660715itc.2 for ; Sat, 01 Apr 2017 09:02:46 -0700 (PDT) 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=ItXW61e5JBrFD2mO9oV4aeSp5MsLijOQQiXn9vQxqjw=; b=J6EkOHduuu5PEobHzmC3mwzT5XNLKsugZO3haI1HjBnOcx73aoa7d/rMxmvBz1QMnr M+AFjHU0r2CIx5nraMxjN3z6odkVNw5VV94bXAIuGpitE54EO/jtWfUCOJXXIFSUKCoi ZetuF/4cW5nv43G1w65SctCo/NWpQFdPDIIK7GOZ2hrGpkDqx62kmgASyztBFuRYr7fs R/Mx7JaAXb+/GnGc4tUZ6c6MSf+oRjFHDwim6EuwVYe+ICdutG8FQeh6cnpBdWrSrPjI HBxQ/08iJJ4drD7ddrNOGdFdwKecGpTIN6L/MaIoU+TX/W260/5nnKrYgbQN9bO0V8N1 HKNw== 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=ItXW61e5JBrFD2mO9oV4aeSp5MsLijOQQiXn9vQxqjw=; b=tkznmxu5p2nh0sgfZnqC49/gRYT2OCNmdm5P+O2TgVCMQqzz9XnJ0+uQvbGf0/G55+ 5I87OvLMUfx6pxt64VUDDRdRvzlByaCzobCG0iu2ucF0ExVy4MA48YyFgYeQCjA3LBoV 1XZ53eDyVT8gLvNvvvh3CoCuZo61c2hgYz064HuEFqzzvoC2L/G/UO4JrhWlZ10Tj4Ue lBh60hnlP29Gi6/BHwccD0UQ6W41nIGvP55Kf6jF/FVtG+vj2iffzlucqr2bnuuzKRS7 bHf9n7oXZA8Mr5BvsTPqSGlGikLI7jyftyNIR8jwlh2I36S22hlVpkryzr4zVUZk1r3f Ev0g== X-Gm-Message-State: AFeK/H37QOFOEDPpcLyq/835J1xTFlt85lPGewDjXAIvGNuSJC1fm3UO xOG5p63ySBioxw== X-Received: by 10.36.107.214 with SMTP id v205mr3191635itc.65.1491062566064; Sat, 01 Apr 2017 09:02:46 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id l5sm3098817ita.13.2017.04.01.09.02.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 09:02:45 -0700 (PDT) To: Lorenzo Colitti References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> Cc: Russ White <7riw77@gmail.com>, Gert Doering , Fred Baker , IPv6 Ops WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <99c8207a-ab98-01d6-2f47-83f1d72bf249@gmail.com> Date: Sun, 2 Apr 2017 04:02:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 16:08:45 -0000 On 02/04/2017 02:44, Lorenzo Colitti wrote: > On Sat, Apr 1, 2017 at 9:04 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> That was what draft-gont-v6ops-host-configuration proposed, and there >> was >>> strong pushback from major host OS developers against making both of >> them a >>> MUST. Examples: >>> >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html >>> >>> I think that's unlikely to reach consensus. >> >> However, it could reach rough consensus, which is sufficient. >> > > It's always possible that a document that mandates hosts to implement > something is going to reach rough consensus even though a) the developers > of major host OS implementations have said they can't live with it, and b) > the current state of affairs has persisted for many years. But I don't > think that's likely enough to be a good use of the working group's time. > > Making RDNSS a MUST is an equally valid solution to the problem posed > by draft-gont-v6ops-host-configuration ("there is no single protocol that > works everywhere"), and seems much more likely to reach rough consensus. I was actually arguing that making them both a MUST implement is "more" valid because it increases that chance that an arbitrary host will work on an arbitrary network. We all know that product managers and open source developers are not overly impressed by MUSTs and SHOULDs anyway. So personally I'd be part of the consensus for pretty much any set of MUSTs and SHOULDs. Fill in the matrix as you prefer: ---------------------------- | | host | router | ---------------------------- |RDNSS | MUST | MUST | ---------------------------- |DHCPv6| MUST | MUST | ---------------------------- Brian From nobody Sat Apr 1 12:27: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 3A014129669 for ; Sat, 1 Apr 2017 12:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 L4odndQrD2Xp for ; Sat, 1 Apr 2017 12:27:46 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1782129450 for ; Sat, 1 Apr 2017 12:27:45 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v31JRegh008369 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Apr 2017 20:27:40 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58DFFF2C.5080902@foobar.org> Date: Sat, 01 Apr 2017 20:27:40 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.12 (Macintosh/20170323) MIME-Version: 1.0 To: Brian E Carpenter CC: IPv6 Ops WG References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> <99c8207a-ab98-01d6-2f47-83f1d72bf249@gmail.com> In-Reply-To: <99c8207a-ab98-01d6-2f47-83f1d72bf249@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 19:27:48 -0000 Brian E Carpenter wrote: > ---------------------------- > | | host | router | > ---------------------------- > |RDNSS | MUST | MUST | > ---------------------------- > |DHCPv6| MUST | MUST | > ---------------------------- dhcpv6 service support on the router itself is troublesome due to the configuration complexity and lease management requirements of dhcpv6 (think: flash storage with limited number of writes, arcane / non-flexible CLI interfaces, etc). I would also argue it's unnecessary because most people use servers to handle dhcpv6 service, with relays for non link-local requests. Anyway, DHCP cannot feasibly be provisioned on non-trivial sized networks without relay support. Therefore, I'd suggest: > ---------------------------- > | | host | router | > ---------------------------- > |RDNSS | MUST | MUST | > ---------------------------- > |DHCPv6| MUST | MAY | > ---------------------------- > |Relay | n/a | MUST | > ---------------------------- Nick From nobody Sat Apr 1 13:13: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 3C0D1129573 for ; Sat, 1 Apr 2017 13:13:01 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 iSRNDKTbVeJE for ; Sat, 1 Apr 2017 13:12:59 -0700 (PDT) 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 336C3128CD5 for ; Sat, 1 Apr 2017 13:12:58 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1BB4361CB8 for ; Sat, 1 Apr 2017 22:12:56 +0200 (CEST) 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 D0FEE61C2E; Sat, 1 Apr 2017 22:12:55 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id C2E997068E; Sat, 1 Apr 2017 22:12:55 +0200 (CEST) Date: Sat, 1 Apr 2017 22:12:55 +0200 From: Gert Doering To: Nick Hilliard Cc: Brian E Carpenter , IPv6 Ops WG Message-ID: <20170401201255.GG25069@Space.Net> References: <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> <99c8207a-ab98-01d6-2f47-83f1d72bf249@gmail.com> <58DFFF2C.5080902@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58DFFF2C.5080902@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 20:13:01 -0000 Hi, On Sat, Apr 01, 2017 at 08:27:40PM +0100, Nick Hilliard wrote: > Brian E Carpenter wrote: > > ---------------------------- > > | | host | router | > > ---------------------------- > > |RDNSS | MUST | MUST | > > ---------------------------- > > |DHCPv6| MUST | MUST | > > ---------------------------- > > dhcpv6 service support on the router itself is troublesome due to the > configuration complexity and lease management requirements of dhcpv6 Maybe we should strongly differenciate between stateless DHCPv6 and IA_NA here...? > (think: flash storage with limited number of writes, arcane / > non-flexible CLI interfaces, etc). I would also argue it's unnecessary > because most people use servers to handle dhcpv6 service, with relays > for non link-local requests. Anyway, DHCP cannot feasibly be > provisioned on non-trivial sized networks without relay support. I disagree for state*less*. Which is perfectly fine for DNS info. 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 Apr 1 14:30: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 C23E1124D6C for ; Sat, 1 Apr 2017 14:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 uhjgxi7mad2k for ; Sat, 1 Apr 2017 14:30:03 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 0BA6012714F for ; Sat, 1 Apr 2017 14:30:02 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 190so27404455itm.0 for ; Sat, 01 Apr 2017 14:30:02 -0700 (PDT) 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=X/GkaMIKaCIVGFNQ6N/99uB80GjdKKVBzqj+dR5/xG0=; b=1kbzIuYw/RGFdO3tI83tH5bVK/i48HZPGYsg42BsJWpsuxVZuaAi/S9QY/Vh8EqPzL vpVJgVxTGUHPCF+zc2IRBiPq33foOzTi1EZcHdM/7dBtWusCD9w1f64Ubp5A4EFvvflQ 4EJbF8yRrz9X7QE3+Z76duR1DxUHsUoJpF/Wqdcy2c7srGYa679UN6ivAGkygd+5VCWG PdJqUKxFwFCYP7AnKdyciKmfD4wt5xUCvmlwMmWcuynHO+2kFO/YekIO3eI2voPewmDC AY5HmSvzvDpfURuf+ioGO7szL0uRs++s2VrFIEexel80z6hdxNib6bzk3+4MGb5xL0Gc fC0w== 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=X/GkaMIKaCIVGFNQ6N/99uB80GjdKKVBzqj+dR5/xG0=; b=JskGoHQWj8Lko8HoTa51rgLC740PsrIkKgCLUPYhKZYyWz2dRlcRXPVvd3J7WsVP7h jKw4OdM60xvOEarBD48JP8uEYWr4rBJmORJ3AMfDbcuQb6Y7FMynfVzPbwRpAw3ZsRdx xdlOWTmHFH907qQeAc50RrCWV0XFjdSbdkB2g3t0mEW8J5B/l/6MqLmACeWhVi7rU0QJ 3BRTzx5fKjUngxng62ehbfXZ0VvTHvOrU2N2dHlH19KNtUktRJodCVNMNo/iEQaou08K H6MSur4ZFxkFIiF7vHzeeKIec5lr1qna+hlPVQ+eZ13+NjlZoUcBXaV6WmduVBhnyGP/ JcLw== X-Gm-Message-State: AFeK/H0WV9ltkIEbBxgls66pyRziHoGbihz65llBdrjkYfIxcVlFVvZC 3iZnjg1SnrXDEA== X-Received: by 10.36.129.133 with SMTP id q127mr4065875itd.89.1491082202251; Sat, 01 Apr 2017 14:30:02 -0700 (PDT) Received: from [172.19.131.126] ([12.130.117.95]) by smtp.gmail.com with ESMTPSA id m125sm5309156iom.38.2017.04.01.14.30.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 14:30:01 -0700 (PDT) From: Ted Lemon Message-Id: <99C92290-AC04-48CF-8FD0-7040AF749D3F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A27524F5-0A1C-4F08-AC8C-1875390E94BA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 1 Apr 2017 16:29:56 -0500 In-Reply-To: Cc: Lorenzo Colitti , IPv6 Ops WG , Russ White <7riw77@gmail.com> To: Brian E Carpenter References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 21:30:05 -0000 --Apple-Mail=_A27524F5-0A1C-4F08-AC8C-1875390E94BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 1, 2017, at 9:29 AM, Brian E Carpenter = wrote: > That sounds like work that needs to be done anyway. Right now it's not mandatory, so there's no need to specify what is = mandatory. We give you the tools, you use them if you want, you decide = how to use them. If we make it mandatory, we have to say what the = mandatory behavior is. Just "support stateless DHCPv6" is not = sufficient. --Apple-Mail=_A27524F5-0A1C-4F08-AC8C-1875390E94BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 1, 2017, at 9:29 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
That sounds like work that needs to be = done anyway.

Right now it's not mandatory, so there's no = need to specify what is mandatory.   We give you the tools, you use = them if you want, you decide how to use them.   If we make it = mandatory, we have to say what the mandatory behavior is.   Just = "support stateless DHCPv6" is not sufficient.

= --Apple-Mail=_A27524F5-0A1C-4F08-AC8C-1875390E94BA-- From nobody Sat Apr 1 16:41: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 3D675128616 for ; Sat, 1 Apr 2017 16:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKOUtJixNFvG for ; Sat, 1 Apr 2017 16:41:13 -0700 (PDT) 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 5D6F6124217 for ; Sat, 1 Apr 2017 16:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491090071; bh=KVJNPc2W/8IAArm5KbyRXLGesxhf9vD1z6YlkwM82vw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VUOh2tHQn6pzAm/ZUlEQ+zWDnkTHTUa+k/dQm5MEqcECDoIcm67i05DJtgi651WN+W8Jq00F4DHIYTbF3qzaDnkV9kSR1T5f4+rN6HHIxgXdkmYIZ3GtmGCFGPMTGchKcGak0eOK37+cKmKwbG+XBSnPtW3rbqkOz4M1/qaMMcI= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0148.outbound.protection.outlook.com [213.199.180.148]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-72-f7EOczc7M2Wzp2ekIznvzw-1; Sun, 02 Apr 2017 00:41:08 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Sat, 1 Apr 2017 23:41:06 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.009; Sat, 1 Apr 2017 23:41:06 +0000 From: Tim Chown To: Brian E Carpenter CC: v6ops list Thread-Topic: [v6ops] Outcomes from v6ops@IETF98 Thread-Index: AQHSqMzOl2pKnVBvckyLliBC42JP2KGvfgiAgAGzOwA= Date: Sat, 1 Apr 2017 23:41:06 +0000 Message-ID: References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> In-Reply-To: <8365a4e0-d317-ed3c-59b3-2e829ff210f3@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:20f3:cb50:43dc:997a] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:rre9mSRc9Nnndig/VwZtcQYCTj+mz3Gnz1iquRUSgMUPHf1e0t0S6TuDyb50JatnMKhqJhe9dqanpvsG0xgmvCIplAm7Q36qt2glU1IjYynkDQYtNnGRvCCX3IU7NFDUnBgKI75JwU+PUMMwZ3vduDLiEPN0hh03ZJrzEKNvA01VUIfy1zBvOvQioNAi+NRLRaP/6fFHb+krycPMaSMZ68pPtIkstG5x6LxM3fYvrM6MktZpoe72Dyu8Fei2dS4O+wTn1CeX0J6XInSaOWT3e5pLJ0thSRQfkOkEKOhox69tI2t+QUCzmzei/W/bvaO270h/dNrV+C9qOAFTMDlgSQ==; 20:MRGjL8U6OlsaZ14rmc0d72GavmdCBSMvMfQg1WOuvrjiJ6ECCeDpRzGybjA4rtCuCE6mfmvn+j9yAqMcgAMKDhLR2WDKhsjQfuVSDqyLS0l2nKrK6dV6KzR4XHcMxpEN+lajRE1VwhMuK3AiRcHflWUss861YUUHmS63LTKOKuw= x-ms-office365-filtering-correlation-id: 476806d6-969e-4c53-10fe-08d4795890f4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(4326008)(25786009)(53546009)(8676002)(53936002)(6512007)(83716003)(39060400002)(305945005)(99286003)(57306001)(6436002)(50226002)(6506006)(38730400002)(110136004)(6486002)(8936002)(81166006)(6246003)(6116002)(3660700001)(2906002)(102836003)(6916009)(2950100002)(42882006)(229853002)(74482002)(33656002)(189998001)(82746002)(5250100002)(2900100001)(7736002)(5660300001)(36756003)(76176999)(3280700002)(5890100001)(86362001)(50986999)(32563001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <5E0121098D10FC428DB79ABA7B6E5F0B@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2017 23:41:06.0673 (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: f7EOczc7M2Wzp2ekIznvzw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 23:41:15 -0000 SGksDQoNCj4gT24gMzEgTWFyIDIwMTcsIGF0IDIyOjQzLCBCcmlhbiBFIENhcnBlbnRlciA8YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIDMwLzAzLzIwMTcgMDk6 NDAsIEZyZWQgQmFrZXIgd3JvdGU6DQo+PiBJIGhhdmUgYXR0YWNoZWQgYSBwZGYgb2YgdGhlIHBy b3Bvc2VkIGNoYXJ0ZXIgYXMgaXQgZW5kZWQgdGhpcyBhZnRlcm5vb24uIEkgaW52aXRlIHB1Ymxp YyBjb21tZW50YXJ5ICh0byB2Nm9wc0BpZXRmLm9yZyksIGFuZCBpZiB5b3Ugc3VwcG9ydCB1c2lu ZyBpdCBhcyBpdCBzdGFuZHMsIHBsZWFzZSBzYXkgc28uLg0KPiANCj4gTG9va3MgZ29vZCB0byBt ZS4NCj4gDQo+PiBPbmUgcXVlc3Rpb24gSSBpbnRlbmRlZCB0byBhc2sgYW5kIGRpZG4ndCBnZXQg dG8gd2FzIHRoZSBhcHByb3ByaWF0ZW5lc3Mgb2YgYW4gaW50ZXJpbSBtZWV0aW5nLCBwZXJoYXBz IGluIG1pZC1NYXkuIEl0IHdvdWxkIHByaW1hcmlseSBhZGRyZXNzIGRyYWZ0LWlldGYtdjZvcHMt dWxhLXVzYWdlLWNvbnNpZGVyYXRpb25zIGFuZCBkcmFmdC1wZXRyZXNjdS12Nm9wcy1pcHY2LXBv d2VyLWlwdjQsIGFuZCBwb3RlbnRpYWxseSBkcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2Vz IGlmIGl0IGlzIHVwZGF0ZWQuIFRoZXJlIGlzIGFuIGFyZ3VtZW50IGZvciBsZWF2aW5nIHRoZXNl IHRvIElFVEYgOTksIGFuZCBwb3RlbnRpYWxseSBib29raW5nIGEgc2Vjb25kIHNsb3QgZm9yIHRo YXQgZGlzY3Vzc2lvbi4gWW91ciBvcGluaW9ucz8NCj4gDQo+IEkgZmluZCBpdCBoYXJkIHRvIGFu c3dlciB3aXRob3V0IHNlZWluZyBhIGxpc3Qgb2Ygb3BlbiBpc3N1ZXMgZm9yIGVhY2ggZHJhZnQu DQoNClNlY29uZGVkLiBJcyB0aGUgaW50ZW50aW9uIGEgcGh5c2ljYWwgb3IgdmlydHVhbCBtZWV0 aW5nLCBvciBib3RoPw0KDQo+PiBXZSBoYXZlIHR3byBXR0xDcyBpbiBwcm9ncmVzcyBvciBhYm91 dCB0byBiZSBzby4gVGhlIFdHTEMgb24gZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3QsIHdoaWNoIFJvbiBvcGVuZWQgb24gMTQgTWFyY2gsIHdpbGwgZW5kIG9uIDkg QXByaWwuIFdlIHdpbGwgdGhlbiBvcGVuIGEgV0dMQyBvbiBkcmFmdC1pZXRmLXY2b3BzLXY0djYt eGxhdC1wcmVmaXgsIHRvIGVuZCAyMyBBcHJpbC4NCj4+IA0KPj4gSSBiZWxpZXZlIHRoYXQgdGhl IGRpc2N1c3Npb24gdG9kYXkgc3VwcG9ydGVkIGFkb3B0aW9uIG9mIHRoZSBmb2xsb3dpbmcgYXMg d29ya2luZyBncm91cCBkcmFmdHM6DQo+PiBkcmFmdC1hbGktaXB2NnJ0ci1yZXFzIChhcyBkcmFm dC1pZXRmLXY2b3BzLWlwdjZydHItcmVxcykNCj4+IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzcwODQt YmlzIChhcyBkcmFmdC1pZXRmLXY2b3BzLXJmYzcwODQtYmlzKQ0KPj4gZHJhZnQtcGF1bHktdjZv cHMtaGFwcHktZXllYmFsbHMtdXBkYXRlIChhcyBkcmFmdC1pZXRmLXY2b3BzLWhhcHB5LWV5ZWJh bGxzLXVwZGF0ZSkNCj4gDQo+IEknbSBPSyB3aXRoIGFkb3B0aW5nIGFsbCB0aHJlZS4gSSB0aGlu ayBmcm9tIHRoZSBkaXNjdXNzaW9uIHRoYXQgaGFwcHktZXllYmFsbHMtdXBkYXRlDQo+IHNob3Vs ZCBwZXJoYXBzIGJlIG5hbWVkIGRpZmZlcmVudGx5LCB3aXRoIEludGVuZGVkIHN0YXR1czogSW5m b3JtYXRpb25hbCwgc2luY2UNCj4gcHV0dGluZyBpdCBvbiB0aGUgc3RhbmRhcmRzIHRyYWNrIHdv dWxkIHByb2JhYmx5IHRha2Ugc29tZSBoZWF2eSBsaWZ0aW5nLiBBcyBhDQo+IHJlcG9ydCBvbiBl bmhhbmNlbWVudHMgaXQgY291bGQgcHJvZ3Jlc3MgcXVpY2tseS4NCg0KQWdyZWVkLiANCg0KSSBy ZWFsbHkgbGlrZSB0aGUgdXBkYXRlZCBoYXBweSBleWViYWxscyBkb2N1bWVudC4gSG93IGFib3V0 IOKAnEhhcHB5IElQcyBUb3dhcmRzIEVuaGFuY2VkIFJlc2lsaWVuY2XigJ0gb3IgSElQc1RFUj8g IA0KDQpUaW0= From nobody Sat Apr 1 16:55: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 269B81274D0 for ; Sat, 1 Apr 2017 16:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bofpWTXAeft2 for ; Sat, 1 Apr 2017 16:55:51 -0700 (PDT) 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 E4121124217 for ; Sat, 1 Apr 2017 16:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491090949; bh=JLpVirUu/X57m5lYbFHxtJW4o/IusLLqu8CZ0MJLeK4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KwTDYB1S9uMykFJtueQRAqLcy4BsJYss0+f7alQ7Fl4V72w6rtvR77orv8HEljH+afTu4K0sWssO9a3m+531bxVUCev4D7ugAPlfAEDvw1DxnayeAzsNLOklfXDXFW94UTseCkCz21ECwktyw1sdOgovTZifxMHgb/sHZVRZRy0= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0146.outbound.protection.outlook.com [213.199.154.146]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-38-3MBalUJ7NyC3k1NEOCCrgg-1; Sun, 02 Apr 2017 00:55:45 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Sat, 1 Apr 2017 23:55:43 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.009; Sat, 1 Apr 2017 23:55:43 +0000 From: Tim Chown To: Russ White <7riw77@gmail.com> CC: Joe Touch , Ron Bonica , IPv6 Ops WG Thread-Topic: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 Thread-Index: AQFgkFfbJAUmSx69OkO5wODN0Nb9M6KRsm5AgAGJrICAAB9QgIAAmcYAgAFxEQA= Date: Sat, 1 Apr 2017 23:55:43 +0000 Message-ID: <4ED7131F-791C-4321-AAF3-99FB9370FDCF@jisc.ac.uk> References: <020401d2a96c$0d320630$27961290$@gmail.com> <03a118c6-e352-6f01-5283-46f4ff54727e@isi.edu> <018501d2aa8a$f1137a40$d33a6ec0$@gmail.com> In-Reply-To: <018501d2aa8a$f1137a40$d33a6ec0$@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:20f3:cb50:43dc:997a] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:rR+t0nnDX9W78rL+dEXN0h01t1LBGSzwCk3OWd4y8nY2NeBethxZ+QgBfeP5yxfYpi6S+mmiEM+NQWq+QS0vyzEjzOhoDcdOJql75B472+uhP98HhcpOTjdzZyjTvlz9GECN91VtTaJ6Rs7v5KnspnEk1pYkXu9N8Wnng6jrcAbV6YbchXY6Kge2blz6BCRwpcw67PwE3+4+jKnAMYnxigLPik6dtJ+lofNIfAv71tR7GJuANbhCbczIgd51rdP5sTEK/CIojaYjBH5nA14Llyr/TStw2R+1dvo7R1pLIWZZ1qRK6p4MWgCXBf6qIje6zLJccFE/P6ZX69RfM4uWow==; 20:GL77UIiiOfv35JRUjBNuZu7QTj7RAx8rf9HK2JCunE/xDj27XEbYp8wxYlCTMYRHiJb3Ka+pZ4wZfE2dplgoCXShRTWs/rANNSYpLK+fEv09I+I/3Rls8ZZ6//UMa1uPSxcgG264e0ZbTHzLiT5tRYX1nairz9f0NpXsvT1N0vI= x-ms-office365-filtering-correlation-id: 0e0079d3-0597-4253-3dd1-08d4795a9bbc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39840400002)(39450400003)(52314003)(24454002)(76176999)(53936002)(229853002)(2950100002)(305945005)(1411001)(6916009)(50986999)(42882006)(6486002)(39060400002)(6512007)(6506006)(7736002)(6306002)(102836003)(6116002)(8666007)(6436002)(54906002)(189998001)(33656002)(99286003)(36756003)(2906002)(3660700001)(57306001)(3280700002)(50226002)(8936002)(74482002)(83716003)(82746002)(4326008)(230783001)(25786009)(2900100001)(8676002)(110136004)(5660300001)(5250100002)(93886004)(53546009)(81166006)(38730400002)(86362001)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <79C96C82762AAC4FB8A1B679B7A6AC22@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2017 23:55:43.1967 (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: 3MBalUJ7NyC3k1NEOCCrgg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 23:55:53 -0000 SGkgUnVzcywNCg0KPiBPbiAxIEFwciAyMDE3LCBhdCAwMjo1NCwgUnVzcyBXaGl0ZSA8N3Jpdzc3 QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4+IElNTywgdGhlIHJlbGF0ZWQgcmVxdWlyZW1l bnQgbWlnaHQgYmUgImNvbmZpZ3VyYWJsZSIsIGJ1dCBpbmRpY2F0aW5nIGhvdyBpcw0KPj4gb3V0 IG9mIHNjb3BlIHVubGVzcyB5b3UgZGVtYW5kIHN1cHBvcnQgZm9yIGEgcGFydGljdWxhciBwcm90 b2NvbC4NCj4+IEkgc2VlIG5vIHZhbGlkIHJlYXNvbiB0byByZXF1aXJlIFRFTE5FVCB2cy4gYW55 IG90aGVyIHNlcnZpY2Ugb3ZlciB3aGljaA0KPj4gY29uZmlndXJhdGlvbiBjYW4gYmUgYWNoaWV2 ZWQuDQo+IA0KPiBMZXQgbWUgcHV0IHRoaXMgYW5vdGhlciB3YXk6IHNvbWUgc2V0cyBvZiBmZWF0 dXJlcyBtYWtlIGEgbmV0d29yayBlYXNpZXIgdG8gb3BlcmF0ZS4gT3RoZXJzIG1ha2UgYSBuZXR3 b3JrIG1vcmUgZGlmZmljdWx0IHRvIG9wZXJhdGUuIFdoYXQgSSd2ZSBoZWFyZCBmcm9tIG9wZXJh dG9ycyAoaW5jbHVkaW5nIG15IG9wZXJhdGlvbmFsIGZvbGtzKSBpcyB3aGF0IGlzIGluIHRoZSBk cmFmdC4gVGhpcyBpcyBub3QgYSBkb2N1bWVudCB0aGF0IHNheXMsICJ0aGlzIGlzIHdoYXQgaXMg dGVjaG5pY2FsbHkgYmVzdCwiIG9yICJ0aGlzIGlzIHdoYXQgaXMgdGhlIG1vc3QgYWR2YW5jZWQu IiBJbnN0ZWFkLCB0aGlzIGRvY3VtZW50IHdhcyBkZXNpZ25lZCBqdXN0IHRvIGdpdmUgb3BlcmF0 b3JzIGEgY2hhbmNlIHRvIHNheSwgInRoaXMgaXMgd2hhdCBJIGV4cGVjdCB0byBzZWUgaW4gYSBy b3V0ZXIgb24gd2hpY2ggSSBkZXBsb3kgSVB2Ni4iIA0KPiANCj4gSWYgd2UgYXJlIGdvaW5nIHRv IG1vdmUgYXdheSBmcm9tIHdoYXQgb3BlcmF0b3JzIGFyZ3VlIGltcGxlbWVudGF0aW9ucyBTSE9V TEQvTVVTVC9NQVkgaW1wbGVtZW50LCB0aGVuIHdlIGFyZSBtb3ZpbmcgYXdheSBmcm9tIHRoZSBv cmlnaW5hbCBpbnRlbnQgb2YgdGhlIGRvY3VtZW50LS13aGljaCBtZWFucyBpdCBiZWNvbWVzIGEg ZGlmZmVyZW50IGRvY3VtZW50IGVudGlyZWx5LCBhbmQgd2UgYXJlIGdvaW5nIHRvIG5lZWQgdG8g ZmluZCBkaWZmZXJlbnQgZ3JvdW5kIHJ1bGVzIGZvciBkZXRlcm1pbmluZyB3aGF0IHRvIGluY2x1 ZGUgb3Igbm90LiBJZiBzb21lb25lIHdvdWxkIGxpa2UgdG8gbWFrZSBhIHN1Z2dlc3Rpb24gb2Yg d2hhdCB0aG9zZSBncm91bmQgcnVsZXMgbWlnaHQgYmUgKHBsZWFzZSBkbyBub3Qgc3VnZ2VzdCAi dGhlIGJlc3QgdGVjaG5pY2FsIHNvbHV0aW9uLCIgYXMgdGhhdCBpZGVhIHdpbGwgc2ltcGx5IHJl c3VsdCBpbiBhbiBlbmRsZXNzIGZpZ2h0KSwgcGxlYXNlIHN1Z2dlc3QgaXQuDQo+IA0KPiBJJ20g cGVyZmVjdGx5IGhhcHB5IHRvIGRvIHdoYXRldmVyIGVkaXRpbmcgaXMgbmVlZGVkLi4uIEJ1dCBJ IG5lZWQgdG8ga25vdyB3aGF0IHRoZSBuZXcgZ3JvdW5kIHJ1bGVzIGFyZSBnb2luZyB0byBiZSBp ZiB0aGUgaW50ZW50IG9mIHRoZSBkcmFmdCBpcyBnb2luZyB0byBiZSBjaGFuZ2VkLCBpbiBvcmRl ciB0byBlZmZlY3RpdmVseSBldmFsdWF0ZSB3aGF0IHNob3VsZCBpbiAob3Igb3V0KSBvZiB0aGUg ZHJhZnQgLS0gYW5kIGlmIHRoZSBncm91bmQgcnVsZXMgZG8gY2hhbmdlLCB0aGVuIGEgZHJhZnQg d2l0aCB0aGUgb3JpZ2luYWwgaW50ZW50IGlzIGdvaW5nIHRvIHJlYXBwZWFyIGFueXdheSwgYXMg bWFueSBvcGVyYXRvcnMgSSd2ZSBzcG9rZW4gdG8gYmVsaWV2ZSBzdWNoIGEgZG9jdW1lbnQgaXMg dXNlZnVsIGFuZCBuZWNlc3NhcnkuDQoNCkkgdGhpbmsgY2FwdHVyaW5nIHRoZSBzcGlyaXQgb2Yg d2hhdCB5b3Ugc2F5IGFib3ZlIGluIHRoZSBkcmFmdCB3b3VsZCBiZSB1c2VmdWwsIGVzcC4gd2hh dCB5b3Ugc2F5IGluIHRoZSBmaXJzdCBwYXJhZ3JhcGguDQoNClRpbQ0KDQo+IA0KPiDwn5iKIC9y IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From nobody Sun Apr 2 09:23: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 E919E1294A5 for ; Sun, 2 Apr 2017 09:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xGjX5GIdwt-I for ; Sun, 2 Apr 2017 09:23:36 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 02E5B129495 for ; Sun, 2 Apr 2017 09:23:35 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32GMUXL013528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 09:22:32 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <49A66D86-D916-475C-B8BC-A35111319275@thehobsons.co.uk> Date: Sun, 2 Apr 2017 09:22:30 -0700 Cc: IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <6AE0263F-68C6-43C0-80E2-983F481AC575@delong.com> References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> <49A66D86-D916-475C-B8BC-A35111319275@thehobsons.co.uk> To: Simon Hobson X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 09:22:34 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 16:23:38 -0000 Perhaps we should break this into pieces with different mandates=E2=80=A6 Host: Must support SLAAC Client implementation including=E2=80=A6 Address auto configuration when M=3D0. RDNSS based configuration of resolvers Installation of default route(s) based on received RAs Support for multiple default routers based on received = RAs Support for additional routing information contained in = RAs Should support DHCP6 Client implementation including=E2=80=A6 A host which fails to support DHCP6 Client implementation should = behave in the following manner when confronted with M=3D1: Router: Must support Router Advertisements including=E2=80=A6 Ability to configure/support SLAAC Ability to configure/support =E2=80=9CO-bit =3D 1=E2=80=9D= stateless addressing with DHCP for other information Ability to configure/support =E2=80=9CM-bit =3D 1=E2=80=9D= stateful addressing using DHCP Must support DHCP6 Relay including=E2=80=A6 Should support DHCP6 Server including all requirements from = DHCP6 Server below. DHCP6 Server: Must support DHCP6 services including=E2=80=A6 In this way, perhaps the pushback from host OS developers can be = limited to the Host: portion of the document and we can at least get = some consistent agreement on the router and DHCP6 server portions moving = forward. I think if we can stabilize and standardize the latter 2, then the Host = area might be a more solvable problem in the longer term. Owen > On Apr 1, 2017, at 6:03 AM, Simon Hobson = wrote: >=20 > Lorenzo Colitti wrote: >=20 >> That was what draft-gont-v6ops-host-configuration proposed, and there = was strong pushback from major host OS developers against making both of = them a MUST. Examples: >>=20 >> https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html >> https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html >=20 > I noted that neither of those actually gave any reason other than "I = don't like it" ! >=20 >> On the other hand, there seems to be less opposition to making RDNSS = a MUST. The main objections so far appears to be of the form "if we make = RDNSS a MUST we should make DHCPv6 a MUST as well", but given the = pushback from host OS developers I don't think that's likely. >=20 > The problem being that we've had feedback here from operators who want = to be able to use DHCP, who are justly worried that if RDNSS is = mandated, then those OS vendors against DHCP will simply not make a = feature they wish to use available at all. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Apr 2 09:51: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 B27031294B7 for ; Sun, 2 Apr 2017 09:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 BlVP4eRfpHJt for ; Sun, 2 Apr 2017 09:51:35 -0700 (PDT) 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 31D0A1294B8 for ; Sun, 2 Apr 2017 09:51:33 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id s16so23475432pfs.0 for ; Sun, 02 Apr 2017 09:51:33 -0700 (PDT) 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=69T8Awey34Wpau6Of/s/VXK5e/Kc/oJ4+qkwoL1Bi4M=; b=LftoXgtZ3Svzp5B4MZYADWIl9jzA0bhVQbgba8tl4SmMCB/1MkJISCp9ARqwrueNNb HliSa6LGGA2XmCdrQ23+0dZTY/rMe6ZLe5AgXd5tD0cFPNXRzm6Y50d7Ia6ZkspCaDkR b4YPYua0xo1LW2k7/1RVZBCqEfkiQG3iq3GxZXyWGDAm7fxYoMKhNB7kpasaHVu8TabI vKwP5koYYWoZJZ1IK8c2u9meVCn2w9/iTvvP+jI8JiJ1KW2+UsorvxmJ4t7oKnxtMOLp LjABg64SRDwIayxpTQHAKRaj5Te3bEogqYaq5dEpRHOccOxmc1DybhWOtMIb1BCY66tT urRg== 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=69T8Awey34Wpau6Of/s/VXK5e/Kc/oJ4+qkwoL1Bi4M=; b=M9fsX7b30PjdvZ/SCH/NXfLKx1fsXycO0fz2kTz/coCw6A0Aq2oqHYidsxK96y0HWc KXLlFckOeE144/lZrn/Lk6r5FHrNfwd3INvuH4M2DOsvvz0k7A2m7bMd8D7HnBWXnnjz jk87ugHP8exzlSiYtNSQg9/6QNSBgTyxx3y9HJA5F+pXahmmcf4UTcmcTMTbibT4Eptz Gy3b2jelXViPxrse6PhfqZKFDF4UJe5thvvu5khoku7G0pAV5/4Sm0F38BlOkAwzGqHj yklBoHpuv+d+Et0YPPTFlJmxeqd0jcvtZNmcLZSWqN+KvtrFD4VJ7r0kXtMNd1T4soPm Si/Q== X-Gm-Message-State: AFeK/H1P9V1Ue+STHrJYrdS1L8WLfGLe6tVrxz3mcA2Rw7YO0oiiHLRZlCpDbEsLgv28BQ== X-Received: by 10.99.55.78 with SMTP id g14mr13299871pgn.191.1491151892761; Sun, 02 Apr 2017 09:51:32 -0700 (PDT) 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 b74sm21020278pfd.90.2017.04.02.09.51.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 09:51:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Sun, 2 Apr 2017 09:51:33 -0700 Cc: Brian E Carpenter , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> To: Tim Chown X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 16:51:38 -0000 > On Apr 1, 2017, at 4:41 PM, Tim Chown wrote: >>> One question I intended to ask and didn't get to was the = appropriateness of an interim meeting, perhaps in mid-May. It would = primarily address draft-ietf-v6ops-ula-usage-considerations and = draft-petrescu-v6ops-ipv6-power-ipv4, and potentially = draft-ietf-v6ops-design-choices if it is updated. There is an argument = for leaving these to IETF 99, and potentially booking a second slot for = that discussion. Your opinions? >=20 > Seconded. Is the intention a physical or virtual meeting, or both? I was thinking in terms of webex or equivalent, somewhere in May 8-18. = If folks want to have a meeting, I have to announce it 30 days in = advance, which means I'll send a doodle poll and we'll figure out when = to have it during this coming week. To my small mind, June is late = enough that we may as well delay for July. My *guess* at an agenda in July includes draft-ietf-v6ops-ula-usage-considerations if needed draft-ietf-v6ops-design-choices if updated and needed draft-petrescu-v6ops-ipv6-power-ipv4 if needed draft-ietf-v6ops-happy-eyeballs-update draft-ietf-v6ops-rfc7084-bis draft-ietf-v6ops-ipv6rtr-reqs Plus possible additional work submitted between now and then. Note the = "if needed"; they might be an argument for a second slot if we don't = have an interim meeting, and if we do have one, would only be on the = agenda if updated and there is working group interest. If you look at = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ula-usage-considera= tions-02.txt, you will see that the authors have done some pretty = heavy-duty changes to the document. I think the question would be (and = this could be in email or verbally) what additional changes people would = like to see. I'd invite a thorough review of the document as it stands. = I'll note that "let's deprecate ULA or tell people to never use it" = doesn't fit with current operational practice; when my phone is not = attached to a WiFi, the DNS address my provider offers me is a ULA = address. "Don't NAT", fine, but "don't ULA" as a blanket statement is = inconsistent with operational practice in some providers, and "ULA = implies NAT" is just silly. It implies that the systems so addressed are = not normally advertised in BGP, nothing more and nothing less. draft-petrescu-v6ops-ipv6-power-ipv4 is a brand new draft, slipped in = just under the wire. The first question is whether the working group is = interested; there wasn't time for that discussion to happen before IETF = 98. If we ARE interested, what do we think of it? draft-ietf-v6ops-design-choices didn't get updated for this meeting, and = sooner or later will simply drop off radar. Folks have periodically said = that they find it interesting and potentially useful, but the authors = have largely run out of steam. So at least part of the question is "what = is the future for this draft?".=20= From nobody Sun Apr 2 10:44: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 230C91242EA for ; Sun, 2 Apr 2017 10:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 s1qT0gxVcNfT for ; Sun, 2 Apr 2017 10:44:37 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3099E12940D for ; Sun, 2 Apr 2017 10:44:35 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32HhDhn018301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 10:43:16 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <58DE7B25.7020409@foobar.org> Date: Sun, 2 Apr 2017 10:43:13 -0700 Cc: Ted Lemon , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <907DA759-BEEE-454D-BEE4-B875C4022B29@delong.com> References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 10:43:18 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 17:44:39 -0000 > On Mar 31, 2017, at 8:52 AM, Nick Hilliard wrote: >=20 > Ted Lemon wrote: >> Then you are requiring all constrained devices to spend more = resources.=20 >=20 > claims about dhcpv6 being unsuitable for resource constrained devices > are often made but rarely substantiated. I'm not saying that this = isn't > a problem, but it would be helpful if we had some level of = understanding > in v6ops about the scale of the issue and whether this is a serious > enough thing that it ought to hold up standardisation of what would > otherwise be sensible and practical long term fixes to otherwise > difficult problems. Think about a 6 LOWPAN device with, maybe 512K of code (Flash) space and on the order of 32K of RAM that is the size of a quarter and = you=E2=80=99re in the ball park. Do these constitute the majority of IT spend anywhere? No. Will they = likely comprise a significant number of hosts in the future=E2=80=A6 You bet!! IOT is not a myth and some day developers will pull their heads out of = their asses and start implementing it with real address space. Owen From nobody Sun Apr 2 10:55:24 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 D35DA12940D for ; Sun, 2 Apr 2017 10:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aV6CHSJsaVpi for ; Sun, 2 Apr 2017 10:55:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 990391294DF for ; Sun, 2 Apr 2017 10:55:20 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32HsHEk020488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 10:54:19 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: Date: Sun, 2 Apr 2017 10:54:17 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> To: Philip Homburg X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 10:54:20 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 17:55:23 -0000 > On Mar 31, 2017, at 8:02 AM, Philip Homburg = wrote: >=20 >> Then you are requiring all constrained devices to spend more = resources. >=20 > I don't know about you, but if possible I want my contrained devices = to > use TLS. If possible I want them to use public key crypto to verify = firmware > upgrades. If they provide console access, I want that to be ssh and = not > telnet. Most constrained devices _DONT_ provide console access. Most don=E2=80=99t= run an operating system. Some have rudimentary serial ports (usually TTL and no hardware flow control) that the application developer _MAY_ enable to do stuff. Few have any sort of TELNET or SSH support and the ones that do are arguably a lot less constrained than what I think of when I hear = the term =E2=80=9Cconstrained device=E2=80=9D Let=E2=80=99s, for the sake of argument say that a constrained device is = one with less than 1MB of Flash and less than 64K of RAM. > All of those are more costly than DHCP. Note that the need to actually > do DHCP (as opposed to the code being there passively available) is = signaled > in an RA. So if you don't use DHCP in your network, it should not = consume > any runtime resources. True, but ANY of those being squeezed in with a 6 LOWPAN (or worse, a full IPv6) stack in the resources above leave very little = room left for the actual application. > Finally, if a device is really so constrained that DHCP literally = doesn't > fit, then leave it out. Well, here=E2=80=99s the rub. It=E2=80=99s not a question of does or = doesn=E2=80=99t fit at the end of the day=E2=80=A6 It=E2=80=99s more a question of =E2=80=9CI=E2=80=99ve got = 60 things to put in, my particular need requires these 30, the IETF says I have to include these other 15, = my engineering team wants a different subset of 20 and my device can hold roughly 38 of them.=E2=80=9D > But this is not the controverial part of the discussion. The = problematic > devices are the ones that have more than enough resources and still = don't > do DHCP. So perhaps we should write a requirement in those terms=E2=80=A6 Define the term =E2=80=9CResource Constrained Device=E2=80=9D, provide = an exception to the requirement for DHCP6 Client implementation in such devices, and then = require it on other hosts. I would propose that rather than the arbitrary numeric definition above, = if we are to codify such a definition in an RFC, however, that we should give = it genuine thought and define it in terms that can scale with time and = demands. Perhaps people will want to make changes to the following straw man as a starting point: A =E2=80=9CResource Constrained Device=E2=80=9D is a host which has = resource limitations which make it impossible to include all of the normally required features = specified in the current RFC set without compromising the ability to meet other demands = from the application, environment, or function for which the host is = intended. Then we could, perhaps even in a separate RFC, list which IPv6 = requirements are considered optional in the case of a =E2=80=9CResource Constrained = Device=E2=80=9D implementation. Owen From nobody Sun Apr 2 10:55: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 B4CC71294F6 for ; Sun, 2 Apr 2017 10:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 CT9ZAjPkbIFf for ; Sun, 2 Apr 2017 10:55:28 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 BA9191294F0 for ; Sun, 2 Apr 2017 10:55:28 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id i5so23774024pfc.2 for ; Sun, 02 Apr 2017 10:55:28 -0700 (PDT) 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=GIMkoaxZtySGk/bUhYpiCArxsCfq9YOmmaF+jTDhDUQ=; b=r0xQDpBf2BiiKCJ1mu3pc9gIOnfD723wEzgF6N4pNSLg3YEYQESaWsoLjvARE3TI9S tGI0WmUQcSqNR3JU5ZR5ocZft/KoRoT1grPA5TDbkM8IRR9fcVy9heX4zuOyOT4JMgdC HFlwgxbf0RuwT5ClrIIw5rR7AYAI/AUbnIs0jZ1/TgoS3KKRfM1fpJBAROAMSmBapcYS u1rvH2xtFCyWrqkq7zTiDoPVNbAlMnqytF6H0UuZIHcKBz6BsMdORINJgIr385juyQ9R UmTPvWzn+uoOPgF5MF6k9kzdmCGCxGWedHYlC5+lbNHca663iYPA4xK6wbR2PnhilixZ qFsA== 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=GIMkoaxZtySGk/bUhYpiCArxsCfq9YOmmaF+jTDhDUQ=; b=cXsMSUefk2UNFzp/Xls5qknm9lPWzY009eScTkHDoplNttPPh8ZnU9HzvgMqQvcRWd u0Ivlp3oin7D2TkkwgxmyoZ5NmM9hfyT+evQICKSIY3BVViG5dDjfQVGi8/IDMprACbq nW1Z2VoZ5rVwKEnJD9Jsgct2+4o6w1D8WMUnSgNQMjjh1cNXB1lKhDnW7jc8WYIEy/8G gPK64jZIB+lBishO/Bst/OtS2d2jrychgBCYDLBO1VGdX3V6/F3UHZ0pvTsH26MEFyO4 kNa5PJi3v407acjfYIYxhd7lhCCd24lmXdXdAyaJoN9jyA7ihN07DYX065vNZXPUh4qx UIgA== X-Gm-Message-State: AFeK/H3lHpWCaVcN79G2f3sz688a7KBF58pxDvYJyhQdYH07FbklUqAVxqDQXanSUPKU5A== X-Received: by 10.84.179.193 with SMTP id b59mr16727416plc.56.1491155728381; Sun, 02 Apr 2017 10:55:28 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-223-134.public.wayport.net. [64.134.223.134]) by smtp.gmail.com with ESMTPSA id p68sm4016139pga.6.2017.04.02.10.55.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 10:55:27 -0700 (PDT) From: Ted Lemon Message-Id: <5E3C53CF-3CDB-4177-AC2A-6EE5D4E32BEC@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DA254400-A6B6-4D14-A3F1-1D2BF2F9BE1D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 2 Apr 2017 10:55:26 -0700 In-Reply-To: <907DA759-BEEE-454D-BEE4-B875C4022B29@delong.com> Cc: Nick Hilliard , IPv6 Ops WG To: Owen DeLong References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <907DA759-BEEE-454D-BEE4-B875C4022B29@delong.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 17:55:31 -0000 --Apple-Mail=_DA254400-A6B6-4D14-A3F1-1D2BF2F9BE1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 2, 2017, at 10:43 AM, Owen DeLong wrote: > Think about a 6 LOWPAN device with, maybe 512K of code (Flash) space > and on the order of 32K of RAM that is the size of a quarter and = you=E2=80=99re in > the ball park. Right, and more importantly, a battery that fits in a device the size of = a quarter will not support a doubling of the packet count required to = join the network. --Apple-Mail=_DA254400-A6B6-4D14-A3F1-1D2BF2F9BE1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 2, 2017, at 10:43 AM, Owen DeLong <owen@delong.com> = wrote:
Think about a 6 = LOWPAN device with, maybe 512K of code (Flash) space
and on the order of 32K of RAM that is the size = of a quarter and you=E2=80=99re in
the ball = park.

Right, and more importantly, a battery that = fits in a device the size of a quarter will not support a doubling of = the packet count required to join the network.

= --Apple-Mail=_DA254400-A6B6-4D14-A3F1-1D2BF2F9BE1D-- From nobody Sun Apr 2 11:02: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 17A8A1294F0 for ; Sun, 2 Apr 2017 11:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8CVwVhk_A2ej for ; Sun, 2 Apr 2017 11:02:08 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 238721294EF for ; Sun, 2 Apr 2017 11:02:07 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32I12rl021897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 11:01:06 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> Date: Sun, 2 Apr 2017 11:01:02 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> To: Ola Thoresen X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 11:01:06 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 18:02:10 -0000 > On Mar 31, 2017, at 7:32 AM, Ola Thoresen wrote: >=20 > On 31. mars 2017 16:18, Philip Homburg wrote: >=20 >>> I'd like to see both RDNSS and DHCPv6 required too. But I'd be = willing to >>> compromise a little, requiring RDNSS for "all" hosts and routers, = and then >>> maybe a more qualified requirement for DHCPv6, such as for hosts and >>> routers "intended for enterprise use". This way a developer has an = out to >>> not support DHCPv6 if they choose, but there are consequences. Not >>> supporting DHCPv6 becomes tantamount to admitting that a device is = not >>> intended or suitable for enterprise use, or in other words is only a >>> consumer device. >> I can see 3 reasons for not doing DHCPv6: >>=20 >> 1) The device is too constrained. Obviously, if a device is too small = to >> support both SLAAC/RDNSS and DHCP IA_NA/DNS then we have to = compromise. >>=20 >> 2) The implementor is lazy. I certainly fall in that category. But = that's >> no excuse. >>=20 >> 3) There is something about DHCPv6 not working well enough. >>=20 >=20 > 4) The manager does not want to do all the extra work of setting up a = DHCP-server. It does not mean I am lazy. It means I don't need another = service running, all the extra lines of config, managing pools and = networks and so on. I think we should distinguish between =E2=80=9COperational = Requirements=E2=80=9D and =E2=80=9CImplementation Requirements=E2=80=9D = here. I don=E2=80=99t think anyone is requiring operators to deploy DHCP on = every device or every network in this proposal (at least I hope not and = we shouldn=E2=80=99t be IMHO). I think, instead, what is being discussed is a requirement that all = devices support both options for obtaining configuration information so = that the operator can choose the option best suited to their environment = without having to worry about the fact that some fraction of their = devices won=E2=80=99t support A while some other fraction won=E2=80=99t = support B. > If all you need is an "ad hoc" network, and you don't need to know who = the clients are, or control the assignment of addresses and don't care = as long as they get on "the internet" somehow. Why bother with DHCP? I couldn=E2=80=99t agree more, but that only works if RDNSS client = support is an implementation requirement. OTOH, if you don=E2=80=99t want to run RDNSS for whatever reason and you = prefer DHCP, that only works if DHCP client support is an implementation = requirement. Currently, both are implementation =E2=80=9Coptions=E2=80=9D and it=E2=80=99= s created a huge mess where virtually every client platform out there = supports one or the other and only a few support both, leaving operators = having to support both on their network or face some subset of clients = that simply won=E2=80=99t work on their network. Owen From nobody Sun Apr 2 11: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 85AAD1294E1 for ; Sun, 2 Apr 2017 11:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AsJlQOpz9q_l for ; Sun, 2 Apr 2017 11:16:41 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id E5FAF120726 for ; Sun, 2 Apr 2017 11:16:39 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32IFaYE025004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 11:15:37 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: Date: Sun, 2 Apr 2017 11:15:36 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0B3DFE98-9838-4AEA-B44D-A25D0155FBB3@delong.com> References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> To: Philip Homburg X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 11:15:38 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 18:16:42 -0000 > On Mar 31, 2017, at 6:58 AM, Philip Homburg = wrote: >=20 >> I'm saying that one option is to deprecate the DHCP DNS option. I = didn't >> say anything about deprecating all of stateless DHCP. >>=20 >> And the other option is to make support for the DHCP DNS option = mandatory. >>=20 >> I'm just saying we have to choose and not leave it open. >>=20 >>=20 >> Okay, now I understand. This would prevent networks from requiring = stateful >> DHCP. So we can't do it. >=20 > So my compromise position was: > - If a host gets an address using IA_NA it MUST support the DHCP DNS = option. > - All nodes have to support RDNSS. >=20 > This way there is a simple message for operators, either you use SLAAC = and > RDNSS or you can use DHCP for both addressing and DNS. Don't try to = mix and > match. But that doesn=E2=80=99t make sense. It=E2=80=99s perfectly valid and = many operational networks today use the M=3D0, O=3D1 for SLAAC + other information from DHCP. As long as the client is capable of DHCP, this shouldn=E2=80=99t be a = problem and there=E2=80=99s no reason not to allow this (previously intentionally enabled) perfectly valid = configuration mechanism. I agree that any host which supports IA_NA must support DHCP DNS = option.I also agree that all hosts must support RDNSS I don=E2=80=99t agree that a host = which supports IA_NA and DHCP DNS option should be allowed to refuse DHCP DNS information if it = gets an address via SLAAC with the O bit set (which while not part of your = =E2=80=9Cposition=E2=80=9D is what is implied from your =E2=80=9Csimple message for operators=E2=80=9D. Owen From nobody Sun Apr 2 11:24: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 B3D511294FC for ; Sun, 2 Apr 2017 11:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 afDUygt-Qy4z for ; Sun, 2 Apr 2017 11:24:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDF51294F6 for ; Sun, 2 Apr 2017 11:24:12 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32IN9b6025797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 11:23:11 -0700 From: Owen DeLong Message-Id: <07EED00C-1C97-40B4-ACE4-25CBA19687CF@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6104646C-D639-4C09-A099-F00B157D329F" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 2 Apr 2017 11:23:09 -0700 In-Reply-To: Cc: Philip Homburg , V6 Ops List To: David Farmer References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 11:23:12 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 18:24:15 -0000 --Apple-Mail=_6104646C-D639-4C09-A099-F00B157D329F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 31, 2017, at 6:46 AM, David Farmer wrote: >=20 >=20 >=20 > On Fri, Mar 31, 2017 at 7:57 AM, Philip Homburg = > wrote: > >Philip, forgive me for holding your feet to the fire here, but you = haven't > >actually stated any reason why what I said was wrong. >=20 > The current situation where we have two mechnisms for DNS resolver = information > and devices just support one of the two is really bad. >=20 > I agree the current situation is bad. > =20 > So we should make a choice, either it is mandatory for all devices to > support both options or we kill one of them. >=20 > I wouldn't go quite that far, personally. > =20 > So if we only mandate RDNSS and not DHCP, then we should make it very = clear > to operators that any deployment plans that rely on DHCP for DNS = configuration > are likely to fail. And then we can just as well formally deprecate = the DHCP > DNS option. >=20 > But just to be clear, I'm perfectly okay with mandating both RA (SLAAC = and > RDNSS) as well as DHCP (IA_NA and DNS) to be supported in all nodes. >=20 > I'd like to see both RDNSS and DHCPv6 required too. But I'd be = willing to compromise a little, requiring RDNSS for "all" hosts and = routers, and then maybe a more qualified requirement for DHCPv6, such as = for hosts and routers "intended for enterprise use". This way a = developer has an out to not support DHCPv6 if they choose, but there are = consequences. Not supporting DHCPv6 becomes tantamount to admitting = that a device is not intended or suitable for enterprise use, or in = other words is only a consumer device. =20 I think this is an artificial and unjustified mechanism for = qualification. While it=E2=80=99s convenient to divide the world into = =E2=80=9Centerprise=E2=80=9D and =E2=80=9Cconsumer=E2=80=9D use, first, = those are not well defined terms to begin with. Second, there=E2=80=99s = a category of devices that are unlikely to support DHCP6 which are = intended for enterprise use (e.g. resource constrained sensor packages). = While an enterprise may need to require DHCPv6 for clients in certain = trusted parts of the network, the reality is that it is perfectly valid = to create sensor networks with entirely different security parameters = where other mechanisms may be more practical (e.g. MAC-based = authentication, router/firewall ACLs preventing access to corporate = resources, etc.). There=E2=80=99s no reason to absolve consumer devices = of the need to support DHCP6. Instead, I believe that we should make = exceptions for resource constrained devices and no others. > I just had an idea, what if we crated an new hybrid operating mode of = DHCPv6 IA_NA for stable addresses and SLAAC for temporary addresses, = using RA flags of A=3D0, M=3D1, therefore requiring use of IA_NA, but = created a new DHCPv6 option that says that despite the A=3D0 flag that = SLACC may be used for the generation of temporary addresses. This would = give enterprise network operators a level of control for addresses that = are intended to provide services (act as servers), maybe allowing DHCPv6 = as a control plane for provisioning reverse DNS, poking appropriate = holes in firewalls, etc... While at the same time allowing rapid = generation of addresses that access services (act as clients). =20 Why does a host with a stable address from DHCP need a temporary = address? I=E2=80=99m not expressing opposition (yet), but I=E2=80=99m = trying to understand the application where this would be perceived as = useful vs. yet more confusion piled on to the existing mess that is the = interaction between RA/SLAAC and DHCP6. Owen --Apple-Mail=_6104646C-D639-4C09-A099-F00B157D329F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 31, 2017, at 6:46 AM, David Farmer <farmer@umn.edu> = wrote:



On Fri, Mar 31, 2017 at 7:57 AM, = Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
>Philip, forgive me = for holding your feet to the fire here, but you haven't
>actually stated any reason why what I said was wrong.

The current situation where we have two mechnisms for DNS resolver = information
and devices just support one of the two is really bad.

I agree the current situation is bad.
 
So we should make a choice, either it is mandatory for all devices to
support both options or we kill one of them.

I wouldn't go quite that far, personally.
 
So if we only mandate RDNSS and not DHCP, then we should make it very = clear
to operators that any deployment plans that rely on DHCP for DNS = configuration
are likely to fail. And then we can just as well formally deprecate the = DHCP
DNS option.

But just to be clear, I'm perfectly okay with mandating both RA (SLAAC = and
RDNSS) as well as DHCP (IA_NA and DNS) to be supported in all nodes.

I'd like to see both RDNSS and DHCPv6 required too.  But = I'd be willing to compromise a little, requiring RDNSS for "all" hosts = and routers, and then maybe a more qualified requirement for DHCPv6, = such as for hosts and routers "intended for enterprise use".  This = way a developer has an out to not support DHCPv6 if they choose, but = there are consequences.  Not supporting DHCPv6 becomes tantamount = to admitting that a device is not intended or suitable for enterprise = use, or in other words is only a consumer device.   =  

I think this is an artificial and unjustified mechanism = for qualification. While it=E2=80=99s convenient to divide the world = into =E2=80=9Centerprise=E2=80=9D and =E2=80=9Cconsumer=E2=80=9D use, = first, those are not well defined terms to begin with. Second, there=E2=80= =99s a category of devices that are unlikely to support DHCP6 which are = intended for enterprise use (e.g. resource constrained sensor packages). = While an enterprise may need to require DHCPv6 for clients in certain = trusted parts of the network, the reality is that it is perfectly valid = to create sensor networks with entirely different security parameters = where other mechanisms may be more practical (e.g. MAC-based = authentication, router/firewall ACLs preventing access to corporate = resources, etc.). There=E2=80=99s no reason to absolve consumer devices = of the need to support DHCP6. Instead, I believe that we should make = exceptions for resource constrained devices and no others.

I just had an idea, what if we = crated an new hybrid operating mode of DHCPv6 IA_NA for stable addresses = and SLAAC for temporary addresses, using RA flags of A=3D0, M=3D1, = therefore requiring use of IA_NA, but created a new DHCPv6 option that = says that despite the A=3D0 flag that SLACC may be used for the = generation of temporary addresses.  This would give enterprise = network operators a level of control for addresses that are intended to = provide services (act as servers), maybe allowing DHCPv6 as a control = plane for provisioning reverse DNS, poking appropriate holes in = firewalls, etc...  While at the same time allowing rapid generation = of addresses that access services (act as clients).   =  

Why does a host with a stable address from DHCP need a = temporary address? I=E2=80=99m not expressing opposition (yet), but = I=E2=80=99m trying to understand the application where this would be = perceived as useful vs. yet more confusion piled on to the existing mess = that is the interaction between RA/SLAAC and DHCP6.

Owen

= --Apple-Mail=_6104646C-D639-4C09-A099-F00B157D329F-- From nobody Sun Apr 2 12:46: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 24031129501 for ; Sun, 2 Apr 2017 12:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, 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 hwai_h7KQZ6n for ; Sun, 2 Apr 2017 12:46:47 -0700 (PDT) Received: from poseidon.nytt.no (poseidon.nytt.no [195.159.132.73]) (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 6324512948F for ; Sun, 2 Apr 2017 12:46:46 -0700 (PDT) Received: from dhcp-94.olen.net (dhcp-91.olen.net [195.159.132.91] (may be forged)) (authenticated bits=0) by poseidon.nytt.no (8.15.2/8.15.2) with ESMTPSA id v32Jkciv013134 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 2 Apr 2017 21:46:40 +0200 Cc: v6ops@ietf.org References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> From: Ola Thoresen Message-ID: <668b306a-caea-402a-3ab2-1bd91bd8af1e@nlogic.no> Date: Sun, 2 Apr 2017 21:46:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 19:46:50 -0000 On 02. april 2017 20:01, Owen DeLong wrote: >> On Mar 31, 2017, at 7:32 AM, Ola Thoresen wrote: >> >> 4) The manager does not want to do all the extra work of setting up a DHCP-server. It does not mean I am lazy. It means I don't need another service running, all the extra lines of config, managing pools and networks and so on. > I think we should distinguish between “Operational Requirements†and “Implementation Requirements†here. > > I don’t think anyone is requiring operators to deploy DHCP on every device or every network in this proposal (at least I hope not and we shouldn’t be IMHO). > > I think, instead, what is being discussed is a requirement that all devices support both options for obtaining configuration information so that the operator can choose the option best suited to their environment without having to worry about the fact that some fraction of their devices won’t support A while some other fraction won’t support B. Obviously. And I am sorry if my point was not very clear. The discussion I was referring to used managers as an example. What I was trying to argue for, was that making _one_ of the options a requirement, should not necessarily make us want to abolish the other. I can see situations where both running SLAAC only, and running DHCP only cloud be a viable solution. And as you say, it should be up to the operator to make that choice. But also - IF we just want to make ONE of the options compulsory in all implementations, it should be RDNSS. The reason being that RDNSS is the simplest one and makes the least impact on managers. Since RAs are already there, I believe it is a smaller problem for an admin that want to run DHCP only for address assignment, to include dns-servers in the already present RAs than it is to require that people wanting to run a SLAAC only network to set up a DHCP-server only to give out dns-servers. I am not sure it is right to make _both_ DHCP and RDNSS a "MUST" for all implementations. And if I have to chose, I chose RDNSS as "MUST" and DHCP as "SHOULD". - If that makes it clearer? Rgds. Ola Thoresen From nobody Sun Apr 2 12:59: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 92661126557 for ; Sun, 2 Apr 2017 12:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0ve00WPvJSJ for ; Sun, 2 Apr 2017 12:59:11 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 31D43126FB3 for ; Sun, 2 Apr 2017 12:59:11 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 1072085 for ; Sun, 2 Apr 2017 12:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491163154; bh=NzdKBNJMfmyMaO0Ri8BrnE9shzse3H4etXmoqv+ABBk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JKi0JSN9MSPv9wjGfomaN6r+S0Hj//H7T12RI0E3Ad5sueSzIg0IWSIk2eip/Lqmp YBRNvki9gcb3ONVetmVvBAJpGkC+duNk5XULMfwPlbpdiNwYOupIUZH/nU42cyWwea t6adjQF8cYwkqXyP0P1Hk2fY1M0dWJYKPOKM/g7g= To: v6ops@ietf.org References: <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <907DA759-BEEE-454D-BEE4-B875C4022B29@delong.com> From: Doug Barton Message-ID: <81eb9509-9510-db3c-2949-99be43856c75@dougbarton.us> Date: Sun, 2 Apr 2017 12:59:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <907DA759-BEEE-454D-BEE4-B875C4022B29@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 19:59:13 -0000 On 04/02/2017 10:43 AM, Owen DeLong wrote: > >> On Mar 31, 2017, at 8:52 AM, Nick Hilliard wrote: >> >> Ted Lemon wrote: >>> Then you are requiring all constrained devices to spend more resources. >> >> claims about dhcpv6 being unsuitable for resource constrained devices >> are often made but rarely substantiated. I'm not saying that this isn't >> a problem, but it would be helpful if we had some level of understanding >> in v6ops about the scale of the issue and whether this is a serious >> enough thing that it ought to hold up standardisation of what would >> otherwise be sensible and practical long term fixes to otherwise >> difficult problems. > > Think about a 6 LOWPAN device with, maybe 512K of code (Flash) space > and on the order of 32K of RAM that is the size of a quarter and you’re in > the ball park. > > Do these constitute the majority of IT spend anywhere? No. Will they likely > comprise a significant number of hosts in the future… You bet!! > > IOT is not a myth and some day developers will pull their heads out of their > asses and start implementing it with real address space. I'm with you on needing to spec things that meet actual market demands. But, a few questions related to that theoretical device. 1. Why is it doing DNS lookups? 2. What is it using to make the DNS lookups? 3. How does the size/complexity of the code necessary for stateless DHCPv6 to get address and/or DNS configuration compare to the size/complexity of the equivalent code for SLAAC? Until we have those answers, I agree with Fred that this is a purely political discussion. Doug From nobody Sun Apr 2 13:02: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 7F730129548 for ; Sun, 2 Apr 2017 13:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOUqyb5j9J3m for ; Sun, 2 Apr 2017 13:02:06 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 35714126FB3 for ; Sun, 2 Apr 2017 13:02:06 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 225C985 for ; Sun, 2 Apr 2017 13:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491163329; bh=YraE09vt+yKU+tKhHS7lq8tq1iw6eCUejy0+mH+zKS8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DDdxOGPWTUumn8r3ux0l8xVNwldeB7yoklIqGZVCsYQszPqj5rYxc5erekHDGSE/0 Kv2o4esMQ7x8CZsHAEMc6jc5dhyd47q2jIGftv4qn6j58ETk2X/vHVKd0CX9lqzRL6 ATpz5x5/AyV9vZDS1bdfLOR+FSeUJQjGb+6SZyTA= To: v6ops@ietf.org References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> <99c8207a-ab98-01d6-2f47-83f1d72bf249@gmail.com> From: Doug Barton Message-ID: <97401688-0b0c-cd20-2639-200722efa579@dougbarton.us> Date: Sun, 2 Apr 2017 13:02:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <99c8207a-ab98-01d6-2f47-83f1d72bf249@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:02:07 -0000 On 04/01/2017 09:02 AM, Brian E Carpenter wrote: > I was actually arguing that making them both a MUST implement is "more" > valid because it increases that chance that an arbitrary host will work > on an arbitrary network. No, it wouldn't, because "MUST support" is not the same as "MUST provide." And people are going to continue configuring their network the way they want to in any case. Doug From nobody Sun Apr 2 13:05: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 6DB2B1286B1 for ; Sun, 2 Apr 2017 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyNGPC-pfuZK for ; Sun, 2 Apr 2017 13:05:40 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 3AF3A126FB3 for ; Sun, 2 Apr 2017 13:05:40 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 46C2E85 for ; Sun, 2 Apr 2017 13:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491163543; bh=252rRa8yxJZTS75G01Wv/S1jkMn8YTDj08RGAOcb9qc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Zl7a24Q21gSIvWSvcx1/A/MLef3+soYlYfIhAt4ezT6rJd9dFVGuX94WJPdZIYsD1 AMEJeWo6/qAFlbzK60hWr2yfiBHZCHndI3ssPBMGZ5Anm00wwGuCzGRa9jcD5Ad6YT BCFPLNojObaU6fAKD2y52tW9LRUYEU2BgyhKrWTQ= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> From: Doug Barton Message-ID: <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> Date: Sun, 2 Apr 2017 13:05:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:05:41 -0000 On 03/31/2017 12:18 AM, Simon Hobson wrote: > Doug Barton wrote: > >> People who like it can implement it, people who don't, shouldn't >> have to. > > But that is the whole problem ! As referenced some time ago, in the > real world there is a problem where there are two ways of providing > the information, and two ways of getting it. If router only does A > and device only does B then device doesn't get DNS info; similarly if > router only does B and device only does A then device doesn't get DNS > info; in either case the problem is that you've connected a device to > an IPv6 network and "it doesn't work". Yes. That was the completely predictable result of the introduction of new options to SLAAC beyond RA, and the core objection made by those of us who have been opposing additional such options for over a decade. I've snipped the rest of your message because we all know how we got here. We have created this mess by allowing the anti-DHCP crowd to run the asylum. We need to stop letting that happen. Doug From nobody Sun Apr 2 13:08: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 D83F1129421 for ; Sun, 2 Apr 2017 13:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14VJ_wNS5baD for ; Sun, 2 Apr 2017 13:08:53 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 81D8C1293FF for ; Sun, 2 Apr 2017 13:08:53 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 8E92885 for ; Sun, 2 Apr 2017 13:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491163736; bh=dO1MZOyj77uK/Zy793CbfdmNtWbQVwjWUu522qVSFqE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=fnIjhIcubV48qKqUMKEstvAnQo8CrTJFCqbTxDTKiUIhJ+pZu4FBPEfJHRkphaw6c kaeH/5Lzq27QXxH5PpAB7reGM2DtLtwm7fXuR24M+kpfwFlF/mo1NZ7aMdYcYPq7pt WLZjeRhirE8Kr0qFldh2srxQ7yUB3nCTc0s4I+Ek= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <58DE38D5.4050802@foobar.org> From: Doug Barton Message-ID: Date: Sun, 2 Apr 2017 13:08:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <58DE38D5.4050802@foobar.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:08:55 -0000 On 03/31/2017 04:09 AM, Nick Hilliard wrote: > Simon Hobson wrote: >> But if things are going to move forward, there has to be a "standard" >> setting a minimum requirement so that devices will work when plugged >> in - at the moment there isn't that. > > it's probably fair to assume that everyone on this list understands the > underlying technical issues. > > The problem is that the primary motivation for this proposal is not > technical but political: Here, here. > namely the point blank refusal of specific > companies - on policy grounds - to implement dhcpv6 in their host > stacks, which as a side effect has caused serious deployment problems > for end users on production v6 networks. > > As the ipv6 deployment problems that this is causing for end user sites > can no longer be ignored, it needs to be fixed. There are several ways > to handle this, including: > > 1. waiting for vendors and operators to support RDNSS at the router > stack level Operators and vendors will not do this. They have already voted with their feet, and have made it quite clear that DHCP is the preferred method of host configuration. > 2. take a longer term approach of fixing the current limitations in > dhcpv6 which currently make it a politically unfavourable tool to use > for host autoconfig, then supporting dhcpv6 in the host stack Yes, please. :) > 3. using the IETF policy process as a stick with which to beat everyone > else into compliance with your own internal policies, disregarding the > consequences - often scorched earth - for the rest of the v6 internet. > > Given the extensive practice of option #3 on v6ops, 6man and dhc in > relation to SLAAC vs DHCPv6, I'm inclined to think that this will be the > inevitable outcome of MUST for RDNSS, and that it will be used as > ammunition in future both to shout down and block future consensus on > dhcpv6 protocol development and to force vendors and operators down one > particular protocol deployment path. > > I'm genuinely sad to feel it necessary to say this, but I think it needs > to be stated explicitly. You said it far more elegantly than I did, but this is the gist of what I was trying to get across the other day. Doug From nobody Sun Apr 2 13:14: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 C93E9129420 for ; Sun, 2 Apr 2017 13:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSsRf8WBp5TE for ; Sun, 2 Apr 2017 13:14:50 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 87ABF129449 for ; Sun, 2 Apr 2017 13:14:50 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 8D23385 for ; Sun, 2 Apr 2017 13:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491164093; bh=+/1waVyCJQABawDFS80mr5QtDVhVC+eZEEsbTER2kvw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=eK6eji9kghd6IqLwVHDgYo6EU2BeAWDtVTq3VsWkJ5TpToOOiKDWPNU5JL72XjQ8c q5YT2owniL0nehyIHpSp0BYiFtM+ujnRhn6EWYJD3erCyzkMrKkPG3MIwW6ova413B RYOOHqCzlqxgSWOmX4nfXq8apfdxvDmm7WcNKysE= To: v6ops@ietf.org References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> From: Doug Barton Message-ID: Date: Sun, 2 Apr 2017 13:14:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:14:52 -0000 On 03/31/2017 05:57 AM, Philip Homburg wrote: >> Philip, forgive me for holding your feet to the fire here, but you haven't >> actually stated any reason why what I said was wrong. > > The current situation where we have two mechnisms for DNS resolver information > and devices just support one of the two is really bad. > > So we should make a choice, either it is mandatory for all devices to > support both options or we kill one of them. Some may find it surprising to learn that I'm actually Ok with letting RDNSS live. I was (and am) thoroughly opposed to it being introduced in the first place, but now that it's here I think those that like it and find it sufficient should be allowed to continue to use it. Making it mandatory to implement, however, would only serve to show how out of touch the IETF is with over a decade of expressed operator preference, and as Nick pointed out serve the political purpose of acting as more ammunition for killing off DHCPv6. I would argue that making DHCPv6 (stateless, or stateful, I don't care) mandatory to implement would be a much better solution, as it matches what the operators have said they want, would help break the stalemate, and would get us closer to a complete DHCPv6 solution. But this is not the right place/time to tilt at that particular windmill. :) Doug From nobody Sun Apr 2 13:19: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 7DA7112751F for ; Sun, 2 Apr 2017 13:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Oygma3Mqs2T for ; Sun, 2 Apr 2017 13:19:05 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 43DBC124C27 for ; Sun, 2 Apr 2017 13:19:05 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 4EA2885 for ; Sun, 2 Apr 2017 13:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491164348; bh=ZuD5Qb0fNNJrhONgAaisFkQ+0Jruen12gNRadn2XEJE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LEtapQjnLQA9OvCo96u8sfHCktfDk5l5EyB4/lWw3er9dG0f4dfSlsppARNER4tlE Y915jLXlEy6d/NQ0UEpuaEvENgElm2m42bt5h1sREwLyXr9Hse5EtTisYvW/6hISzA pGqSd4YdGqU6E6CHdBFWu+JUkaqhnvBlI/Z2szvg= To: v6ops@ietf.org References: <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> From: Doug Barton Message-ID: <5c61521a-af0f-5505-a656-6d10ed947d1d@dougbarton.us> Date: Sun, 2 Apr 2017 13:19:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:19:06 -0000 On 03/31/2017 07:27 AM, David Farmer wrote: > It's time for all routers and general purpose devices to support both. > I'm willing to allow highly constrained devices some flexibility. > However, honestly there is no good reason for most devices to not > support both religions. Yes, there is. Completely aside from the overwhelming lack of market demand for RDNSS, implementing (which includes extensive development and testing) two solutions to do the same job costs real money to vendors, and real time to open source software developers. What you're essentially saying is that because the IETF can't get its act together, those 3rd parties have to bear the cost. That's so far out of touch with the real world that it's hard for me to even know where to begin to explain how wrong it is. Doug From nobody Sun Apr 2 13:23: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 C04AD1243F3 for ; Sun, 2 Apr 2017 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c8sQ4Mng63G for ; Sun, 2 Apr 2017 13:23:51 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 901421292C5 for ; Sun, 2 Apr 2017 13:23:51 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 42F7F85 for ; Sun, 2 Apr 2017 13:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491164634; bh=d6mKTxDAxvPFJDZxQKXjxZlA7I5CPmUoP8kL9Ut8mnc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=d7muDzxv8CKBN/AxBHnWviraotSLLf5MGcT8eDg63bmOhJIHs370d89A8cZWnd6rE j+3EMMOZexDueE4jvqON5QcZAE0Je33c3+MnJ3ch01bWEznAsXhj5s+S2FjEiEie7m yENJ+dzm207xSKH30FCawaKZM8AR8MOaeCO+94do= To: v6ops@ietf.org References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> From: Doug Barton Message-ID: <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> Date: Sun, 2 Apr 2017 13:23:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:23:53 -0000 On 03/31/2017 07:32 AM, Ola Thoresen wrote: > 4) The manager does not want to do all the extra work of setting up a > DHCP-server. The operator community has spoken clearly, for over a decade, that they are going to do DHCP regardless. > If all you need is an "ad hoc" network, and you don't need to know who > the clients are, or control the assignment of addresses and don't care > as long as they get on "the internet" somehow. Why bother with DHCP? Can you give examples of where such networks might exist? At home, potentially (but even home routers come with DHCPv6 nowadays). Certainly nowhere in any modern enterprise. > You dont need to be "stupid". For "IoT" (for whatever that term i > worth) it makes no sense to have to set up DHCP just to get the devices > online. Even if they have enough resources to run a dhcp client, it > should not be necessary. I'll ask you the same question I asked Owen. What are these theoretical constrained devices that cannot run DHCP, yet have the memory and processing power to do DNS lookups, and then do something useful with the results? Doug From nobody Sun Apr 2 13:42: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 094C31293FF for ; Sun, 2 Apr 2017 13:42:03 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 j12pinWpp0gU for ; Sun, 2 Apr 2017 13:42:01 -0700 (PDT) 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 DC8DC129329 for ; Sun, 2 Apr 2017 13:42:00 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C10C061CA0 for ; Sun, 2 Apr 2017 22:41:58 +0200 (CEST) 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 88BD561C2F; Sun, 2 Apr 2017 22:41:58 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 7AE603531; Sun, 2 Apr 2017 22:41:58 +0200 (CEST) Date: Sun, 2 Apr 2017 22:41:58 +0200 From: Gert Doering To: Doug Barton Cc: v6ops@ietf.org Message-ID: <20170402204158.GK25069@Space.Net> References: <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:42:03 -0000 Hi, On Sun, Apr 02, 2017 at 01:23:49PM -0700, Doug Barton wrote: > On 03/31/2017 07:32 AM, Ola Thoresen wrote: > > > 4) The manager does not want to do all the extra work of setting up a > > DHCP-server. > > The operator community has spoken clearly, for over a decade, that they > are going to do DHCP regardless. No. Some people, mostly from the Enterprise camp, have, but that is not "the operator community speaking with one voice". I'm an operator, and mostly happy with SLAAC+RDNSS. That doesn't mean I'm *opposed* to having stateless DHCPv6 MTI, and having IA_NA around as a useful tool for more strictly managed environments. To the contrary. I just do not want words to be put into my mouth. 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 Sun Apr 2 13:52: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 2338F1293DA for ; Sun, 2 Apr 2017 13:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dw4DJalheRn for ; Sun, 2 Apr 2017 13:52:52 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 9E451129329 for ; Sun, 2 Apr 2017 13:52:52 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id ACB3E85 for ; Sun, 2 Apr 2017 13:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491166375; bh=G1SLcLpCs/cNYRDT9lIMtiKvR7ur6AsTzVeEFKLyxZk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=edFx42yWrE/b7Z7sjCmeMa1us6ojVrY+Tra3nGXqDOI56zyUazRgk+uxeRSU/5o9U wp2hosqXJ9cmW0H3DpGKVc2ep34ErRLChoecWQqAB9+6uK30I3xYo8lrCNofxcBkEW xf4fTMV0Tet6wGiUjIPH/wpEkx5TPUgDH64bbaoE= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> From: Doug Barton Message-ID: <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> Date: Sun, 2 Apr 2017 13:52:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:52:54 -0000 On 03/31/2017 05:28 AM, Brian E Carpenter wrote: > Doug, > On 31/03/2017 16:17, Doug Barton wrote: >> On 3/29/2017 4:08 PM, Lorenzo Colitti wrote: >>> Given the discussion today on draft-gont-v6ops-host-configuration and >>> draft-ali-ipv6rtr-reqs , I'm wondering if we might find consensus to say >>> that host and router implementations MUST implement RDNSS. >> >> No. >> >> People who like it can implement it, people who don't, shouldn't have to. > > The word "implement" is hopelessly ambiguous. No, it's a term of art, that I chose with great care. Completely aside from my long experience in the IETF, my term as GM of the IANA (which partially overlapped your term as IETF chair), and my 17+ years as a FreeBSD developer; frankly I'm a little bit insulted that you didn't assume that I was using it both correctly, and intentionally. OTOH I can't expect everyone to keep everyone's resumes in mind all the time, so I forgive you. :) > As far as a vendor or open source developer is concerned, the suggestion > is that they MUST include code for both methods. I'd be a bit more precise > and add that they MUST both be enabled by default in hosts, and at least one > MUST be enabled by default in routers, and they MUST be individually configurable > on or off in all nodes. This is a terrible idea, for all of the reasons that I have expressed already today. Most importantly for the reason that the IETF should not be pushing the cost of its own inability to get its act together onto vendors. Doug From nobody Sun Apr 2 13:58: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 BC4D5129329 for ; Sun, 2 Apr 2017 13:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHtfHvWwlOtT for ; Sun, 2 Apr 2017 13:58:02 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 9BE9112953A for ; Sun, 2 Apr 2017 13:58:02 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id AA61D85 for ; Sun, 2 Apr 2017 13:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491166685; bh=fWWGmeyIfl7iTDD9o+QO4r4O82l/mdD8o7ggHpYv6RI=; h=Subject:References:To:From:Date:In-Reply-To:From; b=tD5qxFbs4yMj0vMBchgUEdqikcoCC+UOdzAoWXkGz4Yqe6lBrb1OTFHj/tBZllDAU nicXRCeuk57SXaivxgIKlsi+K+Be+M42iU0gP68QQ5eE5hinODcefZqoexBPGANYmC R4jK+ZSFjFXXbEUbDy2uPMJOyn0QEnaPwKHy3Y/k= References: <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> <20170402204158.GK25069@Space.Net> To: v6ops@ietf.org From: Doug Barton Message-ID: <885144b0-7ec4-5fa7-6b79-0c4a77f0dd11@dougbarton.us> Date: Sun, 2 Apr 2017 13:58:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170402204158.GK25069@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:58:04 -0000 On 04/02/2017 01:41 PM, Gert Doering wrote: > Hi, > > On Sun, Apr 02, 2017 at 01:23:49PM -0700, Doug Barton wrote: >> On 03/31/2017 07:32 AM, Ola Thoresen wrote: >> >>> 4) The manager does not want to do all the extra work of setting up a >>> DHCP-server. >> >> The operator community has spoken clearly, for over a decade, that they >> are going to do DHCP regardless. > > No. Some people, mostly from the Enterprise camp, have, but that is > not "the operator community speaking with one voice". Fair enough, but at the same time it's worth pointing out that without major enterprise support the vendors aren't going to move, and that enterprises account for the overwhelming majority of hosts under management where these issues matter in the first place. > I'm an operator, and mostly happy with SLAAC+RDNSS. > > That doesn't mean I'm *opposed* to having stateless DHCPv6 MTI, > and having IA_NA around as a useful tool for more strictly managed > environments. To the contrary. ... just as I am not opposed (at this stage) to the mere existence of RDNSS. I simply don't want it to be mandatory. :) > I just do not want words to be put into my mouth. Again, fair enough, and my apologies for speaking too broadly. Doug From nobody Sun Apr 2 14:13: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 00758129548 for ; Sun, 2 Apr 2017 14:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw2Lkip6Oby8 for ; Sun, 2 Apr 2017 14:12:54 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6706B1292FC for ; Sun, 2 Apr 2017 14:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491167520; x=1491772320; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=r3r9NReRFVSJV+FdJu37EmABi ocsOgbjrmm6vxHNLsc=; b=NbTHNsxcW4gluu/ppelkbzjyojlOpJwm2v6syiV+i 91x5K+z55mZ8ckVDLKrdQ/omEteohDgFdXv3ZBC4H4PRYdX4a93MVbbTS9Wtwdge /TKqlLRli/1XxCiP+Z68Mu64DFos64qmy3BSUypCgf0Pf6m2kjRNVJu4PE28LRxq f0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=K1kaoJbctobRQ66FqzRUIX0FW6a2O7hN4lZQv6YmFQmHzURRYJvju9aa71CT lo5SYIgNPADDCBQDuE8EcsYzuqqEnAogauh6K+aCdG2XLY8wuOmW5S20H aIQnGnzqHHHLx/mZnec+lY8DRISsbgPd87JWJu4qVnfBGiGo1YVZ88=; X-MDAV-Processed: mail.consulintel.es, Sun, 02 Apr 2017 23:12:00 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 02 Apr 2017 23:11:59 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005400661.msg for ; Sun, 02 Apr 2017 23:11:58 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170402:md50005400661::jMO/pCLKMJVtdczO:00002EKz X-Return-Path: prvs=1265f0bd07=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Sun, 02 Apr 2017 23:11:54 +0200 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: Thread-Topic: [v6ops] Outcomes from v6ops@IETF98 References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> In-Reply-To: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 21:12:59 -0000 Hi Fred, +1 for the new chapter. Regarding the interim meeting, do we really need that? I don=E2=80=99t thin= k so, and for some of the participants, it may be an extra cost that not ev= erybody can afford, or for some may be even difficult to attend even remote= ly if organized with so short notice as May with already a few meetings org= anized from long time ago =E2=80=A6 unless, is a short meeting that we can = coordinate for example with RIPE (8-12 May, Budapest) or LACNIC (22-26 May,= Foz do Igua=C3=A7=C3=BA) meetings which are being hold also in May, and th= ey can spare a meeting room for us for 3-4 hours? Of course, this is only v= alid if many of the intended participants are also there. Regarding the new WG items, I have the same understanding that the 3 docume= nts have been adopted. In fact, I just submitted a new version as WG 00 =E2= =80=A6 Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: v6ops list Fecha: mi=C3=A9rcoles, 29 de marzo de 2017, 22:40 Para: v6ops list Asunto: [v6ops] Outcomes from v6ops@IETF98 I have attached a pdf of the proposed charter as it ended this afternoo= n. I invite public commentary (to v6ops@ietf.org), and if you support using= it as it stands, please say so.. =20 One question I intended to ask and didn't get to was the appropriatenes= s of an interim meeting, perhaps in mid-May. It would primarily address dra= ft-ietf-v6ops-ula-usage-considerations and draft-petrescu-v6ops-ipv6-power-= ipv4, and potentially draft-ietf-v6ops-design-choices if it is updated. The= re is an argument for leaving these to IETF 99, and potentially booking a s= econd slot for that discussion. Your opinions? =20 We have two WGLCs in progress or about to be so. The WGLC on draft-ietf= -v6ops-unique-ipv6-prefix-per-host, which Ron opened on 14 March, will end = on 9 April. We will then open a WGLC on draft-ietf-v6ops-v4v6-xlat-prefix, = to end 23 April. =20 I believe that the discussion today supported adoption of the following= as working group drafts: draft-ali-ipv6rtr-reqs (as draft-ietf-v6ops-ipv6rtr-reqs) draft-palet-v6ops-rfc7084-bis (as draft-ietf-v6ops-rfc7084-bis) draft-pauly-v6ops-happy-eyeballs-update (as draft-ietf-v6ops-happy-eyeb= alls-update) =20 None of these can be considered to be "done". I would encourage people = with comments to make them to the list, carrying the draft name in the subj= ect line, and including suggested text for anything specific. =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Apr 2 14:42: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 DC1B8128B44 for ; Sun, 2 Apr 2017 14:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 n_55Fy1z0Ef6 for ; Sun, 2 Apr 2017 14:42:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 42EA6127077 for ; Sun, 2 Apr 2017 14:42:11 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32Lf457006911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 14:41:06 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> Date: Sun, 2 Apr 2017 14:41:04 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DC3DE6D-825B-4572-B617-1DA4D788E4B8@delong.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 14:41:07 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 21:42:14 -0000 > On Apr 2, 2017, at 1:52 PM, Doug Barton wrote: >=20 > On 03/31/2017 05:28 AM, Brian E Carpenter wrote: >> Doug, >> On 31/03/2017 16:17, Doug Barton wrote: >>> On 3/29/2017 4:08 PM, Lorenzo Colitti wrote: >>>> Given the discussion today on draft-gont-v6ops-host-configuration = and >>>> draft-ali-ipv6rtr-reqs , I'm wondering if we might find consensus = to say >>>> that host and router implementations MUST implement RDNSS. >>>=20 >>> No. >>>=20 >>> People who like it can implement it, people who don't, shouldn't = have to. >>=20 This is the current state of things and it=E2=80=99s frankly, rather = awful from a network operator/administrator/end-user perspective. [snip] =E2=80=94 No need for squabbling over the ambiguity or use of the = term implement >> As far as a vendor or open source developer is concerned, the = suggestion >> is that they MUST include code for both methods. I'd be a bit more = precise >> and add that they MUST both be enabled by default in hosts, and at = least one >> MUST be enabled by default in routers, and they MUST be individually = configurable >> on or off in all nodes. >=20 > This is a terrible idea, for all of the reasons that I have expressed = already today. Most importantly for the reason that the IETF should not = be pushing the cost of its own inability to get its act together onto = vendors. I disagree. Not with your statement, but, with the idea that the = statement above applies in this case. The existence of SLAAC and DHCP6 both rather than a single = one-size-fits-all solution in IPv6 from the IETF is not so much the IETF = failing to get its act together as a representation of the diversity of = stakeholders and the fact that no single host auto configuration = mechanism fits the needs of all stakeholders today. As such, the = operators themselves and not the IETF or vendors should be making the = decision about which one(s) to implement in any particular operational = network. The only way to make that possible is to make SLACC+RDNSS and DHCP6 = support mandatory in host and router capability requirements. There are = already relatively well defined mechanisms for expressing which subset = of the two protocols is desired on any given network through the use of = the A, M, and O bits of the RA. I don=E2=80=99t think that the client node should necessarily be able to = configure them on or off as that would create an override bypassing the = operator=E2=80=99s intended configuration expressed in the A, M, and O = bits of the RA. Of course, even if we prohibit same, some client = implementations will likely include it, but I would argue that from an = IETF perspective, the expression desired is either =E2=80=9CMUST NOT=E2=80= =9D or at the very least =E2=80=9CSHOULD NOT=E2=80=9D in terms of direct = client configuration of same. The exception would be a client which is = configured statically, which by definition bypasses RA and ignores the = A, M, and O bits as well as all other information in the RA. Owen From nobody Sun Apr 2 14:48: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 5A8C8127F0E for ; Sun, 2 Apr 2017 14:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQlMAKLgomk0 for ; Sun, 2 Apr 2017 14:48:54 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48042126B7F for ; Sun, 2 Apr 2017 14:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491169684; x=1491774484; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=FzoXgvrIbejFNzqgbKP7sOY9nOqh60tskXAmdNoAUHs=; b=NmH jfZ4r48V/2FrZhgtIWk6P8w9zXVYRQaeSkVeSempgPt5IkOwTp6M1K37k2En3zEg 0h3/Jzh3Titu85F4k74JcaxoCUEoZYxPrbDomoOjbZzWX4pg/MdusTSLTT9OWTuG 047zP2GKY2gm9I4s16lYOtn3CZqyX6WrgLitbcFI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=q+vZnXVnNKQVUxtFTKg+L1iixi7tTafbL/HvIjSV0134/yosobK5dwQL3CPH uTn3PEruANCMRQ0qQz981Y7gq9InoLxfd6+y3YLsdHV5GxX3y0yjSZkUW mnaJh9SDtXXhvpiyoEzbb7gDIgOzPa5JPxdJs8x9Dinq+YFmXA/Etk=; X-MDAV-Processed: mail.consulintel.es, Sun, 02 Apr 2017 23:48:04 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 02 Apr 2017 23:48:04 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005400678.msg for ; Sun, 02 Apr 2017 23:48:03 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170402:md50005400678::KWHkrdfF1J37WLCM:00000PIU X-Return-Path: prvs=1265f0bd07=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Sun, 02 Apr 2017 23:47:59 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt In-Reply-To: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 21:48:56 -0000 Hi all, I=E2=80=99ve submitted WG 00 for this document. https://datatracker.ietf.org/doc/draft-v6ops-rfc7084-bis I tried to incorporate all the inputs that I captured in the meeting, hopef= ully didn=E2=80=99t miss anything!, plus some minor edits. Here is the summary for the changes: 1) Added an annex (A) regarding the code considerations as I mention in my = presentation. 2) Added an annex (B) with the changes from the original RFC7084. 3) Transition mechanisms in alphabetical order. 4) Changed the IPv6-in-IPv4 transition mechanism (6RD and 6in4) to MAY inst= ead of SHOULD. 5) Added a new section regarding IPv4 multicast support in IPv6-only-WAN. 6) Added some text regarding the PCP support to learn PLAT info in 464XLAT = (RFC 7225). I=E2=80=99ve one question for the WG. In all the IPv4-in-IPv6 transition mechanisms, I=E2=80=99m requiring: =E2=80=9CThe CE router MUST support the DHCPv4-over-DHCPv6 (DHCP4o6) transp= ort described in [RFC7341].=E2=80=9D I got a comment that this is not needed, however, my feeling is that the co= nfiguration of certain IPv4 parameters for the CPE, during the transition, = are still needed and the ISP may need that. So, the question is, what do you think about this? Please, note that the original RFC7084 didn=E2=80=99t considered this (RFC7= 341 didn=E2=80=99t exist when it was published), so the actual version is r= equesting this not just for the new supported transition mechanisms (lw4o6,= MAP T/E, 464XLAT), but also for DS-Lite. Please provide inputs ASAP. I will like to avoid having this document sleep= ing for too many weeks, and my goal is to publish a new version in about 2 = weeks with any comments received. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: domingo, 2 de abril de 2017, 22:57 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-v6ops-rfc7084-bis-00.txt =20 A new version of I-D, draft-v6ops-rfc7084-bis-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-v6ops-rfc7084-bis Revision: 00 Title: Basic Requirements for IPv6 Customer Edge Routers Document date: 2017-03-31 Group: Individual Submission Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-v6ops-rfc708= 4-bis-00.txt Status: https://datatracker.ietf.org/doc/draft-v6ops-rfc7084-bi= s/ Htmlized: https://tools.ietf.org/html/draft-v6ops-rfc7084-bis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-v6ops-rfc70= 84-bis-00 =20 =20 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers several transition technologies, as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-onl= y or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. The document obsoletes RFC 7084. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Apr 2 15:08: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 31A60127077 for ; Sun, 2 Apr 2017 15:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4mbI4yzUcvvl for ; Sun, 2 Apr 2017 15:07:58 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 634DB120724 for ; Sun, 2 Apr 2017 15:07:58 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32M6t6q007695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 15:06:56 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> Date: Sun, 2 Apr 2017 15:06:55 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <56397D1E-F117-478D-9FBA-AEA5FE1BB105@delong.com> References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 15:06:56 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:08:00 -0000 > On Apr 2, 2017, at 1:23 PM, Doug Barton wrote: >=20 > On 03/31/2017 07:32 AM, Ola Thoresen wrote: >=20 >> 4) The manager does not want to do all the extra work of setting up a >> DHCP-server. >=20 > The operator community has spoken clearly, for over a decade, that = they are going to do DHCP regardless. >=20 >> If all you need is an "ad hoc" network, and you don't need to know = who >> the clients are, or control the assignment of addresses and don't = care >> as long as they get on "the internet" somehow. Why bother with DHCP? >=20 > Can you give examples of where such networks might exist? At home, = potentially (but even home routers come with DHCPv6 nowadays). Certainly = nowhere in any modern enterprise. I know of a number of large service provider installations that do not = use DHCP6 for host addressing. There are, in fact, many such networks. Perhaps not in =E2=80=9Centerprise= IT", but in a number of research, education, trade show, service = provider, and other installations, this is, in fact, the case. >> You dont need to be "stupid". For "IoT" (for whatever that term i >> worth) it makes no sense to have to set up DHCP just to get the = devices >> online. Even if they have enough resources to run a dhcp client, it >> should not be necessary. >=20 > I'll ask you the same question I asked Owen. What are these = theoretical constrained devices that cannot run DHCP, yet have the = memory and processing power to do DNS lookups, and then do something = useful with the results? Doing a lookup for an AAAA record and doing something useful with the = result does not take nearly as much memory as doing that _AND_ running = enough of a DHCP stack to process IA_NA and all the other relevant DHCP = options required. Remember, even if you require DHCP and abandon RDNSS entirely (bad idea = IMHO), you=E2=80=99re still in a situation where you need the full stack = to do the DNS lookup, do something useful with it, _AND_ the full DHCP = client _AND_ most of the RA stack exclusive of the tiny part that parses = and processes the RDNSS option. OTOH, if you support RDNSS, then you only need the full stack to do the = DNS lookup, do something useful with it, _AND the RA stack. So.. To sum up, in both cases, you need full IPv6 stack (or at least = 6LOWPAN stack), the ability to process RAs, the ability to do a DNS = lookup, and the ability todo something useful with it. In the RDNSS case, you need a tiny additional amount of code that = processes the RDNSS options of the RA. In the DHCP case, you need a full DHCP client implementation which is = quite a bit larger than the codebase required to process an RDNSS = option. As to examples, if they ever get their IPv6 act together, an example = would be the devices sold by particle.io. Other examples would include = the various devices from espressif (ESP10 and now ESP32, for example). When vendors start making IPv6-capable chips that perform the same = functions as chips like the W5500, those will likely be examples as = well. Frankly, vendors are telling me that part of the reasons these things = don=E2=80=99t exist yet is because they can=E2=80=99t depend on RDNSS = support in their client environments due to the lack of consistent IETF = guidance to router vendors such as what you are advocating here (the = continued unfortunate status quo that we have today). So no, this isn=E2=80=99t mythology even if I can=E2=80=99t point to = real hardware running IPv6 today because I can point to real hardware = not running IPv6 today partially because of this very issue. Owen From nobody Sun Apr 2 15:09: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 C2A50126B7F for ; Sun, 2 Apr 2017 15:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGYbfIgoNOnX for ; Sun, 2 Apr 2017 15:09:02 -0700 (PDT) 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 EE167120724 for ; Sun, 2 Apr 2017 15:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491170939; bh=ItKLYmrd5/TMDJ3Q/dsEfJIs91TQB0F4fP7ADEB8Cro=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ix+TX7vZzoLL+3XaIFg0XJkuNYHAKvcjf5AyU7tG1l7SLukQjEfsmNSlnZjJldmGVtT9DTTi9Nm0dkdT2mnsokaRj6ojKt9lBWI0Idyopvv7DScpiDJRAFvh/YY9lRIqlCXmdmbs5EfZOsPKlD15FrRN3Fpe46/UazmEKBRbo00= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0143.outbound.protection.outlook.com [213.199.154.143]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-58-0vydU-5PPTGy992imAk-GQ-1; Sun, 02 Apr 2017 23:08:54 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Sun, 2 Apr 2017 22:08:53 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Sun, 2 Apr 2017 22:08:53 +0000 From: Tim Chown To: Fred Baker CC: Brian E Carpenter , v6ops list Thread-Topic: [v6ops] Outcomes from v6ops@IETF98 Thread-Index: AQHSqMzOl2pKnVBvckyLliBC42JP2KGvfgiAgAGzOwCAAR/ngIAAWKgA Date: Sun, 2 Apr 2017 22:08:53 +0000 Message-ID: References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> 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: [2001:a88:d510:1101:2c40:904f:2602:55e7] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:q/PCPOALp8CYr0Hz1SIw3ZCscWnWet+JwkLa13H7rDI+aSSGoAeCFnlxpmPEke30SgWvlxxw/wGVB8m1Ldg11jRiDPwy2VpBMnzcE0hThYYmLoaOqJW1UeEByHySFcCxE2Krf4J6ki99qfyHoVJFqeB05lv5krtzPcX9zoRjAsUXP4Tvs8ET2OgxaUIxl/dySs2fBVcto2vql1RpcGstWCFp7zvlzp0ExgU52yqTGVsESxghgxyUmZMu4qBHwlzGe8whaRD3o+kzULNAjGl+dkaleVBe4Hu1zcvBfTDK7On7NvKLflT4S6tv+Jx1e8uqDbzl6PukLTxMHaS1Ivguig==; 20:M5BHABpPayRaHd4RVhAGCHOmlnimYCFj8FpGCoILvqZzmT7IOc5uMkqekDkO//MLRPVdzFmRr+Xa4rBaS1O9Tjwbu4JIxED2RqgiUthmSDKrThvYmQUuDLRMcjxQQcs868JGI+hLcB3CVyx9lB0DxhBxDqsQUOrrD7r7kVzMCUE= x-ms-office365-filtering-correlation-id: 6e8c9113-03e9-42da-3647-08d47a14d962 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39840400002)(39450400003)(24454002)(377454003)(39060400002)(38730400002)(53936002)(3660700001)(110136004)(6116002)(102836003)(5660300001)(6246003)(99286003)(7736002)(4326008)(305945005)(6506006)(42882006)(6306002)(2950100002)(8936002)(6916009)(54906002)(74482002)(86362001)(6512007)(93886004)(6436002)(8676002)(189998001)(33656002)(5250100002)(81166006)(25786009)(50226002)(53546009)(229853002)(36756003)(5890100001)(57306001)(83716003)(3280700002)(2906002)(82746002)(2900100001)(6486002)(50986999)(76176999)(32563001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <30A01FBBC7E47C4B9549561A539383BD@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2017 22:08:53.0015 (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: 0vydU-5PPTGy992imAk-GQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:09:05 -0000 SGkgRnJlZCwNCg0KPiBPbiAyIEFwciAyMDE3LCBhdCAxNzo1MSwgRnJlZCBCYWtlciA8RnJlZEJh a2VyLklFVEZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPj4gT24gQXByIDEsIDIwMTcsIGF0 IDQ6NDEgUE0sIFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KPj4+PiBP bmUgcXVlc3Rpb24gSSBpbnRlbmRlZCB0byBhc2sgYW5kIGRpZG4ndCBnZXQgdG8gd2FzIHRoZSBh cHByb3ByaWF0ZW5lc3Mgb2YgYW4gaW50ZXJpbSBtZWV0aW5nLCBwZXJoYXBzIGluIG1pZC1NYXku IEl0IHdvdWxkIHByaW1hcmlseSBhZGRyZXNzIGRyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLWNv bnNpZGVyYXRpb25zIGFuZCBkcmFmdC1wZXRyZXNjdS12Nm9wcy1pcHY2LXBvd2VyLWlwdjQsIGFu ZCBwb3RlbnRpYWxseSBkcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzIGlmIGl0IGlzIHVw ZGF0ZWQuIFRoZXJlIGlzIGFuIGFyZ3VtZW50IGZvciBsZWF2aW5nIHRoZXNlIHRvIElFVEYgOTks IGFuZCBwb3RlbnRpYWxseSBib29raW5nIGEgc2Vjb25kIHNsb3QgZm9yIHRoYXQgZGlzY3Vzc2lv bi4gWW91ciBvcGluaW9ucz8NCj4+IA0KPj4gU2Vjb25kZWQuIElzIHRoZSBpbnRlbnRpb24gYSBw aHlzaWNhbCBvciB2aXJ0dWFsIG1lZXRpbmcsIG9yIGJvdGg/DQo+IA0KPiBJIHdhcyB0aGlua2lu ZyBpbiB0ZXJtcyBvZiB3ZWJleCBvciBlcXVpdmFsZW50LCBzb21ld2hlcmUgaW4gTWF5IDgtMTgu IElmIGZvbGtzIHdhbnQgdG8gaGF2ZSBhIG1lZXRpbmcsIEkgaGF2ZSB0byBhbm5vdW5jZSBpdCAz MCBkYXlzIGluIGFkdmFuY2UsIHdoaWNoIG1lYW5zIEknbGwgc2VuZCBhIGRvb2RsZSBwb2xsIGFu ZCB3ZSdsbCBmaWd1cmUgb3V0IHdoZW4gdG8gaGF2ZSBpdCBkdXJpbmcgdGhpcyBjb21pbmcgd2Vl ay4gVG8gbXkgc21hbGwgbWluZCwgSnVuZSBpcyBsYXRlIGVub3VnaCB0aGF0IHdlIG1heSBhcyB3 ZWxsIGRlbGF5IGZvciBKdWx5Lg0KDQpPSzsgYXMgSm9yZGkgc2F5cywgSSBkb3VidCBtYW55IHBl b3BsZSB3b3VsZCB0cmF2ZWwganVzdCBmb3IgdGhpcy4gTWlkLXRvLWxhdGUgTWF5IHNvdW5kcyBy aWdodC4gVGhlIGFnZS1vbGQgcHJvYmxlbSBpcyBwaWNraW5nIHdoaWNoIHBhcnQgb2YgdGhlIHdv cmxkIHRvIGluY29udmVuaWVuY2UgdGhlIG1vc3Q7IEkgZ3Vlc3MgbG9va2luZyBhdCB0aGUgbG9j YWxlIG9mIHRoZSBidWxrIG9mIHRoZSBhdXRob3JzIGlzIHRoZSBmYWlyZXN0IHdheT8gDQoNCj4g TXkgKmd1ZXNzKiBhdCBhbiBhZ2VuZGEgaW4gSnVseSBpbmNsdWRlcw0KPiAgICBkcmFmdC1pZXRm LXY2b3BzLXVsYS11c2FnZS1jb25zaWRlcmF0aW9ucyBpZiBuZWVkZWQNCj4gICAgZHJhZnQtaWV0 Zi12Nm9wcy1kZXNpZ24tY2hvaWNlcyBpZiB1cGRhdGVkIGFuZCBuZWVkZWQNCj4gICAgZHJhZnQt cGV0cmVzY3UtdjZvcHMtaXB2Ni1wb3dlci1pcHY0IGlmIG5lZWRlZA0KPiANCj4gICAgZHJhZnQt aWV0Zi12Nm9wcy1oYXBweS1leWViYWxscy11cGRhdGUNCj4gICAgZHJhZnQtaWV0Zi12Nm9wcy1y ZmM3MDg0LWJpcw0KPiAgICBkcmFmdC1pZXRmLXY2b3BzLWlwdjZydHItcmVxcw0KPiANCj4gUGx1 cyBwb3NzaWJsZSBhZGRpdGlvbmFsIHdvcmsgc3VibWl0dGVkIGJldHdlZW4gbm93IGFuZCB0aGVu LiBOb3RlIHRoZSAiaWYgbmVlZGVkIjsgdGhleSBtaWdodCBiZSBhbiBhcmd1bWVudCBmb3IgYSBz ZWNvbmQgc2xvdCBpZiB3ZSBkb24ndCBoYXZlIGFuIGludGVyaW0gbWVldGluZywgYW5kIGlmIHdl IGRvIGhhdmUgb25lLCB3b3VsZCBvbmx5IGJlIG9uIHRoZSBhZ2VuZGEgaWYgdXBkYXRlZCBhbmQg dGhlcmUgaXMgd29ya2luZyBncm91cCBpbnRlcmVzdC4NCg0KSeKAmWQgYXNzdW1lIHdlIGhhdmUg YSBkcmFmdCBjdXRvZmYgb25lIHdlZWsgYmVmb3JlIHRoZSBtZWV0aW5nIHNvIHVwZGF0ZSBjb3Vs ZCBiZSBkaXNjdXNzZWQ/ICBXb3JzdCBjYXNlIHdl4oCZZCB0aGVuIGVuc3VyZSBhbiBleHRyYSBj eWNsZSBvZiB3b3JrIGJlZm9yZSBQcmFndWUuDQoNCj4gSWYgeW91IGxvb2sgYXQgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNhZ2UtY29u c2lkZXJhdGlvbnMtMDIudHh0LCB5b3Ugd2lsbCBzZWUgdGhhdCB0aGUgYXV0aG9ycyBoYXZlIGRv bmUgc29tZSBwcmV0dHkgaGVhdnktZHV0eSBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudC4gSSB0aGlu ayB0aGUgcXVlc3Rpb24gd291bGQgYmUgKGFuZCB0aGlzIGNvdWxkIGJlIGluIGVtYWlsIG9yIHZl cmJhbGx5KSB3aGF0IGFkZGl0aW9uYWwgY2hhbmdlcyBwZW9wbGUgd291bGQgbGlrZSB0byBzZWUu IEknZCBpbnZpdGUgYSB0aG9yb3VnaCByZXZpZXcgb2YgdGhlIGRvY3VtZW50IGFzIGl0IHN0YW5k cy4gSSdsbCBub3RlIHRoYXQgImxldCdzIGRlcHJlY2F0ZSBVTEEgb3IgdGVsbCBwZW9wbGUgdG8g bmV2ZXIgdXNlIGl0IiBkb2Vzbid0IGZpdCB3aXRoIGN1cnJlbnQgb3BlcmF0aW9uYWwgcHJhY3Rp Y2U7IHdoZW4gbXkgcGhvbmUgaXMgbm90IGF0dGFjaGVkIHRvIGEgV2lGaSwgdGhlIEROUyBhZGRy ZXNzIG15IHByb3ZpZGVyIG9mZmVycyBtZSBpcyBhIFVMQSBhZGRyZXNzLiAiRG9uJ3QgTkFUIiwg ZmluZSwgYnV0ICJkb24ndCBVTEEiIGFzIGEgYmxhbmtldCBzdGF0ZW1lbnQgaXMgaW5jb25zaXN0 ZW50IHdpdGggb3BlcmF0aW9uYWwgcHJhY3RpY2UgaW4gc29tZSBwcm92aWRlcnMsIGFuZCAiVUxB IGltcGxpZXMgTkFUIiBpcyBqdXN0IHNpbGx5LiBJdCBpbXBsaWVzIHRoYXQgdGhlIHN5c3RlbXMg c28gYWRkcmVzc2VkIGFyZSBub3Qgbm9ybWFsbHkgYWR2ZXJ0aXNlZCBpbiBCR1AsIG5vdGhpbmcg bW9yZSBhbmQgbm90aGluZyBsZXNzLg0KPiANCj4gZHJhZnQtcGV0cmVzY3UtdjZvcHMtaXB2Ni1w b3dlci1pcHY0IGlzIGEgYnJhbmQgbmV3IGRyYWZ0LCBzbGlwcGVkIGluIGp1c3QgdW5kZXIgdGhl IHdpcmUuIFRoZSBmaXJzdCBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSB3b3JraW5nIGdyb3VwIGlz IGludGVyZXN0ZWQ7IHRoZXJlIHdhc24ndCB0aW1lIGZvciB0aGF0IGRpc2N1c3Npb24gdG8gaGFw cGVuIGJlZm9yZSBJRVRGIDk4LiBJZiB3ZSBBUkUgaW50ZXJlc3RlZCwgd2hhdCBkbyB3ZSB0aGlu ayBvZiBpdD8NCg0KSXQgd291bGQgYmUgbW9yZSBpbnRlcmVzdGluZyBpZiB0aGUgcmVhc29ucyBm b3IgdGhlIGFkZGl0aW9uYWwgcG93ZXIgY29uc3VtcHRpb24gd2VyZSBpZGVudGlmaWVkIGFuZCBk aXNjdXNzZWQgLSB0aGVyZeKAmXMgbm8gc2lnbiBvZiB0aGlzIHRoYXQgSSBjYW4gc2VlIGluIHRo ZSBkb2N1bWVudCAtIGFyZSB0aGVyZSByZWNvbW1lbmRhdGlvbnMgZm9yIHJlZHVjaW5nIHBvd2Vy IGNvbnN1bXB0aW9uIGZvciBJUHY2LCBkaWZmZXJlbnQgdG8gSVB2ND8NCg0KPiBkcmFmdC1pZXRm LXY2b3BzLWRlc2lnbi1jaG9pY2VzIGRpZG4ndCBnZXQgdXBkYXRlZCBmb3IgdGhpcyBtZWV0aW5n LCBhbmQgc29vbmVyIG9yIGxhdGVyIHdpbGwgc2ltcGx5IGRyb3Agb2ZmIHJhZGFyLiBGb2xrcyBo YXZlIHBlcmlvZGljYWxseSBzYWlkIHRoYXQgdGhleSBmaW5kIGl0IGludGVyZXN0aW5nIGFuZCBw b3RlbnRpYWxseSB1c2VmdWwsIGJ1dCB0aGUgYXV0aG9ycyBoYXZlIGxhcmdlbHkgcnVuIG91dCBv ZiBzdGVhbS4gU28gYXQgbGVhc3QgcGFydCBvZiB0aGUgcXVlc3Rpb24gaXMgIndoYXQgaXMgdGhl IGZ1dHVyZSBmb3IgdGhpcyBkcmFmdD8iLiANCg0KSSB0aGluayB0aGVyZeKAmXMgZ29vZCBtYXRl cmlhbCwgd2VsbCB3cml0dGVuLCBpbiBkZXNpZ24tY2hvaWNlczsgaXQgd291bGQgYmUgYSBzaGFt ZSB0byBsb3NlIGl0LiBJdCB3b3VsZCBjb21wbGVtZW50IGRyYWZ0LWFsaS1pcHY2cnRyLXJlcXMg cXVpdGUgbmljZWx5LiBJIG5vdGUgdGhlIGZpcnN0IC0wMCB3YXMgbmVhcmx5IDUgeWVhcnMgYWdv IHRob3VnaCENCg0KVGltDQoNCg== From nobody Sun Apr 2 15:19: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 2D50C128B37 for ; Sun, 2 Apr 2017 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NUSK-zs4IFc for ; Sun, 2 Apr 2017 15:19:27 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 E455B126B7F for ; Sun, 2 Apr 2017 15:19:25 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 12E4885 for ; Sun, 2 Apr 2017 15:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491171569; bh=RZXB9Z1g6q15ItFSjlay6sIY3GH8zIbyruunzWlL7uE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EBBopLTpp6cjpugIUgSjl+hf4c0KpSJRpJPFxMzHIbfu1o2wklgkpqPbyehDp19Qv kkbl6g+5wNY3kaBvE1Vm37pXk4jEfFXOCce9zZbuxgf/SwmRGq1C8uFFfglxXOkk5W sTWRL2iRwAjjwIZWj30ixeLvLtLRUeOpo+9H2Ccc= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> <2DC3DE6D-825B-4572-B617-1DA4D788E4B8@delong.com> From: Doug Barton Message-ID: Date: Sun, 2 Apr 2017 15:19:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2DC3DE6D-825B-4572-B617-1DA4D788E4B8@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:19:29 -0000 On 04/02/2017 02:41 PM, Owen DeLong wrote: > >> On Apr 2, 2017, at 1:52 PM, Doug Barton >> wrote: >> >> On 03/31/2017 05:28 AM, Brian E Carpenter wrote: >>> Doug, On 31/03/2017 16:17, Doug Barton wrote: >>>> On 3/29/2017 4:08 PM, Lorenzo Colitti wrote: >>>>> Given the discussion today on >>>>> draft-gont-v6ops-host-configuration and >>>>> draft-ali-ipv6rtr-reqs , I'm wondering if we might find >>>>> consensus to say that host and router implementations MUST >>>>> implement RDNSS. >>>> >>>> No. >>>> >>>> People who like it can implement it, people who don't, >>>> shouldn't have to. >>> > > This is the current state of things and it’s frankly, rather awful > from a network operator/administrator/end-user perspective. Yes, as I pointed out elsewhere the current situation was not only entirely predictable when RDNSS was first suggested, it was, in fact, predicted. :) >>> As far as a vendor or open source developer is concerned, the >>> suggestion is that they MUST include code for both methods. I'd >>> be a bit more precise and add that they MUST both be enabled by >>> default in hosts, and at least one MUST be enabled by default in >>> routers, and they MUST be individually configurable on or off in >>> all nodes. >> >> This is a terrible idea, for all of the reasons that I have >> expressed already today. Most importantly for the reason that the >> IETF should not be pushing the cost of its own inability to get its >> act together onto vendors. > > I disagree. Not with your statement, but, with the idea that the > statement above applies in this case. > > The existence of SLAAC and DHCP6 both rather than a single > one-size-fits-all solution in IPv6 from the IETF is not so much the > IETF failing to get its act together as a representation of the > diversity of stakeholders and the fact that no single host auto > configuration mechanism fits the needs of all stakeholders today. As > such, the operators themselves and not the IETF or vendors should be > making the decision about which one(s) to implement in any particular > operational network. That is a matter of perspective, on which we disagree. > The only way to make that possible is to make SLACC+RDNSS and DHCP6 > support mandatory in host and router capability requirements. Sorry, again we disagree here. As you pointed out, different networks and environments have different needs. Let's give a theoretical counter-example to the IOT case. If I am a vendor creating a product that needs more configuration options than are available through SLAAC, I know that I have to implement a DHCP client. Since I'm doing DHCP anyway, all of the time that I spend on RDNSS implementation (which I would need to do in order to check the "Complies with RFCNNNN" check box that my customers will be looking for) completely wasted. Further, if customers find out that the RDNSS support exists, some of them will try to use it. Many of them will get it wrong, thus increasing my support costs. All of this for exactly zero benefit. Going back to the IOT crowd, they raise Cain every time DHCP is even hinted at, it's not reasonable to expect that they will agree to making it mandatory to implement, never mind actually go out and implement it. We're all in agreement that the status quo sucks. But saying that both protocols should be mandatory is a political decision, it's not good engineering. Doug From nobody Sun Apr 2 15:23: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 24F431292F4 for ; Sun, 2 Apr 2017 15:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7a-OGZ2KtKhl for ; Sun, 2 Apr 2017 15:23:53 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 35B73128B37 for ; Sun, 2 Apr 2017 15:23:53 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32MMoXW009898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 15:22:51 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: Date: Sun, 2 Apr 2017 15:22:49 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <58DE38D5.4050802@foobar.org> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 15:22:51 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:23:55 -0000 > On Apr 2, 2017, at 1:08 PM, Doug Barton wrote: >=20 > On 03/31/2017 04:09 AM, Nick Hilliard wrote: >> Simon Hobson wrote: >>> But if things are going to move forward, there has to be a = "standard" >>> setting a minimum requirement so that devices will work when plugged >>> in - at the moment there isn't that. >>=20 >> it's probably fair to assume that everyone on this list understands = the >> underlying technical issues. >>=20 >> The problem is that the primary motivation for this proposal is not >> technical but political: >=20 > Here, here. >=20 >> namely the point blank refusal of specific >> companies - on policy grounds - to implement dhcpv6 in their host >> stacks, which as a side effect has caused serious deployment problems >> for end users on production v6 networks. >>=20 >> As the ipv6 deployment problems that this is causing for end user = sites >> can no longer be ignored, it needs to be fixed. There are several = ways >> to handle this, including: >>=20 >> 1. waiting for vendors and operators to support RDNSS at the router >> stack level >=20 > Operators and vendors will not do this. They have already voted with = their feet, and have made it quite clear that DHCP is the preferred = method of host configuration. Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD = supports RDNSS=E2=80=A6 Which major router platforms are you thinking of that don=E2=80=99t = support RDNSS? In terms of hosts, Apple supports RDNSS, Linux supports RDNSS, Android = supports RDNSS, Windows can do RDNSS client using an open-source add-on = since Windows Vista. OTOH, DHCP6 is not supported by Android. So looking at the support matrix, it seems to me that from the host = implementation perspective, more hosts support RDNSS than don=E2=80=99t = and in terms of installed base, more phone handsets are ready for RDNSS = than are ready for DHCP6. When you say =E2=80=9CThe operator Community=E2=80=9D, what you really = seem to mean is =E2=80=9CThe enterprise IT community=E2=80=9D which is a = large subset of the operator community, to be sure, but not the entire = operator community. The reality is that there is an equally important = fraction of the operator community in the form of service providers, = cloud platforms, research and education networks and others, many of = whom actually do find SLAAC and RDNSS useful, have implemented it, are = running networks with it, etc. There is a significant installed base of = RDNSS/SLAAC networks out there and pretending that they don=E2=80=99t = exist does not advance this discussion in a useful way. >=20 >> 2. take a longer term approach of fixing the current limitations in >> dhcpv6 which currently make it a politically unfavourable tool to use >> for host autoconfig, then supporting dhcpv6 in the host stack >=20 > Yes, please. :) Such as? One of the biggest disadvantages it has in many of the networks = I deal with is the addition of an entire unnecessary service and = protocol stack to perform a function which is easily handled by an = additional optional datum in the RA packet (namely the RDNSS option(s)). Why do I want to have to spin up a DHCP server and manage it vs. a = two-line configuration of additional options in an RA I already have to = configure in order to give the host an address and default router to = begin with? >> 3. using the IETF policy process as a stick with which to beat = everyone >> else into compliance with your own internal policies, disregarding = the >> consequences - often scorched earth - for the rest of the v6 = internet. >>=20 >> Given the extensive practice of option #3 on v6ops, 6man and dhc in >> relation to SLAAC vs DHCPv6, I'm inclined to think that this will be = the >> inevitable outcome of MUST for RDNSS, and that it will be used as >> ammunition in future both to shout down and block future consensus on >> dhcpv6 protocol development and to force vendors and operators down = one >> particular protocol deployment path. >>=20 >> I'm genuinely sad to feel it necessary to say this, but I think it = needs >> to be stated explicitly. >=20 > You said it far more elegantly than I did, but this is the gist of = what I was trying to get across the other day. I=E2=80=99m not in favor of shutting down or shouting down DHCPv6 = development, but I=E2=80=99m flat out fed up with the status quo as it = has come from the IETF so far. The current situation is untenable to operators and end users because = there=E2=80=99s no consistent set of guidelines or requirements that = create a guaranteed interoperability between any two platforms. As such, I=E2=80=99m in favor of making both DHCPv6 and RDNSS support a = must for all routers/servers and a must for all clients which are not = otherwise resource constrained to the point that this is infeasible. For = constrained clients, I support RDNSS as a should and dhcpv6 as a = desirable. Instead of trying to ram any policy agenda or beat anyone up using the = IETF process, I=E2=80=99m trying to beat the IETF into producing a = usable standard that allows the operator to decide what is best in his = particular network. Does this come at a cost to vendors? Sure=E2=80=A6 You bet it does. SO = WHAT!! Vendors are in the business of supplying what operators need. If = they want to serve an operator community that has grown sufficiently = diverse that no one autoconfiguration solution fits all needs, then they = will have to do just that=E2=80=A6 Support more than one solution to = meet the needs of that diverse community. That=E2=80=99s what we pay = them to do. Owen From nobody Sun Apr 2 15:25: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 B3CFB128708 for ; Sun, 2 Apr 2017 15:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8jdPeQg6m2Cb for ; Sun, 2 Apr 2017 15:25:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1ED126B7F for ; Sun, 2 Apr 2017 15:25:05 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32MNrOg009969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 15:23:54 -0700 From: Owen DeLong Message-Id: <79E84FCF-9CB1-4A2E-99AD-9DB70CD8739E@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D5453CD2-AD61-481C-BE45-B5FD7C256DE3" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 2 Apr 2017 15:23:52 -0700 In-Reply-To: <5E3C53CF-3CDB-4177-AC2A-6EE5D4E32BEC@fugue.com> Cc: Nick Hilliard , IPv6 Ops WG To: Ted Lemon References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <907DA759-BEEE-454D-BEE4-B875C4022B29@delong.com> <5E3C53CF-3CDB-4177-AC2A-6EE5D4E32BEC@fugue.com> X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 15:23:55 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:25:07 -0000 --Apple-Mail=_D5453CD2-AD61-481C-BE45-B5FD7C256DE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 2, 2017, at 10:55 AM, Ted Lemon wrote: >=20 > On Apr 2, 2017, at 10:43 AM, Owen DeLong > wrote: >> Think about a 6 LOWPAN device with, maybe 512K of code (Flash) space >> and on the order of 32K of RAM that is the size of a quarter and = you=E2=80=99re in >> the ball park. >=20 > Right, and more importantly, a battery that fits in a device the size = of a quarter will not support a doubling of the packet count required to = join the network. >=20 IIRC, there are at least 4 packets required to get an address and full = set of options from DHCP, so it=E2=80=99s actually 3x the packets = (RS+RA+DHCPx4 vs. RS+RA). Owen --Apple-Mail=_D5453CD2-AD61-481C-BE45-B5FD7C256DE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 2, 2017, at 10:55 AM, Ted Lemon <mellon@fugue.com> = wrote:

On Apr 2, = 2017, at 10:43 AM, Owen DeLong <owen@delong.com> wrote:
Think about a 6 LOWPAN device with, maybe = 512K of code (Flash) space
and on the order of = 32K of RAM that is the size of a quarter and you=E2=80=99re in
the ball park.

Right, = and more importantly, a battery that fits in a device the size of a = quarter will not support a doubling of the packet count required to join = the network.


IIRC, there are at least 4 packets required to get an address = and full set of options from DHCP, so it=E2=80=99s actually 3x the = packets (RS+RA+DHCPx4 vs. RS+RA).

Owen

= --Apple-Mail=_D5453CD2-AD61-481C-BE45-B5FD7C256DE3-- From nobody Sun Apr 2 15:32:24 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 621E712702E for ; Sun, 2 Apr 2017 15:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 wcfNrME7pyUe for ; Sun, 2 Apr 2017 15:32:20 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A8A37126B7F for ; Sun, 2 Apr 2017 15:32:20 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32MVHWi010191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 15:31:18 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: Date: Sun, 2 Apr 2017 15:31:17 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <52F551E1-86A0-4109-A615-7D602ACFCF1D@delong.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> <2DC3DE6D-825B-4572-B617-1DA4D788E4B8@delong.com> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 15:31:19 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:32:22 -0000 >> The existence of SLAAC and DHCP6 both rather than a single >> one-size-fits-all solution in IPv6 from the IETF is not so much the >> IETF failing to get its act together as a representation of the >> diversity of stakeholders and the fact that no single host auto >> configuration mechanism fits the needs of all stakeholders today. As >> such, the operators themselves and not the IETF or vendors should be >> making the decision about which one(s) to implement in any particular >> operational network. >=20 > That is a matter of perspective, on which we disagree. IMHO, this is because your perspective is rather limited and apparently = rather enterprise-IT specific to the exclusion of all others. >> The only way to make that possible is to make SLACC+RDNSS and DHCP6 >> support mandatory in host and router capability requirements. >=20 > Sorry, again we disagree here. As you pointed out, different networks = and environments have different needs. Right=E2=80=A6 > Let's give a theoretical counter-example to the IOT case. If I am a = vendor creating a product that needs more configuration options than are = available through SLAAC, I know that I have to implement a DHCP client. = Since I'm doing DHCP anyway, all of the time that I spend on RDNSS = implementation (which I would need to do in order to check the "Complies = with RFCNNNN" check box that my customers will be looking for) = completely wasted. Further, if customers find out that the RDNSS support = exists, some of them will try to use it. Many of them will get it wrong, = thus increasing my support costs. All of this for exactly zero benefit. If you=E2=80=99re implementing a host that is so tightly tied to its = application that you can predict this in advance, then perhaps what is = appropriate is to create a further exemption for =E2=80=9CPurpose Built = Hosts=E2=80=9D and reduce the requirement scope to =E2=80=9Chosts = suitable for multiple purposes or likely to be subject to diverse = network requirements=E2=80=9D. > Going back to the IOT crowd, they raise Cain every time DHCP is even = hinted at, it's not reasonable to expect that they will agree to making = it mandatory to implement, never mind actually go out and implement it. Actually, I think you are wrong about that. I think that if you look at = the cain they raise, it=E2=80=99s almost all specifically about resource = constrained hosts. If you grant an exemption for those hosts, I think = you=E2=80=99d see a lot more willingness. > We're all in agreement that the status quo sucks. But saying that both = protocols should be mandatory is a political decision, it's not good = engineering. Both protocols exist. Not requiring a compatible subset across all = implementations is bad engineering. Requiring DHCP across everything is a non-starter because resource = constrained hosts really do exist and will continue to be a reality. Requiring RDNSS across everything is a non-starter because you exist and = there=E2=80=99s a vocal contingency of DHCP zealots to back you up. So=E2=80=A6 The only pragmatic solution is to require both across the = broadest possible set of hosts, exempt DHCP where absolutely necessary, = perhaps exempt RDNSS where its omission is unlikely to cause harm, and = move on. If you have a better solution, I=E2=80=99m all ears. Owen From nobody Sun Apr 2 15:35: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 A3D01128B37 for ; Sun, 2 Apr 2017 15:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMfSbqBRJD2e for ; Sun, 2 Apr 2017 15:35:33 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 EFD281200FC for ; Sun, 2 Apr 2017 15:35:32 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 04A5085; Sun, 2 Apr 2017 15:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491172536; bh=SGZ5lL1Y6oV/o/NZi5i7FEYvi1coEn5PSrF3X7mmZyc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=QMnpB18zqfH2ZrhsNjctN3EIaIc7DEWxuzKjq8iFzKLaALPviM8nurF0jQCAdhtre x5/zLM3ZBA5B57apbsyiRkpCpXuOZVMqk965sg9ajB6etQ6XIlM0JQSCKEwUfLpJTF buMSK6Yy+ov9vTFAZBlQhgZBBTf2tCArQwFZpCp4= To: Owen DeLong References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> <56397D1E-F117-478D-9FBA-AEA5FE1BB105@delong.com> Cc: v6ops@ietf.org From: Doug Barton Message-ID: <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> Date: Sun, 2 Apr 2017 15:35:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <56397D1E-F117-478D-9FBA-AEA5FE1BB105@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:35:35 -0000 On 04/02/2017 03:06 PM, Owen DeLong wrote: > >> On Apr 2, 2017, at 1:23 PM, Doug Barton wrote: >> >> On 03/31/2017 07:32 AM, Ola Thoresen wrote: >> >>> 4) The manager does not want to do all the extra work of setting up a >>> DHCP-server. >> >> The operator community has spoken clearly, for over a decade, that they are going to do DHCP regardless. >> >>> If all you need is an "ad hoc" network, and you don't need to know who >>> the clients are, or control the assignment of addresses and don't care >>> as long as they get on "the internet" somehow. Why bother with DHCP? >> >> Can you give examples of where such networks might exist? At home, potentially (but even home routers come with DHCPv6 nowadays). Certainly nowhere in any modern enterprise. > > I know of a number of large service provider installations that do not use DHCP6 for host addressing. Bully for them, but that's not relevant to my argument. I am curious though, how are they doing PD, and if they are not, how do they handle addressing their customers? > There are, in fact, many such networks. Perhaps not in “enterprise IT", but in a number of research, education, trade show, service provider, and other installations, this is, in fact, the case. I never said, "Everyone wants to do, or is doing, DHCP." My argument is that in ENTERPRISE networks, where the vast majority of dollars are spent, and where the largest numbers of hosts are under management, the operators have spoken overwhelmingly in favor of DHCP. It's also worth pointing out that in many of your examples, particularly things like trade shows where the expectation is that attendee's hosts will "just work" the reason that they can get away with not running DHCPv6 is that they are already running it for v4, and the relevant configuration is being provided that way. In those cases they wouldn't be running RDNSS, either. >>> You dont need to be "stupid". For "IoT" (for whatever that term i >>> worth) it makes no sense to have to set up DHCP just to get the devices >>> online. Even if they have enough resources to run a dhcp client, it >>> should not be necessary. >> >> I'll ask you the same question I asked Owen. What are these theoretical constrained devices that cannot run DHCP, yet have the memory and processing power to do DNS lookups, and then do something useful with the results? > > Doing a lookup for an AAAA record and doing something useful with the result does not take nearly as much memory as doing that _AND_ running enough of a DHCP stack to process IA_NA and all the other relevant DHCP options required. I don't understand this answer. Who said anything about IA_NA? What I'm looking for is an actual comparison between SLAAC (defined here as RA + RDNSS) and stateless DHCP, including the same DNS configuration info. In other words, apples to apples. Until we get some actual numbers we are simply arguing political merits, not engineering merits. If the proponents of "make RDNSS mandatory to implement" do not want to do that work, that's Ok, but their proposal should then be rejected for lack of evidence of merit. > Remember, even if you require DHCP and abandon RDNSS entirely (bad idea IMHO), ... and as I've stated several times now, is not at all what I'm proposing. > you’re still in a situation where you need the full stack to do the DNS lookup, do something useful with it, _AND_ the full DHCP client _AND_ most of the RA stack exclusive of the tiny part that parses and processes the RDNSS option. ... which is why we should have a full featured DHCP option in v6, so that those that don't want SLAAC shouldn't have to implement it. And your argument is moot if the host in question needs additional configuration options beyond RDNSS. > OTOH, if you support RDNSS, then you only need the full stack to do the DNS lookup, do something useful with it, _AND the RA stack. So, those that are designing products that meet this criteria *already have* the solution that they need. Making RDNSS mandatory doesn't change their situation in any way. > Frankly, vendors are telling me that part of the reasons these things don’t exist yet is because they can’t depend on RDNSS support in their client environments due to the lack of consistent IETF guidance to router vendors such as what you are advocating here (the continued unfortunate status quo that we have today). Thank you for validating my point that RDNSS has failed to gain market share. Your experience echoes my own in this area. However it's mystifying to me that while recognizing that we have one failed "solution looking for a problem" and one successful solution that matches what operators want, and already have deployed; your proposed fix is to bulk up the failed solution. I am sorry to repeat myself yet again, but that is a bad engineering decision. The correct engineering decision is for us to make DHCP robust, and allow implementors that do not want SLAAC to do away with it entirely. Doug From nobody Sun Apr 2 15:35: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 62A1B1294EF for ; Sun, 2 Apr 2017 15:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 i0NJOGH3D-pd for ; Sun, 2 Apr 2017 15:35:52 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id BA9D91293E8 for ; Sun, 2 Apr 2017 15:35:46 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32MYh3L010278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 15:34:44 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> Date: Sun, 2 Apr 2017 15:34:43 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 15:34:44 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:35:54 -0000 > On Apr 2, 2017, at 1:05 PM, Doug Barton wrote: >=20 > On 03/31/2017 12:18 AM, Simon Hobson wrote: >> Doug Barton wrote: >>=20 >>> People who like it can implement it, people who don't, shouldn't >>> have to. >>=20 >> But that is the whole problem ! As referenced some time ago, in the >> real world there is a problem where there are two ways of providing >> the information, and two ways of getting it. If router only does A >> and device only does B then device doesn't get DNS info; similarly if >> router only does B and device only does A then device doesn't get DNS >> info; in either case the problem is that you've connected a device to >> an IPv6 network and "it doesn't work". >=20 > Yes. That was the completely predictable result of the introduction of = new options to SLAAC beyond RA, and the core objection made by those of = us who have been opposing additional such options for over a decade. You=E2=80=99re kidding, right? RDNSS was the completely predictable and all too needed result of the = introduction of SLAAC without RDNSS and the idiotic assumption that you = could run a network without name servers unless you were willing to deal = with the overhead of running both RA and DHCP together. > I've snipped the rest of your message because we all know how we got = here. We have created this mess by allowing the anti-DHCP crowd to run = the asylum. We need to stop letting that happen. One could argue that we created this mess by allowing the pro-DHCP crowd = to mess up the asylum in the first place, but I understand why you = don=E2=80=99t share my perspective there. What we really need to stop is we need to stop letting the religious war = between the anti-SLAAC crowd and the anti-DHCP crowd get in the way of = useful progress for the rest of the world. I am pro-SLAAC and pro-RDNSS. I am not anti-DHCP, though if I were going to do away with one or the = other, it wouldn=E2=80=99t be SLAAC/RDNSS that would get my vote. IMHO, the rational solution is to let the operator choose what is best = in their environment. The only way to do that is to require vendors to = implement both wherever feasible. Owen From nobody Sun Apr 2 15:39: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 74B47127077 for ; Sun, 2 Apr 2017 15:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 n3BexE6RA-3N for ; Sun, 2 Apr 2017 15:39:37 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 05F4E1267BB for ; Sun, 2 Apr 2017 15:39:36 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v32McYZx010445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 15:38:34 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <81eb9509-9510-db3c-2949-99be43856c75@dougbarton.us> Date: Sun, 2 Apr 2017 15:38:33 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <907DA759-BEEE-454D-BEE4-B875C4022B29@delong.com> <81eb9509-9510-db3c-2949-99be43856c75@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 15:38:35 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:39:38 -0000 > On Apr 2, 2017, at 12:59 PM, Doug Barton wrote: >=20 >=20 >=20 > On 04/02/2017 10:43 AM, Owen DeLong wrote: >>=20 >>> On Mar 31, 2017, at 8:52 AM, Nick Hilliard wrote: >>>=20 >>> Ted Lemon wrote: >>>> Then you are requiring all constrained devices to spend more = resources. >>>=20 >>> claims about dhcpv6 being unsuitable for resource constrained = devices >>> are often made but rarely substantiated. I'm not saying that this = isn't >>> a problem, but it would be helpful if we had some level of = understanding >>> in v6ops about the scale of the issue and whether this is a serious >>> enough thing that it ought to hold up standardisation of what would >>> otherwise be sensible and practical long term fixes to otherwise >>> difficult problems. >>=20 >> Think about a 6 LOWPAN device with, maybe 512K of code (Flash) space >> and on the order of 32K of RAM that is the size of a quarter and = you=E2=80=99re in >> the ball park. >>=20 >> Do these constitute the majority of IT spend anywhere? No. Will they = likely >> comprise a significant number of hosts in the future=E2=80=A6 You = bet!! >>=20 >> IOT is not a myth and some day developers will pull their heads out = of their >> asses and start implementing it with real address space. >=20 > I'm with you on needing to spec things that meet actual market = demands. But, a few questions related to that theoretical device. >=20 > 1. Why is it doing DNS lookups? Because a lot of these sensor packs deliver their data by making an HTTP = POST request. > 2. What is it using to make the DNS lookups? Usually a library call to gethostinfo() > 3. How does the size/complexity of the code necessary for stateless = DHCPv6 to get address and/or DNS configuration compare to the = size/complexity of the equivalent code for SLAAC? 99% of the code for SLAAC is needed just to get to where you can see the = M bit and act on it to go ask DHCP6 the question. The added code to process the RDNSS option in the RA packet is pretty = small. Maybe 1 or 2k octets on most platforms. Most DHCP6 implementations are on the order of 32K or more in my = experience. > Until we have those answers, I agree with Fred that this is a purely = political discussion. Political or not, the reality is that the current status quo sucks for = network operators and end users and unless someone has a better solution = to that situation, whether it=E2=80=99s considered political or = technical, we should do this. Owen From nobody Sun Apr 2 15:52:24 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 F06E81293F3 for ; Sun, 2 Apr 2017 15:52:22 -0700 (PDT) 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, 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=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 z93bnFKzbdhq for ; Sun, 2 Apr 2017 15:52:21 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::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 D8651127077 for ; Sun, 2 Apr 2017 15:52:20 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id f84so10587176ioj.0 for ; Sun, 02 Apr 2017 15:52:20 -0700 (PDT) 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=/j7rOZjKoeH2GHMRLdD0iLxX6eBYNpL8MsAFvJf+C6o=; b=sIc8nh29JluFe60WSpxHgDdeDoSnYcCRkHTYj6PL3KvYbqlXed1O93Lqs60Cq7J8KB fRcxCLuADWI2DSpVq/RJbDZqp2IexUNTjsBz6OEiik9XoXrpoZj6vj0q9JAHJGDeWNSv bXbaF1Nmwe7y7KIJXmkzNWbUvUik1C6JkVaLb2nclempE92YHqvcS/vduf6EMVHQdROg +bfQDtal7IoROnRgCJK3YqWF+fXxVUBR/pXSOI12Oi7JJqVk+l00SkMMB7z+g701ONYd XZYJsYJkbHYgvnfoajWkDJpi7f3xwOdO1/m1JyWWKKBU0iuj83c+y9o0kfAhiEefAPRZ tIVQ== 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=/j7rOZjKoeH2GHMRLdD0iLxX6eBYNpL8MsAFvJf+C6o=; b=uItXUhJpuGU2gF6VywczLKswL9fxZ1d76Jsw1z+xtO69bTaUYWEyG39EF26xY7RuCt 3W8WL520eIAzyMi8AF31ZuP6R7gslIwu4qPI6ZM7wpip344wHdhmpanz7YsCBqGY1END B36LA7I5QOLGwULMUQMGdPsvUEvx7fUdiMd6a9JGS7jn5SzeRn6MiLZM4kiRCj38lR6J syd8LJCK1qCv1lZ5nSDoYwXdmF0YAPc1czfBe1/vrM99RDnwlu7eB9nnv+Mv73lpZ/7N KeK/IzaRCyua349D8oyXpMbKULKUiFU9YMGoI1Rq01DkhljA7sXcKAPL42tmj8vQbLi2 qNlg== X-Gm-Message-State: AFeK/H1XK9UornDNz6lrOyUhdBTC7nea+9KUhDIYcaCCocTDZGTLlmEkBZTAkq4caJa2aA== X-Received: by 10.107.152.84 with SMTP id a81mr15228657ioe.207.1491173540031; Sun, 02 Apr 2017 15:52:20 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 141sm6819358ioe.47.2017.04.02.15.52.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 15:52:19 -0700 (PDT) To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 3 Apr 2017 10:52:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:52:23 -0000 Doug, A few points, on three of your messages: On 03/04/2017 08:02, Doug Barton wrote: > On 04/01/2017 09:02 AM, Brian E Carpenter wrote: >> I was actually arguing that making them both a MUST implement is "more" >> valid because it increases that chance that an arbitrary host will work >> on an arbitrary network. > > No, it wouldn't, because "MUST support" is not the same as "MUST > provide." And people are going to continue configuring their network the > way they want to in any case. Your understanding of statistics and probability seems to be a bit different from mine. What we have out there is, in practice, a random mixture of hosts of all ages connected to a random mixture of better or worse managed networks using routers of all ages. All I'm saying is that the more implementers are chivvied in the direction of implementing both solutions, the more interoperability we will get, statistically, over the next decades. That is true precisely *because* operators will configure their networks the way they want to, not the way some RFC says. On 03/04/2017 08:05, Doug Barton wrote:> On 03/31/2017 12:18 AM, Simon Hobson wrote: >> Doug Barton wrote: >> >>> People who like it can implement it, people who don't, shouldn't >>> have to. >> >> But that is the whole problem ! As referenced some time ago, in the >> real world there is a problem where there are two ways of providing >> the information, and two ways of getting it. If router only does A >> and device only does B then device doesn't get DNS info; similarly if >> router only does B and device only does A then device doesn't get DNS >> info; in either case the problem is that you've connected a device to >> an IPv6 network and "it doesn't work". > > Yes. That was the completely predictable result of the introduction of > new options to SLAAC beyond RA, and the core objection made by those of > us who have been opposing additional such options for over a decade. > > I've snipped the rest of your message because we all know how we got > here. We have created this mess by allowing the anti-DHCP crowd to run > the asylum. We need to stop letting that happen. That is grossly unfair. My recollection is that RDNSS was added not as an anti-DHCP provocation, but because we have always had a target "market" for IPv6 that we referred to in the early days as the "dentist's office scenario" where people with zero skill could plug stuff together and it would work. Given SLAAC, the only missing link for that sceanrio was DNS server configuration, and that is why RDNSS was specified. And it works. On 03/04/2017 08:52, Doug Barton wrote: > On 03/31/2017 05:28 AM, Brian E Carpenter wrote: >> Doug, >> On 31/03/2017 16:17, Doug Barton wrote: >>> On 3/29/2017 4:08 PM, Lorenzo Colitti wrote: >>>> Given the discussion today on draft-gont-v6ops-host-configuration and >>>> draft-ali-ipv6rtr-reqs , I'm wondering if we might find consensus to say >>>> that host and router implementations MUST implement RDNSS. >>> >>> No. >>> >>> People who like it can implement it, people who don't, shouldn't have to. >> >> The word "implement" is hopelessly ambiguous. > > No, it's a term of art, that I chose with great care. Completely aside > from my long experience in the IETF, my term as GM of the IANA (which > partially overlapped your term as IETF chair), and my 17+ years as a > FreeBSD developer; frankly I'm a little bit insulted that you didn't > assume that I was using it both correctly, and intentionally. OTOH I > can't expect everyone to keep everyone's resumes in mind all the time, > so I forgive you. :) My observation is that the word "implement" is ambiguous. I have often heard or seen it used such that it was impossible to know whether it meant "write the code" or "switch it on." >> As far as a vendor or open source developer is concerned, the suggestion >> is that they MUST include code for both methods. I'd be a bit more precise >> and add that they MUST both be enabled by default in hosts, and at least one >> MUST be enabled by default in routers, and they MUST be individually configurable >> on or off in all nodes. > > This is a terrible idea, for all of the reasons that I have expressed > already today. Most importantly for the reason that the IETF should not > be pushing the cost of its own inability to get its act together onto > vendors. We've specified doing the same thing in two different ways. What we haven't done, evidently, is describe the scenarios in which the two solutions are more, or less, appropriate. That's a gap. Brian From nobody Sun Apr 2 15:54: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 50CFA1293F3 for ; Sun, 2 Apr 2017 15:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGRzy8cgsSLJ for ; Sun, 2 Apr 2017 15:54:26 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 4B7C01267BB for ; Sun, 2 Apr 2017 15:54:26 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 68B1585 for ; Sun, 2 Apr 2017 15:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491173669; bh=/6QevPQSQAv/b0+ORbia2tg8pLq7VHF6+crWZYQw5hY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CmzczFDl9YqQYUkYiBRDHKwY+DH8pfD/94zkM3LtbkAjvJUr96DyNqCAjLuN21lqj eB7LOp2mq8CNthm/o3pewZlkBVK381/pGRyH801qBC/X5kypGqREHtOKKqID2UjvVD 4VneBzfLXnkHJs4Vvs51L8thjHKvDR7yxoNIDfMc= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <58DE38D5.4050802@foobar.org> <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> From: Doug Barton Message-ID: <737af17b-801d-3af7-8479-41c091967c46@dougbarton.us> Date: Sun, 2 Apr 2017 15:54:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:54:28 -0000 On 04/02/2017 03:22 PM, Owen DeLong wrote: > >> On Apr 2, 2017, at 1:08 PM, Doug Barton wrote: >> >> On 03/31/2017 04:09 AM, Nick Hilliard wrote: >>> Simon Hobson wrote: >>>> But if things are going to move forward, there has to be a "standard" >>>> setting a minimum requirement so that devices will work when plugged >>>> in - at the moment there isn't that. >>> >>> it's probably fair to assume that everyone on this list understands the >>> underlying technical issues. >>> >>> The problem is that the primary motivation for this proposal is not >>> technical but political: >> >> Here, here. >> >>> namely the point blank refusal of specific >>> companies - on policy grounds - to implement dhcpv6 in their host >>> stacks, which as a side effect has caused serious deployment problems >>> for end users on production v6 networks. >>> >>> As the ipv6 deployment problems that this is causing for end user sites >>> can no longer be ignored, it needs to be fixed. There are several ways >>> to handle this, including: >>> >>> 1. waiting for vendors and operators to support RDNSS at the router >>> stack level >> >> Operators and vendors will not do this. They have already voted with their feet, and have made it quite clear that DHCP is the preferred method of host configuration. > > Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD supports RDNSS… > > Which major router platforms are you thinking of that don’t support RDNSS? > > In terms of hosts, Apple supports RDNSS, Linux supports RDNSS, Android supports RDNSS, Windows can do RDNSS client using an open-source add-on since Windows Vista. Owen, you said yourself in another message that vendors don't make products that rely on RDNSS because they know they can't rely on it being present in a network. And yes, many vendors have solutions for RDNSS, but they are not all up to the same level of compliance with the latest RFCs, and this feature is not a reason anyone is going to be buying new hardware/software. The mere fact that a solution exists, in some form, does not mean that it is reliable, or widely deployed. Again, as you yourself have pointed out. > OTOH, DHCP6 is not supported by Android. Yes, that's a result of Lorenzo's religious decision not to support it. That isn't evidence that RDNSS is good, or that DHCP is bad. > So looking at the support matrix, it seems to me that from the host implementation perspective, more hosts support RDNSS than don’t How do you leap to that conclusion? > and in terms of installed base, more phone handsets are ready for RDNSS than are ready for DHCP6. How many of those handsets also support DHCPv4, and how many of them are operating on v6-only networks? (And yes, I realize that the latter number is larger than most people realize.) > When you say “The operator Communityâ€, what you really seem to mean is “The enterprise IT community†which is a large subset of the operator community, to be sure, but not the entire operator community. The reality is that there is an equally important fraction of the operator community in the form of service providers, cloud platforms, research and education networks and others, many of whom actually do find SLAAC and RDNSS useful, have implemented it, are running networks with it, etc. There is a significant installed base of RDNSS/SLAAC networks out there and pretending that they don’t exist does not advance this discussion in a useful way. I have very intentionally avoid using the term "important" in my discussion, because I agree that the other use cases you describe are also "important," whatever that means. See my previous response for why your arguments about some of those environments not doing DHCPv6 don't hold up. Meanwhile, my argument is that yes, it's largely enterprise network operators who are clamoring for robust DHCPv6, but that is "important" (again, for whatever value you want to place on it) because that's where the bulk of the money is going to be spent, and where the bulk of the hosts under management exist. I think all the low-power, IOT, restricted devices, etc. etc. are awesome (to the extent that they have decent security, can't be used as DDOS vectors, etc.) and I am not saying that RDNSS should be taken away from them. But (again, repeating myself) making it mandatory doesn't help those people. If they need it, they are already running it. >>> 2. take a longer term approach of fixing the current limitations in >>> dhcpv6 which currently make it a politically unfavourable tool to use >>> for host autoconfig, then supporting dhcpv6 in the host stack >> >> Yes, please. :) > > Such as? One of the biggest disadvantages it has in many of the networks I deal with is the addition of an entire unnecessary service and protocol stack to perform a function which is easily handled by an additional optional datum in the RA packet (namely the RDNSS option(s)). > > Why do I want to have to spin up a DHCP server and manage it vs. a two-line configuration of additional options in an RA I already have to configure in order to give the host an address and default router to begin with? If you don't want to run DHCPv6, don't. I don't care. :) My point is that people are going to run DHCP should not have to ALSO run SLAAC. To them, SLAAC is all the things you just said you don't like about DHCP. Seriously, please try to understand what I just wrote. >>> 3. using the IETF policy process as a stick with which to beat everyone >>> else into compliance with your own internal policies, disregarding the >>> consequences - often scorched earth - for the rest of the v6 internet. >>> >>> Given the extensive practice of option #3 on v6ops, 6man and dhc in >>> relation to SLAAC vs DHCPv6, I'm inclined to think that this will be the >>> inevitable outcome of MUST for RDNSS, and that it will be used as >>> ammunition in future both to shout down and block future consensus on >>> dhcpv6 protocol development and to force vendors and operators down one >>> particular protocol deployment path. >>> >>> I'm genuinely sad to feel it necessary to say this, but I think it needs >>> to be stated explicitly. >> >> You said it far more elegantly than I did, but this is the gist of what I was trying to get across the other day. > > I’m not in favor of shutting down or shouting down DHCPv6 development, but I’m flat out fed up with the status quo as it has come from the IETF so far. > > The current situation is untenable to operators and end users because there’s no consistent set of guidelines or requirements that create a guaranteed interoperability between any two platforms. That would not be the case if we made DHCPv6 robust, given that the market has already expressed its preference for it. If operators could do DHCP-only that is what they would implement, and you could rely on it being present for any network where there are hosts more complex than toasters. The status quo is the result of the anti-DHCP crowd refusing to give up on making SLAAC/RA mandatory. Making it "more mandatory" is, therefore, not the answer. Further, the anti-DHCP people know this, which is why they keep trying to make SLAAC more robust, and more mandatory. > Does this come at a cost to vendors? Sure… You bet it does. SO WHAT!! Vendors are in the business of supplying what operators need. If they want to serve an operator community that has grown sufficiently diverse that no one autoconfiguration solution fits all needs, then they will have to do just that… Support more than one solution to meet the needs of that diverse community. That’s what we pay them to do. This is laughably out of touch with reality. (You need only to look at the status quo to demonstrate that I'm right.) Doug From nobody Sun Apr 2 16:11: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 E1BB9129441 for ; Sun, 2 Apr 2017 16:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbyXn4kJMmPm for ; Sun, 2 Apr 2017 16:11:04 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 E62101293F3 for ; Sun, 2 Apr 2017 16:11:03 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 065509A for ; Sun, 2 Apr 2017 16:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491174667; bh=NxX+1uVbFPypMAmrgDHVHJ+g+2zvLgE1gMZ0FWtJ4pw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mv9Hdv6pBlYJ0dzek+fHJ5k4r+GoxIV5LPhkJQu7ZbO87nsr5tKCrV6Qxt7bgODpz BEYVqOpdosSFFCG64z0GO8JgYc2WmqgIN3RLfDddXx9HaYRmRTdor1JOtDardokCPr TM1NiITEHCN5jc7MfI6VPTloSCHLSpqWt878s6+U= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> <2DC3DE6D-825B-4572-B617-1DA4D788E4B8@delong.com> <52F551E1-86A0-4109-A615-7D602ACFCF1D@delong.com> From: Doug Barton Message-ID: <7244ff1e-1315-f855-4768-35f9f64ea33e@dougbarton.us> Date: Sun, 2 Apr 2017 16:11:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <52F551E1-86A0-4109-A615-7D602ACFCF1D@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 23:11:06 -0000 On 04/02/2017 03:31 PM, Owen DeLong wrote: >>> The existence of SLAAC and DHCP6 both rather than a single >>> one-size-fits-all solution in IPv6 from the IETF is not so much the >>> IETF failing to get its act together as a representation of the >>> diversity of stakeholders and the fact that no single host auto >>> configuration mechanism fits the needs of all stakeholders today. As >>> such, the operators themselves and not the IETF or vendors should be >>> making the decision about which one(s) to implement in any particular >>> operational network. >> >> That is a matter of perspective, on which we disagree. > > IMHO, this is because your perspective is rather limited and apparently rather enterprise-IT specific to the exclusion of all others. I've addressed this several times already. I will simply repeat my point that your perspective is obviously wrong because the market has not aligned itself to it. >>> The only way to make that possible is to make SLACC+RDNSS and DHCP6 >>> support mandatory in host and router capability requirements. >> >> Sorry, again we disagree here. As you pointed out, different networks and environments have different needs. > > Right… > >> Let's give a theoretical counter-example to the IOT case. If I am a vendor creating a product that needs more configuration options than are available through SLAAC, I know that I have to implement a DHCP client. Since I'm doing DHCP anyway, all of the time that I spend on RDNSS implementation (which I would need to do in order to check the "Complies with RFCNNNN" check box that my customers will be looking for) completely wasted. Further, if customers find out that the RDNSS support exists, some of them will try to use it. Many of them will get it wrong, thus increasing my support costs. All of this for exactly zero benefit. > > If you’re implementing a host that is so tightly tied to its application that you can predict this in advance, then perhaps what is appropriate is to create a further exemption for “Purpose Built Hosts†and reduce the requirement scope to “hosts suitable for multiple purposes or likely to be subject to diverse network requirementsâ€. No, more arguments about how to define "constrained host," "purpose built host," etc. are not only not going to help, they are going to make the problem worse (and make it that much more difficult to reach consensus). Let RA+RDNSS continue to exist for those whose needs it meets. For those folks, they know that's all they need, so that's all they run. I am totally fine with that. (POWER TO THE PEOPLE!) >> Going back to the IOT crowd, they raise Cain every time DHCP is even hinted at, it's not reasonable to expect that they will agree to making it mandatory to implement, never mind actually go out and implement it. > > Actually, I think you are wrong about that. I think that if you look at the cain they raise, it’s almost all specifically about resource constrained hosts. If you grant an exemption for those hosts, I think you’d see a lot more willingness. But if you don't over-engineer the spec in the first place, you don't have to "grant exceptions." And if you do need to grant exceptions, your idea of "mandatory" is seriously flawed. >> We're all in agreement that the status quo sucks. But saying that both protocols should be mandatory is a political decision, it's not good engineering. > > Both protocols exist. Not requiring a compatible subset across all implementations is bad engineering. Sorry, you're just flat-out wrong here. The fact that there is not "One True Solution" is offensive to certain mindsets, but it doesn't match the operational reality. > Requiring DHCP across everything is a non-starter because resource constrained hosts really do exist and will continue to be a reality. > > Requiring RDNSS across everything is a non-starter because you exist and there’s a vocal contingency of DHCP zealots to back you up. Thank you for giving me so much credit. :) But the fact that there are so many "DHCP zealots" probably should give you the idea that we're on to something. As I've pointed out several times now, if we are going to run DHCP anyway, then there is no reason for us to support RDNSS. Every dollar and person-hour spent on supporting that option is wasted. The IETF mandating it to satisfy a certain mindset that needs "One True Solution" is ludicrous on its face. Further, as you so ably point out, "Mandate both" is never going to happen, there are always going to be exceptions, and that can only lead to more confusion, and more "angels on the heads of pins" debates about what is and isn't an exception. So not only do you not get what you're asking for, you make the problems (and arguments) worse instead of better. > So… The only pragmatic solution is to require both across the broadest possible set of hosts, exempt DHCP where absolutely necessary, perhaps exempt RDNSS where its omission is unlikely to cause harm, and move on. > > If you have a better solution, I’m all ears. I've already pointed out that your thinking on possible solutions is severely constrained by assuming that SLAAC must always exist. I have offered a better solution here, and have have been offering it for over a decade: Let SLAAC/RA (and I guess we'll thrown in RDNSS too) exist for those who want it, and for whom it meets their needs. Let DHCP hand out network and gateway information so that those who are going to run DHCP anyway can do so without SLAAC. That is the simplest, lowest common denominator, best ENGINEERING solution. It eliminates the costs and complexities involved for those on the host side who only need one solution, and it will allow the market to gravitate in the direction that the money already wants to go. The only reason NOT to follow that plan is to continue to cater to those who want to avoid DHCPv6 at all costs. But that's what got us into this mess in the first place. Doug From nobody Sun Apr 2 16:23: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 38A82129432 for ; Sun, 2 Apr 2017 16:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Goie584LEt for ; Sun, 2 Apr 2017 16:23:01 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 8994A129441 for ; Sun, 2 Apr 2017 16:23:01 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id B6A2885 for ; Sun, 2 Apr 2017 16:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491175384; bh=UrrSwLed7tJpLZQvpIEy9QtwJGw5ucCHKUstLEI0mog=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q2LKX2qgD4Nycv/bXf78II2sfHdmlYp6aNTCaL5/mVPnul7jtBiePSoaiXfBRWDzw sw0ANswM+4JwsoeqlaPMI7oTSUoigxk2B55gfQ+a3865B5bVYwDYkBZcao+DsjfaDH NnQF7yukbi3tRIPImWA8qhvJoy59h4qO6se8j0oM= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> From: Doug Barton Message-ID: Date: Sun, 2 Apr 2017 16:23:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 23:23:03 -0000 On 04/02/2017 03:34 PM, Owen DeLong wrote: > >> On Apr 2, 2017, at 1:05 PM, Doug Barton wrote: >> >> On 03/31/2017 12:18 AM, Simon Hobson wrote: >>> Doug Barton wrote: >>> >>>> People who like it can implement it, people who don't, shouldn't >>>> have to. >>> >>> But that is the whole problem ! As referenced some time ago, in the >>> real world there is a problem where there are two ways of providing >>> the information, and two ways of getting it. If router only does A >>> and device only does B then device doesn't get DNS info; similarly if >>> router only does B and device only does A then device doesn't get DNS >>> info; in either case the problem is that you've connected a device to >>> an IPv6 network and "it doesn't work". >> >> Yes. That was the completely predictable result of the introduction of new options to SLAAC beyond RA, and the core objection made by those of us who have been opposing additional such options for over a decade. > > You’re kidding, right? No, not at all. > RDNSS was the completely predictable and all too needed result of the introduction of SLAAC without RDNSS and the idiotic assumption that you could run a network without name servers unless you were willing to deal with the overhead of running both RA and DHCP together. Yes, many of us pointed out at the time that RA alone would never be sufficient. Nice to see that there are many things that we agree on. :) At the time IPng was happening, DHCP in the v4 world did not have the dominant position that it does now. The idea of having a lightweight mechanism to provide addressing information to get a host on the network had a lot of merit at the time, and there are still substantial use cases for it. Far from being seen as a nuisance, "Plan A" was to get the hosts on line with RA, then reach out to DHCP, or some other configuration mechanism, to get the rest of the data a host needed. But over time the world has changed. DHCP is now firmly entrenched, and is overwhelmingly the dominant method of host configuration (where "host" includes customer premises routers for v6 PD). I could make an argument that this was true as far back as 2003, and indeed I (and others) said so at the time, and have been saying so ever since. The situation we have ourselves in now is a result of the pro-SLAAC (or anti-DHCP) crowd refusing to budge on requiring RA for addressing configuration. If we could have gone DHCP-only 10 years ago, we would have. That's still true today. >> I've snipped the rest of your message because we all know how we got here. We have created this mess by allowing the anti-DHCP crowd to run the asylum. We need to stop letting that happen. > > One could argue that we created this mess by allowing the pro-DHCP crowd to mess up the asylum in the first place, but I understand why you don’t share my perspective there. > > What we really need to stop is we need to stop letting the religious war between the anti-SLAAC crowd and the anti-DHCP crowd get in the way of useful progress for the rest of the world. > > I am pro-SLAAC and pro-RDNSS. > > I am not anti-DHCP, though if I were going to do away with one or the other, it wouldn’t be SLAAC/RDNSS that would get my vote. > > IMHO, the rational solution is to let the operator choose what is best in their environment. ... except that they can't. All of your arguments are predicated on the idea that SLAAC/RA MUST continue to exist on the wire. That's the wrong way to look at the problem. And as I've said several times now, I'm not anti-SLAAC. I think it's a great solution to a specific problem. But what we've known for over a decade is that it's not a *general* solution for host configuration. That solution is DHCP, and DHCPv6 should be given the ability to handle all of the host configuration, in the absence of SLAAC, specifically so that operators CAN choose the configuration that works for them. Doug From nobody Sun Apr 2 16:32: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 45CD6129496 for ; Sun, 2 Apr 2017 16:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1y0JXlDenyV for ; Sun, 2 Apr 2017 16:32:29 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 AAC4E12702E for ; Sun, 2 Apr 2017 16:32:29 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id C909D85; Sun, 2 Apr 2017 16:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491175952; bh=mGi5fqqL7eweSEojQzID2FMlFoxlU1nQXxwZlezxGxs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fD+etQyDMPwJyOxbYSAkjeMhCWhEUnmg7b/FqEr9zyTP6i6Vd5RgJHodPzojP+5rs NoODSgMd0NIa/aAT77J1Izfk6UVBOGFMe1pfosDNtOs9EVLY8BDtw1tD77LIDY1VoZ Y8TYFI4ik6RccFpItdnw0otL7n6jNQsrjI+bc7Ao= To: Owen DeLong References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <907DA759-BEEE-454D-BEE4-B875C4022B29@delong.com> <81eb9509-9510-db3c-2949-99be43856c75@dougbarton.us> Cc: v6ops@ietf.org From: Doug Barton Message-ID: <5592543b-2fd9-1016-c026-413810af054b@dougbarton.us> Date: Sun, 2 Apr 2017 16:32:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 23:32:31 -0000 This'll be my last one for a bit, as I'm repeating myself (apologies to the group), and we're going around in circles. But I think there is one more important point in this post, so please bear with me just a little bit longer. On 04/02/2017 03:38 PM, Owen DeLong wrote: > >> On Apr 2, 2017, at 12:59 PM, Doug Barton wrote: >> >> >> >> On 04/02/2017 10:43 AM, Owen DeLong wrote: >>> >>>> On Mar 31, 2017, at 8:52 AM, Nick Hilliard wrote: >>>> >>>> Ted Lemon wrote: >>>>> Then you are requiring all constrained devices to spend more resources. >>>> >>>> claims about dhcpv6 being unsuitable for resource constrained devices >>>> are often made but rarely substantiated. I'm not saying that this isn't >>>> a problem, but it would be helpful if we had some level of understanding >>>> in v6ops about the scale of the issue and whether this is a serious >>>> enough thing that it ought to hold up standardisation of what would >>>> otherwise be sensible and practical long term fixes to otherwise >>>> difficult problems. >>> >>> Think about a 6 LOWPAN device with, maybe 512K of code (Flash) space >>> and on the order of 32K of RAM that is the size of a quarter and you’re in >>> the ball park. >>> >>> Do these constitute the majority of IT spend anywhere? No. Will they likely >>> comprise a significant number of hosts in the future… You bet!! >>> >>> IOT is not a myth and some day developers will pull their heads out of their >>> asses and start implementing it with real address space. >> >> I'm with you on needing to spec things that meet actual market demands. But, a few questions related to that theoretical device. >> >> 1. Why is it doing DNS lookups? > > Because a lot of these sensor packs deliver their data by making an HTTP POST request. > >> 2. What is it using to make the DNS lookups? > > Usually a library call to gethostinfo() Thank you for answering this, I think it's useful info. Out of curiosity, what are the sizes of the HTTP stack, and the gethostinfo() stack? The reason I ask is that I'm trying to get an understanding of what is the marginal cost of DHCPv6 in the case of a host that already has enough code complexity to warrant needing name server data in the first place. >> 3. How does the size/complexity of the code necessary for stateless DHCPv6 to get address and/or DNS configuration compare to the size/complexity of the equivalent code for SLAAC? > > 99% of the code for SLAAC is needed just to get to where you can see the M bit and act on it to go ask DHCP6 the question. What is the size of this part of the stack? > The added code to process the RDNSS option in the RA packet is pretty small. Maybe 1 or 2k octets on most platforms. > > Most DHCP6 implementations are on the order of 32K or more in my experience. Your argument is that RDNSS is a tiny marginal cost to the size of the SLAAC stack in the first place. (Which matches my expectation, for whatever that's worth.) What I'm trying to get at is an apples-to-apples comparison of the ENTIRE size of the SLAAC stack (including RDNSS) vs. the size of the DHCPv6 stack needed to do ~the same tasks. The reason for asking this question is that (as I've pointed out already) your arguments are all predicated on "SLAAC must continue to exist in its current form." If we take away that premise, other solutions present themselves. :) Doug From nobody Sun Apr 2 16:54: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 3FE29129548 for ; Sun, 2 Apr 2017 16:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 HnjvV9kR7Lb8 for ; Sun, 2 Apr 2017 16:54:45 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 C0A751275AB for ; Sun, 2 Apr 2017 16:54:45 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id y18so6806448itc.2 for ; Sun, 02 Apr 2017 16:54:45 -0700 (PDT) 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=tRdcS5tB8fk7BSFL5KFzKiP4krQljU+seQ8L1Loj8MY=; b=cTEC+HlqIEO/ghFvVwVGr90n5hs7OwnIN05BvRlKxkKdBbYeEbhVJQlvVMYLaeqSoK TkEXiZkkXCqX41barC/qEGnhY5uJSfqwuNuyDpTS3aB4adVUPgvnpaq4IFiLymUf9/xc DTj05yVkJ7y63HAAMGEUV8U2DW62iqYcVaBBplOK99lj+WNKjlurQ8H5+28HjzsYenSP E1IRL9a3KmRSrKFhuFCNEujOU26AvWnGjf7XenCqxGo/xjptTW+DMA7Px/x3v7ZZmb+N ERxwSyHh6Bz2ePpXKZd6WyHgAeZ8YeM+Y6ZddkeX6ecUhPFtgVKB55gFMJoxc75FhEe3 UiFw== 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=tRdcS5tB8fk7BSFL5KFzKiP4krQljU+seQ8L1Loj8MY=; b=uTqFJ9BXUse+/N/oRvQ4A1qxyKyJBJ4H6p3S6Lye3b4CEtFE2VwYPmCbOqpaHK1H81 Gmg5yWvZ4UfQHDZZ9fwFm9pa5MmcreKW0+2TGFiZXXIRzY+1E4R7eNcGMMtCx6RBaR++ sX6bTSubT9q+YPzATfZJ9pqpK0jQBaBvZ/Z03/3HKsqxg4qbvOcnNId7lsHJo3JsLqkd KRncrBRC5n0l/e2ff2CJbwczZ18Bljec6QQpQRZdiqGACegEEa18+VOcYlyoqZ2QXxhQ yUY9Vw7uBnqAshMY7hp2lZsw5zxQmZp9sgVh+wqILa2W0PfkrajwmyrtdHcvnsM12piw +SoA== X-Gm-Message-State: AFeK/H2a4uPYvvh42aU09/UgV0PSO+yLW8WVDXTp64yQPVOFb+58DSVAyt+lib5PfkmBIQ== X-Received: by 10.36.67.209 with SMTP id s200mr7403524itb.37.1491177285005; Sun, 02 Apr 2017 16:54:45 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 71sm6901590iof.29.2017.04.02.16.54.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 16:54:43 -0700 (PDT) To: Doug Barton , v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 3 Apr 2017 11:54:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 23:54:48 -0000 On 03/04/2017 11:23, Doug Barton wrote: ... > And as I've said several times now, I'm not anti-SLAAC. I think it's a > great solution to a specific problem. But what we've known for over a > decade is that it's not a *general* solution for host configuration. > That solution is DHCP, and DHCPv6 should be given the ability to handle > all of the host configuration, in the absence of SLAAC, specifically so > that operators CAN choose the configuration that works for them. If you're arguing that there should be a DHCPv6 option to communicate the default router, I couldn't agree more, for exactly the same reason that we added RDNSS to RAs: so that both solutions can support a least common denominator for communication: address, router, DNS server. Brian From nobody Sun Apr 2 17:06: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 C92D1126C22 for ; Sun, 2 Apr 2017 17:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBVTnz-HmQI0 for ; Sun, 2 Apr 2017 17:06:02 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 E070B12025C for ; Sun, 2 Apr 2017 17:06:02 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id D682C85 for ; Sun, 2 Apr 2017 17:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491177966; bh=0sWqdBuhnyhqAju/BJg7NmZV0lCydwf78Y4vL7H3Ju4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bzxZcqzAUNQYjxpslHsSXtNhUppRUWH4LToV0sqpBhi8IxLnW0xIUNDrmQWBGFagZ qr880k40WCRFc87YO8uNslpF6JjCpbnpTXonnOUIKvBmLL2o8drcj0NmhFpRQtCrEU jRdTSv32iXeIbLI23PfkmEZm22jOTykbSNjLHFZ8= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> From: Doug Barton Message-ID: <41440470-2b93-841e-357d-b972d5689d8f@dougbarton.us> Date: Sun, 2 Apr 2017 17:06:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 00:06:05 -0000 On 04/02/2017 03:52 PM, Brian E Carpenter wrote: > Doug, > > A few points, on three of your messages: > > On 03/04/2017 08:02, Doug Barton wrote: >> On 04/01/2017 09:02 AM, Brian E Carpenter wrote: >>> I was actually arguing that making them both a MUST implement is "more" >>> valid because it increases that chance that an arbitrary host will work >>> on an arbitrary network. >> >> No, it wouldn't, because "MUST support" is not the same as "MUST >> provide." And people are going to continue configuring their network the >> way they want to in any case. > > Your understanding of statistics and probability seems to be a bit different > from mine. For what it's worth, mine is based on decades of experience configuring, and working with large enterprises to configure, DNS and DHCP solutions that meet real world needs. > What we have out there is, in practice, a random mixture of hosts > of all ages connected to a random mixture of better or worse managed networks > using routers of all ages. Total agreement here. > All I'm saying is that the more implementers are > chivvied in the direction of implementing both solutions, the more > interoperability we will get, statistically, over the next decades. That is > true precisely *because* operators will configure their networks the way > they want to, not the way some RFC says. On this point I don't follow you at all. The market has "voted" overwhelmingly in favor of deploying DHCP, and not deploying RDNSS. My point was that requiring vendors to implement RDNSS does nothing to encourage operators to deploy it. Where did I go wrong there? (That's a sincere question, if I missed something I want to know.) > On 03/04/2017 08:05, Doug Barton wrote:> On 03/31/2017 12:18 AM, Simon Hobson wrote: >>> Doug Barton wrote: >>> >>>> People who like it can implement it, people who don't, shouldn't >>>> have to. >>> >>> But that is the whole problem ! As referenced some time ago, in the >>> real world there is a problem where there are two ways of providing >>> the information, and two ways of getting it. If router only does A >>> and device only does B then device doesn't get DNS info; similarly if >>> router only does B and device only does A then device doesn't get DNS >>> info; in either case the problem is that you've connected a device to >>> an IPv6 network and "it doesn't work". >> >> Yes. That was the completely predictable result of the introduction of >> new options to SLAAC beyond RA, and the core objection made by those of >> us who have been opposing additional such options for over a decade. >> >> I've snipped the rest of your message because we all know how we got >> here. We have created this mess by allowing the anti-DHCP crowd to run >> the asylum. We need to stop letting that happen. > > That is grossly unfair. My recollection is that RDNSS was added not as > an anti-DHCP provocation, but because we have always had a target "market" > for IPv6 that we referred to in the early days as the "dentist's office > scenario" where people with zero skill could plug stuff together and > it would work. Given SLAAC, the only missing link for that sceanrio was > DNS server configuration, and that is why RDNSS was specified. And it > works. I am sure that is your recollection of the situation, and I don't fault you for it. I was around when RDNSS was first suggested, and I remember the same conversations you do (including the dentist's office scenario). However, I also remember that the very first proposed version of what became RDNSS had only the name server list. Those of us who were deeply involved on an operational level doing actual host configuration pointed out that the name server list is only one of several features that hosts on modern networks need to do name lookups, and that at minimum you would also need to include the search string feature, and that really if you have a host with sufficient complexity that it needs to do DNS lookups in order to get its job done the right answer is to use DHCP, which will be able to provide all of the appropriate configuration. The response to that conversation was not, "Oh, I see ... thanks!" It was instead, "Ok, we'll add the search string!" on the one hand, followed by over a decade of denial that DHCP is the right answer here, along with further attempts to glue necessary configuration elements into SLAAC. So from your perspective adding RDNSS was a perfectly reasonable response to the realization that RA alone was not sufficient. From mine it was the result of the complete failure to recognize that RA alone only ever applied to a very limited set of hosts, and never should have been made mandatory to implement in the first place. On the one hand there continues to be lack of enthusiasm for RA in the marketplace, along with ongoing clamor for robust DHCP. On the other hand, the response from the IETF has been continued insistence that RA remain mandatory. You may take offense at my characterization of this situation being allowed to exist for the better part of 14 years, followed by the current recommendations to make RDNSS, or both RDNSS and DHCP mandatory to implement (the latter being something that even its proponents recognize isn't realistic) as "the inmates are running the asylum," but I frankly can't see any other way to describe it. >> On 03/04/2017 08:52, Doug Barton wrote: >>> On 03/31/2017 05:28 AM, Brian E Carpenter wrote: >>> >>> As far as a vendor or open source developer is concerned, the suggestion >>> is that they MUST include code for both methods. I'd be a bit more precise >>> and add that they MUST both be enabled by default in hosts, and at least one >>> MUST be enabled by default in routers, and they MUST be individually configurable >>> on or off in all nodes. >> >> This is a terrible idea, for all of the reasons that I have expressed >> already today. Most importantly for the reason that the IETF should not >> be pushing the cost of its own inability to get its act together onto >> vendors. > > We've specified doing the same thing in two different ways. Only in the sense of RDNSS. > What we haven't > done, evidently, is describe the scenarios in which the two solutions are > more, or less, appropriate. That's a gap. I don't think there is any confusion on that point in the operator community. The extraordinarily limited situations where RA+RDNSS are sufficient on their own are well understood by the people that are operating those types of hosts. Everyone else wants DHCP. It's not the operators who are confused. :) Doug From nobody Sun Apr 2 17:10: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 B799B12947A for ; Sun, 2 Apr 2017 17:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS5cNflTBeA7 for ; Sun, 2 Apr 2017 17:10:11 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 5ECBF1275AB for ; Sun, 2 Apr 2017 17:10:11 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 867DD85 for ; Sun, 2 Apr 2017 17:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491178214; bh=QzIPxunapUpPWT260wkJrsRVsIJSnuRagq3KtNVle/4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=B4IU2YFwGesclwUNf91+k8CSR89OPCOKVxwh3HXbcgpjvpu+poVqH5nhxJipMuzua KNKg6EqA5athm+ZccDqxcEGcQhd+iaT9b95eHjJBpH9FPHXhxa5NYvP8I1nLn3S094 J/yfEtFYq5lO3bf+BkiFkzzK4mjO26NsO0qYwJL0= To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> From: Doug Barton Message-ID: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> Date: Sun, 2 Apr 2017 17:10:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 00:10:13 -0000 On 04/02/2017 04:54 PM, Brian E Carpenter wrote: > On 03/04/2017 11:23, Doug Barton wrote: > > ... >> And as I've said several times now, I'm not anti-SLAAC. I think it's a >> great solution to a specific problem. But what we've known for over a >> decade is that it's not a *general* solution for host configuration. >> That solution is DHCP, and DHCPv6 should be given the ability to handle >> all of the host configuration, in the absence of SLAAC, specifically so >> that operators CAN choose the configuration that works for them. > > If you're arguing that there should be a DHCPv6 option to communicate > the default router, I couldn't agree more, for exactly the same reason > that we added RDNSS to RAs: so that both solutions can support a least > common denominator for communication: address, router, DNS server. Hooray! I am genuinely happy to see common ground on this topic. :) Is it finally time to get it done? Doug From nobody Sun Apr 2 20:09: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 42C2812785F for ; Sun, 2 Apr 2017 20:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 OLhDI-TvC646 for ; Sun, 2 Apr 2017 20:09:34 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A906F12783A for ; Sun, 2 Apr 2017 20:09:34 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v3338Tv1006226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 20:08:31 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> Date: Sun, 2 Apr 2017 20:08:29 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> <56397D1E-F117-478D-9FBA-AEA5FE1BB105@delong.com> <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 20:08:32 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 03:09:37 -0000 > On Apr 2, 2017, at 3:35 PM, Doug Barton wrote: >=20 > On 04/02/2017 03:06 PM, Owen DeLong wrote: >>=20 >>> On Apr 2, 2017, at 1:23 PM, Doug Barton wrote: >>>=20 >>> On 03/31/2017 07:32 AM, Ola Thoresen wrote: >>>=20 >>>> 4) The manager does not want to do all the extra work of setting up = a >>>> DHCP-server. >>>=20 >>> The operator community has spoken clearly, for over a decade, that = they are going to do DHCP regardless. >>>=20 >>>> If all you need is an "ad hoc" network, and you don't need to know = who >>>> the clients are, or control the assignment of addresses and don't = care >>>> as long as they get on "the internet" somehow. Why bother with = DHCP? >>>=20 >>> Can you give examples of where such networks might exist? At home, = potentially (but even home routers come with DHCPv6 nowadays). Certainly = nowhere in any modern enterprise. >>=20 >> I know of a number of large service provider installations that do = not use DHCP6 for host addressing. >=20 > Bully for them, but that's not relevant to my argument. I am curious = though, how are they doing PD, and if they are not, how do they handle = addressing their customers? You asked for an example where such networks might exist. How can that = possibly not be relevant to your argument? I just provided you several = examples. Not all large service providers are ISPs and even among ISPs, not all do = dynamic prefix delegation. This kind of builds on my point about your = perspective being apparently rather limited vs. the larger world out = there. >> There are, in fact, many such networks. Perhaps not in =E2=80=9Centerpr= ise IT", but in a number of research, education, trade show, service = provider, and other installations, this is, in fact, the case. >=20 > I never said, "Everyone wants to do, or is doing, DHCP." My argument = is that in ENTERPRISE networks, where the vast majority of dollars are = spent, and where the largest numbers of hosts are under management, the = operators have spoken overwhelmingly in favor of DHCP. First, given the modern trend of cloud computing, I=E2=80=99m not = completely convinced that ENTERPRISE necessarily actually represents = either the majority of dollars or the majority of hosts. Regardless of whether that=E2=80=99s true or not, the bottom line is = that in the wider world, there are real needs for SLAAC and RDNSS on = real networks even if they aren=E2=80=99t networks that matter to you = and arguing that vendors shouldn=E2=80=99t be required to accommodate = those needs and that only DHCP should be mandatory is = counter-productive. > It's also worth pointing out that in many of your examples, = particularly things like trade shows where the expectation is that = attendee's hosts will "just work" the reason that they can get away with = not running DHCPv6 is that they are already running it for v4, and the = relevant configuration is being provided that way. In those cases they = wouldn't be running RDNSS, either. Simply not true. As an example, at the last Southern California Linux = Expo (SCALE 15x), while we did run DHCP4, we did provide IPv6 name = server information via RDNSS and we had a significant amount of IPv6 DNS = traffic and lots of IPv6 traffic in general. The vast majority of hosts = on the network did just work with SLAAC and RDNSS. Admittedly, there = were almost no Windows hosts in this case, but, frankly Windows is = increasingly becoming a minority at many of the trade shows and = conferences I attend. (Windows being the only remaining major operating = system without RDNSS support). >>>> You dont need to be "stupid". For "IoT" (for whatever that term i >>>> worth) it makes no sense to have to set up DHCP just to get the = devices >>>> online. Even if they have enough resources to run a dhcp client, = it >>>> should not be necessary. >>>=20 >>> I'll ask you the same question I asked Owen. What are these = theoretical constrained devices that cannot run DHCP, yet have the = memory and processing power to do DNS lookups, and then do something = useful with the results? >>=20 >> Doing a lookup for an AAAA record and doing something useful with the = result does not take nearly as much memory as doing that _AND_ running = enough of a DHCP stack to process IA_NA and all the other relevant DHCP = options required. >=20 > I don't understand this answer. Who said anything about IA_NA? >=20 > What I'm looking for is an actual comparison between SLAAC (defined = here as RA + RDNSS) and stateless DHCP, including the same DNS = configuration info. In other words, apples to apples. Fine=E2=80=A6 IPv6 =E2=80=94 Approximately 64k of code or 6LOWPAN approximately 32k of = code RA =E2=80=94 Approximately 18-30k of code RDNSS =E2=80=94 Approximately 2k of code DNS Resolver =E2=80=94 Approximately 12k of code TCP stack =E2=80=94 Approximately 24k of code UDP stack =E2=80=94 Approximately 14k of code DHCP stack =E2=80=94 Approximately 32k of code HTTP client =E2=80=94 Approximately 12k of code So, for minimal RA+RDNSS+HTTP we need IPv6 (64k) + RA (30k) + RDNSS (2k) = + DNS (12k) + TCP (24k) + UDP (14k) + HTTP (12k) Total: 158k (+ ~16k RAM for state/configuration information) For RA+Stateless DHCP+HTTP we need IPv6 (64k) + RA (30k) + DHCP (32k) + = DNS (12k) + TCP (24k) + UDP (14k) + HTTP (12k) Total: 188k (+ ~30k RAM for state/configuration information) Difference: 30k FLASH and ~14k RAM Doesn=E2=80=99t sound like a lot, but on a host with =E2=89=A4512k of = FLASH memory total, you=E2=80=99re talking almost 10% of the total RAM = just to support DHCP with no advantage whatsoever to the application vs. = RDNSS. Worse, many of these hosts have 64k or less of actual RAM, so a = difference of 14k is meaningful. > Until we get some actual numbers we are simply arguing political = merits, not engineering merits. Hopefully that helps. Those numbers are from a while ago and more = efficient stacks may be available, but they should provide reasonable = guidance. > If the proponents of "make RDNSS mandatory to implement" do not want = to do that work, that's Ok, but their proposal should then be rejected = for lack of evidence of merit. That work has been done by several. Of course, part of it is that the = numbers are quite variable depending on processor architecture, = codebase, etc. so the numbers I provided above might not reflect anyone = else=E2=80=99s particular installation. >=20 >> Remember, even if you require DHCP and abandon RDNSS entirely (bad = idea IMHO), >=20 > ... and as I've stated several times now, is not at all what I'm = proposing. Sure it is=E2=80=A6 Just not in so many words. You want to make DHCP = mandatory and insist that Google has to saddle the Android platform with = it, but you don=E2=80=99t want to require router vendors to support = RDNSS. >> you=E2=80=99re still in a situation where you need the full stack to = do the DNS lookup, do something useful with it, _AND_ the full DHCP = client _AND_ most of the RA stack exclusive of the tiny part that parses = and processes the RDNSS option. >=20 > ... which is why we should have a full featured DHCP option in v6, so = that those that don't want SLAAC shouldn't have to implement it. Even if you somehow leave out SLAAC, you still need to parse the rest of = the RA. Let=E2=80=99s assume you could cut back from 30 to 18k (pretty = optimistic) by eliminating the parsing of the A bit, the Prefix options = in the packet, etc. You=E2=80=99ve still only reduced things by 12k of = the 30k you=E2=80=99re adding, so it=E2=80=99s still a bad idea. > And your argument is moot if the host in question needs additional = configuration options beyond RDNSS. But most hosts just don=E2=80=99t need additional configuration options = beyond RDNSS with the notable exceptions of enterprise and imaging (and = not all imaging). >> OTOH, if you support RDNSS, then you only need the full stack to do = the DNS lookup, do something useful with it, _AND the RA stack. >=20 > So, those that are designing products that meet this criteria *already = have* the solution that they need. Making RDNSS mandatory doesn't change = their situation in any way. Sure it does. In the case of router vendors that don=E2=80=99t yet = support RDNSS, or, in the situation where they are (for reasons = admittedly passing understanding) saddled with Windows Servers. OTOH, it does mean that adding the RDNSS requirement really doesn=E2=80=99= t effect very many people other than a few developers in Redmond, WA. >> Frankly, vendors are telling me that part of the reasons these things = don=E2=80=99t exist yet is because they can=E2=80=99t depend on RDNSS = support in their client environments due to the lack of consistent IETF = guidance to router vendors such as what you are advocating here (the = continued unfortunate status quo that we have today). >=20 > Thank you for validating my point that RDNSS has failed to gain market = share. Your experience echoes my own in this area. Huh? What I=E2=80=99ve said is that because there are notable failures = of client implementations to support RDNSS, there are products that are = holding off on IPv6 implementations. If you want to use that as a justification to claim RDNSS has failed to = gain market share, then I will hold up the fact that Android has refused = to implement DHCP6 as an equally valid indication that DHCP6 has failed = to gain market share and thank you for making the same point about DHCP. The reality is that both are failures by vendors that are harming real = networks and both should be rectified. > However it's mystifying to me that while recognizing that we have one = failed "solution looking for a problem" and one successful solution that = matches what operators want, and already have deployed; your proposed = fix is to bulk up the failed solution. First, you are putting words in my mouth that simply don=E2=80=99t = represent anything remotely resembling my perspective or my statements. If there is a failed solution looking for a problem here, it=E2=80=99s = DHCP. However, I don=E2=80=99t think that is the case, either. I would say that we have a combination of failed solutions which have = resulted in incompatible implementations on both the =E2=80=9Caddress = consumer=E2=80=9D and the =E2=80=9Caddress supplier=E2=80=9D side of the = equation which has become an untenable failure which is preventing = deployment and adoption of IPv6 overall. My solution is to mandate that both the address consumer developers and = the address supplier developers be required to provide implementations = capable of supporting BOTH solutions wherever feasible so that operators = can choose whatever combination of solutions best fits their particular = environment. The mechanisms to enable operators to do so already exist in the form of = the A, M, and O bits of the RA. The part that is missing (and the most = notable failures) are RDNSS client support (Microsoft) and DHCPv6 Client = support (Android). > I am sorry to repeat myself yet again, but that is a bad engineering = decision. The correct engineering decision is for us to make DHCP = robust, and allow implementors that do not want SLAAC to do away with it = entirely. I argue that=E2=80=99s a worse engineering decision than making the = smallest number of effective changes necessary to resolve the current = situation, namely, requiring the developers/vendors to implement both = solutions whenever feasible. The simple reality is that if Microsoft = would incorporate RDNSS support and Android would incorporate DHCPv6 = Client support, we=E2=80=99d actually be more than 99% done with this = issue. I=E2=80=99m not sure why you are so resistant to this or why you believe = that solving the enterprise at the expense of virtually every other = stakeholder group somehow is a good engineering decision. Owen From nobody Sun Apr 2 20:24: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 68729126BF0 for ; Sun, 2 Apr 2017 20:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 eaXe5_K7XXYT for ; Sun, 2 Apr 2017 20:24:26 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 01040126CC7 for ; Sun, 2 Apr 2017 20:24:25 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id z204so124577651vkd.1 for ; Sun, 02 Apr 2017 20:24:25 -0700 (PDT) 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=SOCFlX63L6MdHY57Z/LNt/GCE63F/sJNQdFoYwi8W0Y=; b=ayrCVvNn88GRon6PN5SvWaRd/7VUA/wI1Z35GyvEAz6iAIlWzRLXWd47WYE33cRq+t lDqEMOE84S4GhYQcodsJeYBto9KASYvSSwgjekVGGjIiGOoCuP1gOQs0NWMyD4LxHOOK 9IDTR/HS4G3D2DcmoYIavMDMHEyL/mhk3swVdzE2TAK0HpmcHJiMz/dBf64oDrnU30wJ 9TDkdoSKY/iT0waT7w19UTOkU9uMneKUYmDJ+xQv8kFIqhbhD3LsV/R7bfas41qURMmK 5a7j6FsRFDLYwfWsNpmrQOefflrY4Qi6yMtc16lfy6ChwZOQWTzHBB1XNnlgkW+iTVZk ciZg== 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=SOCFlX63L6MdHY57Z/LNt/GCE63F/sJNQdFoYwi8W0Y=; b=eeTc9l86q1zQOOEAcOmiggScPsMBQblCoFzILAUVXc7Ci6ySeY/LYoNYVp6AFX1Qj2 Lu017yuYqTzEYG8s+IM9dvQsO8Lto3gqeVJ+kKzK8jfLdDDsBV4sxA+MFZijsDODObYl fAqv3vmey7Cte5dFTsvd1/zSa87s0KZ1bB8m7d5TYKHkkc/qaMoBPnAsLncJSU4FIUFA t5d63FokN1/5H1vpLeDT23xup2fhh9GHPFZ+qmzSVrvXJKPHtvQrneDerua75gjSrNpt umzgy3WGAnVOUw8ghw4JOSNDc1Cr3ggSLDZXS0s8wBOG0E8fO23Se+5zprwFwmeCgf8+ l8Kg== X-Gm-Message-State: AFeK/H0DRddv0Mu9NDb+06pfR+1l30qrLirTRW/iMbojW+Ofjo8+t51OJHnH2pA6rjefpYJ0S19TkM7Xy8542K/r X-Received: by 10.31.107.93 with SMTP id g90mr6676074vkc.155.1491189864812; Sun, 02 Apr 2017 20:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Sun, 2 Apr 2017 20:24:03 -0700 (PDT) In-Reply-To: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> From: Lorenzo Colitti Date: Mon, 3 Apr 2017 12:24:03 +0900 Message-ID: To: Doug Barton Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11478dd02fb069054c3ab237 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 03:24:28 -0000 --001a11478dd02fb069054c3ab237 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 9:10 AM, Doug Barton wrote: > If you're arguing that there should be a DHCPv6 option to communicate >> the default router, I couldn't agree more, for exactly the same reason >> that we added RDNSS to RAs: so that both solutions can support a least >> common denominator for communication: address, router, DNS server. >> > > Hooray! I am genuinely happy to see common ground on this topic. :) > > Is it finally time to get it done? Only if you have reason to believe that a new attempt to get consensus is going to be more successful than the past three. I very much doubt that's the case; in fact, if you proposed it again, I expect you'd see more opposition from host OS developers than there was last time. We've seen how there has been substantial opposition to "MUST implement getting DNS servers from stateless DHCPv6" from those developers - including developers of major OSes that *already implement it*. I'd expect those developers would oppose a DHCPv6 route option even more, citing the clear disadvantages it has compared to RA-only routing configuration such as inability to support multiple sources of information, difficulty/inability to update things due to lack of RECONFIGURE support, lack of fate sharing, difficulty in supporting draft-ietf-rtgwg-enterprise-pa-multihoming, lack of necessity given that we already have a way to configure routing, complexity due to having two ways of configuring the same information, etc. --001a11478dd02fb069054c3ab237 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 3, 2017 at 9:10 AM, Doug Barton <dougb@dougbarton.us> wrote:
If you're= arguing that there should be a DHCPv6 option to communicate
the default router, I couldn't agree more, for exactly the same reason<= br> that we added RDNSS to RAs: so that both solutions can support a least
common denominator for communication: address, router, DNS server.

 Hooray!=C2=A0 I am genuinely happy to see common ground on this topic. :)
Is it finally time to get it done?

Only if = you have reason to believe that a new attempt to get consensus is going to = be more successful than the past three. I very much doubt that's the ca= se; in fact, if you proposed it again, I expect you'd see more oppositi= on from host OS developers than there was last time.

We've seen how there has been substantial opposition to "MUST i= mplement getting DNS servers from stateless DHCPv6" from those develop= ers - including developers of major OSes that *already implement it*. I'= ;d expect those developers would oppose a DHCPv6 route option even more, ci= ting the clear disadvantages it has compared to RA-only routing configurati= on such as inability to support multiple sources of information, difficulty= /inability to update things due to lack of RECONFIGURE support, lack of fat= e sharing, difficulty in supporting draft-ietf-rtgwg-enterprise-pa-multihom= ing, lack of necessity given that we already have a way to configure routin= g, complexity due to having two ways of configuring the same information, e= tc.
--001a11478dd02fb069054c3ab237-- From nobody Sun Apr 2 20:39: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 1C79412025C for ; Sun, 2 Apr 2017 20:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 gwURvQ27SA2E for ; Sun, 2 Apr 2017 20:39:06 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 9EA911201F8 for ; Sun, 2 Apr 2017 20:39:06 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 21so107089863pgg.1 for ; Sun, 02 Apr 2017 20:39:06 -0700 (PDT) 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=oKxSxw+rnzQ9+Na+QRKZJ3axDIbBeMyXJEp/JjETAsI=; b=p78B7Fh00vQTxpSz5VkW+F/xJo0/I0FqTG9zwVY3hT8Ms1k9i2Y0DAiEvTmbCVRW9B 43C/2b1SZJ9EOLbPXmAvLO81mWsvO92TSpPRbprF+TkwW/XEsDXM0GFa2PcFfIrOX8RT CQTd4ImIyiPLtaQvDYFBe0s0zkyzabUW/jb3SMFQFE8MpXzvYwkAKPR8nRB8/iGEsG50 sVLNXloahLIOkXTpdvNmhbq2J2gNVmwHbrcGIKuXyhquwZkRMvgKnVnmEUQCdthIQJtU xJo+jyV/irH0cUHLad2jtlccuQkfD+C59dsDog6EeHNB6f7ay6zEkuyjjlWEyFGXmCBO 6lxg== 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=oKxSxw+rnzQ9+Na+QRKZJ3axDIbBeMyXJEp/JjETAsI=; b=nIkk31Cl9AX3+gi+VHH5kt2girJFg5N2C81FPEyoXR+/0on+lC88qMSAl1aBHpoQgK DERNzH3QzeWYWr4ucwjtUdu+HoC1rhzYKqHx04cMARjUXSwEiAYISH12d14JyNh8imy5 Uz20tKnc0MkTCKpiDlkKUmGsJZ4/YanEqrJVxIuJtgSVn0FBRPPJ/+FwbN4dUwKxeMR6 esfxllqV5Wu1sGMx2ek5JiTJo9cANgK4DvX8ULDbyC0Hfi1T3Ch5TOEr2v9o/zuumvLd iYmzouUzR04Yuw5dVyspm3UeNM+KWkHdNKuUud9hEYFEbJs1ccNGCZLdfg/WD/38tveq Br6g== X-Gm-Message-State: AFeK/H0NthXegj3leAIngRksjl8iSN4Zl/pEkD413G7GXRYNXgta7Mw6wpuPzLd8yGJxuA== X-Received: by 10.98.7.203 with SMTP id 72mr14819150pfh.197.1491190746324; Sun, 02 Apr 2017 20:39:06 -0700 (PDT) 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 y7sm22326559pfk.93.2017.04.02.20.39.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 20:39:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Sun, 2 Apr 2017 20:39:06 -0700 Cc: Brian E Carpenter , v6ops list Content-Transfer-Encoding: 7bit Message-Id: <48E707D0-B1BD-472B-890A-A8BFE9CF96A4@gmail.com> References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> To: Tim Chown X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 03:39:08 -0000 > On Apr 2, 2017, at 3:08 PM, Tim Chown wrote: > > OK; as Jordi says, I doubt many people would travel just for this. Who is suggesting that they travel? From nobody Sun Apr 2 22:20: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 7D575127863 for ; Sun, 2 Apr 2017 22:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 nC3DML7aJChc for ; Sun, 2 Apr 2017 22:20:23 -0700 (PDT) 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 1C50E120727 for ; Sun, 2 Apr 2017 22:20:23 -0700 (PDT) Received: from [192.168.0.104] (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v335KJE3096265 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Apr 2017 05:20:20 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be [192.168.0.104] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (14E277) In-Reply-To: <48E707D0-B1BD-472B-890A-A8BFE9CF96A4@gmail.com> Date: Sun, 2 Apr 2017 22:20:14 -0700 Cc: Tim Chown , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> <48E707D0-B1BD-472B-890A-A8BFE9CF96A4@gmail.com> To: Fred Baker Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 05:20:26 -0000 Sent from my iPhone > On Apr 2, 2017, at 20:39, Fred Baker wrote: >=20 >=20 >> On Apr 2, 2017, at 3:08 PM, Tim Chown wrote: >>=20 >> OK; as Jordi says, I doubt many people would travel just for this. >=20 > Who is suggesting that they travel? Almost all interims at this point are virtual so I assumed likewise. That said notification of the date for them is typically 2 or more weeks not= 4 per IESG guidance.=20 Regards=20 Joel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sun Apr 2 22: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 1BEAD126579 for ; Sun, 2 Apr 2017 22:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 PKHm9dO9ZuVD for ; Sun, 2 Apr 2017 22:50:13 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A96B8120727 for ; Sun, 2 Apr 2017 22:50:12 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v335n9x1017430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 22:49:10 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <737af17b-801d-3af7-8479-41c091967c46@dougbarton.us> Date: Sun, 2 Apr 2017 22:49:08 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2CB77688-DB75-4362-BF5E-F28200D1ACF0@delong.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <58DE38D5.4050802@foobar.org> <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> <737af17b-801d-3af7-8479-41c091967c46@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 22:49:10 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 05:50:16 -0000 > On Apr 2, 2017, at 3:54 PM, Doug Barton wrote: >=20 > On 04/02/2017 03:22 PM, Owen DeLong wrote: >>=20 >>> On Apr 2, 2017, at 1:08 PM, Doug Barton wrote: >>>=20 >>> On 03/31/2017 04:09 AM, Nick Hilliard wrote: >>>> Simon Hobson wrote: >>>>> But if things are going to move forward, there has to be a = "standard" >>>>> setting a minimum requirement so that devices will work when = plugged >>>>> in - at the moment there isn't that. >>>>=20 >>>> it's probably fair to assume that everyone on this list understands = the >>>> underlying technical issues. >>>>=20 >>>> The problem is that the primary motivation for this proposal is not >>>> technical but political: >>>=20 >>> Here, here. >>>=20 >>>> namely the point blank refusal of specific >>>> companies - on policy grounds - to implement dhcpv6 in their host >>>> stacks, which as a side effect has caused serious deployment = problems >>>> for end users on production v6 networks. >>>>=20 >>>> As the ipv6 deployment problems that this is causing for end user = sites >>>> can no longer be ignored, it needs to be fixed. There are several = ways >>>> to handle this, including: >>>>=20 >>>> 1. waiting for vendors and operators to support RDNSS at the router >>>> stack level >>>=20 >>> Operators and vendors will not do this. They have already voted with = their feet, and have made it quite clear that DHCP is the preferred = method of host configuration. >>=20 >> Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD = supports RDNSS=E2=80=A6 >>=20 >> Which major router platforms are you thinking of that don=E2=80=99t = support RDNSS? >>=20 >> In terms of hosts, Apple supports RDNSS, Linux supports RDNSS, = Android supports RDNSS, Windows can do RDNSS client using an open-source = add-on since Windows Vista. >=20 > Owen, you said yourself in another message that vendors don't make = products that rely on RDNSS because they know they can't rely on it = being present in a network. Sure, but those same vendors don=E2=80=99t make products that rely on = DHCP6 support because they can=E2=80=99t afford the bloat in the code = base that would require. Further, they can=E2=80=99t exactly depend on DHCP6 being there, either, = so the assumption that my statement somehow supports the idea that RDNSS = and SLAAC are unnecessary and only DHCP is needed is an absurd = over-extension of my statement into something I obviously didn=E2=80=99t = say. > And yes, many vendors have solutions for RDNSS, but they are not all = up to the same level of compliance with the latest RFCs, and this = feature is not a reason anyone is going to be buying new = hardware/software. The mere fact that a solution exists, in some form, = does not mean that it is reliable, or widely deployed. Again, as you = yourself have pointed out. Right and the reality is that as long as we continue this idiotic = deadlock of arguing for one solution over another at the specification = level instead of recognizing that there are legitimate needs for both = solutions in the real world and we therefor need to require vendors to = implement both solutions wherever feasible so that we can get rid of the = negative effects of the stupid religious war and move forward with = deployment recognizing that operators need to be free to choose the = solution that best fits their application instead of trying to let the = IETF or vendors pick for them, and, especially instead of allowing = vendor A to choose a single incompatible implementation option on the = server side from the single implementation chosen by a vendor B on the = client side. The simple fact is that if you have a router that supports both DHCP6 = and RDNSS and a client that supports both DHCP6 and RDNSS, then you have = a situation where the operator can choose any combination that works for = them. OTOH, if you have a router that only supports DHCP6 and a client that = only supports RDNSS, then you=E2=80=99re screwed. Similarly, if you have a router that only supports RDNSS and a client = that only supports DHCP, you=E2=80=99re also screwed. So, it seems to me that the clear choice is to require implementations = (note, this is software/hardware implementations, not deployments) to = provide support for both and allow the operator to configure the choice = they want. This should _NOT_ require specific client configuration = except in the case where the operator wants to use static client = configuration. Short of the MUST on RDNSS and DHCP6 support, everything necessary to = achieve this is in place. >=20 >> OTOH, DHCP6 is not supported by Android. >=20 > Yes, that's a result of Lorenzo's religious decision not to support = it. That isn't evidence that RDNSS is good, or that DHCP is bad. I could argue that the failure to support RDNSS on Windows and Windows = phones is equally religious stupidity on Microsoft=E2=80=99s part, but = really, where does that get us=E2=80=A6 Nowhere useful. >> So looking at the support matrix, it seems to me that from the host = implementation perspective, more hosts support RDNSS than don=E2=80=99t >=20 > How do you leap to that conclusion? Windows hosts can support RDNSS (admittedly with open source add-on = software). Between Linux, Mac, and Windows, you have the vast majority = of non-phone hosts covered. Beyond that, it=E2=80=99s mobile devices (tablets/handhelds). Windows = Phone is the only major tablet/handheld OS that doesn=E2=80=99t support = RDNSS and that=E2=80=99s clearly a tiny fraction of the overall market. So in summary, supports RDNSS: Windows, Linux, Mac, iOS, Android Does not support RDNSS: Windows Phone If you want to argue that there are more hosts in the =E2=80=9CWindows = Phone=E2=80=9D camp than all the others, I think that=E2=80=99s a pretty = hard case to make. If you are willing to stipulate to the fact that = Windows+Linux+Mac+iOS+Android =3D more hosts than Windows Phone, then = I=E2=80=99d say my statement stands=E2=80=A6 More hosts support RDNSS than do not. If you want to make the argument that Windows doesn=E2=80=99t support = RDNSS because it requires add-on software, that might be a somewhat = valid case, but even there, I don=E2=80=99t think Windows desktop is = enough to really tip that balance, though I will admit it might come = closer. According to Gartner, device shipments, 2015: Android 54% iOS/Mac 12.3% (276M iOS, 21M macOS) Windows 11.7% Others 21.6% So even if we put Windows and Others (whatever they are) together and = assume that they don=E2=80=99t support RDNSS, you=E2=80=99re looking at = 33.3%, well under half. Android alone being 54% of all device shipments in 2015 (not an = anomalous year from looking at earlier statistics), and Windows showing = a declining trend in terms of market share, I think you=E2=80=99re = really hard pressed to make the case that I am wrong, EVEN if you = include Windows desktop as =E2=80=9Cnot supporting RDNSS=E2=80=9D. >=20 >> and in terms of installed base, more phone handsets are ready for = RDNSS than are ready for DHCP6. >=20 > How many of those handsets also support DHCPv4, and how many of them = are operating on v6-only networks? (And yes, I realize that the latter = number is larger than most people realize.) Probably all of them support DHCPv4, but so what and who cares? How is that at all relevant to the damage caused to v6 deployment by = allowing vendors to implement incompatible subsets of IPv6 host auto = configuration and still claim compliance with the host requirements = RFCs? >> When you say =E2=80=9CThe operator Community=E2=80=9D, what you = really seem to mean is =E2=80=9CThe enterprise IT community=E2=80=9D = which is a large subset of the operator community, to be sure, but not = the entire operator community. The reality is that there is an equally = important fraction of the operator community in the form of service = providers, cloud platforms, research and education networks and others, = many of whom actually do find SLAAC and RDNSS useful, have implemented = it, are running networks with it, etc. There is a significant installed = base of RDNSS/SLAAC networks out there and pretending that they don=E2=80=99= t exist does not advance this discussion in a useful way. >=20 > I have very intentionally avoid using the term "important" in my = discussion, because I agree that the other use cases you describe are = also "important," whatever that means. See my previous response for why = your arguments about some of those environments not doing DHCPv6 don't = hold up. Your previous response didn=E2=80=99t really hold up IMHO. > Meanwhile, my argument is that yes, it's largely enterprise network = operators who are clamoring for robust DHCPv6, but that is "important" = (again, for whatever value you want to place on it) because that's where = the bulk of the money is going to be spent, and where the bulk of the = hosts under management exist. OK, so what? I=E2=80=99m not arguing against robust DHCPv6, I=E2=80=99m = arguing for robust requirements to support both so that operators can = decide which one to use in their network deployments. Meanwhile, you = seem to be arguing that RDNSS should remain a second class citizen which = seems ridiculous and utterly unjustifiable to me. > I think all the low-power, IOT, restricted devices, etc. etc. are = awesome (to the extent that they have decent security, can't be used as = DDOS vectors, etc.) and I am not saying that RDNSS should be taken away = from them. But (again, repeating myself) making it mandatory doesn't = help those people. If they need it, they are already running it. Wrong and wrong and wrong again. Lots of them are getting implemented = IPv4 only _BECAUSE_ there are still enough installations that don=E2=80=99= t have router-side RDNSS support. Cisco has only added it fairly = recently. There are still some vendors that don=E2=80=99t support it, = unfortunately. Making it mandatory on the router side ABSOLUTELY helps = this situation. >>>> 2. take a longer term approach of fixing the current limitations in >>>> dhcpv6 which currently make it a politically unfavourable tool to = use >>>> for host autoconfig, then supporting dhcpv6 in the host stack >>>=20 >>> Yes, please. :) >>=20 >> Such as? One of the biggest disadvantages it has in many of the = networks I deal with is the addition of an entire unnecessary service = and protocol stack to perform a function which is easily handled by an = additional optional datum in the RA packet (namely the RDNSS option(s)). >>=20 >> Why do I want to have to spin up a DHCP server and manage it vs. a = two-line configuration of additional options in an RA I already have to = configure in order to give the host an address and default router to = begin with? >=20 > If you don't want to run DHCPv6, don't. I don't care. :) My point is = that people are going to run DHCP should not have to ALSO run SLAAC. To = them, SLAAC is all the things you just said you don't like about DHCP. You don=E2=80=99t have to run SLAAC=E2=80=A6 You are perfectly free to = set the M bit, turn off the A bit, take the PREFIX options out of your = RA and you can already run DHCP without SLAAC, so I=E2=80=99m really not = sure what your bitching about. > Seriously, please try to understand what I just wrote. I completely understand what you just wrote=E2=80=A6 Do you? Are you trying to say you should be able to run DHCP without depending = on RAs? In that case, how does an unconfigured host decide which = protocol to ask for which information? Where does it get its default = router information? Please elaborate on exactly what incredibly poor = engineering decision you are proposing. Note, I=E2=80=99m being very specific here=E2=80=A6 If you truly mean = without SLAAC, then, an RA with M=3D1, O=3D1, A=3D0 and no prefix = options will do _EXACTLY_ what you have specified already. If you mean without RAs, then that really is a different kettle of bad = ideas. >>>> 3. using the IETF policy process as a stick with which to beat = everyone >>>> else into compliance with your own internal policies, disregarding = the >>>> consequences - often scorched earth - for the rest of the v6 = internet. >>>>=20 >>>> Given the extensive practice of option #3 on v6ops, 6man and dhc in >>>> relation to SLAAC vs DHCPv6, I'm inclined to think that this will = be the >>>> inevitable outcome of MUST for RDNSS, and that it will be used as >>>> ammunition in future both to shout down and block future consensus = on >>>> dhcpv6 protocol development and to force vendors and operators down = one >>>> particular protocol deployment path. >>>>=20 >>>> I'm genuinely sad to feel it necessary to say this, but I think it = needs >>>> to be stated explicitly. >>>=20 >>> You said it far more elegantly than I did, but this is the gist of = what I was trying to get across the other day. >>=20 >> I=E2=80=99m not in favor of shutting down or shouting down DHCPv6 = development, but I=E2=80=99m flat out fed up with the status quo as it = has come from the IETF so far. >>=20 >> The current situation is untenable to operators and end users because = there=E2=80=99s no consistent set of guidelines or requirements that = create a guaranteed interoperability between any two platforms. >=20 > That would not be the case if we made DHCPv6 robust, given that the = market has already expressed its preference for it. If operators could = do DHCP-only that is what they would implement, and you could rely on it = being present for any network where there are hosts more complex than = toasters. But the MARKET hasn=E2=80=99t done so. Some segments of the market have = expressed a strong preference for DHCP6. Other segments have expressed a = strong preference for SLAAC and RDNSS. Operators _CAN_ do DHCP only today. I=E2=80=99m not sure why you are = arguing that they can=E2=80=99t, nor have you made it clear what you = mean by =E2=80=9Cmade DHCP6 robust=E2=80=9D. Since I don=E2=80=99t have = any implementations where I actually care about DHCP for anything other = than PD, I admit I didn=E2=80=99t consider it particularly relevant to = the discussion of an acceptable solution, but now that you=E2=80=99re = arguing that =E2=80=9Crobust DHCP6=E2=80=9D (whatever that means) is = somehow a magic bullet that solves the problems of all the hosts outside = of the enterprise too, let=E2=80=99s hear what you have to offer and see = if it actually holds up. > The status quo is the result of the anti-DHCP crowd refusing to give = up on making SLAAC/RA mandatory. I call BS on this. I=E2=80=99m _NOT_ anti-DHCP. DHCP is a fine protocol for what it does = and where it is needed/useful. The addition of DHCP-PD is especially = useful (and the only real use I=E2=80=99ve found for DHCP in _ANY_ = implementation I have worked on, though I do understand its usefulness = in the enterprise desktop support context (which is a world I have = fortunately avoided for the majority of my career)). The status quo is the result of the combination of failures to make = proper support of both tools sufficiently mandatory in device and = software implementations that the operator can configure the devices on = his network as he sees fit for whichever legitimate combinations of the = existing tools said operator desires. > Making it "more mandatory" is, therefore, not the answer. It is, actually. Making both it _AND_ DHCP more mandatory gives = operators freedom of choice and ensures a compatible set of options = across all devices. > Further, the anti-DHCP people know this, which is why they keep trying = to make SLAAC more robust, and more mandatory. Again, you continue to approach me with this ridiculous us vs. them = attitude that is the real problem. I=E2=80=99m not =E2=80=9Cthem=E2=80=9D = in that I=E2=80=99m _NOT_ anti-DHCP. I am PRO-SLAAC and PRO-RDNSS, but that doesn=E2=80=99t make me = anti-DHCP. I=E2=80=99m all for putting an option into DHCP6 to provide route = information. In fact, I=E2=80=99d like to see it be a robust = multi-instance option that can support a 16 octet prefix, 1 octet = prefix_length and 16 octet next-hop specification. I=E2=80=99m well aware that the =E2=80=9CRA purists=E2=80=9D out there = vehemently oppose this, but I never have. I=E2=80=99ve always supported = it. (Note, I refer to the RA purists because I don=E2=80=99t believe = that all (or even most) of them are actually =E2=80=9Canti-DHCP=E2=80=9D).= I admit that there is an anit-DHCP crowd, but I think they are a = relatively small minority at this point. >> Does this come at a cost to vendors? Sure=E2=80=A6 You bet it does. = SO WHAT!! Vendors are in the business of supplying what operators need. = If they want to serve an operator community that has grown sufficiently = diverse that no one autoconfiguration solution fits all needs, then they = will have to do just that=E2=80=A6 Support more than one solution to = meet the needs of that diverse community. That=E2=80=99s what we pay = them to do. >=20 > This is laughably out of touch with reality. (You need only to look at = the status quo to demonstrate that I'm right.) The status quo is the result of poorly specified requirements which you = are (apparently) defending. It doesn=E2=80=99t demonstrate that you are = right, it demonstrates how wrong you are. Vendors won=E2=80=99t reliably = implement what they are not required to implement by the RFCs unless = they get strong requirements from their user base. The fact that RDNSS = has received wider vendor acceptance than DHCP client support would, if = anything, serve as evidence of just how out of touch with reality you = are and bolster my position. Owen From nobody Sun Apr 2 23:04: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 37E3C126C23 for ; Sun, 2 Apr 2017 23:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 roo8oLTZJYeS for ; Sun, 2 Apr 2017 23:04:23 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 14B1D124B0A for ; Sun, 2 Apr 2017 23:04:23 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 7512DE6067; Mon, 3 Apr 2017 08:04:21 +0200 (CEST) Date: Mon, 03 Apr 2017 08:04:21 +0200 (CEST) Message-Id: <20170403.080421.74700070.sthaug@nethelp.no> To: owen@delong.com Cc: dougb@dougbarton.us, v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> References: <58DE38D5.4050802@foobar.org> <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-2 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:04:25 -0000 > > Operators and vendors will not do this. They have already voted with their feet, and have made it quite clear that DHCP is the preferred method of host configuration. > > Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD supports RDNSS$,1s&(B > > Which major router platforms are you thinking of that don$,1ry(Bt support RDNSS? Huawei. No support, no plans last time we asked them. Steinar Haug, AS2116 From nobody Sun Apr 2 23:12: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 D684E1205D3 for ; Sun, 2 Apr 2017 23:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 ivjhk9Coukk6 for ; Sun, 2 Apr 2017 23:12:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id D009B129572 for ; Sun, 2 Apr 2017 23:12:04 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v336B2vl019036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 23:11:02 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <7244ff1e-1315-f855-4768-35f9f64ea33e@dougbarton.us> Date: Sun, 2 Apr 2017 23:11:01 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> <2DC3DE6D-825B-4572-B617-1DA4D788E4B8@delong.com> <52F551E1-86A0-4109-A615-7D602ACFCF1D@delong.com> <7244ff1e-1315-f855-4768-35f9f64ea33e@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 23:11:03 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:12:08 -0000 > On Apr 2, 2017, at 4:11 PM, Doug Barton wrote: >=20 > On 04/02/2017 03:31 PM, Owen DeLong wrote: >>>> The existence of SLAAC and DHCP6 both rather than a single >>>> one-size-fits-all solution in IPv6 from the IETF is not so much the >>>> IETF failing to get its act together as a representation of the >>>> diversity of stakeholders and the fact that no single host auto >>>> configuration mechanism fits the needs of all stakeholders today. = As >>>> such, the operators themselves and not the IETF or vendors should = be >>>> making the decision about which one(s) to implement in any = particular >>>> operational network. >>>=20 >>> That is a matter of perspective, on which we disagree. >>=20 >> IMHO, this is because your perspective is rather limited and = apparently rather enterprise-IT specific to the exclusion of all others. >=20 > I've addressed this several times already. I will simply repeat my = point that your perspective is obviously wrong because the market has = not aligned itself to it. Now I feel like I=E2=80=99m talking to Fox news. No matter how many = times you repeat the same falsehood, it still remains false. I=E2=80=99ve provided statistics showing that the market has, in fact, = aligned with my position and not yours. >>>> The only way to make that possible is to make SLACC+RDNSS and DHCP6 >>>> support mandatory in host and router capability requirements. >>>=20 >>> Sorry, again we disagree here. As you pointed out, different = networks and environments have different needs. >>=20 >> Right=E2=80=A6 >>=20 >>> Let's give a theoretical counter-example to the IOT case. If I am a = vendor creating a product that needs more configuration options than are = available through SLAAC, I know that I have to implement a DHCP client. = Since I'm doing DHCP anyway, all of the time that I spend on RDNSS = implementation (which I would need to do in order to check the "Complies = with RFCNNNN" check box that my customers will be looking for) = completely wasted. Further, if customers find out that the RDNSS support = exists, some of them will try to use it. Many of them will get it wrong, = thus increasing my support costs. All of this for exactly zero benefit. >>=20 >> If you=E2=80=99re implementing a host that is so tightly tied to its = application that you can predict this in advance, then perhaps what is = appropriate is to create a further exemption for =E2=80=9CPurpose Built = Hosts=E2=80=9D and reduce the requirement scope to =E2=80=9Chosts = suitable for multiple purposes or likely to be subject to diverse = network requirements=E2=80=9D. >=20 > No, more arguments about how to define "constrained host," "purpose = built host," etc. are not only not going to help, they are going to make = the problem worse (and make it that much more difficult to reach = consensus). >=20 > Let RA+RDNSS continue to exist for those whose needs it meets. For = those folks, they know that's all they need, so that's all they run. I = am totally fine with that. (POWER TO THE PEOPLE!) Except you don=E2=80=99t want to require vendors to implement it so that = they can actually count on being able to deploy it. (FAIL!) >>> Going back to the IOT crowd, they raise Cain every time DHCP is even = hinted at, it's not reasonable to expect that they will agree to making = it mandatory to implement, never mind actually go out and implement it. >>=20 >> Actually, I think you are wrong about that. I think that if you look = at the cain they raise, it=E2=80=99s almost all specifically about = resource constrained hosts. If you grant an exemption for those hosts, I = think you=E2=80=99d see a lot more willingness. >=20 > But if you don't over-engineer the spec in the first place, you don't = have to "grant exceptions." And if you do need to grant exceptions, your = idea of "mandatory" is seriously flawed. OK=E2=80=A6 Let=E2=80=99s get rid of DHCP altogether then so that we = aren=E2=80=99t saddled with an over-engineered spec. SLAAC and RDNSS is = mostly fine with me. Oh, wait, there are those places where we need PD. = OK, let=E2=80=99s get rid of IA_NA and all the host configuration = options from DHCP. If we do that, then there are no needs for exceptions. Those people who = want an over-engineered spec can do DHCP if they can convince their = vendors. If the market has moved in that direction as you claim, then = surely the lack of a standards-based requirement will not be an obstacle = to implementation. >>> We're all in agreement that the status quo sucks. But saying that = both protocols should be mandatory is a political decision, it's not = good engineering. >>=20 >> Both protocols exist. Not requiring a compatible subset across all = implementations is bad engineering. >=20 > Sorry, you're just flat-out wrong here. The fact that there is not = "One True Solution" is offensive to certain mindsets, but it doesn't = match the operational reality. I don=E2=80=99t care who it is offensive to, the reality is that there = isn=E2=80=99t =E2=80=9Cone true solution=E2=80=9D. Given that, failing to create requirements that a compatible subset = exist across all implementations remains bad engineering. >> Requiring DHCP across everything is a non-starter because resource = constrained hosts really do exist and will continue to be a reality. >>=20 >> Requiring RDNSS across everything is a non-starter because you exist = and there=E2=80=99s a vocal contingency of DHCP zealots to back you up. >=20 > Thank you for giving me so much credit. :) But the fact that there = are so many "DHCP zealots" probably should give you the idea that we're = on to something. I=E2=80=99m not seeing so many. Perhaps I missed a head count somewhere. = In this thread there seems to be 1. > As I've pointed out several times now, if we are going to run DHCP = anyway, then there is no reason for us to support RDNSS. Every dollar = and person-hour spent on supporting that option is wasted. The IETF = mandating it to satisfy a certain mindset that needs "One True Solution" = is ludicrous on its face. Sure, but lots of deployments ARE NOT GOING TO RUN DHCP anyway, so there = is need for RDNSS there. I=E2=80=99m not seeking =E2=80=9COne True Solution=E2=80=9D. If = anything, you are in your arguments against RDNSS being mandatory. I=E2=80= =99m arguing that both solutions MUST be supported in vendor = implementations wherever feasible so that operators can make an informed = decision about which subset they want to use on their networks. Your argument boils down to =E2=80=9CSince I want to run DHCP and I = think most of the IT dollars are in my camp, I assert that implementing = RDNSS is a waste of time and money.=E2=80=9D That=E2=80=99s great for you, but those same routers and servers that = you are deploying in your environment also get deployed in other = environments that don=E2=80=99t want to run DHCP and need RDNSS, so = failing to require the vendor to implement RDNSS is just as useless to = those installations as failing to require DHCP is to you. > Further, as you so ably point out, "Mandate both" is never going to = happen, there are always going to be exceptions, and that can only lead = to more confusion, and more "angels on the heads of pins" debates about = what is and isn't an exception. So not only do you not get what you're = asking for, you make the problems (and arguments) worse instead of = better. I think that the exceptions could be sufficiently narrowly defined so as = to limit confusion. Especially since there seems to be exactly one class = of exclusions for each of the two requirements: RDNSS CLIENT is optional in a purpose built host whose = application cannot be deployed without DHCP6. DHCP CLIENT is optional in a host with such limited resources = (memory, battery life, etc.) that DHCP implementation would = significantly reduce the hosts suitability for its intended purpose. I don=E2=80=99t think those exceptions are open to a lot of = interpretation or confusion and I don=E2=80=99t think vendors are = generally so stupid that they would have trouble understanding the = intent. >> So=E2=80=A6 The only pragmatic solution is to require both across the = broadest possible set of hosts, exempt DHCP where absolutely necessary, = perhaps exempt RDNSS where its omission is unlikely to cause harm, and = move on. >>=20 >> If you have a better solution, I=E2=80=99m all ears. >=20 > I've already pointed out that your thinking on possible solutions is = severely constrained by assuming that SLAAC must always exist. I have no such assumption. Without SLAAC, you can=E2=80=99t do stateless = DHCP, so it=E2=80=99s required in all those cases (you discarded my = reference to IA_NA in an earlier message arguing in favor of stateless = DHCP). However, as I have repeatedly stated, if you want to turn off SLAAC, go = for it. Set your RAs to M=3D1, O=3D1, A=3D0 and remove the prefix = options and you=E2=80=99re good to go. > I have offered a better solution here, and have have been offering it = for over a decade: >=20 > Let SLAAC/RA (and I guess we'll thrown in RDNSS too) exist for those = who want it, and for whom it meets their needs. But this doesn=E2=80=99t reliably happen if we don=E2=80=99t mandate = support for it in vendor implementations. > Let DHCP hand out network and gateway information so that those who = are going to run DHCP anyway can do so without SLAAC. Now I=E2=80=99m confused=E2=80=A6 SLAAC doesn=E2=80=99t hand out gateway = information and it can be turned off already. Short of DHCP route options, this is already implemented and I=E2=80=99ve = repeatedly stated my support for a DHCP route option. > That is the simplest, lowest common denominator, best ENGINEERING = solution. It eliminates the costs and complexities involved for those on = the host side who only need one solution, and it will allow the market = to gravitate in the direction that the money already wants to go. But that=E2=80=99s simply not true because it is exactly how we have = ended up where we are today=E2=80=A6 Some vendors choosing the SLAAC = religion and some choosing DHCP and many implementing incompatible = subsets of the protocol(s). > The only reason NOT to follow that plan is to continue to cater to = those who want to avoid DHCPv6 at all costs. But that's what got us into = this mess in the first place. As someone who needs to avoid DHCP6 in a number of deployments, I=E2=80=99= m unwilling to accept that failing to cater to that need is valid. So I=E2=80=99d say that=E2=80=99s a darn good reason NOT to follow that = plan. What got us into the mess is the zealots on BOTH sides. What we need is = for people to step back and realize that continued zealotry is not = helpful and we need to accept and properly support both protocols if = anything useful is to come out of this. Owen From nobody Sun Apr 2 23:27: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 F264412940A for ; Sun, 2 Apr 2017 23:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 u1e78T9Gx23I for ; Sun, 2 Apr 2017 23:27:33 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id B02FD1243FE for ; Sun, 2 Apr 2017 23:27:33 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 5B3DFE6065 for ; Mon, 3 Apr 2017 08:27:32 +0200 (CEST) Date: Mon, 03 Apr 2017 08:27:32 +0200 (CEST) Message-Id: <20170403.082732.41681152.sthaug@nethelp.no> To: v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> References: <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> <56397D1E-F117-478D-9FBA-AEA5FE1BB105@delong.com> <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> 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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:27:36 -0000 > I never said, "Everyone wants to do, or is doing, DHCP." My argument is > that in ENTERPRISE networks, where the vast majority of dollars are > spent, and where the largest numbers of hosts are under management, the > operators have spoken overwhelmingly in favor of DHCP. There are also plenty of operators who have significant infrastructure and support systems based on DHCP, and will continue to use this for IPv6. Also, some of these operators have legal requirements to log and keep (for some time) the association between IP address and customer - a requirement which doesn't go away with IPv6, and which for IPv4 is easily provided by DHCP. With IPv6 and RA/SLAAC it means we need to (additionally) start scraping the router IPv6 neighbor tables, instead of having it all in one convenient place (the DHCP server). Absolutely doable, but an added IPv6 pain which in my opinion should be completely unnecessary. Steinar Haug, AS2116 From nobody Sun Apr 2 23:35: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 0D08A12957F for ; Sun, 2 Apr 2017 23:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 UOK7sIylE5Qt for ; Sun, 2 Apr 2017 23:35:12 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D179129573 for ; Sun, 2 Apr 2017 23:35:12 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 0A6FDE6067 for ; Mon, 3 Apr 2017 08:35:11 +0200 (CEST) Date: Mon, 03 Apr 2017 08:35:11 +0200 (CEST) Message-Id: <20170403.083511.71133691.sthaug@nethelp.no> To: v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: <7244ff1e-1315-f855-4768-35f9f64ea33e@dougbarton.us> References: <52F551E1-86A0-4109-A615-7D602ACFCF1D@delong.com> <7244ff1e-1315-f855-4768-35f9f64ea33e@dougbarton.us> 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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:35:14 -0000 > I've already pointed out that your thinking on possible solutions is > severely constrained by assuming that SLAAC must always exist. > > I have offered a better solution here, and have have been offering it > for over a decade: > > Let SLAAC/RA (and I guess we'll thrown in RDNSS too) exist for those who > want it, and for whom it meets their needs. > > Let DHCP hand out network and gateway information so that those who are > going to run DHCP anyway can do so without SLAAC. > > That is the simplest, lowest common denominator, best ENGINEERING > solution. It eliminates the costs and complexities involved for those on > the host side who only need one solution, and it will allow the market > to gravitate in the direction that the money already wants to go. +1 (not optimistic it'll happen - but yes, that would be a great solution.) Steinar Haug, AS2116 From nobody Sun Apr 2 23:38: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 21BDD12940A for ; Sun, 2 Apr 2017 23:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 RuF0upNih79a for ; Sun, 2 Apr 2017 23:37:58 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id B9084126C3D for ; Sun, 2 Apr 2017 23:37:58 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v336asIc020023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 23:36:55 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <41440470-2b93-841e-357d-b972d5689d8f@dougbarton.us> Date: Sun, 2 Apr 2017 23:36:54 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0B39090F-9549-46D9-A0D1-623967BD019F@delong.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> <41440470-2b93-841e-357d-b972d5689d8f@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 23:36:56 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:38:01 -0000 > On Apr 2, 2017, at 5:06 PM, Doug Barton wrote: >=20 > On 04/02/2017 03:52 PM, Brian E Carpenter wrote: >> Doug, >>=20 >> A few points, on three of your messages: >>=20 >> On 03/04/2017 08:02, Doug Barton wrote: >>> On 04/01/2017 09:02 AM, Brian E Carpenter wrote: >>>> I was actually arguing that making them both a MUST implement is = "more" >>>> valid because it increases that chance that an arbitrary host will = work >>>> on an arbitrary network. >>>=20 >>> No, it wouldn't, because "MUST support" is not the same as "MUST >>> provide." And people are going to continue configuring their network = the >>> way they want to in any case. >>=20 >> Your understanding of statistics and probability seems to be a bit = different >> from mine. >=20 > For what it's worth, mine is based on decades of experience = configuring, and working with large enterprises to configure, DNS and = DHCP solutions that meet real world needs. Unfortunately, your experience seems to be limited only to that world = and large enterprises alone do not represent all (or necessarily even a = majority) of deployed hosts or networks. They _MIGHT_ represent a majority of IT spend, but that=E2=80=99s hardly = the same thing. You completely ignore all of the SMB, service provider, R&E, and other = types of installations where DHCP is utterly unnecessary and unwanted = overhead. >> All I'm saying is that the more implementers are >> chivvied in the direction of implementing both solutions, the more >> interoperability we will get, statistically, over the next decades. = That is >> true precisely *because* operators will configure their networks the = way >> they want to, not the way some RFC says. >=20 > On this point I don't follow you at all. The market has "voted" = overwhelmingly in favor of deploying DHCP, and not deploying RDNSS. My = point was that requiring vendors to implement RDNSS does nothing to = encourage operators to deploy it. No, it has not. In fact, if anything, the market is close to evenly = split between DHCP and RDNSS. Who cares whether operators are encouraged = to deploy it or not=E2=80=A6 That=E2=80=99s not what we are after here. = What we are after is requiring vendors to implement BOTH RDNSS and DHCP = wherever feasible so that operators don=E2=80=99t have to be encouraged = to deploy either one, they can choose the one(s) that works for their = deployment(s). > Where did I go wrong there? (That's a sincere question, if I missed = something I want to know.) I will attempt to answer, sincerely: 1. Drop the us vs. them mentality. 2. Recognize that there is a world beyond the large = enterprise and it matters. 3. Recognize that we aren=E2=80=99t arguing for encouraging = use of one protocol over the other, but, rather for mandating vendor implementation of both (to the = largest extent feasible) so that operators can choose and deploy as they wish. >> On 03/04/2017 08:05, Doug Barton wrote:> On 03/31/2017 12:18 AM, = Simon Hobson wrote: >>>> Doug Barton wrote: >>>>=20 >>>>> People who like it can implement it, people who don't, shouldn't >>>>> have to. >>>>=20 >>>> But that is the whole problem ! As referenced some time ago, in the >>>> real world there is a problem where there are two ways of providing >>>> the information, and two ways of getting it. If router only does A >>>> and device only does B then device doesn't get DNS info; similarly = if >>>> router only does B and device only does A then device doesn't get = DNS >>>> info; in either case the problem is that you've connected a device = to >>>> an IPv6 network and "it doesn't work". >>>=20 >>> Yes. That was the completely predictable result of the introduction = of >>> new options to SLAAC beyond RA, and the core objection made by those = of >>> us who have been opposing additional such options for over a decade. >>>=20 >>> I've snipped the rest of your message because we all know how we got >>> here. We have created this mess by allowing the anti-DHCP crowd to = run >>> the asylum. We need to stop letting that happen. >>=20 >> That is grossly unfair. My recollection is that RDNSS was added not = as >> an anti-DHCP provocation, but because we have always had a target = "market" >> for IPv6 that we referred to in the early days as the "dentist's = office >> scenario" where people with zero skill could plug stuff together and >> it would work. Given SLAAC, the only missing link for that sceanrio = was >> DNS server configuration, and that is why RDNSS was specified. And it >> works. >=20 > I am sure that is your recollection of the situation, and I don't = fault you for it. I was around when RDNSS was first suggested, and I = remember the same conversations you do (including the dentist's office = scenario). >=20 > However, I also remember that the very first proposed version of what = became RDNSS had only the name server list. Those of us who were deeply = involved on an operational level doing actual host configuration pointed = out that the name server list is only one of several features that hosts = on modern networks need to do name lookups, and that at minimum you = would also need to include the search string feature, and that really if = you have a host with sufficient complexity that it needs to do DNS = lookups in order to get its job done the right answer is to use DHCP, = which will be able to provide all of the appropriate configuration. >=20 > The response to that conversation was not, "Oh, I see ... thanks!" It = was instead, "Ok, we'll add the search string!" on the one hand, = followed by over a decade of denial that DHCP is the right answer here, = along with further attempts to glue necessary configuration elements = into SLAAC. Perhaps people legitimately think DHCP isn=E2=80=99t the right answer = here in their installations? > So from your perspective adding RDNSS was a perfectly reasonable = response to the realization that RA alone was not sufficient. =46rom = mine it was the result of the complete failure to recognize that RA = alone only ever applied to a very limited set of hosts, and never should = have been made mandatory to implement in the first place. >=20 > On the one hand there continues to be lack of enthusiasm for RA in the = marketplace, along with ongoing clamor for robust DHCP. On the other = hand, the response from the IETF has been continued insistence that RA = remain mandatory. Again, this expresses what I believe to be a severely limited and biased = view of the marketplace tilted very heavily to one (admittedly sizable) = subset of a much broader market to the exclusion of many other segments = which are quite enthusiastically happy with RA+RDNSS.=20 > You may take offense at my characterization of this situation being = allowed to exist for the better part of 14 years, followed by the = current recommendations to make RDNSS, or both RDNSS and DHCP mandatory = to implement (the latter being something that even its proponents = recognize isn't realistic) as "the inmates are running the asylum," but = I frankly can't see any other way to describe it. I could argue that the insistence on DHCP to the exclusion of RA would = be a bigger example of the inmates running the asylum if it were allowed = to pass, but fortunately, at least for now, that seems unlikely. >=20 >=20 >>> On 03/04/2017 08:52, Doug Barton wrote: >>>> On 03/31/2017 05:28 AM, Brian E Carpenter wrote: >>>>=20 >>>> As far as a vendor or open source developer is concerned, the = suggestion >>>> is that they MUST include code for both methods. I'd be a bit more = precise >>>> and add that they MUST both be enabled by default in hosts, and at = least one >>>> MUST be enabled by default in routers, and they MUST be = individually configurable >>>> on or off in all nodes. >>>=20 >>> This is a terrible idea, for all of the reasons that I have = expressed >>> already today. Most importantly for the reason that the IETF should = not >>> be pushing the cost of its own inability to get its act together = onto >>> vendors. >>=20 >> We've specified doing the same thing in two different ways. >=20 > Only in the sense of RDNSS. True. We=E2=80=99ve specified at least 4 ways to assign host addresses: IA_NA DHCP Stateless DHCP using SLAAC SLAAC Static Then, of course, there are the other (more bizarre) subsets if you count = privacy addresses, etc. >=20 >> What we haven't >> done, evidently, is describe the scenarios in which the two solutions = are >> more, or less, appropriate. That's a gap. >=20 > I don't think there is any confusion on that point in the operator = community. The extraordinarily limited situations where RA+RDNSS are = sufficient on their own are well understood by the people that are = operating those types of hosts. Referring to this as =E2=80=9Cextraordinarily limited=E2=80=9D is = disingenuous at best. In reality as soon as you step out side of the = large enterprise environment, the vast majority of use cases can = actually do quite well with RA+RDNSS. > Everyone else wants DHCP. Where everyone else is Large enterprises and a handful of other = specialized cases. > It's not the operators who are confused. :) Oh, yes, yes it is in many many cases. Owen From nobody Sun Apr 2 23:39: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 E344A120046 for ; Sun, 2 Apr 2017 23:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 ZtL_COYzBQzU for ; Sun, 2 Apr 2017 23:39:09 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 066CF12940A for ; Sun, 2 Apr 2017 23:39:04 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v336c1vE020044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2017 23:38:03 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> Date: Sun, 2 Apr 2017 23:38:01 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <58F27AB4-E761-4308-9E5D-CC22F6709D3F@delong.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Sun, 02 Apr 2017 23:38:03 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:39:11 -0000 > On Apr 2, 2017, at 5:10 PM, Doug Barton wrote: >=20 > On 04/02/2017 04:54 PM, Brian E Carpenter wrote: >> On 03/04/2017 11:23, Doug Barton wrote: >>=20 >> ... >>> And as I've said several times now, I'm not anti-SLAAC. I think it's = a >>> great solution to a specific problem. But what we've known for over = a >>> decade is that it's not a *general* solution for host configuration. >>> That solution is DHCP, and DHCPv6 should be given the ability to = handle >>> all of the host configuration, in the absence of SLAAC, specifically = so >>> that operators CAN choose the configuration that works for them. >>=20 >> If you're arguing that there should be a DHCPv6 option to communicate >> the default router, I couldn't agree more, for exactly the same = reason >> that we added RDNSS to RAs: so that both solutions can support a = least >> common denominator for communication: address, router, DNS server. >=20 > Hooray! I am genuinely happy to see common ground on this topic. :) >=20 > Is it finally time to get it done? >=20 Long overdue in my opinion, just as requiring vendors to implement = support for both mechanisms is also long overdue IMHO. Owen From nobody Sun Apr 2 23:48: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 48CA0129573 for ; Sun, 2 Apr 2017 23:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 BVbcm5QJKoTy for ; Sun, 2 Apr 2017 23:48:27 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 7A2C6129572 for ; Sun, 2 Apr 2017 23:48:27 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id s68so127460069vke.3 for ; Sun, 02 Apr 2017 23:48:27 -0700 (PDT) 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=AK20/RqxjiZwRnR3MtdM7YTPN/54fVpaF5k7enazNak=; b=upNJ9yfcpK/aVEAIwlBoX7UGKS24k3KUEReB2ZSI9dCgLXBNVoVuB3X5YeF5Gv//dH 0V2eUjh5iy2PKwvUNAJSkQmufnc96taZu0Km9d9ZdsumqvVxbpE4llsw+Vf3dptgUCJV CB6m/9S++U+xrZXZU4ND7EmREZS94ZJjBmP9/1nNgC4AIZNu8FwtUqpn92sBPe9UgzVH hHifkSKnAjVHs0YlIHFti1O7gOBl77e6RmUV72VyOKVmHWyXdrox2oB2sk540vealgzF YiCzALUDDK4oRMdHdI27is0z+hGm5GfE4JVkR7onTpxUCqM3J3ZmwKDm4RXWfH9j0R1C o/Cw== 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=AK20/RqxjiZwRnR3MtdM7YTPN/54fVpaF5k7enazNak=; b=MaT6ugzegNnS3nKgMOTBzieyElhjKjRxDO8hXcua6zBkDTV7YJ31N0EbicqwTnz6r1 ZD9haGYrPQVh0o0diJNeZ4/udZUCrKaBHLO9jMGgdmjE3ysCu94GCHFKVkkmHXcqL9g8 Azrj6gXg4tz0OK4zfrwNOgYCSqxeWSdTGzC9nO0NTkkPUL2343cfDavzC0mj84rCVTFF H4sG7tyoccQmBt2R+lF1l/WyubVxRX+145u6dklCkBBIsZwKd8LITDERX+7oUtvYvaaU 6KffFrSyPrHlBkXH8y3a8EMe7Q8xAue5xZJnAqu2iywFWRQgOgKQSJeeosXvUqGuXMTs c/BA== X-Gm-Message-State: AFeK/H0+4SQoTfSYYdRVY58hmrT15oYbDZHprv9b6dF6e6DpCQ4teS4WcQn6XKS5HYrBTeQk7r2zHF2zX2TVn2l/ X-Received: by 10.31.185.73 with SMTP id j70mr6037867vkf.102.1491202106344; Sun, 02 Apr 2017 23:48:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Sun, 2 Apr 2017 23:48:05 -0700 (PDT) In-Reply-To: <20170403.082732.41681152.sthaug@nethelp.no> References: <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> <56397D1E-F117-478D-9FBA-AEA5FE1BB105@delong.com> <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> <20170403.082732.41681152.sthaug@nethelp.no> From: Lorenzo Colitti Date: Mon, 3 Apr 2017 15:48:05 +0900 Message-ID: To: sthaug@nethelp.no Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11439f3cd6abdd054c3d8b70 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:48:29 -0000 --001a11439f3cd6abdd054c3d8b70 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 3:27 PM, wrote: > Also, some of these operators have legal requirements to log and keep > (for some time) the association between IP address and customer - a > requirement which doesn't go away with IPv6, and which for IPv4 is > easily provided by DHCP. With IPv6 and RA/SLAAC it means we need to > (additionally) start scraping the router IPv6 neighbor tables > That argument sounds plausible but it's actually not true. See RFC 7931 section 9.1, but briefly: - If you don't have strong L2 security, DHCP tracking cannot track malicious hosts. - If you do have strong L2 security, you don't need DHCP for tracking. --001a11439f3cd6abdd054c3d8b70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 3, 2017 at 3:27 PM, <sthaug@nethelp.no> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Also, some of these operators have legal requ= irements to log and keep
(for some time) the association between IP address and customer - a
requirement which doesn't go away with IPv6, and which for IPv4 is
easily provided by DHCP. With IPv6 and RA/SLAAC it means we need to
(additionally) start scraping the router IPv6 neighbor tables

That argument sounds plausible but it's actually not true. = See RFC 7931 section 9.1, but briefly:
  • If you don't have str= ong L2 security, DHCP tracking cannot track malicious hosts.
  • If you= do have strong L2 security, you don't need DHCP for tracking.
--001a11439f3cd6abdd054c3d8b70-- From nobody Sun Apr 2 23:51: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 E22E312958B for ; Sun, 2 Apr 2017 23:51:00 -0700 (PDT) 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, HK_RANDOM_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 6YUk923OuBDH for ; Sun, 2 Apr 2017 23:50:57 -0700 (PDT) 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 7619A12957B for ; Sun, 2 Apr 2017 23:50:57 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id s68so127510743vke.3 for ; Sun, 02 Apr 2017 23:50:57 -0700 (PDT) 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=VzSBIS/a0vLbh7gZsUIKK03ErWUdcN5JpQpTAqfQzww=; b=YvPJcR6Tw2Z2i4K5AGUxKsv/w4XqY7Go6EI+oGd6Vope/WYI6aN6k7LlQra3w4+n5E uUFsAy05x6DrAHXL9xndrdgUHjzoICaMfOJuxn7oU/pQjzBc+QCok9Os0qVnvzRm57Cj mjkVOFGxUxQ5+u/0mn5/S2T8tgYlY/wVG1N30g3WlTVqVd/dqCIRIBp13dUOhfCUn/9J qnWzZcR0Ms8WrqcHEON8IOe7WNA4C2KiCp8adq5EmhSmJ8CiK8U5V/zdIiHYE/LKOYUG j9fziQvrhgLTRm/as2EddtGxI/+vZsA7LKndjk8vseH/5FlTnYoZBBu8QdlBlOZ2cNZ9 ThdQ== 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=VzSBIS/a0vLbh7gZsUIKK03ErWUdcN5JpQpTAqfQzww=; b=IueUhQbiuWnC8Hj8tubvXmrYlIj+hKzt3/IFaeFMtf7KPAg5Q2El1r70t1cCtT6+n2 akChYgBU18ZLD9GbDbsWPHTHmwm7wp8Qkq8Z+NdCz2PwcfQNxVJHMW3zMyBku5pRI7oh +y0MXk4fsoHGhyMRjyYmBVRRlqSf1wRRRMH5n5x19F3upysZizt9QUwtbYMEOuL9Z6Tm 1wlav3NhCWDhQZOM387VQOEOK5yVa/zrugJxhKdCTHI13haEFQiy2RcyTCkyUTW8rj4K eR0sHlwmVsj8sgpJnXgXWj+cAeXZB+DgnzTqg9OdK8Kwmes/8r+bXDMO/JmzuxMOw/lB qoZw== X-Gm-Message-State: AFeK/H0APJyMbbvfw2GfcdjsvyRnheB+tEg7E6oV8f0oWrY+DccBsgBQ5pu13mTzfQPl3wEAZTKV0xKtofdsyQ== X-Received: by 10.176.68.101 with SMTP id m92mr6550818uam.18.1491202256540; Sun, 02 Apr 2017 23:50:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Sun, 2 Apr 2017 23:50:25 -0700 (PDT) In-Reply-To: <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> References: <399316c0-058c-5918-2245-e2ab938fae47@gmail.com> <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> From: Mark Smith Date: Mon, 3 Apr 2017 16:50:25 +1000 Message-ID: To: Fred Baker Cc: Nick Hilliard , IPv6 Ops WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:51:01 -0000 Hi, On 1 April 2017 at 05:26, Fred Baker wrote: > > On Mar 31, 2017, at 8:52 AM, Nick Hilliard wrote: >> claims about dhcpv6 being unsuitable > > Speaking as chair, but also speaking for myself. > > My perception has been and is that the argument between DHCP and the RA h= as been driven by political considerations more than anything else. Some op= erators are happy with the RA, and some strongly prefer DHCP. Telling eithe= r one "you're wrong" seems to me an unproductive exercise - we may as well = try to tell them what routing protocols to run, or how to lay out their net= works. They do it their way, and they don't really care what we think about= it. > > It turns out that there are reasons to support the RA approach and reason= s to support the DHCP approach. At least part of that has to do with the fa= ct that the sets of information elements differ, and when one creates a new= information element in either model, it has to be duplicated in the other = to maintain parity. It seems like a lot of work. > > RFC 4339, of course, tries to analyze that in the context of DNS. > > In this discussion, I, personally, would like to separate between "I like= , all is evil", and "the technical differences between an= d are , with ramifications." > Although the primary perspective was a combination of a DHCPv6 client and server in a CPE verses a DHCPv6 relay, I think took that approach when describing those issues in the section titled "Internet Transparency and Application Configuration" in this draft " IPv6 CE Device DHCPv6 Option Transparency" https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 I also discussed some of the consequences of lack of application configuration option support in routers in the Introduction. Some people might think this is an IS-IS vs OSPF type situation. I think it is quite different. The decision to use IS-IS or OSPF is internal to the network, and the choice isn't visible to external parties. I think this situation is different because we're talking about a configuration interface between the network and the hosts, and it is quite common that the operators of the network are different from the operators of the hosts. So this is an external interface between systems. If routing protocols can be used an analogy, then we'd be in the same situation if some router vendors only supported BGP, while other router vendors only supported Inter-Domain Routing Protocol (ISO 10747, basically ISOs version of BGP). Regards, Mark. From nobody Mon Apr 3 00:20: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 38B5512894A for ; Mon, 3 Apr 2017 00:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 7UYX4amj029k for ; Mon, 3 Apr 2017 00:20:03 -0700 (PDT) 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 A40E9127097 for ; Mon, 3 Apr 2017 00:20:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1F2B1A2; Mon, 3 Apr 2017 09:20:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491204001; bh=oYsSc4vt14rf0Resmvs2+EVKmZg7cE3PHU4dBpjb1OY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fzg86F7EMjTkii+Ze5lfVltzG8W32g7HyFVDfSmJQdJNpcpd6tivSlMAzM/h3jjgM s6xbckUvje76g6AVnqsGS2WPyfONjRlZVVPsxGvRUYtCeOOM2V2KQYAfpVxOOpRcFS uA15MgzF7Ei7uVSZ+KH7XnoU1wHuLfcHE3EftShw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1C65688; Mon, 3 Apr 2017 09:20:01 +0200 (CEST) Date: Mon, 3 Apr 2017 09:20:01 +0200 (CEST) From: Mikael Abrahamsson To: Fred Baker cc: IPv6 Ops WG In-Reply-To: <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> Message-ID: References: <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 07:20:06 -0000 On Fri, 31 Mar 2017, Fred Baker wrote: > Something that would help me, in this discussion, would be a simple and > incontrovertible statement of what breaks, or in which circumstances > RDNSS would be inappropriate. That would help me distinguish between > "SHOULD" and "MUST". Failing either, it sounds to me like "MAY". What I would like to see (this is not breakage though, only potential breakage and cause of confusion) is what a host should do if it gets RDNSS information and potentially DNS resolver information via DHCP. If a host doesn't implement a logic for this, there is potential breakage. I have already run into this when I dual stacked enterprise wifi Internet access and wired enterprise network was single stack IPv4, and windows chose the IPv6 resolver which was on the wrong side of "split horizon". Remedy there was no not provide any resolver in any IPv6 mechanism, so it's not really applicable to the RDNSS vs DHCPv6 resolver debate. So if we decide to MTI a mechanism, do we at the same time want to recommend something on what to do with multiple resolvers, perhaps along the lines of RFC6731 ? Personally I would like to MTI RDNSS and keep DHCPv6 optional, mostly because that would mean I didn't have to configure DHCPv6 for basic Internet IPv6 access. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 3 00:26: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 6FE3412955D for ; Mon, 3 Apr 2017 00:26:41 -0700 (PDT) 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, HK_RANDOM_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 OhFXod9bcIw2 for ; Mon, 3 Apr 2017 00:26:39 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 91EFC12955B for ; Mon, 3 Apr 2017 00:26:39 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id r69so128362411vke.2 for ; Mon, 03 Apr 2017 00:26:39 -0700 (PDT) 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=0gWHq5gMCzvRZuEHBL2x5cLyvJlKkWEsvYXn6Bd0Kss=; b=rV1ucj+Z8M6jHR3Oz+vxyjYN/Fe8ySdX32zBG/aMfw4+62cUrc9mEeAjfSs7Inw8qD QiiIY9cntigHPTmT+Jand5SO3NVELEnQJYmZrO3616n6zW/v1fXzPLk1l6KFiGYMJgIn yffxmj+XtKdhZ+ykfW6Wz5NA4fuGltJTtgZq4ZkCZ2baB1FyicBQtQZ5eIIU4VafbYvU 2dEAYc+wRMso11aQx8Bmqpzw142oJeu8irT81wKBJYSj/TNmXkrioPQd2RkOKzev/Yd+ uBRA8VIXvupPBFns9F9GRHU0lrb/nIO8WPNCR+KLkt+EslJAMfEAhACV+riVMHqslo1U SQiw== 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=0gWHq5gMCzvRZuEHBL2x5cLyvJlKkWEsvYXn6Bd0Kss=; b=qdR0gnUwpIsmjpdafO9l1wUnyUqN396AwLP6tjG9dlSddfRtxUrvyoJ1vk/0atF76H n2rMjO7fdseaAszx37eQlPxbDLfH0Sm2XThh8RWIM60nP7X3Sn8oF2Pm35WNfxOsZiy5 Vv7frBOP2IwtZpg9P1PTpWXk+MVc325A20p34Lt1l2dUpiJU1uwl40/5jQbB6D9VwGPd mO4QlQe4Oy54uZ6b1WWJS0X2fMmuBpHug0vRMF0sT4h8QjYRX+LcSqxeLE5mIH2wVvw5 LXn1Iz+v8YdWKF+qG0il7meIp4NkNN0NLt2QBNRXxraON3Pjtu2bZSqJ4K2OhCqtloTC oXHg== X-Gm-Message-State: AFeK/H3Hdj5b60fysCuEsSCqiDjHtN4zSrb79HfeegCUcMfLZW92Kj3gBrFahv7y1V52IlDUCuLrU/xeHjZlzg== X-Received: by 10.176.3.212 with SMTP id 78mr8384806uau.97.1491204398622; Mon, 03 Apr 2017 00:26:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 00:26:08 -0700 (PDT) In-Reply-To: <7244ff1e-1315-f855-4768-35f9f64ea33e@dougbarton.us> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> <2DC3DE6D-825B-4572-B617-1DA4D788E4B8@delong.com> <52F551E1-86A0-4109-A615-7D602ACFCF1D@delong.com> <7244ff1e-1315-f855-4768-35f9f64ea33e@dougbarton.us> From: Mark Smith Date: Mon, 3 Apr 2017 17:26:08 +1000 Message-ID: To: Doug Barton Cc: v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 07:26:41 -0000 On 3 April 2017 at 09:11, Doug Barton wrote: > On 04/02/2017 03:31 PM, Owen DeLong wrote: >>>> > > Let SLAAC/RA (and I guess we'll thrown in RDNSS too) exist for those who > want it, and for whom it meets their needs. > > Let DHCP hand out network and gateway information so that those who are > going to run DHCP anyway can do so without SLAAC. > "IPv6 RAs Mostly Necessary" http://www.users.on.net/~markachy/IPv6_RAs_Mostly_Necessary.pdf > That is the simplest, lowest common denominator, best ENGINEERING solution. > It eliminates the costs and complexities involved for those on the host side > who only need one solution, No, it doesn't eliminate costs and complexities. It increases them. This whole discussion is caused by having two protocols that perform the same function. You would be to creating the same situation with DHCPv6 by duplicating RA functionality in it. Think about the better conversations we could be having about unsolved problems rather than having to sort out the problem of having two solutions to one problem when each of them don't have a clear advantage over the other. > and it will allow the market to gravitate in the > direction that the money already wants to go. > > The only reason NOT to follow that plan is to continue to cater to those who > want to avoid DHCPv6 at all costs. But that's what got us into this mess in > the first place. > No, what got us in this mess in the first place is not following what is in RFC1958, " 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." RDNSS isn't a significant improvement over stateless DHCPv6, which is why host and router vendors are unsure about which one to implement, and operators are unsure about which one to deploy when they have a choice. Regards, Mark. From nobody Mon Apr 3 00:59: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 3259B1273E2 for ; Mon, 3 Apr 2017 00:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 j_F2QMRROftW for ; Mon, 3 Apr 2017 00:59:02 -0700 (PDT) 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 134851273B1 for ; Mon, 3 Apr 2017 00:59:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B0AD9A2; Mon, 3 Apr 2017 09:58:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491206339; bh=KvPrtl1zpDyFH6CCxsxRUw0SMDbbpqcdHDuqeUep9eQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2jgNSWnt2LK96LPPtve6A/0p1wcIYnxOlhSTknR87cUjRvOxGedD/BVb4oYyJbcxZ zcn652buxt5Z6BijiC6b6SsvXLPoYgVtgIREjBjjEFlpS62d99nCquu3+wduynYlwS TMXXh/LfbvIKzV0Rj3MMluGj+M70eICl2xKofEFQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AE35E88; Mon, 3 Apr 2017 09:58:59 +0200 (CEST) Date: Mon, 3 Apr 2017 09:58:59 +0200 (CEST) From: Mikael Abrahamsson To: sthaug@nethelp.no cc: v6ops@ietf.org In-Reply-To: <20170403.082732.41681152.sthaug@nethelp.no> Message-ID: References: <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> <56397D1E-F117-478D-9FBA-AEA5FE1BB105@delong.com> <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> <20170403.082732.41681152.sthaug@nethelp.no> 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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 07:59:03 -0000 On Mon, 3 Apr 2017, sthaug@nethelp.no wrote: > Also, some of these operators have legal requirements to log and keep > (for some time) the association between IP address and customer - a > requirement which doesn't go away with IPv6, and which for IPv4 is > easily provided by DHCP. With IPv6 and RA/SLAAC it means we need to > (additionally) start scraping the router IPv6 neighbor tables, instead > of having it all in one convenient place (the DHCP server). Absolutely > doable, but an added IPv6 pain which in my opinion should be completely > unnecessary. There are other ways to skin that cat, but you already know that. From nobody Mon Apr 3 01:02: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 91B80127444 for ; Mon, 3 Apr 2017 01:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 Nf_gpAVkTSPp for ; Mon, 3 Apr 2017 01:02:54 -0700 (PDT) Received: from mta04.svc.cra.dublin.eircom.net (mta04.svc.cra.dublin.eircom.net [159.134.118.171]) by ietfa.amsl.com (Postfix) with SMTP id 19A02126BFD for ; Mon, 3 Apr 2017 01:02:53 -0700 (PDT) Received: (qmail 7529 messnum 9489795 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 3 Apr 2017 08:02:52 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (HELO avas01) (213.94.190.12) by mta04.svc.cra.dublin.eircom.net (qp 7529) with SMTP; 3 Apr 2017 08:02:52 -0000 Received: from [192.168.1.4] ([86.45.37.230]) by Cloudmark Gateway with SMTP id uwwtcHwCNZcJquwwuc5Mch; Mon, 03 Apr 2017 09:02:52 +0100 X-CNFS-Analysis: v=2.2 cv=NbyW7yL4 c=1 sm=1 tr=0 a=kvhl2hrZG42DSHFjhA0PKA==:117 a=kvhl2hrZG42DSHFjhA0PKA==:17 a=UqnCAUKRAAAA:8 a=48vgC7mUAAAA:8 a=5MDTMIL2jiEYIwDwZ60A:9 a=QEXdDO2ut3YA:10 a=PG0OayP7ibYH8bxE:21 a=_W_S_7VecoQA:10 a=lJY-YgW9qqlnPSXIK45r:22 a=w1C3t2QeGrPiZgrLijVG:22 Date: Mon, 03 Apr 2017 09:02:51 +0100 Message-ID: <9wy26w8ispm006ny91v95g2i.1491206571198@email.android.com> Importance: normal From: Ross Chandler To: sthaug@nethelp.no, owen@delong.com Cc: v6ops@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_823104219517950" X-CMAE-Envelope: MS4wfM3XQA40BtCHaNLY/5teyPbDKCHK6gOuQc7cbZV6wfaJ+ROG/X5RbWVp06dqVbUhNkQDyk5CO2bAA1z5fXul2bom9YQOnzJ8o8a0CLLbYqzbbhYLQdzo hATXSmfNEtWtxuxVyGNY2Rk5EKyYObOaccQD4g2DNFOIuwx4nYWKuidr/M6cGH1WYhuzESYryg/MRoF09Z4sQ8j6inDrnC8LZ+E= Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 08:02:57 -0000 ----_com.android.email_823104219517950 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKSHVhd2VpIGFkZGVkIFJETlNTIGluIFJBIHRvIG91ciBob21lIHJvdXRlciBhZnRlciB3 ZSBhc2tlZCBmb3IgaXQuwqAKSSB3b25kZXIgaG93IGNvbW1pdHRlZCB0byBub3Qgc3VwcG9ydGlu ZyBzdGF0ZWxlc3MgREhDUHY2IG9yIFJETlNTIGluIFJBIG90aGVyIHJvdXRlciBhbmQgaG9zdCBv cGVyYXRpbmcgc3lzdGVtIHZlbmRvcnMgYXJlIHdoZW4gdGhlcmUncyBhIGNvbnRyYWN0IGdpdmlu ZyB0aGUgY3VzdG9tZXIgc29tZSBsZXZlcmFnZSB3aGVuIGFza2luZyBmb3IgaXQuIFRoaXMgcHJv YmxlbSBzZWVtcyB0byBiZSBvbmUgb2YgYSBzaW5nbGUgdmVuZG9yIGRvaW5nIDk5JSBvZiB0aGUg YmxvY2tpbmcuClJvc3MKCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTog c3RoYXVnQG5ldGhlbHAubm8gCkRhdGU6IDAzLzA0LzIwMTcgIDA3OjA0ICAoR01UKzAwOjAwKSAK VG86IG93ZW5AZGVsb25nLmNvbSAKQ2M6IHY2b3BzQGlldGYub3JnIApTdWJqZWN0OiBSZTogW3Y2 b3BzXSBNYWtpbmcgUkROU1MgYSBNVVNUPyAKCj4gPiBPcGVyYXRvcnMgYW5kIHZlbmRvcnMgd2ls bCBub3QgZG8gdGhpcy4gVGhleSBoYXZlIGFscmVhZHkgdm90ZWQgd2l0aCB0aGVpciBmZWV0LCBh bmQgaGF2ZSBtYWRlIGl0IHF1aXRlIGNsZWFyIHRoYXQgREhDUCBpcyB0aGUgcHJlZmVycmVkIG1l dGhvZCBvZiBob3N0IGNvbmZpZ3VyYXRpb24uCj4gCj4gV2hpY2ggdmVuZG9ycz8gSnVuaXBlciBz dXBwb3J0cyBSRE5TUywgQ2lzY28gc3VwcG9ydHMgUkROU1MsIFJBRFZEIHN1cHBvcnRzIFJETlNT GyQsMXMmGyhCCj4gCj4gV2hpY2ggbWFqb3Igcm91dGVyIHBsYXRmb3JtcyBhcmUgeW91IHRoaW5r aW5nIG9mIHRoYXQgZG9uGyQsMXJ5GyhCdCBzdXBwb3J0IFJETlNTPwoKSHVhd2VpLiBObyBzdXBw b3J0LCBubyBwbGFucyBsYXN0IHRpbWUgd2UgYXNrZWQgdGhlbS4KClN0ZWluYXIgSGF1ZywgQVMy MTE2CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdjZv cHMgbWFpbGluZyBsaXN0CnY2b3BzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMK ----_com.android.email_823104219517950 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2Pkh1YXdlaSBhZGRl ZCBSRE5TUyBpbiBSQSB0byBvdXIgaG9tZSByb3V0ZXIgYWZ0ZXIgd2UgYXNrZWQgZm9yIGl0LiZu YnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB3b25kZXIgaG93IGNvbW1pdHRlZCB0byBu b3Qgc3VwcG9ydGluZyBzdGF0ZWxlc3MgREhDUHY2IG9yIFJETlNTIGluIFJBIG90aGVyIHJvdXRl ciBhbmQgaG9zdCBvcGVyYXRpbmcgc3lzdGVtIHZlbmRvcnMgYXJlIHdoZW4gdGhlcmUncyBhIGNv bnRyYWN0IGdpdmluZyB0aGUgY3VzdG9tZXIgc29tZSBsZXZlcmFnZSB3aGVuIGFza2luZyBmb3Ig aXQuIFRoaXMgcHJvYmxlbSBzZWVtcyB0byBiZSBvbmUgb2YgYSBzaW5nbGUgdmVuZG9yIGRvaW5n IDk5JSBvZiB0aGUgYmxvY2tpbmcuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Sb3NzPC9kaXY+ PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZyb206IHN0aGF1 Z0BuZXRoZWxwLm5vIDxicj5EYXRlOiAwMy8wNC8yMDE3ICAwNzowNCAgKEdNVCswMDowMCkgPGJy PlRvOiBvd2VuQGRlbG9uZy5jb20gPGJyPkNjOiB2Nm9wc0BpZXRmLm9yZyA8YnI+U3ViamVjdDog UmU6IFt2Nm9wc10gTWFraW5nIFJETlNTIGEgTVVTVD8gPGJyPjxicj4mZ3Q7ICZndDsgT3BlcmF0 b3JzIGFuZCB2ZW5kb3JzIHdpbGwgbm90IGRvIHRoaXMuIFRoZXkgaGF2ZSBhbHJlYWR5IHZvdGVk IHdpdGggdGhlaXIgZmVldCwgYW5kIGhhdmUgbWFkZSBpdCBxdWl0ZSBjbGVhciB0aGF0IERIQ1Ag aXMgdGhlIHByZWZlcnJlZCBtZXRob2Qgb2YgaG9zdCBjb25maWd1cmF0aW9uLjxicj4mZ3Q7IDxi cj4mZ3Q7IFdoaWNoIHZlbmRvcnM/IEp1bmlwZXIgc3VwcG9ydHMgUkROU1MsIENpc2NvIHN1cHBv cnRzIFJETlNTLCBSQURWRCBzdXBwb3J0cyBSRE5TUxskLDFzJmFtcDsbKEI8YnI+Jmd0OyA8YnI+ Jmd0OyBXaGljaCBtYWpvciByb3V0ZXIgcGxhdGZvcm1zIGFyZSB5b3UgdGhpbmtpbmcgb2YgdGhh dCBkb24bJCwxcnkbKEJ0IHN1cHBvcnQgUkROU1M/PGJyPjxicj5IdWF3ZWkuIE5vIHN1cHBvcnQs IG5vIHBsYW5zIGxhc3QgdGltZSB3ZSBhc2tlZCB0aGVtLjxicj48YnI+U3RlaW5hciBIYXVnLCBB UzIxMTY8YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj52Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+djZvcHNAaWV0Zi5vcmc8YnI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczxicj48L2JvZHk+PC9odG1sPg== ----_com.android.email_823104219517950-- From nobody Mon Apr 3 02:47: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 745A01295EA for ; Mon, 3 Apr 2017 02:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 hCyuNZ1idAZP for ; Mon, 3 Apr 2017 02:47:47 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68F61273E2 for ; Mon, 3 Apr 2017 02:47:46 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id A5F3B2732A for ; Mon, 3 Apr 2017 11:47:42 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 8922632B00F for ; Mon, 3 Apr 2017 11:47:42 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 98A2139796; Mon, 3 Apr 2017 11:47:43 +0200 (CEST) Date: Mon, 3 Apr 2017 11:47:43 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20170403094743.GA14217@ernw.de> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 09:47:49 -0000 Hi, On Mon, Apr 03, 2017 at 09:20:01AM +0200, Mikael Abrahamsson wrote: > On Fri, 31 Mar 2017, Fred Baker wrote: >=20 > > Something that would help me, in this discussion, would be a simple and= =20 > > incontrovertible statement of what breaks, or in which circumstances=20 > > RDNSS would be inappropriate. That would help me distinguish between=20 > > "SHOULD" and "MUST". Failing either, it sounds to me like "MAY". >=20 > What I would like to see (this is not breakage though, only potential=20 > breakage and cause of confusion) is what a host should do if it gets RDNS= S=20 > information and potentially DNS resolver information via DHCP. This is somewhat covered in RFC 4862, 5.6 Configuration Consistency =E2=80=9CIf the same configuration information is provided by multiple sour= ces, the value of this information should be consistent.=E2=80=9D =E2=80=9CIn any case, if there is no security difference, the most recently= obtained values SHOULD have precedence over information learned earlier.= =E2=80=9D and RFC 6106 =E2=80=9C1.2 Coexistence of RA Options and DHCP Options for DNS Configurati= on =09 Two protocols exist to configure the DNS information on a host, the Router = Advertisement options described in this document and the DHCPv6 options des= cribed in [RFC3646]. They can be used together.=0B The rules governing the decision to use stateful configuration mechanisms a= re specified in [RFC4861]. Hosts conforming to this specification MUST ext= ract DNS information from Router Advertisement messages, unless static DNS = configuration has been specified by the user.=20 If there is DNS information available from multiple Router Advertisements a= nd/or from DHCP, the host MUST maintain an ordered list of this information= as specified in Section 5.3.1. RFC 6106, sect. 5.3.1: In the case where the DNS options of RDNSS and DNSSL can be obtained from m= ultiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS op= tions from all sources. =0B=0BUnless explicitly specified for the discovery= mechanism, the exact number of addresses and domain names to keep is a mat= ter of local policy and implementation choice.=0B=0BHowever, the ability to= store at least three RDNSS addresses (or DNSSL domain names) from at least= two different sources is RECOMMENDED.=0B=0BThe DNS options from Router Adv= ertisements and DHCP SHOULD be stored into the DNS Repository and Resolver = Repository so that information from DHCP appears there first and therefore = takes precedence.=0B=0BThus, the DNS information from DHCP takes precedence= over that from RA for DNS queries. =3D=3D=3D cheers Enno --=20 Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902=20 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From nobody Mon Apr 3 02:50: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 A70981273E2 for ; Mon, 3 Apr 2017 02:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 OHM8XNwxpD6K for ; Mon, 3 Apr 2017 02:49:58 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 13F9B126B72 for ; Mon, 3 Apr 2017 02:49:58 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id s68so131694547vke.3 for ; Mon, 03 Apr 2017 02:49:58 -0700 (PDT) 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=y6d8DlqaHBP+q9B+TdxBdbPpA5DoBziNuZIkEtHD1j0=; b=UKGr5d1GeEeHduSJXlnVs1u2yzVvNJ4dlgxc3f/EO7L5fyx1ClLxXDZtGgCJQMU0Bg EvtFVjmBcuJFiKqi2UOEugvzbcPYKp8qp5pmTrga4Bwn9V05xd0wNweYfQAnvmQZwrv6 3q7rwDqu/RMZg5Ktqby8FuY+W0BrJV767VLQiEf0xDTyUUUEUN5jzjK0uSWSg7U2Hded g+AWJB168QvO3Q6OtJv7oGqGOCVNUkcnpj9vuVr3mqY4PL026paE1WHHCzG+Pw6sxNO1 GVu2Hikp/TlHV1PAr31aZsscb518c7Wp10qajhYtTOroJviLoCb2Zn/4EJvcy36LIDBa hJqg== 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=y6d8DlqaHBP+q9B+TdxBdbPpA5DoBziNuZIkEtHD1j0=; b=swx5qTW8ceqxBX3XQFfM1A8eNGsn/rUE2zVUo9A80Q5UgvQg68Dl6LDm8LnQGwhARb i8skpFmiqPlLjqeyT3LfBlCbzMgpowH0yLoDjT+oaixjClHoqdwmTgg8boA6jp5Poj4N gA5d8Gm8bKulabqbEf1ePHo63LHBbAjZ9jgaPczoqe0USGVJL2VQydcnlVj7HD1OuHSl /5I3TA0engiDxswOSIaCPRwQjd16Dhcy921yeSgUK0NtS3z/H9Wnqpyg8Xiq+KUC+c53 Od/22GANj83UfFwxU3iYs8oqN68WhjcgdfDDGZNirPTOSSrD1cFibdnclmajxRaI/bbx SwQQ== X-Gm-Message-State: AFeK/H1Fn4cXyJefFbK9UFaoh9b4goyiVvyHhQvMlbLgSe57K9XY0haswSsXhBkaMXhVOFG5L7tDEmoXwoqdascq X-Received: by 10.31.15.82 with SMTP id 79mr6853931vkp.156.1491212996960; Mon, 03 Apr 2017 02:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Mon, 3 Apr 2017 02:49:36 -0700 (PDT) In-Reply-To: References: <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> From: Lorenzo Colitti Date: Mon, 3 Apr 2017 18:49:36 +0900 Message-ID: To: Mikael Abrahamsson Cc: Fred Baker , IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11436188f853b3054c40147f Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 09:50:00 -0000 --001a11436188f853b3054c40147f Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 4:20 PM, Mikael Abrahamsson wrote: > What I would like to see (this is not breakage though, only potential > breakage and cause of confusion) is what a host should do if it gets RDNSS > information and potentially DNS resolver information via DHCP. Per RFC 8106, it prefers DHCP. (Assuming it supports DHCP, which it is not required to do.) --001a11436188f853b3054c40147f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 3, 2017 at 4:20 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
What I would like to see (thi= s is not breakage though, only potential breakage and cause of confusion) i= s what a host should do if it gets RDNSS information and potentially DNS re= solver information via DHCP.

Per RFC 8106, = it prefers DHCP. (Assuming it supports DHCP, which it is not required to do= .)
--001a11436188f853b3054c40147f-- From nobody Mon Apr 3 03:10: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 CF9F71273E2 for ; Mon, 3 Apr 2017 03:10:37 -0700 (PDT) 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, HK_RANDOM_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 zALZAmgaMMqy for ; Mon, 3 Apr 2017 03:10:36 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 26BAF1250B8 for ; Mon, 3 Apr 2017 03:10:35 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id z204so132494804vkd.1 for ; Mon, 03 Apr 2017 03:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=6B2C28wtQrJ/8pTagj5IHDYyTHwR5+JnbiTQ0KtanU8=; b=s8g/ztGUF4hBpxys4RbxzcbJS3iCZXI0Xsnk1Fz/pufXhruAU6/YbNdwMz4lGMPalC 9FW7g7KGq63C7ZipQW/4QeSWJPn8HPeMiWjF2xYoIOlNkTk0N29PSqwLsAFaMfxRm71k lqIGhiVCiLkkwxT9ps9kocKyEtrkoPz2xDVJAQYw+OcM+oUSGC6jQuIsBxccJQ9baPIW KNYUyokxtIPpHNomOY/fyFZgeqR3WNHGJ5G6asTi/ab5yZUPH4HgQCt32XFmvSU2yKtk dBf2R1cOFxE09ZuVYqpD8EASZodRTpYdvhuGZ3MdGyNQzMSPEnnbZ0vCalYL2YaXRd0Q 7BAA== 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:cc; bh=6B2C28wtQrJ/8pTagj5IHDYyTHwR5+JnbiTQ0KtanU8=; b=sTgkIN7OpxBlA9uHSv87KZM41oPes6lPer2cQySYVsHrl03Htqg6bMZt8jGGBkbppB Wk/fDYzuiXbh/Ez7OQvHRiMmSJI8XHOuYeNwp8Q6o4zS5++782w9vze6I9HJXJEBm6zI W8dujtVhyj5j+CDvoSo/tmUz/ojvVqNYiMSKzxL0wjY30t04x1CdfGX+xXt/MCJaa4Np 9srHIAHH0iAzACHae5f2jq2MiQJ3WY4Q68IYFTksnFeG6/CfmDEBNYS4EN74zC0RdP1n KNUjJYcY6NAsNS+ZVQx6CKRXwsWE1Cf6EsdNDAQnr+jBqPFxhk82bwH02e50f8fPaMLN MOFg== X-Gm-Message-State: AFeK/H1NZq+PwD/Ka1eFTlhzMcBSxJfLSvZ83RgtlmXJPC2Cgb1RM9Tc1m79oefmKaTFeYnvto9MNSG21y+Dlw== X-Received: by 10.31.60.65 with SMTP id j62mr5914704vka.25.1491214234976; Mon, 03 Apr 2017 03:10:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 03:10:04 -0700 (PDT) From: Mark Smith Date: Mon, 3 Apr 2017 20:10:04 +1000 Message-ID: To: Doug Barton Cc: Owen DeLong , v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 10:10:38 -0000 On 3 April 2017 at 08:35, Doug Barton wrote: > > I never said, "Everyone wants to do, or is doing, DHCP." My argument is that > in ENTERPRISE networks, where the vast majority of dollars are spent, and > where the largest numbers of hosts are under management, the operators have > spoken overwhelmingly in favor of DHCP. > I don't think you can make that assertion if you're making it about IPv4 and extrapolating it to IPv6. The choice people were making was much simpler than that. It was a choice between: (a) manually configured static addresses (b) automated configured addresses and it only really became a choice when PC operating systems gained a DHCP client - BOOTP would have been a previous choice, however IP stacks and bootp clients on PCs were rare or non-existent at the time (~1994 IIRC). That is not a choice or preference of DHCP. Consequently there was no technical evaluation of or preference for DHCP; DHCP is what you had to use if (b) was your goal. I doubt people are not deploying IPv6 in Enterprises because DHCPv6 doesn't support default gateways. Very few enterprises have a business need to deploy IPv6, because it isn't solving for them a problem that IPv4 isn't already or can't be used to solve. Technology needs to make or save a business money. If you can't identify how a technology you want to deploy can do either of those things for the business, then there isn't a business need for the technology, and the money people won't sign the Purchase Orders for it. Regards, Mark. From nobody Mon Apr 3 03:27: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 84363126C83 for ; Mon, 3 Apr 2017 03:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 snMLOoRUSGlL for ; Mon, 3 Apr 2017 03:27:15 -0700 (PDT) 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 C6001126B72 for ; Mon, 3 Apr 2017 03:27:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7CB05A2; Mon, 3 Apr 2017 12:27:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491215233; bh=ryPQtcVZAmDXSMU32kamu4b0LHubPHi+m/4YyeKJ8Q0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=yFDUlH0EHHi/WyL9wd3/Kpp/EyWbd1eoZPFrHsmQOvuyCVatUh5vCxNxAABwtsxVI 18ttRsZrCA3XSHlQ+y2YSeXRdLlRD6FeOgjhxWvuBqYpg/5Qo0MTO+lZcFtXLUH4nN erRXsx3hR6/8/6Zc0oFMoUMkKuHPV6rAi/JU+75Y= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7A0EF88; Mon, 3 Apr 2017 12:27:13 +0200 (CEST) Date: Mon, 3 Apr 2017 12:27:13 +0200 (CEST) From: Mikael Abrahamsson To: Mark Smith cc: v6ops list In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 10:27:19 -0000 On Mon, 3 Apr 2017, Mark Smith wrote: > I doubt people are not deploying IPv6 in Enterprises because DHCPv6 > doesn't support default gateways. Very few enterprises have a business > need to deploy IPv6, because it isn't solving for them a problem that > IPv4 isn't already or can't be used to solve. I have talked to several. They have built operational practices around how IPv4 happened to evolve, and if you show them IPv6 then they'll try to hammer that into being as close carbon-copy of IPv4 as possible so they don't have to change the way they run things. I don't know what they end up doing in the long run, but I've seen many times where people will take whatever IPv4 design they had and try to cram in IPv6 into it with as little change as possible. I also have stated that they won't deploy IPv6 until Android gains IA_NA capability. "my network my rules". "We do client tracking via DHCPv4 address leases, so we need to do that in IPv6 as well". "Do you have SAVI on your switches?" "no" "then your tracking is not guaranteed" "it's good enough for $RULEMAKER". I have spent considerable time with people trying to convince them there are other ways to do what they need to do. At least the initial reaction is always "NOOOOOOOO", I don't know what the end result is. Just to be clear, I don't think it's a good idea to cripple IPv6 just so that people can make it look like IPv4 to suit their current operational practices. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 3 03:48: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 8540812944A for ; Mon, 3 Apr 2017 03:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmCcdV6Sf6Qy for ; Mon, 3 Apr 2017 03:47:58 -0700 (PDT) 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 9D71C127BA3 for ; Mon, 3 Apr 2017 03:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491216476; bh=MELZMqrwHlFvVv9Kjk2wB1B5vyPF8s5ZKgjr6cCKLWw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hUufxJG7WNHTl04ulB0ilOLbOy1DZckeicotxVs+tFV7QTBt54STPFPl2BssIrDBjwNS23r9lvht5j+9jRxbQKaeKh//3eJ1UXqHHVdNTbfWXsruMzbnaFfZgd9jE9uscQIjyT03tqs88vKgnazxfzolg9FlNP299xpTBnMBdh4= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0216.outbound.protection.outlook.com [213.199.154.216]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-62-mIpO4OcRNre18WL3Fq6dTA-1; Mon, 03 Apr 2017 11:47:48 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Mon, 3 Apr 2017 10:47:46 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Mon, 3 Apr 2017 10:47:46 +0000 From: Tim Chown To: Fred Baker CC: Brian E Carpenter , v6ops list Thread-Topic: [v6ops] Outcomes from v6ops@IETF98 Thread-Index: AQHSqMzOl2pKnVBvckyLliBC42JP2KGvfgiAgAGzOwCAAR/ngIAAWKgAgABcRQCAAHfEAA== Date: Mon, 3 Apr 2017 10:47:46 +0000 Message-ID: References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> <48E707D0-B1BD-472B-890A-A8BFE9CF96A4@gmail.com> In-Reply-To: <48E707D0-B1BD-472B-890A-A8BFE9CF96A4@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:f14f:15a4:6a00:cc70] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:KU2MwmP+Keu+A2k7T6zVj7T7KLnInaNhBvP78xZKLgn9llcpm3TRRAd9rljQsFW+EU6IUMDV85Y5ee+ZxrlWHYbxCtP3Rat50mZMykBBMiwepCBpayKPf3odzMkquN5gOEO5b7NYFxsRULTd4jKqBs1iWZpTOJ20kUVKfjIXqMa8nLNBDf4iI+ysOWvjfDU3nM4DjI5oaPqjmgLxdDV9aDk499mFgY59HznJS+B0NsVoKpSPe9SsoestvSYzhZsm47X6KhNSMDXbDdMo6y2HQdAOEd5g0L+YJr2RfA8l3UEcJs/cxJbSSc52hr7uAvgGNUVvA1x9wlakxc5lA4PLpw==; 20:IUZpgqavrcAmYCOOW3t/J2FKsq1xwoYF5xWWRkWqfM53xFw87U6XHiVHyW9j8Kc5OF9xm46jy8c4X6Br4Uyk1ckjA5H/90MLBZE7l62tkzSnxodHGoJ4D25CtEWAKhEer42mHEDkE3rAurpoka5WevcwiWoYFuhN1PexsV8W+Jk= x-ms-office365-filtering-correlation-id: 97b910ae-f598-458c-f6eb-08d47a7edd7e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39840400002)(39410400002)(377454003)(24454002)(3660700001)(2900100001)(36756003)(3280700002)(53936002)(189998001)(6512007)(50226002)(8936002)(93886004)(8676002)(2906002)(33656002)(76176999)(97736004)(81166006)(50986999)(5250100002)(99286003)(102836003)(6116002)(83716003)(6436002)(82746002)(42882006)(5660300001)(2950100002)(6916009)(229853002)(6246003)(305945005)(7736002)(74482002)(86362001)(57306001)(39060400002)(4326008)(6506006)(38730400002)(53546009)(25786009)(110136004)(6486002)(54906002)(32563001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <80B7DB77654FC2429FA3A920927EAB89@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 10:47:46.5229 (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: mIpO4OcRNre18WL3Fq6dTA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 10:48:02 -0000 > On 3 Apr 2017, at 04:39, Fred Baker wrote: >=20 >> On Apr 2, 2017, at 3:08 PM, Tim Chown wrote: >>=20 >> OK; as Jordi says, I doubt many people would travel just for this. >=20 > Who is suggesting that they travel? I only asked whether the meeting was physical, virtual, or a mix, and agree= ing above that virtual-only is the best option in this case. As it happens, Ive attended more physical interim meetings than virtual one= s. Tim From nobody Mon Apr 3 05:21: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 30BB6128768 for ; Mon, 3 Apr 2017 05:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 4o__W54159gI for ; Mon, 3 Apr 2017 05:21:00 -0700 (PDT) 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 79192127599 for ; Mon, 3 Apr 2017 05:21:00 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cv0yh-0000FkC; Mon, 3 Apr 2017 14:20:59 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: In-reply-to: Your message of "Mon, 3 Apr 2017 12:27:13 +0200 (CEST) ." Date: Mon, 03 Apr 2017 14:20:58 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 12:21:03 -0000 >Just to be clear, I don't think it's a good idea to cripple IPv6 just so >that people can make it look like IPv4 to suit their current operational >practices. I find 'cripple' a very odd choice in this context. In my experience, IPv4 networks that have plenty of public IPv4 addresses can work very well. There is absolutely no evidence that using the same techniques for IPv6 would cripple IPv6. RA/SLAAC/RDNSS offer some benefits that are hard to realize with DHCP. However, looking at the history of RA/SLAAC/RDNSS we can also see an endless number of RFCs that try to correct various mistakes that were made initially. In some networks, RA/SLAAC/RDNSS works really well and can do things you can't do with DHCP. In other networks, forcing people to deploy RA/SLAAC/RDNSS is hugely disruptive and brings no benefits because those networks are designed for DHCP. As far as I can tell, none of the two options is inherently better. Both have their own strengths and weaknesses. From nobody Mon Apr 3 05:33: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 CBD45129431 for ; Mon, 3 Apr 2017 05:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_NONE=-0.0001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] 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 aF0dh_ZNiRo1 for ; Mon, 3 Apr 2017 05:33:12 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 C89F412941C for ; Mon, 3 Apr 2017 05:33:11 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id m133so31708683ybb.1 for ; Mon, 03 Apr 2017 05:33:11 -0700 (PDT) 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=bnOLk+WpsWWj2ywwUjXAI7Sz8WKO/XSsC8jSlyB0Ifc=; b=X0icnddov0SFsMNhnpC0H4xCadPOsxoU+naI/HycrRKfCM3OFOHGVhCJ2Qqz/CktwF lRewpWdiUGJ38nkeuvrdx71Lmz3RbXA+gSwv6kLFM1TSyGPdI24vbYQEl8YeiAsPFql5 wQyGucIw4c5/VG/hygS0XagkZ7XUuKNm0U5BzmQ3vyRUWT4O4q8tLe+09bMMbs5wz638 VuD/N/bXGzmhwEULsEHtmLnvoFZiaPv51XfygzywuiERR459rtiuNiu2G4CiI7f6u0/l tg5qxxk6a23gi7/iS0bzPp6uzWqe3y/Har56CYu1BYKKM0Okn5mWAQtBA/9KoTLGJiYV g7gw== 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=bnOLk+WpsWWj2ywwUjXAI7Sz8WKO/XSsC8jSlyB0Ifc=; b=VD+9vmnZWNb0B6btYxa0KjJCc1MNnDC02SEcbUFY+jqZayamhZGN2wAkJ1UGoYddh6 wlCxXugOhlUJC/bVHd9UQ/0922cNNLMamP8UcUAknMYTmef7CTsrBM8LCFqa+f+1gf1X FupyRrwA8JUYjENpmmtDJZQE7vUS8UcyYf/nR3XyYHpM/jMDFJs5HXEw8oZrzwz5ZgH3 +1oFYxAwfeHR6Ioh/JdUGWeAPYDdvtPI6y5CSLRvrgGpSsfQRQfjbIyf7vHPWkRceKlr E+yKNkjZIUZFVhjYOb8lLWR1aWulv0UdssuB1OWm9iHpAVvsiqtgEYlgOwXbyTQlNEiW DEuQ== X-Gm-Message-State: AFeK/H3E8QRCTfNP3F9ael9HOr1UH8qq/EwH/G9+xV13iuTZ3kftNlXE2J+OhAFbgmmEpOrINlB8qoAcBJlu6w== X-Received: by 10.37.42.205 with SMTP id q196mr11489167ybq.49.1491222790648; Mon, 03 Apr 2017 05:33:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.210.4 with HTTP; Mon, 3 Apr 2017 05:32:40 -0700 (PDT) In-Reply-To: <20170403094743.GA14217@ernw.de> References: <20170403094743.GA14217@ernw.de> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 3 Apr 2017 07:32:40 -0500 Message-ID: To: Enno Rey Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary=001a1144186cb7bacb054c425cf2 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 12:33:15 -0000 --001a1144186cb7bacb054c425cf2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rey, Though the main idea is almost the same in your mentioned text in Section 1.2 and Section 5.3.1, RFC 8106 replaces RFC 6106 as follows:T https://tools.ietf.org/html/rfc8106 --------------------------------------------------------- 1.2. Coexistence of RA Options and DHCP Options for DNS Configuration Two protocols exist to configure the DNS information on a host: the RA options specified in this document and the DHCPv6 options specified in [RFC3646]. They can be used together. The rules governing the decision to use stateful configuration mechanisms are specified in [RFC4861]. Hosts conforming to this specification MUST extract DNS information from RA messages, unless static DNS configuration has been specified by the user. If there is DNS information available from multiple RAs and/or from DHCP, the host MUST maintain an ordered list of this information as specified in Section 5.3.1. 5.3.1. Procedure in IPv6 Hosts ... In the case where the DNS information of RDNSS and DNSSL can be obtained from multiple sources, such as RAs and DHCP, the IPv6 host SHOULD keep some DNS options from all sources. Unless explicitly specified for the discovery mechanism, the exact number of addresses and domain names to keep is a matter of local policy and implementation choice as a local configuration option. However, in the case of multiple sources, the ability to store a total of at least three RDNSS addresses (or DNSSL domain names) from the multiple sources is RECOMMENDED. The DNS options from RAs and DHCP SHOULD be stored in the DNS Repository and Resolver Repository so that information from DHCP appears there first and therefore takes precedence. Thus, the DNS information from DHCP takes precedence over that from RAs for DNS queries. On the other hand, for DNS options announced by RAs, if some RAs use the Secure Neighbor Discovery (SEND) protocol [RFC3971] for RA security, they MUST be preferred over those that do not use SEND. Also, DNS options announced by RAs via SEND MUST be preferred over those announced by unauthenticated DHCP [RFC3118]. Refer to Section 7 for a detailed discussion of SEND for DNS RA options. --------------------------------------------------------- Thanks. Paul On Mon, Apr 3, 2017 at 4:47 AM, Enno Rey wrote: > Hi, > > On Mon, Apr 03, 2017 at 09:20:01AM +0200, Mikael Abrahamsson wrote: > > On Fri, 31 Mar 2017, Fred Baker wrote: > > > > > Something that would help me, in this discussion, would be a simple a= nd > > > incontrovertible statement of what breaks, or in which circumstances > > > RDNSS would be inappropriate. That would help me distinguish between > > > "SHOULD" and "MUST". Failing either, it sounds to me like "MAY". > > > > What I would like to see (this is not breakage though, only potential > > breakage and cause of confusion) is what a host should do if it gets > RDNSS > > information and potentially DNS resolver information via DHCP. > > This is somewhat covered in > > RFC 4862, 5.6 Configuration Consistency > =E2=80=9CIf the same configuration information is provided by multiple so= urces, > the value of this information should be consistent.=E2=80=9D > =E2=80=9CIn any case, if there is no security difference, the most recent= ly > obtained values SHOULD have precedence over information learned earlier.= =E2=80=9D > > and > > RFC 6106 > > =E2=80=9C1.2 Coexistence of RA Options and DHCP Options for DNS Configura= tion > > Two protocols exist to configure the DNS information on a host, the Route= r > Advertisement options described in this document and the DHCPv6 options > described in [RFC3646]. They can be used together. > The rules governing the decision to use stateful configuration mechanisms > are specified in [RFC4861]. Hosts conforming to this specification MUST > extract DNS information from Router Advertisement messages, unless static > DNS configuration has been specified by the user. > If there is DNS information available from multiple Router Advertisements > and/or from DHCP, the host MUST maintain an ordered list of this > information as specified in Section 5.3.1. > > RFC 6106, sect. 5.3.1: > > In the case where the DNS options of RDNSS and DNSSL can be obtained from > multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS > options from all sources. Unless explicitly specified for the discovery > mechanism, the exact number of addresses and domain names to keep is a > matter of local policy and implementation choice. However, the ability t= o > store at least three RDNSS addresses (or DNSSL domain names) from at leas= t > two different sources is RECOMMENDED. The DNS options from Router > Advertisements and DHCP SHOULD be stored into the DNS Repository and > Resolver Repository so that information from DHCP appears there first and > therefore takes precedence. Thus, the DNS information from DHCP takes > precedence over that from RA for DNS queries. > > =3D=3D=3D > > cheers > > Enno > > > > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a1144186cb7bacb054c425cf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rey,
Though the main idea is almost the same in= your mentioned text in Section 1.2 and Section 5.3.1,=C2=A0
RFC = 8106 replaces RFC 6106 as follows:T

---------------------------------------------------------=
1.2.=C2=A0 Coexistence of RA Options and DHCP Options for DN= S Configuration

=C2=A0 =C2=A0Two protocols exist t= o configure the DNS information on a host: the
=C2=A0 =C2=A0RA op= tions specified in this document and the DHCPv6 options
=C2=A0 = =C2=A0specified in [RFC3646].=C2=A0 They can be used together.=C2=A0 The ru= les
=C2=A0 =C2=A0governing the decision to use stateful configura= tion mechanisms are
=C2=A0 =C2=A0specified in [RFC4861].=C2=A0 Ho= sts conforming to this specification MUST
=C2=A0 =C2=A0extract DN= S information from RA messages, unless static DNS
=C2=A0 =C2=A0co= nfiguration has been specified by the user.=C2=A0 If there is DNS
=C2=A0 =C2=A0information available from multiple RAs and/or from DHCP, the= host
=C2=A0 =C2=A0MUST maintain an ordered list of this informat= ion as specified in
=C2=A0 =C2=A0Section 5.3.1.
=C2=A0 = =C2=A0
5.3.1.=C2=A0 Procedure in IPv6 Hosts
=C2=A0 =C2= =A0...
=C2=A0 =C2=A0In the case where the DNS information of RDNS= S and DNSSL can be
=C2=A0 =C2=A0obtained from multiple sources, s= uch as RAs and DHCP, the IPv6 host
=C2=A0 =C2=A0SHOULD keep some = DNS options from all sources.=C2=A0 Unless explicitly
=C2=A0 =C2= =A0specified for the discovery mechanism, the exact number of addresses
=C2=A0 =C2=A0and domain names to keep is a matter of local policy an= d
=C2=A0 =C2=A0implementation choice as a local configuration opt= ion.=C2=A0 However, in
=C2=A0 =C2=A0the case of multiple sources,= the ability to store a total of at
=C2=A0 =C2=A0least three RDNS= S addresses (or DNSSL domain names) from the multiple
=C2=A0 =C2= =A0sources is RECOMMENDED.=C2=A0 The DNS options from RAs and DHCP SHOULD b= e
=C2=A0 =C2=A0stored in the DNS Repository and Resolver Reposito= ry so that
=C2=A0 =C2=A0information from DHCP appears there first= and therefore takes
=C2=A0 =C2=A0precedence.=C2=A0 Thus, the DNS= information from DHCP takes precedence
=C2=A0 =C2=A0over that fr= om RAs for DNS queries.=C2=A0 On the other hand, for DNS
=C2=A0 = =C2=A0options announced by RAs, if some RAs use the Secure Neighbor
=C2=A0 =C2=A0Discovery (SEND) protocol [RFC3971] for RA security, they M= UST be
=C2=A0 =C2=A0preferred over those that do not use SEND.=C2= =A0 Also, DNS options
=C2=A0 =C2=A0announced by RAs via SEND MUST= be preferred over those announced by
=C2=A0 =C2=A0unauthenticate= d DHCP [RFC3118].=C2=A0 Refer to Section 7 for a detailed
=C2=A0 = =C2=A0discussion of SEND for DNS RA options.
--------------= -------------------------------------------

Thanks= .

Paul

<= div class=3D"gmail_quote">On Mon, Apr 3, 2017 at 4:47 AM, Enno Rey <erey@ernw.d= e> wrote:
Hi,

On Mon, Apr 03, 2017 at 09:20:01AM +0200, Mikael Abrahamsson wrote:
> On Fri, 31 Mar 2017, Fred Baker wrote:
>
> > Something that would help me, in this discussion, would be a simp= le and
> > incontrovertible statement of what breaks, or in which circumstan= ces
> > RDNSS would be inappropriate. That would help me distinguish betw= een
> > "SHOULD" and "MUST". Failing either, it sound= s to me like "MAY".
>
> What I would like to see (this is not breakage though, only potential<= br> > breakage and cause of confusion) is what a host should do if it gets R= DNSS
> information and potentially DNS resolver information via DHCP.

This is somewhat covered in

RFC 4862, 5.6 Configuration Consistency
=E2=80=9CIf the same configuration information is provided by multiple sour= ces, the value of this information should be consistent.=E2=80=9D
=E2=80=9CIn any case, if there is no security difference, the most recently= obtained values SHOULD have precedence over information learned earlier.= =E2=80=9D

and

RFC 6106

=E2=80=9C1.2 Coexistence of RA Options and DHCP Options for DNS Configurati= on

Two protocols exist to configure the DNS information on a host, the Router = Advertisement options described in this document and the DHCPv6 options des= cribed in [RFC3646]. They can be used together.
The rules governing the decision to use stateful configuration mechanisms a= re specified in [RFC4861].=C2=A0 Hosts conforming to this specification MUS= T extract DNS information from Router Advertisement messages, unless static= DNS configuration has been specified by the user.
If there is DNS information available from multiple Router Advertisements a= nd/or from DHCP, the host MUST maintain an ordered list of this information= as specified in Section 5.3.1.

RFC 6106, sect. 5.3.1:

In the case where the DNS options of RDNSS and DNSSL can be obtained from m= ultiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS op= tions from all sources.=C2=A0 =C2=A0Unless explicitly specified for the dis= covery mechanism, the exact number of addresses and domain names to keep is= a matter of local policy and implementation choice.=C2=A0 However, the abi= lity to store at least three RDNSS addresses (or DNSSL domain names) from a= t least two different sources is RECOMMENDED.=C2=A0 The DNS options from Ro= uter Advertisements and DHCP SHOULD be stored into the DNS Repository and R= esolver Repository so that information from DHCP appears there first and th= erefore takes precedence.=C2=A0 Thus, the DNS information from DHCP takes p= recedence over that from RA for DNS queries.

=3D=3D=3D

cheers

Enno




--
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D


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




--
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) J= eong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwa= n University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.= skku.edu/people-jaehoon-jeong.php
--001a1144186cb7bacb054c425cf2-- From nobody Mon Apr 3 05:44: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 711B2128768 for ; Mon, 3 Apr 2017 05:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 nlzsl7bnOss5 for ; Mon, 3 Apr 2017 05:44:07 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 34343128BA2 for ; Mon, 3 Apr 2017 05:44:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v33Ci5oo048395 for ; Mon, 3 Apr 2017 14:44:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 314BA20ED17 for ; Mon, 3 Apr 2017 14:44:05 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2823220EC22 for ; Mon, 3 Apr 2017 14:44:05 +0200 (CEST) Received: from [132.166.85.88] ([132.166.85.88]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v33Ci4CX005588 for ; Mon, 3 Apr 2017 14:44:04 +0200 To: v6ops@ietf.org References: <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> From: Alexandre Petrescu Message-ID: <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> Date: Mon, 3 Apr 2017 14:43:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 12:44:10 -0000 Le 31/03/2017 à 20:26, Fred Baker a écrit : [...] > Something that would help me, in this discussion, would be a simple > and incontrovertible statement of what breaks, or in which > circumstances RDNSS would be inappropriate. Not quite a breaking statement, and more implementation aspects: - the main OS distribution on Raspberry Pi does not implement DNS in RA (other such distrib does, but it's rather marginally deployed). - I understand Windows PCs and routers at IETF dont implement DNS in RA, but rather DNS in DHCP. A speculative breaking statement would be: resolver address delivered by RA overwrites the one delivered by DHCP, despite M==1 (or vice-versa). But never tried it :-) Alex > > YMMV, and probably does. > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Apr 3 06:05: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 2822D129590 for ; Mon, 3 Apr 2017 06:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 XZ15TaTEbldE for ; Mon, 3 Apr 2017 06:05:01 -0700 (PDT) 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 E9F30127286 for ; Mon, 3 Apr 2017 06:05:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 32C0BA2; Mon, 3 Apr 2017 15:04:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491224698; bh=lO6fdFpt1rL/odOhkVUhqGT8FywbplOvSselONDKFo0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sxE/5wz7A0TiAAaWPikIBIUndb5cF6U2kpWqONubVLKRmKSpWPsNBPF6yuV8A50q1 XVdYsnBLicGiFtB+9eVDJJl5q2FJRf5nejCduRYyKw4D26CqHp0xNxFcGWiuWN2iEI uEilkQEXQN9QM3FLZZSj5ENVtCT4hW3pddxct81U= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 19DE488; Mon, 3 Apr 2017 15:04:58 +0200 (CEST) Date: Mon, 3 Apr 2017 15:04:58 +0200 (CEST) From: Mikael Abrahamsson To: Philip Homburg cc: v6ops@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:05:03 -0000 On Mon, 3 Apr 2017, Philip Homburg wrote: > RA/SLAAC/RDNSS is hugely disruptive and brings no benefits because those > networks are designed for DHCP. I imagine you mean SLAAC A=1 is disruptive, ie hosts choosing their own addresses? Or in what is RA as opposed to default-gw-in-DHCPv6 differ for the network? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 3 06:21: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 D306B129579 for ; Mon, 3 Apr 2017 06:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 d5ll-LqoaRBy for ; Mon, 3 Apr 2017 06:21:18 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 77E0A1287A7 for ; Mon, 3 Apr 2017 06:21:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v33DLGhm020558 for ; Mon, 3 Apr 2017 15:21:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B21A320EE49 for ; Mon, 3 Apr 2017 15:21:16 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9D65F20EE1D for ; Mon, 3 Apr 2017 15:21:16 +0200 (CEST) Received: from [132.166.84.103] ([132.166.84.103]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v33DLGtF012263 for ; Mon, 3 Apr 2017 15:21:16 +0200 To: v6ops@ietf.org References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> From: Alexandre Petrescu Message-ID: <12b0913b-32ce-b0c2-b57d-2dec854032f0@gmail.com> Date: Mon, 3 Apr 2017 15:20:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:21:21 -0000 Le 03/04/2017 à 00:08, Tim Chown a écrit : [...] >> draft-petrescu-v6ops-ipv6-power-ipv4 is a brand new draft, slipped >> in just under the wire. The first question is whether the working >> group is interested; there wasn't time for that discussion to >> happen before IETF 98. If we ARE interested, what do we think of >> it? > > It would be more interesting if the reasons for the additional power > consumption were identified and discussed - there’s no sign of this > that I can see in the document - Right - no such sign in the document, although on the email list someone (Jen and colleagues?) tried an explanation several months ago - something related to the header size being larger. > are there recommendations for reducing power consumption for IPv6, > different to IPv4? At this time no recommendation we wrote. We are first doing our best make the figures are correct, wondering whether somebody else could confirm or infirm. Another organisation presented with these figures indicated these may represent bad news. Alex From nobody Mon Apr 3 06:26: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 4E0AD129629 for ; Mon, 3 Apr 2017 06:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 RnmODYKen_ex for ; Mon, 3 Apr 2017 06:26:47 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 15B38124234 for ; Mon, 3 Apr 2017 06:26:47 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 76F4EE6065; Mon, 3 Apr 2017 15:26:45 +0200 (CEST) Date: Mon, 03 Apr 2017 15:26:45 +0200 (CEST) Message-Id: <20170403.152645.74700966.sthaug@nethelp.no> To: lorenzo@google.com Cc: v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: References: <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> <20170403.082732.41681152.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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:26:49 -0000 > > Also, some of these operators have legal requirements to log and keep > > (for some time) the association between IP address and customer - a > > requirement which doesn't go away with IPv6, and which for IPv4 is > > easily provided by DHCP. With IPv6 and RA/SLAAC it means we need to > > (additionally) start scraping the router IPv6 neighbor tables > > That argument sounds plausible but it's actually not true. See RFC 7931 > section 9.1, but briefly: > > - If you don't have strong L2 security, DHCP tracking cannot track > malicious hosts. > - If you do have strong L2 security, you don't need DHCP for tracking. The L2 security is strong enough for $REGULATORY_AUTHORITY. I didn't find a section 9.1 in RFC 7931 "NFSv4.0 Migration: Specification Update", so I assume you meant a different RFC. Steinar Haug, AS2116 From nobody Mon Apr 3 06:33: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 C8FF0128C82 for ; Mon, 3 Apr 2017 06:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=dougbarton.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h992mXvAa5AE for ; Mon, 3 Apr 2017 06:33:18 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 58A5712869B for ; Mon, 3 Apr 2017 06:33:18 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 2650A85 for ; Mon, 3 Apr 2017 06:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491226402; bh=br+Lt68/lMhBr2lcCVwtOmmhZzTytHMb4EjJr19d2sI=; h=Subject:References:To:From:Date:In-Reply-To:From; b=RflOULcvjv+Sw2qQ+ziXLaGxvnLtbGMThnei7a9Fg0sMgU9TR/U5uedBYLpbmKYz/ mHtq8ignOoiAlaXkiFhbMVwC94HiuQgD6g0gZc8zbe4V3ImXnGev4IDc7HkJitpH3h P7n4dzJFuYQpe0UvOG6jFX6Ng5LKUiJqeDyQMuHQ= References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58F27AB4-E761-4308-9E5D-CC22F6709D3F@delong.com> To: v6ops@ietf.org From: Doug Barton Message-ID: <3e2df1a2-9807-4e6e-200f-243afea84c94@dougbarton.us> Date: Mon, 3 Apr 2017 06:33:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <58F27AB4-E761-4308-9E5D-CC22F6709D3F@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:33:20 -0000 On 04/02/2017 11:38 PM, Owen DeLong wrote: > >> On Apr 2, 2017, at 5:10 PM, Doug Barton wrote: >> >> On 04/02/2017 04:54 PM, Brian E Carpenter wrote: >>> On 03/04/2017 11:23, Doug Barton wrote: >>> >>> ... >>>> And as I've said several times now, I'm not anti-SLAAC. I think it's a >>>> great solution to a specific problem. But what we've known for over a >>>> decade is that it's not a *general* solution for host configuration. >>>> That solution is DHCP, and DHCPv6 should be given the ability to handle >>>> all of the host configuration, in the absence of SLAAC, specifically so >>>> that operators CAN choose the configuration that works for them. >>> >>> If you're arguing that there should be a DHCPv6 option to communicate >>> the default router, I couldn't agree more, for exactly the same reason >>> that we added RDNSS to RAs: so that both solutions can support a least >>> common denominator for communication: address, router, DNS server. >> >> Hooray! I am genuinely happy to see common ground on this topic. :) >> >> Is it finally time to get it done? >> > > Long overdue in my opinion, Glad to see we agree on something. :) Meanwhile, I'm taking a break from replying to you. Your latest replies continue to be in contradiction to things I didn't say, and/or am not proposing, making the conversation rather exhausting. Doug From nobody Mon Apr 3 06:39: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 3F3E112869B for ; Mon, 3 Apr 2017 06:39:51 -0700 (PDT) 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 Q9NVlwe-YdXt for ; Mon, 3 Apr 2017 06:39:49 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::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 630241286CA for ; Mon, 3 Apr 2017 06:39:49 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id e75so8160223itd.1 for ; Mon, 03 Apr 2017 06:39:49 -0700 (PDT) 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=nqc6wYEcXHIPlXzR7d6PcTxK9cu/JSvhUiGvnqPJxT8=; b=foFwF4kpcYR9pGGtspXRPlbstGQxIpMn1tySlpXj9AgxQi61tfD9uHD6gIpzfTcEBW A3aSk1d6LQ4EHQqYev1M25a6U2hxQ0F14g7hufC4yG9+4er8/6h1vSbCSSOzHxbzWJMb RI35i1Kok9huwHxL+6BeEtoWkdm8ZWEkMVL8VHKMS71BSP1YLlZrSfvyKpRUsbK2A/tB yG3JKPP5NrZiKy6U5RpHeyxRS7hUs9XDrDzAMBxmthg63kzsHoj8VYdeqo41UCshgUl5 YchN8qAQIBm7cuPbvwc0Ao6fhrWRFl2xgc0T+xVKZ/GV6oMl0WcKjl/lmwngvRJvhjTE sU0Q== 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=nqc6wYEcXHIPlXzR7d6PcTxK9cu/JSvhUiGvnqPJxT8=; b=uYR0a1CqRBjzQMnxDW0DTc4K8IqXZUkKgWr/GuhuVVJby8AbbbTtiGx5oywkZdjRyC YVqtIVxaR7/cv7ahv2T5yg5Q6FHStlC0Wk5yHjYWq5EjkAQ9V0VNWeXJknV0QNkcb67z 73KiUhCubEJh/JlxH/2ZdqxyxIh+a14hPnQj9X4/fulycMbyluA1zC4UqbEbzKBoNGPU x1nVGWqKp97k/pc9b7rsEc8O+5nTPbfHSngBWtCZxqOWti1BkjBd2L9FovcIqvPEt+qw u7XRMFjHYE67WOJ5E7/gZ5f4oXAO+66ySdytjBVRpRebiNA8jCPo6m9MVxJsBfNa1Z9w bu3A== X-Gm-Message-State: AFeK/H0RKBMu5l0NrDiIn1lDajUs8cFHkVbE1rYGzrEB7QTcLZwDUdTMYEQij9+8PHR39A== X-Received: by 10.36.205.194 with SMTP id l185mr9829223itg.87.1491226788658; Mon, 03 Apr 2017 06:39:48 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 189sm5770987itx.25.2017.04.03.06.39.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 06:39:48 -0700 (PDT) To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 4 Apr 2017 01:39:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:39:51 -0000 Lorenzo, On 03/04/2017 15:24, Lorenzo Colitti wrote: > On Mon, Apr 3, 2017 at 9:10 AM, Doug Barton wrote: > >> If you're arguing that there should be a DHCPv6 option to communicate >>> the default router, I couldn't agree more, for exactly the same reason >>> that we added RDNSS to RAs: so that both solutions can support a least >>> common denominator for communication: address, router, DNS server. >>> >> >> Hooray! I am genuinely happy to see common ground on this topic. :) >> >> Is it finally time to get it done? > > > Only if you have reason to believe that a new attempt to get consensus is > going to be more successful than the past three. I very much doubt that's > the case; in fact, if you proposed it again, I expect you'd see more > opposition from host OS developers than there was last time. I take a rather simplistic view of this. If the IETF defines two complete solutions, the "market will decide" applies. The particular combination of MUSTs and SHOULDs that we write down won't really matter; they could all just as well be MAYs. I might have my preferences, but all I really care about is that everybody gets connectivity. At the moment the IETF has defined two incomplete solutions, and as this thread shows, that makes it essentially impossible to define a combination of MUSTs and SHOULDs that make sense. Brian From nobody Mon Apr 3 06:53: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 9C6251287A7 for ; Mon, 3 Apr 2017 06:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 V52SboaFspxB for ; Mon, 3 Apr 2017 06:52:57 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F982124234 for ; Mon, 3 Apr 2017 06:52:57 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v33DqrjP021156 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Apr 2017 14:52:54 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <58E253B4.9010501@foobar.org> Date: Mon, 03 Apr 2017 14:52:52 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.12 (Macintosh/20170323) MIME-Version: 1.0 To: Brian E Carpenter CC: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:52:59 -0000 Brian E Carpenter wrote: > At the moment the IETF has defined two incomplete solutions, and as this > thread shows, that makes it essentially impossible to define a combination > of MUSTs and SHOULDs that make sense. which is the critical point: all attempts to augment the DHCPv6 protocol to make it feature complete are actively blocked because of what are for the most part, religious / political arguments. It would be helpful if those people who were consistently throwing hurdles in the path of e.g. dhcpv6 route option and one or two other feature gaps would kindly desist from doing so, particularly noting that they do not in general use the dhcpv6 protocol themselves. Nick From nobody Mon Apr 3 06:57: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 9A6D3128CFF for ; Mon, 3 Apr 2017 06:57:32 -0700 (PDT) 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, HK_RANDOM_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 SPR77O293TDi for ; Mon, 3 Apr 2017 06:57:30 -0700 (PDT) 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 B5E55128C82 for ; Mon, 3 Apr 2017 06:57:30 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id z204so139297834vkd.1 for ; Mon, 03 Apr 2017 06:57:30 -0700 (PDT) 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=BBUKhsYCHHg1nIvoAlI/ezy8gWoscHO94UYVyr5XVOg=; b=rxWLhvvLX4XsxYanzY+MclEmvqpT1u5cbyZGjyK0wQU11kcm2zFkOEuo2/RfX9q4SY n1UHS+xEdO9Ynt7Dsy477xBB3fYRXN/sUExLxsMcWdxUIthmPVxkrb3UyKpghduufJZI l8V2oFkwt7GwgcQ2YqhmTDazP+kVhp5SmFmB+zrbTlcngBtM4Y79xnl3bMecuAaZrLeQ /axoLHQaNMJtNlftGuvOcj378rNKVu1/Yu8ZtHG/IkzamEGUvfXrUmIoGlmtKFHBxBLn waclcYCDAyMlpnX4Dt1/rImBymGkYjAwuwym7nbh3bfRw+nRsxqyXifzZk2W5Eir4yaK GvNQ== 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=BBUKhsYCHHg1nIvoAlI/ezy8gWoscHO94UYVyr5XVOg=; b=XlN0Lm1pa9N23zkquSYNCAxmOLmvJtJ749Y4ne3MXEp3/F/Q3MizPWVgc3HCn+RxWo ghJCN1iST9nWFjnuDs5Hziyq6YDLDmOOVg/WCtg+HQyekvV5PCVDc/fd/RYb+AhFjq/+ RlKs9Ccxbenw1LSj+4KkR9NPxCmLKGGecB8y4o7IsWUwVNUEr1vjDGvmwHXCsQB26FkV p8M/8UFH2TFIWWYc0E0T+bOvCW66qltzrnUR46FK3CWNSg7qZAfQZfvZfcA2RqDmQEQu SKScY3UkzWyvjRcq58NYHMI4kSbj2mJ7f+3blfB44D++6H8EcG7mRhYhiaSR4LvIp9UK zPdg== X-Gm-Message-State: AFeK/H0qeZDGL7phghkVRcPLZKmKUy9LjeUp+HHwdVUTB0AQrriGWmBGWg7jQyuiFp3O5ZfEhmVXe1SzXQhAAw== X-Received: by 10.176.3.212 with SMTP id 78mr9242897uau.97.1491227849736; Mon, 03 Apr 2017 06:57:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 06:56:59 -0700 (PDT) In-Reply-To: <20170403.152645.74700966.sthaug@nethelp.no> References: <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> <20170403.082732.41681152.sthaug@nethelp.no> <20170403.152645.74700966.sthaug@nethelp.no> From: Mark Smith Date: Mon, 3 Apr 2017 23:56:59 +1000 Message-ID: To: sthaug@nethelp.no Cc: Lorenzo Colitti , v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:57:33 -0000 On 3 April 2017 at 23:26, wrote: >> > Also, some of these operators have legal requirements to log and keep >> > (for some time) the association between IP address and customer - a >> > requirement which doesn't go away with IPv6, and which for IPv4 is >> > easily provided by DHCP. With IPv6 and RA/SLAAC it means we need to >> > (additionally) start scraping the router IPv6 neighbor tables >> >> That argument sounds plausible but it's actually not true. See RFC 7931 >> section 9.1, but briefly: >> >> - If you don't have strong L2 security, DHCP tracking cannot track >> malicious hosts. >> - If you do have strong L2 security, you don't need DHCP for tracking. > > The L2 security is strong enough for $REGULATORY_AUTHORITY. > > I didn't find a section 9.1 in RFC 7931 "NFSv4.0 Migration: > Specification Update", so I assume you meant a different RFC. > What he is is saying is that neither DHCPv4 or DHCPv6 were designed to accurately audit IP address use on a link. If they were, they'd also somehow record static addresses in use and for DHCPv6, link-local addresses use. They don't and can't. This needs to be called out as often as possible, because people assume the security mechanism that relies on this false assumption is effective at its purpose, when it actually it isn't. This group shouldn't accept this as a reason for using stateful DHCPv6 for addressing. Regards, Mark. From nobody Mon Apr 3 06:57: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 468571292AE for ; Mon, 3 Apr 2017 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 63Y4PjoF8gqu for ; Mon, 3 Apr 2017 06:57:38 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::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 C3B84128D44 for ; Mon, 3 Apr 2017 06:57:38 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id w11so8200046itb.0 for ; Mon, 03 Apr 2017 06:57:38 -0700 (PDT) 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=HM2Iw00frzggPCwebLt5eokjda8TeTEHAKLMFVvTgbg=; b=eL/6dh23hVO+iUOrtkefrKVPtqcltFUIC3agUxA9gTxGm2YnO9+Mr20DQ+foXWWYm9 jBX5ZbrvZ5vzqNKbwZ5OQwVsNBenkrf1kUDaHDfTNHr+nZop9iMAW5FGm+ImjWoIWb31 r/0QNm/oQEBqiyd1Vwm/AjeLsOMEeRvpDUiKwE4XEtcdu8E2mCcdS9HSr7o6fuSEXLHA K/8pUPJSAFBqQKV6HKygAE6J9NizaKeKWTLGK0fGUgZEySpwIyzoySUvIAxnBReRyhm0 Q7JY3b5UVmLtufizHlB7MsUgWqpNmiYj7qVd5/oaJbvlxDbsMnwwKnObKBMNBQPp/Qho mJOQ== 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=HM2Iw00frzggPCwebLt5eokjda8TeTEHAKLMFVvTgbg=; b=JDr6aqnAn1fLHy/5Wn9a0hwqFyd5FWUyTyG9fuQdpCSQ9dSrRxb6U3xfTDlyWMGi+O uzgCfyeYe+zzp58pJR9vFc1ZGQKZc5Ip4EVvMDKztvuHd0SLICjNbl0IuXggJPHOE+nB R4duTJewwCN69pV+1gazH7vzrhnayjfSWytwXfRZupalDnZKMm91eZp/YrVn2SBcHT8X Blh48IZ3NNykIMeSelI26vk4OEv0PU0AVfIICieEtCbU/AvF+FBS7Ke34BTRK3kHcVhk 2nloBWUrr90zpK5v+0T7TuqRTVVzJSkBoSaDiIzPrH2300zP1DjuwYrTvoeiz3/TpnfJ Jwsw== X-Gm-Message-State: AFeK/H0yy0MeYO6ZIT0lmPkmvCobtfOznt7JSJ0c3g/ShS48z5LhDLc4 fmzIlncbcHxQkDxS X-Received: by 10.36.196.8 with SMTP id v8mr9561767itf.115.1491227858100; Mon, 03 Apr 2017 06:57:38 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id r133sm5819670ith.9.2017.04.03.06.57.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 06:57:37 -0700 (PDT) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <57f50cf9-7b70-4e38-fc85-39885acff54d@gmail.com> Date: Tue, 4 Apr 2017 01:57:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:57:40 -0000 On 04/04/2017 01:04, Mikael Abrahamsson wrote: > On Mon, 3 Apr 2017, Philip Homburg wrote: > >> RA/SLAAC/RDNSS is hugely disruptive and brings no benefits because those >> networks are designed for DHCP. > > I imagine you mean SLAAC A=1 is disruptive, ie hosts choosing their own > addresses? There are certainly a lot of networks that work that way. When they need asset management and traceability, they use MAC addresses. (MAC address randomization is a considerable threat to this operating model, unlike SLAAC.) Brian From nobody Mon Apr 3 06:58: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 CFD021292F5 for ; Mon, 3 Apr 2017 06:58:10 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 F4QIldeVZXnQ for ; Mon, 3 Apr 2017 06:58:08 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::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 435D4124234 for ; Mon, 3 Apr 2017 06:58:08 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id f204so33595440ybc.2 for ; Mon, 03 Apr 2017 06:58:08 -0700 (PDT) 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=rMlz6mkbp8mdKcFUhTu78icI8PeA2HtLzL85kNU7gjU=; b=nVYumsFpkfzuqask4PQ+GFcVKlkawSHXmUoQJVaToHb5M1M1Hc/RUh42qydi2osdGx +IzsiBFv2Uto4MW06mbTxpXcbo/89c4KXG66M5Kt61AQPg5ghh5MkH3Krc1HskkNNWHJ 6f2q3/xB/WeZiSiDn/KQtxTGLaWltXw9mfntMKoH2Ja7W3zpiafZxSFIOTjXAmQCZKks RrsVBaDwSdbvw2Qr22BOfD4YqX23YjHxr9CpalM5u59DzSJOxIS62m4prhO2CzFJyCCx CkWeFYXqj/h2tvT1dbEVpYVVwMssCxlWu0zSAwq23uVl7MJKIwoC7gx2WdW4r5fwh8hL Vn9A== 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=rMlz6mkbp8mdKcFUhTu78icI8PeA2HtLzL85kNU7gjU=; b=cs1vjBoXQ1qh2ZosX90G/IpVvg1wB56uscxEufDdbgDtMmWh4Lqpb9NMmP4T8a9YKV r/DKwft/60y7qxQ6IOuDvKlJSbL7p8HVm0koHAqU8TxhAuLkLX5nG+O+++9MJf7jW8l7 zW//ODVoIwrkzgW7oUhgEMJymRCblANjZXQ6qxzheuQfQ5d0a8D2wZ9YFT5ktTOg96xc 12ojXx/xlPdgCxbF13f0kgogtGhPdsdlKyJ0nd6ZZRJSjq8Gho/mW1RU/tO7aL6+BhVY z2i/cmDp0u8XkVtf0LR1jaUJ5g2IfAxFcl9yRRdouS5ybQjOfnP9BhPrvcd6UnzqvV3m 5e8Q== X-Gm-Message-State: AFeK/H1E5lsswaMJpqt/qUbgYQeGfZS9Lk6fBJTUldkctVaaJnSj427B8+CzN3yUTEhUJhfEWHu9koePnWfZLxLB X-Received: by 10.159.36.77 with SMTP id 71mr9153690uaq.124.1491227887002; Mon, 03 Apr 2017 06:58:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Mon, 3 Apr 2017 06:57:46 -0700 (PDT) In-Reply-To: <20170403.152645.74700966.sthaug@nethelp.no> References: <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> <20170403.082732.41681152.sthaug@nethelp.no> <20170403.152645.74700966.sthaug@nethelp.no> From: Lorenzo Colitti Date: Mon, 3 Apr 2017 22:57:46 +0900 Message-ID: To: sthaug@nethelp.no Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a113dc80e7cde34054c438c30 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:58:11 -0000 --001a113dc80e7cde34054c438c30 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 10:26 PM, wrote: > > - If you don't have strong L2 security, DHCP tracking cannot track > > malicious hosts. > > - If you do have strong L2 security, you don't need DHCP for tracking. > > The L2 security is strong enough for $REGULATORY_AUTHORITY. > Then we should explain to $REGULATORY_AUTHORITY that what they are asking for is insecure and they should follow the best current practices in RFC 7934. I didn't find a section 9.1 in RFC 7931 https://tools.ietf.org/html/rfc7934#section-9.1 --001a113dc80e7cde34054c438c30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 3, 2017 at 10:26 PM, <sthaug@nethelp.no> wrote:
=
>=C2=A0 =C2=A0 - If yo= u don't have strong L2 security, DHCP tracking cannot track
>=C2=A0 =C2=A0 malicious hosts.
>=C2=A0 =C2=A0 - If you do have strong L2 security, you don't need D= HCP for tracking.

The L2 security is strong enough for $REGULATORY_AUTHORITY.

Then we should explain to $REGULATORY_AUTHORITY that w= hat they are asking for is insecure and they should follow the best current= practices in RFC 7934.

I didn't find a section 9.1 in RFC 7931
=
=C2=A0
--001a113dc80e7cde34054c438c30-- From nobody Mon Apr 3 07:05: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 940611286CA for ; Mon, 3 Apr 2017 07:05:40 -0700 (PDT) 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 jNJggqEoi2Oc for ; Mon, 3 Apr 2017 07:05:39 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::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 EDC06124234 for ; Mon, 3 Apr 2017 07:05:38 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id f103so12136002ioi.2 for ; Mon, 03 Apr 2017 07:05:38 -0700 (PDT) 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=h1Jb2OgoyVTghKdqfu1qFm8xVw/dhW71zLkngtFeGEs=; b=i8ZBuLzm00E+Ge+oNIXfiOyi9O3244eIXFmu5+/ONAn44LyKerjHyjDPhqUcCKm044 EP9Tq26nTkvizpQp8FHNzHzRW+HZL0GMmLLnAgA+ui2xLvyfFI75OXqY4qBGNORkW/cG K01JZdbHze2ThsYpUNtyf9/j/ol9EcYE0GthOSpXbdiB9tJlg7pMpptD9DLkqYNQR43k URrtCiCnjS4lTjg1GI9R46MKLcglssKxw02/DZAw8MegTzEdtLT2vu3Jend3GIwDXXVi EQia7U7p9i6/lE8TicL+2uX4T4/pK9EajRrN2gVaFeiixHBfRHY2NHuaSQw3dOhiEu+7 tGzw== 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=h1Jb2OgoyVTghKdqfu1qFm8xVw/dhW71zLkngtFeGEs=; b=Amu4AgWgsKFiiVMiXpjWALXcD95HjBBALkDOWGu3gEUd4G4iKXlwNa4ODdIl4pSrbt 14v/zO7raf776aLe4T5HzaraxMdZv8J/YH2MjPwruRQ7uy4H6Jb143dCvW4N7uh/rUpZ rSbUultxy3YwJB/+e7JkC6PySaBiToKm/61wh0XWKEojZkFvDG4avumOvNFPf786WRMD dnvyV6lc2MVnhk+00jaJvIoCy57t+YBM7JdsGgZTtQN3CKLvsESVuH+sICmloPv9Xlmi UZvEVc/781DiLTZVATFewEN3rFHNzQ4lo47D0pJNBng//VcpYK3UFyhyq0uJH6JQonLM m2AA== X-Gm-Message-State: AFeK/H13Jflx1gt+KolvBqjEYONUWVK/giwrsPpRHVnlWBgi4n54ihylDxK7wZlUj2a1zA== X-Received: by 10.107.134.94 with SMTP id i91mr16273699iod.0.1491228338109; Mon, 03 Apr 2017 07:05:38 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 9sm4567751itm.6.2017.04.03.07.05.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 07:05:37 -0700 (PDT) To: Mark Smith , Doug Barton References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <8ab82700-3590-4370-d15c-e41f6d6bb64f@gmail.com> <25600485-9133-28d4-25e8-b13373a0cffd@dougbarton.us> <2DC3DE6D-825B-4572-B617-1DA4D788E4B8@delong.com> <52F551E1-86A0-4109-A615-7D602ACFCF1D@delong.com> <7244ff1e-1315-f855-4768-35f9f64ea33e@dougbarton.us> Cc: v6ops list From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 4 Apr 2017 02:05:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:05:40 -0000 On 03/04/2017 19:26, Mark Smith wrote: ... > No, what got us in this mess in the first place is not following what > is in RFC1958, > > " 3.2 If there are several ways of doing the same thing, choose one. > If a previous design, in the Internet context or elsewhere, has > successfully solved the same problem, choose the same solution unless > there is a good technical reason not to. Duplication of the same > protocol functionality should be avoided as far as possible, without > of course using this argument to reject improvements." > > RDNSS isn't a significant improvement over stateless DHCPv6, which is > why host and router vendors are unsure about which one to implement, > and operators are unsure about which one to deploy when they have a > choice. Being the editor of RFC1958, I'll make a final comment (then try to shut up on this thread): We were in a bind in this case. SLAAC was aimed at the dentist's office scenario. DHCPv6 was not part of the initial IPv6 design - it was a retro-fit for enterprise scenarios, when DHCP(v4) became a success. And IMHO we screwed up by not clearly separating the scenarios and not thinking jointly about the points where the functional requirements overlapped. Brian From nobody Mon Apr 3 07:28: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 1C262128DE5 for ; Mon, 3 Apr 2017 07:27:58 -0700 (PDT) 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, HK_RANDOM_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 56p7TPpUClW8 for ; Mon, 3 Apr 2017 07:27:56 -0700 (PDT) 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 754BB128D44 for ; Mon, 3 Apr 2017 07:27:55 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id s68so140197796vke.3 for ; Mon, 03 Apr 2017 07:27:55 -0700 (PDT) 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=F/Q3FSMazCmxcuhSKirKGAqU1wEmEgaZkAxErPNAENk=; b=vWczjjzlbOu9t/S7DZCysCn4X9hOMkivMpIkzpu29wTTk6bIIwIILDgNRdHSPPi2cZ BCyXy/PnqzFPKKtsq4Lr0VDhwDIod22Vor5ilkUmhnSErrbRqv4bY/IHaIr8g8pRWSpG Yca1+VtIg+25Aac0SkAa/gkSpKebeZeSkVk6GvrYInlV0KydsEPbkbZe5DvW+oXUnC9t CvcmnAD4ZRmJhQVYk2Pl3RM0Kj8+xRjKKB7FLLT/eUTjzfhL0jyyodm0TVXr+a5XiSFm Sjk8D1fhQHakjfY6uaHoZzYubOWzaCxWr866IZknRrBlEOBYvjEdcmGleq85MVb6LrrL 7zqA== 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=F/Q3FSMazCmxcuhSKirKGAqU1wEmEgaZkAxErPNAENk=; b=fskUnTjfkKoIwknFE0P3n87nYQHcSevy9O+4x9QJaehS3Ywj4jB39N+wVBCgIwVlxp cg2MLJyH8zEkYGYl2kHi6fFUeaN7EL4E9XaC4rsF5HNqmDVkIVLzoUbjlDMSH0TRlkuR e0UpAk5A6hSyn2AWWk6MR51BV4Kv+VJ7OlKISrjJalMJqfl/OAy65L6J0ClyztuQUCeV x/PwbGK5pJpBzGrAr4YDGz/+2mlVbmzwSs+gxhUDxU2bFbCxX1qYCRgIEFW5rexTprbA CPElFSAktXFWLpvyh7d8BWmyfz9H4dCcR97IJcirtfz5ZghF6v8jaZA81RKw3fdFCpbb m8QQ== X-Gm-Message-State: AFeK/H2APDIH5uK/XT/UwTi4jMoj31kAl+/VFg8JxutrlkH8MNKDdkousHDIUOIWQ1NiXerLnG9x4UsCswRg/Q== X-Received: by 10.159.49.87 with SMTP id n23mr8596617uab.157.1491229674316; Mon, 03 Apr 2017 07:27:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 07:27:23 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Tue, 4 Apr 2017 00:27:23 +1000 Message-ID: To: Mikael Abrahamsson Cc: v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:27:58 -0000 On 3 April 2017 at 20:27, Mikael Abrahamsson wrote: > On Mon, 3 Apr 2017, Mark Smith wrote: > >> I doubt people are not deploying IPv6 in Enterprises because DHCPv6 >> doesn't support default gateways. Very few enterprises have a business need >> to deploy IPv6, because it isn't solving for them a problem that IPv4 isn't >> already or can't be used to solve. > > > I have talked to several. They have built operational practices around how > IPv4 happened to evolve, and if you show them IPv6 then they'll try to > hammer that into being as close carbon-copy of IPv4 as possible so they > don't have to change the way they run things. I don't know what they end up > doing in the long run, but I've seen many times where people will take > whatever IPv4 design they had and try to cram in IPv6 into it with as little > change as possible. I also have stated that they won't deploy IPv6 until > Android gains IA_NA capability. "my network my rules". > > "We do client tracking via DHCPv4 address leases, so we need to do that in > IPv6 as well". "Do you have SAVI on your switches?" "no" "then your tracking > is not guaranteed" "it's good enough for $RULEMAKER". > > I have spent considerable time with people trying to convince them there are > other ways to do what they need to do. At least the initial reaction is > always "NOOOOOOOO", I don't know what the end result is. > So I don't think these people would actually be addressing a real business need that IPv6 can only solve, because they have the luxury of choosing not to deploy it. > Just to be clear, I don't think it's a good idea to cripple IPv6 just so > that people can make it look like IPv4 to suit their current operational > practices. > Agree. I think there are a generation of network engineers that have learned IPv4, and have not had any experience with past other networking protocols such as IPX, Appletalk, CLNS etc. They may believe that the way IPv4 solves various networking problems are both the only and best ways to solve them, having not been exposed to any other ways to solve them. (Radia Perlman's "Interconnections, 2nd Ed" is a great book on different layer 3 protocols and how they solved similar problems.) Some will be willing to accept the new and different IPv6 ways. Others won't, and they'll likely be more vocal about it than those that just accept that something new might be different (I'm not being pejorative, it's human nature, it is common for people to resist change.) Regards, Mark. From nobody Mon Apr 3 07:45: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 137DC126D85 for ; Mon, 3 Apr 2017 07:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDNPXSbrxcpk for ; Mon, 3 Apr 2017 07:45:03 -0700 (PDT) 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 1F75812940E for ; Mon, 3 Apr 2017 07:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491230696; bh=0KI20/TFRJNmKuTW75tUZ7/SLJ+V3+tFSvzBzqoAR2I=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=bn2aLATNhSPSFGDcVzjVTF7KCONhVnNz+MNi4n0p3c8rhjo043i4M4tgML2emNCWI6eyq5WedgoT9avsHg2uhkBsau9NJ8ufpUFzeRhy8WswZ78QwUbZg6sDXd6Dj1GZ9/ydCLRUvr/HGGvQsbUck0zAt6C1Lmcr+vakh65CKjo= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0213.outbound.protection.outlook.com [213.199.154.213]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-91-qtNjqSJRNWi2ZzRk6SrmyA-1; Mon, 03 Apr 2017 15:44:52 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Mon, 3 Apr 2017 14:44:50 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Mon, 3 Apr 2017 14:44:51 +0000 From: Tim Chown To: Brian E Carpenter CC: Lorenzo Colitti , Russ White <7riw77@gmail.com>, "IPv6 Ops WG" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGtY7oAgAAYnICAAAT9AIAAZM8AgAAOCQCAAMuvfYAAJiQAgAAFCe+AAA2VAIAACV1hgAADj4CAAAObUYAAAIjugAASD4CAACtCgIAACo0AgAApOYCAAE8HAIAAMskAgACTUICAAzAMAA== Date: Mon, 3 Apr 2017 14:44:50 +0000 Message-ID: <02E0B454-7BEB-47E7-920A-8E5E4A6A974E@jisc.ac.uk> References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> 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: [2001:a88:d510:1101:f14f:15a4:6a00:cc70] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:J5LlQz7Bt8sAhYrM/H8pfrnSGlGx9qdpELZdBOyoTdWKWjn5o3F0yd+1aVKN8VaUMe2f7f4bO8LjEeWI/gsjmLCaiJv3lrQK9UqOe7OWtffY3qut4zZG3pFmvBlRRQBdA9QfDYuYM3/LwRBvYDGM4/D0KOebAh2PMz6dT7cbth/YHenXaJD71IwtgMWGAEQXJw/79qZTXsW3burd+Kuj8R9OGcEggv8EbKco5tsjLlznCmcI4vTra8e1tsFf5L0qjsSQfL7qX2WfbfvanFhgHbktwbdQtBfto5pj4dBIkC5silnuw1u5oyqqYdIOoXFkiV90iRu+of3oSMPEL1iIIg==; 20:giiPkv0EE5veJUjMJCEkv3eCR2KN3sYVAMECidSqwh1cq0LtK2CkDaicwhpFJG29Mko//dtPkeVgG2jxjfFRFtmGFPDWcGxKkp7hDNi7d/egsPsbEqeKYwx+qa7DRI2X3FRsydZylHHpkE1Y3bxjjFxL53SObCKq75nm04ZwvfI= x-ms-office365-filtering-correlation-id: 3c67b7ff-6db2-423d-1f27-08d47a9ffbec x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39410400002)(39400400002)(39450400003)(24454002)(6916009)(2950100002)(82746002)(42882006)(5660300001)(229853002)(83716003)(6116002)(102836003)(6436002)(4326008)(6506006)(38730400002)(39060400002)(57306001)(54906002)(6486002)(236005)(25786009)(110136004)(53546009)(7736002)(6246003)(74482002)(86362001)(99286003)(189998001)(2900100001)(3660700001)(3280700002)(36756003)(2906002)(33656002)(53936002)(81166006)(76176999)(50986999)(97736004)(6512007)(8936002)(54896002)(50226002)(93886004)(8676002)(5250100002)(80883001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 14:44:50.9620 (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: qtNjqSJRNWi2ZzRk6SrmyA-1 Content-Type: multipart/alternative; boundary="_000_02E0B4547BEB47E7920A8E5E4A6A974Ejiscacuk_" Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:45:08 -0000 --_000_02E0B4547BEB47E7920A8E5E4A6A974Ejiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 1 Apr 2017, at 15:04, Brian E Carpenter > wrote: On 02/04/2017 02:06, Ted Lemon wrote: You should read Fernando's draft. It's short. Ask yourself what "must support" means in practice. How is it configured? If the router has a list of DNS servers, must it send both rdnss and DHCP versions of that info? What if there is centralized DHCP service on the network? Your don't have to ask these questions for rdnss. No, but you have to answer the question of what tools are available for configuring the appropriate DNS server address into the router, which also varies according to the scenario. Maybe there's already a YANG module that covers this? But in both cases extra guidance is needed. No, there is not, but there should be a draft on this capability soon; it w= as left out of the netmod core work on router config as that focused purely= on 4862 features. (Now half way through the 117 emails on this thread :) Tim --_000_02E0B4547BEB47E7920A8E5E4A6A974Ejiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: Content-Transfer-Encoding: quoted-printable
No, there is not, but there should be a draft on this capab= ility soon; it was left out of the netmod core work on router config as tha= t focused purely on 4862 features.

(Now half way through the 117 emails on this thread :)

Tim
--_000_02E0B4547BEB47E7920A8E5E4A6A974Ejiscacuk_-- From nobody Mon Apr 3 07:46: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 C93A51292D0 for ; Mon, 3 Apr 2017 07:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, 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 SG3gU7dKXKeh for ; Mon, 3 Apr 2017 07:46:17 -0700 (PDT) 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 6B7121293E1 for ; Mon, 3 Apr 2017 07:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12934; q=dns/txt; s=iport; t=1491230771; x=1492440371; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/h7jgX2uceYeqB9QkyWXKYACPTGQj44CNzklu0Ecozw=; b=gUvR0yEnuvC0GSVbLwZs395JdGlKIXrGYJzOvh3iDLHpQFUzhFO4F2qP O15HxlPNRkjxrhRW2gKfnzMkTmMyNePIkX6YSrkrEP2fGbLIvbQUy5Q6y aer+fbAp21+f6v6RLl0V/DuKVzeVoOTz1hFPgSdYdlBvWUkuJc/7BPynt w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAgAPX+JY/4wNJK1UBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCbmZhgQsHg1uKEpE1H5AhgyKCD4IOhiICGoMjPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUVAQEBAQMjVhACAQgRAwECKAMCAgIwFAkIAgQBDQWKDapOgiYriisBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdhk6CBQiCYoQtPgkBFRGCPy6CMQWcbQGST5E?= =?us-ascii?q?8k3QBHzhLOlsVUgGGR3WIOIENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,270,1486425600"; d="scan'208,217";a="228231466" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2017 14:46:10 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v33EkAIc007253 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Apr 2017 14:46:10 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Apr 2017 09:46:09 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1210.000; Mon, 3 Apr 2017 09:46:09 -0500 From: "Jeffry Handal (jehandal)" To: Lorenzo Colitti , "sthaug@nethelp.no" CC: "v6ops@ietf.org WG" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFt7uK4Os7GaEihDMgApfuiD6Gtt4wAgAAYnICAAAT9AIAAZM4AgAAOCQCAAHfWgYAAef4A//+xMV2AAGFtAP//tYFkgABXa4CAA4bHgIAAHM6AgAAH/wCAAIPgAIAABb6AgAAg/YA= Date: Mon, 3 Apr 2017 14:46:09 +0000 Message-ID: <7F19BD11-346C-4F18-8641-E721FADA39E3@cisco.com> References: <47418185-1fd7-de45-f81c-ab139f1013d8@dougbarton.us> <56397D1E-F117-478D-9FBA-AEA5FE1BB105@delong.com> <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> <20170403.082732.41681152.sthaug@nethelp.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.156.39] Content-Type: multipart/alternative; boundary="_000_7F19BD11346C4F188641E721FADA39E3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:46:20 -0000 --_000_7F19BD11346C4F188641E721FADA39E3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIExvcmVu em8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPg0KRGF0ZTogTW9uZGF5LCBBcHJpbCAzLCAy MDE3IGF0IDE6NDggQU0NClRvOiAic3RoYXVnQG5ldGhlbHAubm8iIDxzdGhhdWdAbmV0aGVscC5u bz4NCkNjOiAidjZvcHNAaWV0Zi5vcmcgV0ciIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbdjZvcHNdIE1ha2luZyBSRE5TUyBhIE1VU1Q/DQoNCk9uIE1vbiwgQXByIDMsIDIwMTcgYXQg MzoyNyBQTSwgPHN0aGF1Z0BuZXRoZWxwLm5vPG1haWx0bzpzdGhhdWdAbmV0aGVscC5ubz4+IHdy b3RlOg0KQWxzbywgc29tZSBvZiB0aGVzZSBvcGVyYXRvcnMgaGF2ZSBsZWdhbCByZXF1aXJlbWVu dHMgdG8gbG9nIGFuZCBrZWVwDQooZm9yIHNvbWUgdGltZSkgdGhlIGFzc29jaWF0aW9uIGJldHdl ZW4gSVAgYWRkcmVzcyBhbmQgY3VzdG9tZXIgLSBhDQpyZXF1aXJlbWVudCB3aGljaCBkb2Vzbid0 IGdvIGF3YXkgd2l0aCBJUHY2LCBhbmQgd2hpY2ggZm9yIElQdjQgaXMNCmVhc2lseSBwcm92aWRl ZCBieSBESENQLiBXaXRoIElQdjYgYW5kIFJBL1NMQUFDIGl0IG1lYW5zIHdlIG5lZWQgdG8NCihh ZGRpdGlvbmFsbHkpIHN0YXJ0IHNjcmFwaW5nIHRoZSByb3V0ZXIgSVB2NiBuZWlnaGJvciB0YWJs ZXMNCg0KVGhhdCBhcmd1bWVudCBzb3VuZHMgcGxhdXNpYmxlIGJ1dCBpdCdzIGFjdHVhbGx5IG5v dCB0cnVlLiBTZWUgUkZDIDc5MzEgc2VjdGlvbiA5LjEsIGJ1dCBicmllZmx5Og0KDQogICogICBJ ZiB5b3UgZG9uJ3QgaGF2ZSBzdHJvbmcgTDIgc2VjdXJpdHksIERIQ1AgdHJhY2tpbmcgY2Fubm90 IHRyYWNrIG1hbGljaW91cyBob3N0cy4NCiAgKiAgIElmIHlvdSBkbyBoYXZlIHN0cm9uZyBMMiBz ZWN1cml0eSwgeW91IGRvbid0IG5lZWQgREhDUCBmb3IgdHJhY2tpbmcuDQoqKioqKioqKioqKioq KioqKioqKioqKioNCldoZW4gSSB3YXMgb24gdGhlIG9wZXJhdGlvbnMgc2lkZSwgd2Ugc29sdmVk IHRoaXMgd2l0aCA4MDIuMXggYW5kIHJhZGl1cyBhY2NvdW50aW5nLiBUaGlzIHByb3ZpZGVkIHVz IHdpdGggdGhlIGlkZW50aXR5IGFuZCBpcHY0L2lwdjYgYWRkcmVzcyBvZiB0aGF0IHVzZXIuIFRo ZXJlZm9yZSwgaGF2aW5nIGdvb2Qgc2VjdXJpdHkgYW5kIHByb3BlciBsb2dnaW5nIGhlbHBzIHlv dSBzb2x2ZSB0aGUgdHJhY2tpbmcgaXNzdWUgd2l0aG91dCBESENQdjYuDQpPbGQgc2FtcGxlIG91 dHB1dCBmcm9tIGEgcmFkaXVzIGxvZzoNClR1ZSBPY3QgMjEgMDk6MzU6NTYgMjAxNCB1c2VybmFt ZT14eHh4eHh4QHh4eC5lZHU8bWFpbHRvOnh4eHh4eHhAeHh4LmVkdT4gQWNjdC1TZXNzaW9uLUlk PTU0NDY2ZThmLzc4OjdlOjYxOjUwOjk4OmE1LzEwNDM4NTAwIEZyYW1lZC1JUC1BZGRyZXNzPTE3 My54eHguMTY4LjE2MyBGcmFtZWQtSVB2Ni1BZGRyZXNzPTJ4eHg6MTA1OmIwMGI6NDgxMDo4NTQ4 OmU2YTM6ZGEwYToxZDc5IEZyYW1lZC1JUHY2LUFkZHJlc3M9Mnh4eDoxMDU6YjAwYjo0ODEwOjgy YzoxOGUyOmJkNWI6ZjFmYSBGcmFtZWQtSVB2Ni1BZGRyZXNzPTJ4eHg6MTA1OmIwMGI6NDgxMDox ODFmOmU2NmU6MWNiMTplZTNiDQpSZWdhcmRzLA0KLS0NCkplZmZyeSBIYW5kYWwNCig4MzIpIDYw Mi00MjExDQoNCg0K --_000_7F19BD11346C4F188641E721FADA39E3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNv bG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6MTcxOTc0MjQ3NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc1 ODIwMjU4Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZy b206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpi bGFjayI+djZvcHMgJmx0O3Y2b3BzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBM b3JlbnpvIENvbGl0dGkgJmx0O2xvcmVuem9AZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+TW9uZGF5LCBBcHJpbCAzLCAyMDE3IGF0IDE6NDggQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90 O3N0aGF1Z0BuZXRoZWxwLm5vJnF1b3Q7ICZsdDtzdGhhdWdAbmV0aGVscC5ubyZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90O3Y2b3BzQGlldGYub3JnIFdHJnF1b3Q7ICZsdDt2Nm9wc0BpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFt2Nm9wc10gTWFraW5nIFJETlNTIGEgTVVT VD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMywgMjAxNyBhdCAzOjI3IFBNLCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnN0aGF1Z0BuZXRoZWxwLm5vIiB0YXJnZXQ9Il9ibGFuayI+c3RoYXVn QG5ldGhlbHAubm88L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBzb21lIG9mIHRoZXNlIG9wZXJhdG9ycyBoYXZlIGxl Z2FsIHJlcXVpcmVtZW50cyB0byBsb2cgYW5kIGtlZXA8YnI+DQooZm9yIHNvbWUgdGltZSkgdGhl IGFzc29jaWF0aW9uIGJldHdlZW4gSVAgYWRkcmVzcyBhbmQgY3VzdG9tZXIgLSBhPGJyPg0KcmVx dWlyZW1lbnQgd2hpY2ggZG9lc24ndCBnbyBhd2F5IHdpdGggSVB2NiwgYW5kIHdoaWNoIGZvciBJ UHY0IGlzPGJyPg0KZWFzaWx5IHByb3ZpZGVkIGJ5IERIQ1AuIFdpdGggSVB2NiBhbmQgUkEvU0xB QUMgaXQgbWVhbnMgd2UgbmVlZCB0bzxicj4NCihhZGRpdGlvbmFsbHkpIHN0YXJ0IHNjcmFwaW5n IHRoZSByb3V0ZXIgSVB2NiBuZWlnaGJvciB0YWJsZXM8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGF0IGFyZ3VtZW50IHNv dW5kcyBwbGF1c2libGUgYnV0IGl0J3MgYWN0dWFsbHkgbm90IHRydWUuIFNlZSBSRkMgNzkzMSBz ZWN0aW9uIDkuMSwgYnV0IGJyaWVmbHk6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCklmIHlv dSBkb24ndCBoYXZlIHN0cm9uZyBMMiBzZWN1cml0eSwgREhDUCB0cmFja2luZyBjYW5ub3QgdHJh Y2sgbWFsaWNpb3VzIGhvc3RzLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCklmIHlvdSBkbyBoYXZlIHN0cm9uZyBMMiBzZWN1 cml0eSwgeW91IGRvbid0IG5lZWQgREhDUCBmb3IgdHJhY2tpbmcuPG86cD48L286cD48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGVuIEkgd2FzIG9uIHRoZSBvcGVy YXRpb25zIHNpZGUsIHdlIHNvbHZlZCB0aGlzIHdpdGggODAyLjF4IGFuZCByYWRpdXMgYWNjb3Vu dGluZy4gVGhpcyBwcm92aWRlZCB1cyB3aXRoIHRoZSBpZGVudGl0eSBhbmQgaXB2NC9pcHY2IGFk ZHJlc3Mgb2YgdGhhdCB1c2VyLiBUaGVyZWZvcmUsIGhhdmluZyBnb29kDQogc2VjdXJpdHkgYW5k IHByb3BlciBsb2dnaW5nIGhlbHBzIHlvdSBzb2x2ZSB0aGUgdHJhY2tpbmcgaXNzdWUgd2l0aG91 dCBESENQdjYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9sZCBzYW1w bGUgb3V0cHV0IGZyb20gYSByYWRpdXMgbG9nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UdWUgT2N0IDIxIDA5OjM1OjU2IDIwMTQgdXNlcm5hbWU9PGEgaHJlZj0ibWFp bHRvOnh4eHh4eHhAeHh4LmVkdSI+eHh4eHh4eEB4eHguZWR1PC9hPiBBY2N0LVNlc3Npb24tSWQ9 NTQ0NjZlOGYvNzg6N2U6NjE6NTA6OTg6YTUvMTA0Mzg1MDAgRnJhbWVkLUlQLUFkZHJlc3M9MTcz Lnh4eC4xNjguMTYzIEZyYW1lZC1JUHY2LUFkZHJlc3M9Mnh4eDoxMDU6YjAwYjo0ODEwOjg1NDg6 ZTZhMzpkYTBhOjFkNzkNCiBGcmFtZWQtSVB2Ni1BZGRyZXNzPTJ4eHg6MTA1OmIwMGI6NDgxMDo4 MmM6MThlMjpiZDViOmYxZmEgRnJhbWVkLUlQdjYtQWRkcmVzcz0yeHh4OjEwNTpiMDBiOjQ4MTA6 MTgxZjplNjZlOjFjYjE6ZWUzYjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5KZWZmcnkgSGFuZGFsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPig4MzIpIDYwMi00MjExPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7F19BD11346C4F188641E721FADA39E3ciscocom_-- From nobody Mon Apr 3 07: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 0AEA9129422 for ; Mon, 3 Apr 2017 07:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 r9K3O19mFya4 for ; Mon, 3 Apr 2017 07:46:55 -0700 (PDT) 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 8AA571287A7 for ; Mon, 3 Apr 2017 07:46:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cv3Fm-0000HVC; Mon, 3 Apr 2017 16:46:46 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: In-reply-to: Your message of "Mon, 3 Apr 2017 15:04:58 +0200 (CEST) ." Date: Mon, 03 Apr 2017 16:46:45 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:46:58 -0000 >> RA/SLAAC/RDNSS is hugely disruptive and brings no benefits because those >> networks are designed for DHCP. > >I imagine you mean SLAAC A=1 is disruptive, ie hosts choosing their own >addresses? > >Or in what is RA as opposed to default-gw-in-DHCPv6 differ for the >network? One thing that DHCP is good at, is giving hosts unique configuration parameters. For example, some people have argued for a DHCPv6 default router parameter because they give some hosts on a LAN a different default router. Whether or not that make sense is a different question. If your network is designed like that, then having to redesign it to make it work with RAs is disruptive. (Because it is easy to do in DHCPv4, some hosts on my home network have a different set of DNS resolvers. If all I had was RDNSS then probably I could not have experimental DNS resolvers for some hosts without significant hacks). At the same time, there have been various additions to RAs and SLAAC to make it possible to have per host configuration. So in many ways RA/SLAAC is made to emulate DHCP, badly. From nobody Mon Apr 3 08:11: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 46FF91292F5 for ; Mon, 3 Apr 2017 08:11:42 -0700 (PDT) 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, HK_RANDOM_FROM=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 Vwz6cPT86zPu for ; Mon, 3 Apr 2017 08:11:40 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 C691E128CFF for ; Mon, 3 Apr 2017 08:11:40 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id i124so35600480ybc.3 for ; Mon, 03 Apr 2017 08:11:40 -0700 (PDT) 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=c80F8r22I1XQTZRGmV309u8FxgSYZa0sB1s9J5ivc44=; b=vIB5XypRnIDG9jjDemGaq+hhLxbiM9Tq1WHuWSFQxD1EuWnkJXfuqvbWhx60wnu5t1 XQZiNFZGyz95/U6zlkQYDp0v9ScJ+xxsS3vlNGHB3f9s4BWuWplhn4F1GgZWcBaLpNUC BR5o+GEjLo8g4iMjguvqTpTvfpnxvByi43nqxuRlrvu9+DB0OmeTr1hXaNgYkFJSG0eg 4nOe1oAXYXzT0bnIffOoo2JMG9+qpQn8cPYVMPV08eNUW3eTR0Vhd/A5VEQSMisoJUnW n2PvteZ/iPIYYOsgHiygcZT0HYz5E+uMyHunTlxSoqZ/mT96RBnQVyM8tqZLhdG/MeUu YioQ== 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=c80F8r22I1XQTZRGmV309u8FxgSYZa0sB1s9J5ivc44=; b=oAbogwFvy/aojADudabg1+ZRhC0VLko9gkVKv0P8yCne6vUGF+a8M7EU1msaE6PAzA 1bwwxmZiJfN0GOOY2vRcRdnre51l4d3ZPjK/NcHF8FB3ulktdpeffYQZNAKrMjCgivQg wNfHiC6e7ALGqeq9XmWCiVVDYTMiQlJpPbN2VenitKExHaH5WcXI79T56vJSMa7k1mD2 57jeeKG4WuOGYs8sahPFZUp06J2iidciuLNC9f7sZolsbOcInstJEnKhm6k9BM03AiWO 9LUkk9cmdyMPEVIwyGjZnMWJTH1djbp0aZ+yCvAmQsWlS3afXgJKDlo9aJOV1ViStdx/ 1zBQ== X-Gm-Message-State: AFeK/H07Xc8s7F+a7IiE9I7NsSFYjBiV8xo237uBgPqXz4cKrI4/LxNItQpEs3vgCYTnxUbNye6hvXw6nuhXCw== X-Received: by 10.176.83.124 with SMTP id y57mr7658695uay.141.1491232299886; Mon, 03 Apr 2017 08:11:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 08:11:09 -0700 (PDT) In-Reply-To: <58E253B4.9010501@foobar.org> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> From: Mark Smith Date: Tue, 4 Apr 2017 01:11:09 +1000 Message-ID: To: Nick Hilliard Cc: Brian E Carpenter , v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 15:11:42 -0000 On 3 April 2017 at 23:52, Nick Hilliard wrote: > Brian E Carpenter wrote: >> At the moment the IETF has defined two incomplete solutions, and as this >> thread shows, that makes it essentially impossible to define a combination >> of MUSTs and SHOULDs that make sense. > > which is the critical point: all attempts to augment the DHCPv6 protocol > to make it feature complete are actively blocked because of what are for > the most part, religious / political arguments. I think they'e being characterised as religious/political because people don't want to accept they're practical. People who think DHCPv6 should be extended with RA features aren't recognising that this specific RA/DHCP DNS issue and the related discussion, which is about the exact same type of scenario - two different ways to solve one problem where there is no clear advantage for either of them - is an example of would also be repeated in much greater depth by adding RA features into DHCPv6. Even more human effort would be being spent on problems that have already been solved adequately enough and that work instead of being spent on new problems that haven't been solved. > > It would be helpful if those people who were consistently throwing > hurdles in the path of e.g. dhcpv6 route option and one or two other > feature gaps would kindly desist from doing so, particularly noting that > they do not in general use the dhcpv6 protocol themselves. There needs to be a compelling reason why it is worth doing so, which would need to include showing scenarios where RAs aren't or cannot be made adequate. A reason of "it's different to how IPv4 worked" is a subjective ("religious/political"), not objective. A replacement method or an alternative method has a higher bar to reach to be acceptable and succeed, because there is already a method that is demonstrated to work, and in this case, one that has been deployed to literally billions of devices and has worked successfully for at least 18 years (that's when I first ran up radvd if I recall correctly). This is really what people are saying when they say "where were you in 1995 (or earlier)" - in 1995 the costs of changing this would have been far, far cheaper than they are today because there was no installed base. I accept that RAs are the way to convey default router and other link specific layer 3 configuration information because that's how it was done when I learned IPv6. If DHCPv6 had instead been used, I'd have accepted that method. To me, it is more important to have a single solution to a single problem that works well enough, regardless of the actual method. It's simpler, and that means less things to choose between, less things that can conflict with each other and less things that can break. That lowers opex and increases availability - entirely practical benefits of having a single solution. Regards, Mark. From nobody Mon Apr 3 08:43: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 DEDD012943F for ; Mon, 3 Apr 2017 08:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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=psc.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 HjLFsdzHhBPk for ; Mon, 3 Apr 2017 08:43:24 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.70.106]) (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 163EE126B6E for ; Mon, 3 Apr 2017 08:43:23 -0700 (PDT) Received: from dengue.psc.edu (dengue.psc.edu [128.182.160.217]) (authenticated bits=0) by mailer2.psc.edu (8.14.7/8.14.7) with ESMTP id v33FhLKH023155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Apr 2017 11:43:22 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mailer2.psc.edu v33FhLKH023155 Authentication-Results: mailer2.psc.edu; dmarc=none (p=none dis=none) header.from=psc.edu Authentication-Results: mailer2.psc.edu; spf=pass smtp.mailfrom=lambert@psc.edu DKIM-Filter: OpenDKIM Filter v2.11.0 mailer2.psc.edu v33FhLKH023155 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=psc.edu; s=default; t=1491234202; bh=d9YiyTsDJqaGR3/tEHaKGMYEqh2e1fv9zLiksJX/Aa4=; h=Subject:From:In-Reply-To:Date:References:To:From; b=uTZeNgFOd2C+JwhicM+NBEJg+JGNGBPasmxLdNwtAyu2XNmKH3AqfKe/3PEhdntma TkIHGK7i3TKmyzWRlpEEMzAycR8D1iNY4qhwixOTgfpCWjVth5U4TEE2WiuTgWu3o5 VJONVa18eP8EGKEgU94Ib1NQIQVmupkBdEZZDjGw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael H Lambert In-Reply-To: <6AE0263F-68C6-43C0-80E2-983F481AC575@delong.com> Date: Mon, 3 Apr 2017 11:43:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> <49A66D86-D916-475C-B8BC-A35111319275@thehobsons.co.uk> <6AE0263F-68C6-43C0-80E2-983F481AC575@delong.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 15:43:26 -0000 > On 2 Apr 2017, at 12:22, Owen DeLong wrote: >=20 > Perhaps we should break this into pieces with different mandates=E2=80=A6= >=20 > ... >=20 > Router: > Must support Router Advertisements including=E2=80=A6 > Ability to configure/support SLAAC > Ability to configure/support =E2=80=9CO-bit =3D 1=E2=80=9D= stateless addressing with DHCP for other information > Ability to configure/support =E2=80=9CM-bit =3D 1=E2=80=9D= stateful addressing using DHCP > >=20 > Must support DHCP6 Relay including=E2=80=A6 > >=20 > Should support DHCP6 Server including all requirements from = DHCP6 Server below. I'm just considering this last line without prejudice for or against the = merits of RA/SLAAC, DHCPv6, etc. I would argue for MAY, not SHOULD. In = our environment, we operate DHCPv4 servers as separate middle boxes. If = and when we deploy DHCPv6, I would expect to do the same. Any = requirements or strong suggestions that DHCPv6 servers be deployed in a = network should be from the perspective that nodes on a given network = segment have reachability to DHCPv6 services, not that routers on the = network segment provide those services. Michael From nobody Mon Apr 3 08: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 60E53126C7A for ; Mon, 3 Apr 2017 08:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1rbEUPFpWWa4 for ; Mon, 3 Apr 2017 08:57:28 -0700 (PDT) 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 EA242129413 for ; Mon, 3 Apr 2017 08:57:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cv4MA-0000HqC; Mon, 3 Apr 2017 17:57:26 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> In-reply-to: Your message of "Tue, 4 Apr 2017 01:11:09 +1000 ." Date: Mon, 03 Apr 2017 17:57:26 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 15:57:30 -0000 >There needs to be a compelling reason why it is worth doing so, which >would need to include showing scenarios where RAs aren't or cannot be >made adequate. > >A reason of "it's different to how IPv4 worked" is a subjective >("religious/political"), not objective. There are currently deployed networks that have to change a lot more to support RAs then they would have if there would be a DHCPv6 default router option. That's not subjective, that's an additional cost. There are also the vendors that do not support IA_NA. Forcing a change to SLAAC. That's even more expensive. Obviously, adding support for two ways of doing things also has cost. Somehow it seems that RA is the new religion. Adding something to RAs is way easier than adding an option to DHCP. DHCP was already completely standard in 2003 when RDNSS was first described. It seems the aversion against DHCPv6 was so great that in 2007 people were willing to except it as experimental. You would say that in 2010, most implementations would already support the one standard of getting DNS resolvers for IPv6, i.e. using DHCP, so RFC 6106 would just be duplicate effort. Yet somehow, the argument of duplicate functionality only comes up when people ask for support for DHCP. From nobody Mon Apr 3 09:48: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 CB342129482 for ; Mon, 3 Apr 2017 09:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 EMiFVvpU7lOS for ; Mon, 3 Apr 2017 09:48:30 -0700 (PDT) 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 76A60129478 for ; Mon, 3 Apr 2017 09:48:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 362FEA2; Mon, 3 Apr 2017 18:48:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491238108; bh=rusgN+SRaEqhXZqQmPrQbo3olC0Ov0bH6t1u8Hd3474=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DZSQUHggyEpSqrjNvsu7CrF4SCNeq7jE45EVBmPBjYCNFum8V0Seh2O+gKYxr5x/r 59Rxs/GbMy+TcKv/Rw8OdedsZ8o+TwwKDtcJoyA6jQRTDKGlHAIt5Hi8qsTq4GIU2+ ej3ydtHIRrAHn2fu7rNvkM6cfwZGAmYc1dCxTuz0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1E98788; Mon, 3 Apr 2017 18:48:28 +0200 (CEST) Date: Mon, 3 Apr 2017 18:48:28 +0200 (CEST) From: Mikael Abrahamsson To: Philip Homburg cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 16:48:33 -0000 On Mon, 3 Apr 2017, Philip Homburg wrote: > Yet somehow, the argument of duplicate functionality only comes up when > people ask for support for DHCP. Whenever I ask to extend ND or put new things into RA, I get lots of pushback. A lot more pushback than when I want a new DHCP option for something that relates to information for the device. The only major pushback that I have seen to put into DHCPv6 is the default router option for DHCPv6, because if we allow that then I would say that there are lots of other options in RA not currently available in DHCPv6 that I would basically say should be MTI. These are for instance MTU, PIOs with lifetimes etc. I think saying everything should be configurable using DHCP is short-sighted and removes a lot of the new functionality that IPv6 actually supports in current incarnation, that IPv4 currently doesn't. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 3 10:08: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 5A11D129476 for ; Mon, 3 Apr 2017 10:08:10 -0700 (PDT) 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 ZyGVZSu8EG95 for ; Mon, 3 Apr 2017 10:08:08 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9B126DD9 for ; Mon, 3 Apr 2017 10:08:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cv5SY-0000G9C; Mon, 3 Apr 2017 19:08:06 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> In-reply-to: Your message of "Mon, 3 Apr 2017 18:48:28 +0200 (CEST) ." Date: Mon, 03 Apr 2017 19:08:05 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:08:10 -0000 >> Yet somehow, the argument of duplicate functionality only comes up when >> people ask for support for DHCP. > >Whenever I ask to extend ND or put new things into RA, I get lots of >pushback. A lot more pushback than when I want a new DHCP option for >something that relates to information for the device. The text you quoted says 'duplicate functionality'. It is way easier to add new option to DHCP than in RA or ND. The reason is in DHCP if the client doesn't ask for the option, you just don't send it. Historically, RAs (and to some extend ND) are based on multicast where you don't have that kind of negotiation. >The only major pushback that I have seen to put into DHCPv6 is the default >router option for DHCPv6, because if we allow that then I would say that >there are lots of other options in RA not currently available in DHCPv6 >that I would basically say should be MTI. These are for instance MTU, PIOs >with lifetimes etc. I'm missing the point why that would be a big deal. Just about every system already has interfaces for static configuration of MTU and routes. So it would only be a tiny amount of code to support an MTU or an onlink prefix option. More worrying is that you are willing to delay deployment of IPv6 in enterprises because of fear that two new options would have to be added to DHCP. >I think saying everything should be configurable using DHCP is >short-sighted and removes a lot of the new functionality that IPv6 >actually supports in current incarnation, that IPv4 currently doesn't. A lot of that functionality is perfectly useless in many environments. (Note I'm not saying that we should kill RAs. Though I get the impression that they are hugely overvalued). But for some reason, not supporting functionality only provided by DHCP is perfectly alright. Weird. From nobody Mon Apr 3 10:21: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 CC50C12949B for ; Mon, 3 Apr 2017 10:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7ocF7mz8ycXn for ; Mon, 3 Apr 2017 10:21:38 -0700 (PDT) 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 BACF3129495 for ; Mon, 3 Apr 2017 10:21:38 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id x125so126535822pgb.0 for ; Mon, 03 Apr 2017 10:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=FMDWFOBf/3xhPvgYyZ4CgxHTIjzuzitKOldryhQbmtA=; b=WYYZqQ+fro2tBneCmrShSQhWcwj/KkhKj4TzZzFEdeA+HGXvpNA9AV1/j5+Yd2QCGZ ByCcqK7Bb1l5XSXVh0AjLUP1EoHxctkDxOCMDPSA/unF7RcnjjLmQPqN7hhPBH6MMFLU prj/1lcWpDxvHrxKMq8gmA755JXYn1hOoShZuaAWv+sc+Gz5pZeLpgkmOPRyQFHVfGXC rx7oWcJ2GXeuWxa7bWAclGxZ8Yly1K9UogMZd10LDUPky5vFCyl9llfHrXxPZPgkoqUb Nl/pz04dIaQeYFdPtCXiMm6UBUPw5rHxudAvL7Q3zW1I+gMRbDEsl0CVEz00RoWY8nkU WfGg== 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:date:references:to:in-reply-to:message-id; bh=FMDWFOBf/3xhPvgYyZ4CgxHTIjzuzitKOldryhQbmtA=; b=fndB7cBzWS7ankHOz0N3M08l79ldqm1qUQKCG4BcDuvrmW9jtF/y3eGpKbyOZ1pEZT k2oQkfZ/5Ho9FChTQABrQImgfvkUyvxKczZh9BWioFPzbrhqvz13uNsb6PuIVR3CRGsG hG863zsptE4XNQ/M4CO7Hpfk+sLIP1msW71BuwO9mmp133U3bNfHLqgexQV9ljfsoaLs eERNdS1UDL9joy0d0iQnISFmStagVw+Iu18voOzM9vA3En5xls2amFLO7FotATTGrJLF zS5xBUi/X8z2hSkEMfiW7v/wiz1/ihox9Yq+/OHH9CkGlhrUTElN2YWXikPSsBngJgT9 s42Q== X-Gm-Message-State: AFeK/H0Tv3c7hVot3s11SMbvqJPncFB4yXvq/7tzjmCWqBL84gc8xbDJr0ZRL5lZ9Uh9qQ== X-Received: by 10.84.143.1 with SMTP id 1mr23342332ply.70.1491240098121; Mon, 03 Apr 2017 10:21:38 -0700 (PDT) Received: from ?IPv6:2620::b60:17:e2:ff0c:62d0:f1a0? ([2620:0:b60:17:e2:ff0c:62d0:f1a0]) by smtp.gmail.com with ESMTPSA id s21sm27287163pgg.65.2017.04.03.10.21.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 10:21:37 -0700 (PDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Apr 2017 10:21:35 -0700 References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> To: IPv6 Ops WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:21:41 -0000 My reaction to this long and very predictable high-bandwidth = back-and-forth is that I suspect the outcome will be the same as it was = last time: no action. This is frustrating. It seems clear to me that requiring support for = RDNSS would improve the situation. Possibly requiring support for = DHCPv6 would also improve the situation if it were done correctly (which = is not a given). But whenever anybody proposes requiring RDNSS, we get = this demand for parity, and then a giant explosion of opinions, and then = no action. Essentially what I see here is a viable solution being held hostage to = demands for a controversial solution. It may be that the controversy = isn't valid, and that really requiring DHCPv6 is the right thing to do. = But the controversy exists, and makes requiring DHCPv6 problematic. I don't see any justification for a technical objection to RDNSS. So = my personal opinion is that despite the loud protests to the contrary, = there is consensus to require RDNSS. It may also be the case that = there is consensus to require DHCPv6, on the same basis. However, that = would require a document that describes what "require DHCPv6" actually = means. It is of course entirely possible that the document authors are just = plotzing at this discussion, or perhaps have chosen to ignore it, since = the document isn't explicitly mentioned anywhere in the thread. It = would be valid for them to say that this is simply not an opportunity to = re-open this issue. However, the section in the document on Zero Touch = Configuration certainly looks like a good place to insert a requirement. My personal preference would be that if there is any serious desire for = DHCPv6 to be required, that the proponents of this requirement write up = in a document what that support looks like. I don't think it makes = sense to do that in this document. I think it does make sense to = require RDNSS in this document, because I don't think there's any = question as to what that looks like. I realize that holding that hostage probably looks like a great way for = proponents of DHCPv6 support to get their way, but I don't think that's = what would happen: what would happen would be that the authors of the = document would say nothing at all on this topic. So that's your = choice: improve the situation, but don't get everything you want, or get = nothing. For those who do not want RDNSS, of course, the scorched = earth approach will be fine, but for the rest of us I think it's not = fine. From nobody Mon Apr 3 10:51: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 1C0E01294A9 for ; Mon, 3 Apr 2017 10:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 4nP3Tno58Ae5 for ; Mon, 3 Apr 2017 10:51:54 -0700 (PDT) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id DDAF91294B7 for ; Mon, 3 Apr 2017 10:51:53 -0700 (PDT) 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 v33Hpqjc022238 for ; Mon, 3 Apr 2017 13:51:52 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v33Hpqjc022238 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1491241912; bh=PViB1ffdjfjNxFn5Y0cKK3VU97wDKFelS+wv84byAes=; h=Date:From:To:Subject:References:In-Reply-To; b=sWKb5z0pBRI1HX+U2SDm414pHhz3KRuaJUnlrtZNC4QZRLSxiMcFq3q7i0c2aSSRJ t0Rz6Ag0JCjHVwYSJ/xqe1AE8sPXi7Uerm+0hylPiVG6Q/xffVHWgHV/VF+mhWkHzr bL1zYcnOZchKAjVw5+dQsK4SxgD0MKJdv7tX0sAM= 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 v33Hpqrp022232 for ; Mon, 3 Apr 2017 13:51:52 -0400 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 v33HpobV003354 for ; Mon, 3 Apr 2017 13:51:51 -0400 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id C5F42E114E; Mon, 3 Apr 2017 13:51:50 -0400 (EDT) Date: Mon, 3 Apr 2017 13:51:50 -0400 From: Chuck Anderson To: v6ops@ietf.org Message-ID: <20170403175150.GV4764@angus.ind.wpi.edu> References: <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> <20170403.082732.41681152.sthaug@nethelp.no> <20170403.152645.74700966.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=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_1900_1999 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, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_MONEY_CURRENCY 0, __FRAUD_MONEY_CURRENCY_DOLLAR 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_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:51:56 -0000 On Mon, Apr 03, 2017 at 11:56:59PM +1000, Mark Smith wrote: > On 3 April 2017 at 23:26, wrote: > >> > Also, some of these operators have legal requirements to log and keep > >> > (for some time) the association between IP address and customer - a > >> > requirement which doesn't go away with IPv6, and which for IPv4 is > >> > easily provided by DHCP. With IPv6 and RA/SLAAC it means we need to > >> > (additionally) start scraping the router IPv6 neighbor tables > >> > >> That argument sounds plausible but it's actually not true. See RFC 7931 > >> section 9.1, but briefly: > >> > >> - If you don't have strong L2 security, DHCP tracking cannot track > >> malicious hosts. > >> - If you do have strong L2 security, you don't need DHCP for tracking. > > > > The L2 security is strong enough for $REGULATORY_AUTHORITY. > > > > I didn't find a section 9.1 in RFC 7931 "NFSv4.0 Migration: > > Specification Update", so I assume you meant a different RFC. > > > > What he is is saying is that neither DHCPv4 or DHCPv6 were designed to > accurately audit IP address use on a link. If they were, they'd also > somehow record static addresses in use and for DHCPv6, link-local > addresses use. They don't and can't. > > This needs to be called out as often as possible, because people > assume the security mechanism that relies on this false assumption is > effective at its purpose, when it actually it isn't. This group > shouldn't accept this as a reason for using stateful DHCPv6 for > addressing. DHCP enables the security functionality in L2 switches that have DHCP Snooping, ARP Inspection and IP Source Guard features. This makes it possible to require that endpoints complete a DHCP transaction, and they are only allowed to send packets with a source address that matches a DHCP lease for that specific client while the DHCP lease is still valid and unexpired. From nobody Mon Apr 3 11: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 AFFB512948A for ; Mon, 3 Apr 2017 11:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 UmIvDkT-KO2d for ; Mon, 3 Apr 2017 11:07:24 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 942151294BE for ; Mon, 3 Apr 2017 11:07:23 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id g2so126159910pge.3 for ; Mon, 03 Apr 2017 11:07:23 -0700 (PDT) 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=eQ9pl0wtuDsJBwC7LpTczMw92x82ubTJgx8ZV2ZRBAg=; b=EOWmyO+/FiE9UyR5dbWAirotipuXLWLHyw5jWZ8ZUOAcFd7uBNVCUKN/KMYv8gAgXU mXrZI26NwmmeX078sh/MSXj0tViO+K0XUEF6wW+kcIMVhcrPuRoG33aiw3b23wG4SSgF iNukigKSWapHrSS2s1Hoebp6y53aVv6mlT1PQYhtbbrotUnKQgedK6lGR9/sxves0gMl JJ5xicWaPU51B+YT3YM8lySHANtjl25Bt9F4ayzS3JV57y0/Ir9MWXA/xgewRobTQKoT uIEos3xyVEKdWDwIgXBE7jkds1pT33tXuiQff7SIqfPyFCx3P00a8qwrbcTFWyC7eY3t 9YhQ== 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=eQ9pl0wtuDsJBwC7LpTczMw92x82ubTJgx8ZV2ZRBAg=; b=i/pe+6L3f14YMKT77q7TPovLCRPu8K/ByoXNoDq7+8zPQex07pZZ8uVdfOERq1X1+i ujtbKu4fa2VfhmqJ3FPhEjTYpNT8kob/yfUNt1UEHxXPzGTnT/VXP/YDtlEazKRkrmyC yi5KB8fHAQ05iTlETgdgAimEDtIrkX3FOrZfWHUhsWLtDjWdkPSbfN8bzAgmtaa1MCPW Xp3f0duE9ITjojRKzRx6uTzcF5Y76RY2Pt58UIHyBzNtiNave7ffOjYwQfMV3d6h6iAS FdJLXDpZyep6UTYM3GP5FsRvekAqRbj1G2TJlR9e0FWMiv/p0HFfn4Yk68r5ObEsELeh zJRA== X-Gm-Message-State: AFeK/H0JZCYJcl4+UHdZjjoXOMMdiSrhJH4dThJOT9nWNqbfv1+ENfJYLJaN/bz7b0BMhw== X-Received: by 10.84.218.71 with SMTP id f7mr23700899plm.188.1491242843203; Mon, 03 Apr 2017 11:07:23 -0700 (PDT) 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 g5sm27308009pgn.38.2017.04.03.11.07.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 11:07:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Mon, 3 Apr 2017 11:07:20 -0700 Cc: IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> To: Ted Lemon X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:07:26 -0000 On Apr 3, 2017, at 10:21 AM, Ted Lemon wrote: > My reaction to this long and very predictable high-bandwidth = back-and-forth is that I suspect the outcome will be the same as it was = last time: no action. I'm not sure I disagree. =46rom my perspective, the best action would be = to select one methodology - use the RA or use DHCP in some form, but not = both. What I don't see in this is an emerging consensus. I see two sets of = people, one with a consensus around the RA and the other with a = consensus around DHCP, and I don't see them convincing each other. = Absent consensus, I don't think we have a basis for action, and are = likely to therefore not act. In a different email, I commented on there = being, apparently, two sets of users or operators - those who favor the = RA, and those who favor DHCP. This discussion may come down to their = respective information security policies and their financial and = operational impacts. At the moment, I would hazard a guess that in = residential and small corporate networks the RA sounds like not needing = a separate DHCP server, and therefore not managing or investing in one, = and in larger enterprise networks and perhaps SP networks, information = security policies mandate DHCP regardless of your and my technical = viewpoints. I'd be happy to be proven wrong, especially if the argument results in a = consensus on this particular point.= From nobody Mon Apr 3 11:28: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 9A37B1294E4 for ; Mon, 3 Apr 2017 11:27:58 -0700 (PDT) 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 lnk8EUlGBePB for ; Mon, 3 Apr 2017 11:27:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id E5E591294DA for ; Mon, 3 Apr 2017 11:27:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cv6hm-0000EfC; Mon, 3 Apr 2017 20:27:54 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> In-reply-to: Your message of "Mon, 3 Apr 2017 11:07:20 -0700 ." <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> Date: Mon, 03 Apr 2017 20:27:54 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:27:58 -0000 In your letter dated Mon, 3 Apr 2017 11:07:20 -0700 you wrote: >What I don't see in this is an emerging consensus. I see two sets of people, o >ne with a consensus around the RA and the other with a consensus around DHCP, >and I don't see them convincing each other. It seems to me that there is quite a bit of support for making both MTI both in routers and in hosts. There are some parties that will do everything possible to never ever have to support DHCP. So actual consensus is not going to happen. There are also parties that only want to use DHCP and don't see a need for RDNSS. Though it is not clear to me of they would block a proposal that requires support for both protocols in routers and hosts. >email, I commented on there being, apparently, two sets of users or operators >- those who favor the RA, and those who favor DHCP. This discussion may come d >own to their respective information security policies and their financial and >operational impacts. At the moment, I would hazard a guess that in residential > and small corporate networks the RA sounds like not needing a separate DHCP s >erver, and therefore not managing or investing in one, and in larger enterpris >e networks and perhaps SP networks, information security policies mandate DHCP > regardless of your and my technical viewpoints. As long as we are disscussing what hosts and routers should support, then requiring support for both protocols should make all operators happy. From nobody Mon Apr 3 11:38: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 CDA3C1294CF for ; Mon, 3 Apr 2017 11:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 SRgcHvRQv9T4 for ; Mon, 3 Apr 2017 11:38:56 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 C080412945E for ; Mon, 3 Apr 2017 11:38:55 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id t20so2693896wra.1 for ; Mon, 03 Apr 2017 11:38:55 -0700 (PDT) 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=OuyQ+1e3VRNf4hHaL/+MeKw/1h25YA4LfVy3HoVPjOk=; b=GaV56S8Qfydw1/uSple8uet4qy1KAuyjkeKaldn8KQt/HDRIXLFczkvr1vO9ckhwRD s4ujpJFnWix4SpkoJlaQ6WuYjWGGgU/9W2OEgSjlTqlwB59vlP1STlF1SyFKpB7Y+FSv hazRjmuXn/00h6bdMTw4uBV7wjMrRIwPIZIzxo7FTViw6QrU0OOvo/04hwHAmTrB1//V dBYRSKvpuorOOdZZW9M13pnblGyo3QmEKuu8oaEsXXiZOF+oGNeSnVZyOLMSZIb9FGLT L7n7nIkolMfw/HEnioN7xPsLPX8T+LG81/5HFpZ3MjsD1gOomVkXKDRuLzXmyGPbCpTP 8GVQ== 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=OuyQ+1e3VRNf4hHaL/+MeKw/1h25YA4LfVy3HoVPjOk=; b=q2fAPghYdKNluoYmZG4xS9YYGDh+kDFI9e4p8VGheoocV9TlZOk8hEOqhQwhJZ2BCb 47DpD6yeDlppQTrs4n/qI+/En9THE62w+fZvpP/Eol1OZ7BdueomIgbu70nXODrcL9C7 W+Xfbd3mjxAVOZDRjlXrPoMdhylrQZPzOUXjLJhq8J4FKBtYjlBad/AUz5wp7byj6rQu FLHIkgLzEYj31liGPXvDKntM9zF+7Vbmxhbmc2OgyVwAmTCncK1NceEgFO6xm9/3qA/Y SgAFogdmmbVMOCeYy0KsPG/DXNQ8uqyjY98xDPB3C5h+dHphUSKoRhWlt9VoB0fQeomx aAgw== X-Gm-Message-State: AFeK/H1EpoZkY1Fy6/85k1xSCoBlgAJ2YeEDc6Hj+5Qi1QMraANJ9KeT 1bsRmYJc1UxFszv4+UM= X-Received: by 10.28.234.147 with SMTP id g19mr10827750wmi.102.1491244734296; Mon, 03 Apr 2017 11:38:54 -0700 (PDT) Received: from 202.66.20.149.in-addr.arpa (202.66.20.149.in-addr.arpa. [149.20.66.202]) by smtp.gmail.com with ESMTPSA id t85sm15318275wmt.23.2017.04.03.11.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 11:38:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Mon, 3 Apr 2017 11:38:50 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> To: Philip Homburg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:38:58 -0000 > On Apr 3, 2017, at 11:27 AM, Philip Homburg = wrote: >=20 > In your letter dated Mon, 3 Apr 2017 11:07:20 -0700 you wrote: >> What I don't see in this is an emerging consensus. I see two sets of = people, o >> ne with a consensus around the RA and the other with a consensus = around DHCP,=20 >> and I don't see them convincing each other. >=20 > It seems to me that there is quite a bit of support for making both > MTI both in routers and in hosts. Perhaps. I'm certainly willing to see that in the document. That said, I = also see a lot of commentary about picking the writer's favorite. > There are some parties that will do everything possible to never ever > have to support DHCP. So actual consensus is not going to happen. Pretty much. I don't see a way forward other than making both = Mandatory-to-Implement; each side wins their half. > There are also parties that only want to use DHCP and don't see a need = for > RDNSS. Though it is not clear to me of they would block a proposal = that=20 > requires support for both protocols in routers and hosts. >=20 >> email, I commented on there being, apparently, two sets of users or = operators=20 >> - those who favor the RA, and those who favor DHCP. This discussion = may come d >> own to their respective information security policies and their = financial and=20 >> operational impacts. At the moment, I would hazard a guess that in = residential >> and small corporate networks the RA sounds like not needing a = separate DHCP s >> erver, and therefore not managing or investing in one, and in larger = enterpris >> e networks and perhaps SP networks, information security policies = mandate DHCP >> regardless of your and my technical viewpoints. >=20 > As long as we are disscussing what hosts and routers should support, = then > requiring support for both protocols should make all operators happy. >=20 >=20 From nobody Mon Apr 3 11:53: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 36BD61294D4 for ; Mon, 3 Apr 2017 11:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 MHBCq9_jUd27 for ; Mon, 3 Apr 2017 11:53:22 -0700 (PDT) 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 B737B1294C5 for ; Mon, 3 Apr 2017 11:53:19 -0700 (PDT) Received: from mbp-4.local ([IPv6:2620:11a:c081:20:cd56:ffca:d29c:9e23]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v33IrFpL000512 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 3 Apr 2017 18:53:15 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:cd56:ffca:d29c:9e23] claimed to be mbp-4.local To: Fred Baker , Ted Lemon References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> Cc: IPv6 Ops WG From: joel jaeggli Message-ID: <3d7b844a-4be8-dfad-b7b9-b9816de6af50@bogus.com> Date: Mon, 3 Apr 2017 11:53:09 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tVEVFfuSGEtKuqtrC9vHFe6IPKomxIhAO" Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:53:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tVEVFfuSGEtKuqtrC9vHFe6IPKomxIhAO Content-Type: multipart/mixed; boundary="T3ESJ51HXC7kV1SK8mT0vITq9fuKug12F"; protected-headers="v1" From: joel jaeggli To: Fred Baker , Ted Lemon Cc: IPv6 Ops WG Message-ID: <3d7b844a-4be8-dfad-b7b9-b9816de6af50@bogus.com> Subject: Re: [v6ops] Making RDNSS a MUST? References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> In-Reply-To: <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> --T3ESJ51HXC7kV1SK8mT0vITq9fuKug12F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/3/17 11:07, Fred Baker wrote: > On Apr 3, 2017, at 10:21 AM, Ted Lemon wrote: >> My reaction to this long and very predictable high-bandwidth back-and-= forth is that I suspect the outcome will be the same as it was last time:= no action. > I'm not sure I disagree. From my perspective, the best action would be = to select one methodology - use the RA or use DHCP in some form, but not = both. > > What I don't see in this is an emerging consensus. I see two sets of pe= ople, one with a consensus around the RA and the other with a consensus a= round DHCP, and I don't see them convincing each other. As the implmentor of an end system device one may have a different vantage point then that of a network operator or the the designer of routers. ultimately I think the demand to be able to signal information in an RA vs stateful DHCP reflects differing priorities for network mobility. the fact taht router advertisement as a function doesn't not exist in ipv4 necessarily constrains mobility in certain ways (e.g. network operators have to account for information provided with a lease (life the default GW) being stable for the lifetime of the lease) whereas with the RA and slack generally much shorter lifetimes are feasib= le. > Absent consensus, I don't think we have a basis for action, and are li= kely to therefore not act. Imho I personally see them both as feasisble from a network equipment standpoint. I can see cases where a network operator might support only one or the other, and in cases where there's a high degree of vertical integration that seems easy enough, if you don't control what equipment is on your network however you may have limited choice afterall there are legacy operating systems that either need to be configured manually or use well-know addresses, I don't personally have any of those machines anymore, but I also don't run an airport or a railroad. > In a different email, I commented on there being, apparently, two sets= of users or operators - those who favor the RA, and those who favor DHCP= =2E This discussion may come down to their respective information securit= y policies and their financial and operational impacts. At the moment, I = would hazard a guess that in residential and small corporate networks the= RA sounds like not needing a separate DHCP server, and therefore not man= aging or investing in one, and in larger enterprise networks and perhaps = SP networks, information security policies mandate DHCP regardless of you= r and my technical viewpoints. > > I'd be happy to be proven wrong, especially if the argument results in = a consensus on this particular point. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --T3ESJ51HXC7kV1SK8mT0vITq9fuKug12F-- --tVEVFfuSGEtKuqtrC9vHFe6IPKomxIhAO 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 iEYEARECAAYFAljimhYACgkQ8AA1q7Z/VrJDKwCdGm6JszZKPeqFrKwMuX41UO8l 3c0An0bmNVDfONXkPLFbrhItFa4WHuHv =b/SD -----END PGP SIGNATURE----- --tVEVFfuSGEtKuqtrC9vHFe6IPKomxIhAO-- From nobody Mon Apr 3 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 02764128B88 for ; Mon, 3 Apr 2017 12:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 uoHnxbCA849g for ; Mon, 3 Apr 2017 12:10:33 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 460F91294CF for ; Mon, 3 Apr 2017 12:10:32 -0700 (PDT) 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.ams1.isc.org (Postfix) with ESMTPS id D166824AE08; Mon, 3 Apr 2017 19:09:11 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EA5D0160032; Mon, 3 Apr 2017 19:09:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D8941160071; Mon, 3 Apr 2017 19:09:11 +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 BOXPV0lixvkk; Mon, 3 Apr 2017 19:09:11 +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 1F470160032; Mon, 3 Apr 2017 19:09:11 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EAFCB6A752F0; Tue, 4 Apr 2017 05:09:06 +1000 (AEST) To: Fred Baker Cc: Ted Lemon , IPv6 Ops WG From: Mark Andrews References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> In-reply-to: Your message of "Mon, 03 Apr 2017 11:07:20 -0700." <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> Date: Tue, 04 Apr 2017 05:09:06 +1000 Message-Id: <20170403190906.EAFCB6A752F0@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:10:35 -0000 In message <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com>, Fred Baker writes: > > On Apr 3, 2017, at 10:21 AM, Ted Lemon wrote: > > My reaction to this long and very predictable high-bandwidth > > back-and-forth is that I suspect the outcome will be the same > > as it was last time: noaction. > > I'm not sure I disagree. From my perspective, the best action would be to > select one methodology - use the RA or use DHCP in some form, but not both. > > What I don't see in this is an emerging consensus. I see two sets of > people, one with a consensus around the RA and the other with a > consensus around DHCP, and I don't see them convincing each other. > Absent consensus, I don't think we have a basis for action, and are > likely to therefore not act. In a different email, I commented on there > being, apparently, two sets of users or operators - those who favor > the RA, and those who favor DHCP. This discussion may come down to > their respective information security policies and their financial > and operational impacts. At the moment, I would hazard a guess that in > residential and small corporate networks the RA sounds like not > needing a separate DHCP server, and therefore not managing or investing > in one, and in larger enterprise networks and perhaps SP networks, > information security policies mandate DHCP regardless of your and > my technical viewpoints. > > I'd be happy to be proven wrong, especially if the argument results in a > consensus on this particular point. What I see is that there are two sets of operators with different requirements. In almost all devices it isn't that hard to implement *both* RA and DHCPv6 (stateful and stateless). Why are we trying to choose one. Just implement all in both routers and hosts. I want my laptop to work when it is connected to the home network using SLAAC and to networks that use DHCPv6. I also want routers I buy to be able to work in whatever mode I want to configure the network. I want to be able to configure a SLAAC network. I want to be able to configure a DHCPv6 base network. For some networks I want the DHCP server to be in the router for others I want it to be centralised and only a DHCP relay is present or just to be able to tell the nodes that there is a DHCP server on the network. For some networks I want DHCP server to act as DHCP client to get resources. There is no one correct way to run a network. We should acknowlege that and build systems that handle and many of these requirements as possible. Mark > _______________________________________________ > 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 Mon Apr 3 12:20: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 863401294C3 for ; Mon, 3 Apr 2017 12:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8zHBhWmFxWg5 for ; Mon, 3 Apr 2017 12:20:56 -0700 (PDT) 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 0EFAB1294FD for ; Mon, 3 Apr 2017 12:20:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cv7Wz-0000H3C; Mon, 3 Apr 2017 21:20:49 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <3d7b844a-4be8-dfad-b7b9-b9816de6af50@bogus.com> In-reply-to: Your message of "Mon, 3 Apr 2017 11:53:09 -0700 ." <3d7b844a-4be8-dfad-b7b9-b9816de6af50@bogus.com> Date: Mon, 03 Apr 2017 21:20:48 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:20:57 -0000 >the fact taht router advertisement as a function doesn't not >exist in ipv4 necessarily constrains mobility in certain ways (e.g. >network operators have to account for information provided with a lease >(life the default GW) being stable for the lifetime of the lease) Router advertisements for IPv4 are specified in RFC 1256, published in 1991. They were popular for a brief period of time, but lost traction when DHCP got popular. From nobody Mon Apr 3 12:28: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 39AA31294FD for ; Mon, 3 Apr 2017 12:28:14 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 LR2X8jBe_rny for ; Mon, 3 Apr 2017 12:28:11 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 5276C120726 for ; Mon, 3 Apr 2017 12:28:11 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id g2so128010916pge.3 for ; Mon, 03 Apr 2017 12:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=6XOQ/EX2AA0grfxp4TfJQu91SGnco4lucTe4+P8TUvY=; b=HIQay6JNQK9Z8ByDHup1fJbMoTp6Wd/Fx56UzgxOSWHcc7u/Yk1yEBRfzoHyDrPXb6 DkGvXdmlCODVmk+MTyhNFj1t/z7r9nTUNLp7S0AR4cJzGybC43V2RP4Drvsm7nrG794i kIZl/vbPraOwmCHnRHeGaa4ySR5s3DuMbofNFNWfuLXQqcpwyWQN+2pgasncG6t1th// LkXLnKBF8cv588X+0fPEKFi+HA0PsjmUdVCyrO5YwYGwS8pJcmVTUirAkGW2wLx1Tr4E 1JmjB0Aceim7ygK3dHANghG4acs7HSkkEhWxP2kc8yXeAnwE5O4gwhjO2QduZRjhBztN BR4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=6XOQ/EX2AA0grfxp4TfJQu91SGnco4lucTe4+P8TUvY=; b=r5iQpAgZK7vFwzgt0kBPVm1QK4cofRt2Ewej0gQrOqSJ7S//TyColjWSSpMk5Vx8iY QDufyeJ1ueKtlodli+jXQeipuAbk0ThZL31g2nIMfeEIMlBvglKK6gCG1zTt5e2gV5Ly WoReZ2zn0x1c6jRA4IfJmtCdr4iDaLnDBhXG6M2PJ/VvJajmvucwiSWYKiFd6tOJB4FJ H4AqcGmPgNQMZD3Kanm7CWG9qHOpHoYF7tOD8eFXG11pat+cGqGsa1E/6fM0NL5PflbK QmDPcKR8jtyBeDr9YZ53VFu8kRoXOZFOoBvE3iX9kA0kKBWujvFNbESAXlWFpBuOsykM cO0g== X-Gm-Message-State: AFeK/H35ob+kseEsWxcD4fGvAGroHWeO7c16TyswSHHGJDPjpbNkUUO55I773gDaZOvgMYjv X-Received: by 10.98.22.71 with SMTP id 68mr19206695pfw.233.1491247690557; Mon, 03 Apr 2017 12:28:10 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id k2sm27461798pga.47.2017.04.03.12.28.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 12:28:09 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_AF54B3E1-55B4-40FE-AC52-A19495E121B9" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 3 Apr 2017 12:28:08 -0700 References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> To: IPv6 Operations In-Reply-To: <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:28:14 -0000 --Apple-Mail=_AF54B3E1-55B4-40FE-AC52-A19495E121B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 3, 2017, at 11:38, Fred Baker wrote: > On Apr 3, 2017, at 11:27 AM, Philip Homburg = wrote: >>=20 >> There are some parties that will do everything possible to never ever >> have to support DHCP. So actual consensus is not going to happen. >=20 > Pretty much. I don't see a way forward other than making both = Mandatory-to-Implement; each side wins their half. That would entail telling every developer of Internet-enabled home = appliances that expect their products to be deployed mostly (if not = entirely) behind RFC 7084-compliant routers that their designs will fail = IPv6 Node Requirements compliance testing unless they include a DHCPv6 = client. If IETF were to publish such a requirement, then I would strongly = recommend to my product managers that this requirement can be safely = ignored (and should be ignored) until RFC 7084 is revised to include = some kind of administrative interface for configuring the DHCPv6 service = to provide specific configuration to individual home appliances based on = some kind of standard secure identity. (And I=E2=80=99m not going to = hold my breath waiting for all of that to happen.) --james woodyatt > --Apple-Mail=_AF54B3E1-55B4-40FE-AC52-A19495E121B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 3, 2017, at 11:38, Fred Baker <fredbaker.ietf@gmail.com> wrote:
On Apr = 3, 2017, at 11:27 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> = wrote:

There are = some parties that will do everything possible to never ever
have to support DHCP. So actual consensus is not going to = happen.

Pretty much. I don't = see a way forward other than making both Mandatory-to-Implement; each = side wins their half.

That would entail = telling every developer of Internet-enabled home appliances that expect = their products to be deployed mostly (if not entirely) behind RFC = 7084-compliant routers that their designs will fail IPv6 Node = Requirements compliance testing unless they include a DHCPv6 = client.

If = IETF were to publish such a requirement, then I would strongly recommend = to my product managers that this requirement can be safely ignored (and = should be ignored) until RFC 7084 is revised to include some kind of = administrative interface for configuring the DHCPv6 service to provide = specific configuration to individual home appliances based on some kind = of standard secure identity. (And I=E2=80=99m not going to hold my = breath waiting for all of that to happen.)

--james woodyatt <jhw@google.com>



= --Apple-Mail=_AF54B3E1-55B4-40FE-AC52-A19495E121B9-- From nobody Mon Apr 3 12:36: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 0C77D1294C5 for ; Mon, 3 Apr 2017 12:36:44 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 hdGzRuJXxxYe for ; Mon, 3 Apr 2017 12:36:42 -0700 (PDT) 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 E7C891279EB for ; Mon, 3 Apr 2017 12:36:41 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 39D56618C5 for ; Mon, 3 Apr 2017 21:36:39 +0200 (CEST) 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 07922600E4; Mon, 3 Apr 2017 21:36:39 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id ED6FA33024; Mon, 3 Apr 2017 21:36:38 +0200 (CEST) Date: Mon, 3 Apr 2017 21:36:38 +0200 From: Gert Doering To: Mark Andrews Cc: Fred Baker , IPv6 Ops WG Message-ID: <20170403193638.GF25069@Space.Net> References: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <20170403190906.EAFCB6A752F0@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170403190906.EAFCB6A752F0@rock.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:36:44 -0000 Hi, On Tue, Apr 04, 2017 at 05:09:06AM +1000, Mark Andrews wrote: > There is no one correct way to run a network. We should acknowlege > that and build systems that handle and many of these requirements > as possible. This! Gert Doering -- Operator -- 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 Mon Apr 3 12:48: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 C520F129515 for ; Mon, 3 Apr 2017 12:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V_xBxfuSBybG for ; Mon, 3 Apr 2017 12:48:04 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 E3DB51294C3 for ; Mon, 3 Apr 2017 12:48:03 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 81so130133614pgh.2 for ; Mon, 03 Apr 2017 12:48:03 -0700 (PDT) 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=zbVdINR4qJScWTJH2aoFA3Tolq01iS60lgwPtP0Ws5I=; b=pfqBfBFMk86MIjb6BRRWPjrMW8lsubiyFd3+uuWhqpragB/kMdTzHOq0E2YJBmyYlH jn6gsVqtf4hi0tJehXAOSwltYng0n824Q5avympQW9G5ftfL022D9oyOc7MUywpbf1Q6 8UNSq2K8BHRJScsEN9sDCE25CmdUSQ/u3rz1uDN8IGHIzlvZHSwYxaHv62ycGaKnosqF 8yjgBVt2tcqmZ4LpRBhLEWmFHC7PBemx5ULbKepYpRFvXU8N+jLzdzNbFq7temgM0vzm qe1L14UtaaR3GhGSkRjvq+xIOSWFNliHFKmF1I6seZ7nQ+8rpO/VgJ+nzYvSvqoVAGcC kDWg== 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=zbVdINR4qJScWTJH2aoFA3Tolq01iS60lgwPtP0Ws5I=; b=Bhpf7pcmH6mccjqzv3Ycolxcuwj3wJLmlXjKuMIFzzYtj/zF1tA6opcMhOoK6+6DTG zSWFiBEp1mfDeVfBJcOW/i3aGVJZutCYcJjieLmv3Hk9ET/b+IoHjwMAIKeLmkyoGcua B5Tr5pdr70Q4HMuaGcidGvrJMPySX/OtKbOwyb0uOlaoOT1LGLalx0jRHPrZt69Yhav1 SkWGzQvstUBd0lFVN+BIVLmWNc1/GonAoL0/2LBIMRZDNSd2Frl1fcU97Fsp+tEXkDcf rlSmSxJ0aUJGN5G1osEFrargSJzKD+N4GJCkFDyl3N2jssLQfMxYjy7VADpdyTTHkqU/ B6WQ== X-Gm-Message-State: AFeK/H36tnvJPHrJbPgSPqXPcHMmuUxafwtd7F/kghBRzMxyUWo2gvR/1bY/rRQj7aWDIA== X-Received: by 10.99.211.69 with SMTP id u5mr19363354pgi.82.1491248883441; Mon, 03 Apr 2017 12:48:03 -0700 (PDT) Received: from [192.168.43.27] ([166.170.43.94]) by smtp.gmail.com with ESMTPSA id q7sm27461902pfj.34.2017.04.03.12.48.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 12:48:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> Date: Mon, 3 Apr 2017 12:47:51 -0700 Cc: IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <65D05574-6A36-4974-AB53-0458B58A841A@fugue.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:48:06 -0000 Hm, what I mean by consensus is that there's a clear benefit to doing X, = a lot of people agree that X should be done, and nobody has any = technical objection to doing X. You can definitely say this for RDNSS. = You may be able to say this for DHCP; my technical objection is pretty = easily addressed, I think. So yes, you can take the position that since you don't have people = agreeing violently, you don't have consensus, but I don't think that's a = constructive approach. This is a real problem. There is clearly = consensus that it is a problem. Both solutions to the problem are = valid, and there are clear consensuses for both solutions. One of the = solutions can be done now; the other needs more work. So I would really like to see us do the work, rather than not doing it = because not everybody agrees. > On Apr 3, 2017, at 11:07 AM, Fred Baker = wrote: >=20 >=20 > On Apr 3, 2017, at 10:21 AM, Ted Lemon wrote: >> My reaction to this long and very predictable high-bandwidth = back-and-forth is that I suspect the outcome will be the same as it was = last time: no action. >=20 > I'm not sure I disagree. =46rom my perspective, the best action would = be to select one methodology - use the RA or use DHCP in some form, but = not both. >=20 > What I don't see in this is an emerging consensus. I see two sets of = people, one with a consensus around the RA and the other with a = consensus around DHCP, and I don't see them convincing each other. = Absent consensus, I don't think we have a basis for action, and are = likely to therefore not act. In a different email, I commented on there = being, apparently, two sets of users or operators - those who favor the = RA, and those who favor DHCP. This discussion may come down to their = respective information security policies and their financial and = operational impacts. At the moment, I would hazard a guess that in = residential and small corporate networks the RA sounds like not needing = a separate DHCP server, and therefore not managing or investing in one, = and in larger enterprise networks and perhaps SP networks, information = security policies mandate DHCP regardless of your and my technical = viewpoints. >=20 > I'd be happy to be proven wrong, especially if the argument results in = a consensus on this particular point. From nobody Mon Apr 3 12:48: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 C3436129526 for ; Mon, 3 Apr 2017 12:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 Oxb8Xj_LMWyd for ; Mon, 3 Apr 2017 12:48:28 -0700 (PDT) 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 ECA6E129519 for ; Mon, 3 Apr 2017 12:48:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A93B2A2; Mon, 3 Apr 2017 21:48:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491248903; bh=hX55lQBe1ocmXhKdi6O+TXD/lpI+gYphNgYcsKzikw4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=0Aqkn2TfbuXyeB1ACvLpebQKnWXj7G3NMUdRN3oA1mTbi0d7NidCbng3Z+K2raLr6 HrK028Fljf0Sm2PApmO/X2Wu1byLc7ncn4e/pqNqjt3QtF1AXm1J6Nr6sjsmh3B7yF R03D3eCUJQBhDBfjk2r7baxmmUsUvcLGNZYzHXaU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9150D88; Mon, 3 Apr 2017 21:48:23 +0200 (CEST) Date: Mon, 3 Apr 2017 21:48:23 +0200 (CEST) From: Mikael Abrahamsson To: Chuck Anderson cc: v6ops@ietf.org In-Reply-To: <20170403175150.GV4764@angus.ind.wpi.edu> Message-ID: References: <7b5ba139-a229-74f9-1928-9e5cb9fee53b@dougbarton.us> <20170403.082732.41681152.sthaug@nethelp.no> <20170403.152645.74700966.sthaug@nethelp.no> <20170403175150.GV4764@angus.ind.wpi.edu> 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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:48:31 -0000 On Mon, 3 Apr 2017, Chuck Anderson wrote: > DHCP enables the security functionality in L2 switches that have DHCP > Snooping, ARP Inspection and IP Source Guard features. This makes it > possible to require that endpoints complete a DHCP transaction, and they > are only allowed to send packets with a source address that matches a > DHCP lease for that specific client while the DHCP lease is still valid > and unexpired. All of this is true. What is also true is that there are documents doing the same for SLAAC A=1 deployments as well. https://tools.ietf.org/wg/savi/ Do note that the FCFS document predates the DHCP one by 3 years. Also note that there are multiple different ways to skin this cat, most of which not requires the use of DHCPv6. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 3 13:08: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 975AA1294BF for ; Mon, 3 Apr 2017 13:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 JF_WGGvQlCfe for ; Mon, 3 Apr 2017 13:08:14 -0700 (PDT) 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 C13E7120726 for ; Mon, 3 Apr 2017 13:08:14 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v33K4lqI008459 for ; Mon, 3 Apr 2017 16:08:14 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 29ku04w3dx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 03 Apr 2017 16:08:13 -0400 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 v33K8DQs023882 for ; Mon, 3 Apr 2017 16:08:13 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v33K87T7023812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 3 Apr 2017 16:08:08 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi133.aldc.att.com (RSA Interceptor) for ; Mon, 3 Apr 2017 20:07:53 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Mon, 3 Apr 2017 16:07:52 -0400 From: "STARK, BARBARA H" To: "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFt96tfihWCnUqZYstkvT6jfaGui+0AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ID//8n4MIAAUTgAgAAJQYCAAAzIAP//wss/gAAGxqA= Date: Mon, 3 Apr 2017 20:07:52 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB0E143@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.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.158.165] 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-04-03_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_spam policy=outbound_policy score=97 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=97 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704030178 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 20:08:17 -0000 > It seems to me that there is quite a bit of support for making both MTI b= oth > in routers and in hosts. Personally, I am dead-set against stateful and heavily opposed to stateless= DHCPv6 client on hosts. The technical reasons have been stated by others: DHCPv6 client adds comple= xity and demands memory, CPU, and power. Stateful more so than stateless. The original proposal was stateless as a requirement. Discussions around en= terprises wanting to use DHCPv6 for address assignment are an irrelevant di= straction in this context. This would be a justification for hosts *that ar= e designed to be used in such enterprise networks* to implement stateful an= d not just stateless. It is inappropriate for such enterprises to attempt t= o use IETF as some sort of bludgeon on mass market device manufacturers to = try to force them to add cost and complexity to their devices to make them = suitable for such an enterprise environment. Enterprises who want/need to d= o DHCPv6 address assignment will simply have to live with the fact that the= re will exist devices targeted at the mass market (home and small business)= that will not be able to attach to their networks. That is what it is. Hos= t device manufacturers that see a market driver to add DHCPv6 client comple= xity will do so. And those that don't won't. The only justification given so far for not mandating enterprise routers im= plement RDNSS is "some of the enterprise router vendors haven't implemented= it, yet". That is the lamest excuse I have ever seen. It's *not* a technic= al justification. There exists no technical justification for why an enterp= rise router cannot implement RDNSS. Enterprise routers must do RA for route= advertisement. It's totally required. Adding RDNSS to the already-being-se= nt RA is simple, and the additional cost/complexity is negligible as a perc= entage of the overall system. If CE routers can all do it (which they do), = enterprise routers can definitely do it. I've seen no technical justification for why an enterprise that is willing = to allow attachment by devices without stateful DHCPv6 clients is incapable= of enabling RDNSS (if implemented in their enterprise router).=20 Summary: There is no technical justification for any router not to implement RDNSS. There is no technical justification for an enterprise that does not restric= t address assignment to DHCPv6, not to enable RDNSS.=20 It sounds like all enterprise routers are implementing DHCPv6 stateful serv= er. All IPv6-capable CE routers are implementing RDNSS and either stateless= or stateful DHCPv6 server (per RFC 7084). Good. Let them keep doing what t= hey're doing wrt DHCPv6 server. There *is* technical justification for some hosts not to implement a DHCPv6= client (stateless or stateful). Forcing costly and complex enterprise requirements onto mass market consume= r devices is unconscionable. There is no significant technical justification for hosts not to implement = RDNSS. It will not break interoperability with the embedded base if the cur= rent RFC 6434 SHOULD is changed to must for RDNSS. So if people want to man= date host RDNSS implementation, I have no objection to that. Then again, if= nothing is done to mandate new host behavior, I have no objection to that = either.=20 The only broken (causing interoperability issues) elements I've read about = in this thread are the enterprise routers. To me, it was pretty obvious fro= m reading RFC 6434 (back in 2011) that routers had to implement RDNSS and D= HCPv6 server (stateful or stateless) to support all RFC 6434 nodes. Enterpr= ise router manufacturers and enterprises have had a few years to figure thi= s out. Barbara From nobody Mon Apr 3 13:53: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 8C2D8129521 for ; Mon, 3 Apr 2017 13:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-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=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 ly-CYZ17sUJ1 for ; Mon, 3 Apr 2017 13:53:27 -0700 (PDT) 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 8D7DB1294FB for ; Mon, 3 Apr 2017 13:53:27 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id x125so131408347pgb.0 for ; Mon, 03 Apr 2017 13:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=QEYe8/2orXpj5W16/SVV08Hai77vGQ4HAVebMuM725E=; b=OoSjDZGZivIIiQiWkwqG2TEzZ0sWTluh5LDrLD62csSaGXLmlXQNx3MNAM8UbUMzZ9 RV+4NWRlzoU+e79PpwgrU5276MC1cuWLrgzW+t2V5CY9SLglzft2btFb7ph7q6FHAVYw +pEsQYR5kXpk/TNRdV7AkGmbN0u349bKDD57ZhQD29yCuPApTDAHs7LSeAGHuV+bLvep pf33wChjkBed/xGnFwZEw+N0iVlioerTUXntbWfR21MbWatpqrW0e9UQdDVQTo/qa7vQ bmVAjXrsTmLgAgN9F85u0u9L6kz0MBBmWxrsKb4q8aOIpgINqYSK8RAQQxtE9LIJjftc tHIQ== 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:date :subject:message-id:references:in-reply-to:to; bh=QEYe8/2orXpj5W16/SVV08Hai77vGQ4HAVebMuM725E=; b=YMj4nGVHd5FtxkibFMfP3UO/qP5eaMicZdLmHukJfpm8fCdVPMmZ+t3c1R6awX6qNP stvzg+ybfQ/ipUYVPspdbwys32UJASTsWbNqF0PDmruS/a0603rRXWGgEOjiFZ5ep82k NA2rlFQAxeU+JbmI0b+d7HBecOaZTUe22q6sJhpkjBX8edKSgWZDWlNdiRMP8S+t+N9C 0S8QrILS0+vqjihbF17AjQ9jqyTFqlDUZuSxKkMQ+U7wJjRA0SR7ulA3IqcFvnEGwpzu cu/jfeHkSPszkK+N9OF6IS5OiQD3gSq2KxUGzSo9j4Igqe/fUXji45bMgsXHRv/7N+/N WNOQ== X-Gm-Message-State: AFeK/H1Ru2zh0evXZfSZBV9jNEVb1dp55Xw7IehKqU1Bh9jS+l2B+cTEI2owzw0uPWYxTRaI X-Received: by 10.98.50.5 with SMTP id y5mr19260558pfy.169.1491252806815; Mon, 03 Apr 2017 13:53:26 -0700 (PDT) Received: from [10.72.63.6] ([166.170.43.198]) by smtp.gmail.com with ESMTPSA id r12sm27624517pgn.26.2017.04.03.13.53.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 13:53:26 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary=Apple-Mail-E9909CBD-3654-4491-8AD8-820A35987024 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 3 Apr 2017 13:53:25 -0700 Message-Id: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> In-Reply-To: To: IPv6 Operations X-Mailer: iPhone Mail (14D27) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 20:53:29 -0000 --Apple-Mail-E9909CBD-3654-4491-8AD8-820A35987024 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, In case I didn't make myself clear (and private email from one correspondent= suggests I did not), when I said below that I would recommend to product ma= nagers responsible for certain kinds of IPv6-capable hosts intended for depl= oyment in home networks that they ignore any forthcoming requirement to impl= ement a DHCPv6 client, I did not mean to allow that to be interpreted as a p= romise to recommend ignoring it for every product in every category intended= for every use case on the global Internet forever and always. I hope my comments are received as a statement of my opinion about specifica= lly what technical recommendations I would make for products that are target= ed principally for deployment behind RFC-7048 routers, i.e. those for home n= etwork deployment by retail customers, where no special additional support i= s provided for alternative deployment on managed enterprise networks. =E2=80=94sent from my phone > On Apr 3, 2017, at 12:28, james woodyatt wrote: >=20 >> On Apr 3, 2017, at 11:38, Fred Baker wrote: >>> On Apr 3, 2017, at 11:27 AM, Philip Homburg = wrote: >>>=20 >>> There are some parties that will do everything possible to never ever >>> have to support DHCP. So actual consensus is not going to happen. >>=20 >> Pretty much. I don't see a way forward other than making both Mandatory-t= o-Implement; each side wins their half. >=20 >=20 > That would entail telling every developer of Internet-enabled home applian= ces that expect their products to be deployed mostly (if not entirely) behin= d RFC 7084-compliant routers that their designs will fail IPv6 Node Requirem= ents compliance testing unless they include a DHCPv6 client. >=20 > If IETF were to publish such a requirement, then I would strongly recommen= d to my product managers that this requirement can be safely ignored (and sh= ould be ignored) until RFC 7084 is revised to include some kind of administr= ative interface for configuring the DHCPv6 service to provide specific confi= guration to individual home appliances based on some kind of standard secure= identity. (And I=E2=80=99m not going to hold my breath waiting for all of t= hat to happen.) >=20 > --james woodyatt >=20 >=20 >=20 --Apple-Mail-E9909CBD-3654-4491-8AD8-820A35987024 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

In case I didn't make my= self clear (and private email from one correspondent suggests I did not), wh= en I said below that I would recommend to product managers responsible for c= ertain kinds of IPv6-capable hosts intended for deployment in home networks t= hat they ignore any forthcoming requirement to implement a DHCPv6 client, I d= id not mean to allow that to be interpreted as a promise to recommend ignori= ng it for every product in every category intended for every use case on the= global Internet forever and always.
I hope my comments are received as a s= tatement of my opinion about specifically what technical recommendations I w= ould make for products that are targeted principally for deployment behind R= FC-7048 routers, i.e. those for home network deployment by retail customers,= where no special additional support is provided for alternative deployment o= n managed enterprise networks.

=E2=80=94sent from my phone
=
On Apr 3, 2017, at 12:28, james woodyatt <jhw@google.com> wrote:

=
On Apr 3, 2017, at 11:38, Fred Baker <fredbaker.ietf@gmail.com> wrote:
<= div>
On A= pr 3, 2017, at 11:27 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:

There are some parties that will do everyt= hing possible to never ever
have to support DHCP. So actual co= nsensus is not going to happen.

Pr= etty much. I don't see a way forward other than making both Mandatory-to-Imp= lement; each side wins their half.

That would entail t= elling every developer of Internet-enabled home appliances that expect their= products to be deployed mostly (if not entirely) behind RFC 7084-compliant r= outers that their designs will fail IPv6 Node Requirements compliance testin= g unless they include a DHCPv6 client.

<= /div>
If IETF were to publish such a requirement, then I woul= d strongly recommend to my product managers that this requirement can be saf= ely ignored (and should be ignored) until RFC 7084 is revised to include som= e kind of administrative interface for configuring the DHCPv6 service to pro= vide specific configuration to individual home appliances based on some kind= of standard secure identity. (And I=E2=80=99m not going to hold my breath w= aiting for all of that to happen.)

--james woodyatt <jhw@google.com>



= --Apple-Mail-E9909CBD-3654-4491-8AD8-820A35987024-- From nobody Mon Apr 3 14:07: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 2CF94128CD5 for ; Mon, 3 Apr 2017 14:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 7_lKhpk8PuqR for ; Mon, 3 Apr 2017 14:07:37 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 7BA901293DA for ; Mon, 3 Apr 2017 14:07:36 -0700 (PDT) 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.ams1.isc.org (Postfix) with ESMTPS id 44EED24AE0B; Mon, 3 Apr 2017 21:06:16 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 62EFA160032; Mon, 3 Apr 2017 21:06:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 51998160071; Mon, 3 Apr 2017 21:06:16 +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 rBqKtuCY_ikh; Mon, 3 Apr 2017 21:06:16 +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 9B211160032; Mon, 3 Apr 2017 21:06:15 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 549AC6A7A930; Tue, 4 Apr 2017 07:06:11 +1000 (AEST) To: james woodyatt Cc: IPv6 Operations From: Mark Andrews References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> In-reply-to: Your message of "Mon, 03 Apr 2017 13:53:25 -0700." Date: Tue, 04 Apr 2017 07:06:11 +1000 Message-Id: <20170403210611.549AC6A7A930@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 21:07:39 -0000 In message , james woodyatt writes: > Hi everyone, > > In case I didn't make myself clear (and private email from one > correspondent suggests I did not), when I said below that I would > recommend to product managers responsible for certain kinds of > IPv6-capable hosts intended for deployment in home networks that they > ignore any forthcoming requirement to implement a DHCPv6 client, I did > not mean to allow that to be interpreted as a promise to recommend > ignoring it for every product in every category intended for every use > case on the global Internet forever and always. Stuff "designed for homes" gets put on corprate nets all the time. It should just work there. There is very little, if anything, that doesn't get connected to both types of nets. > I hope my comments are received as a statement of my opinion about > specifically what technical recommendations I would make for products > that are targeted principally for deployment behind RFC-7048 routers, > i.e. those for home network deployment by retail customers, where no > special additional support is provided for alternative deployment on > managed enterprise networks. > > —sent from my phone > > > On Apr 3, 2017, at 12:28, james woodyatt wrote: > > > >> On Apr 3, 2017, at 11:38, Fred Baker wrote: > >>> On Apr 3, 2017, at 11:27 AM, Philip Homburg > wrote: > >>> > >>> There are some parties that will do everything possible to never ever > >>> have to support DHCP. So actual consensus is not going to happen. > >> > >> Pretty much. I don't see a way forward other than making both > Mandatory-to-Implement; each side wins their half. > > > > > > That would entail telling every developer of Internet-enabled home > appliances that expect their products to be deployed mostly (if not > entirely) behind RFC 7084-compliant routers that their designs will fail > IPv6 Node Requirements compliance testing unless they include a DHCPv6 > client. > > > > If IETF were to publish such a requirement, then I would strongly > recommend to my product managers that this requirement can be safely > ignored (and should be ignored) until RFC 7084 is revised to include some > kind of administrative interface for configuring the DHCPv6 service to > provide specific configuration to individual home appliances based on > some kind of standard secure identity. (And I’m not going to hold my > breath waiting for all of that to happen.) > > > > --james woodyatt > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Apr 3 14:23:12 2017 Return-Path: <7riw77@gmail.com> 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 1593312950B for ; Mon, 3 Apr 2017 14:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 p3vzRiLvs7qX for ; Mon, 3 Apr 2017 14:23:08 -0700 (PDT) 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 D47F4129515 for ; Mon, 3 Apr 2017 14:22:48 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id 79so32413320pgf.0 for ; Mon, 03 Apr 2017 14:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=tOXSdJu6YW1NMnojmmPt1sLOzeWrAR6TXNbNZ8f4sYo=; b=lRoEWzyZILR9AvxsbzRg9/YnwDtottzEZf9zu+WDUReM2SC8YI1TJ75vq3qAyL/rGc AqohXC+6ZQrYfY2/A75QHFnfy0pfe+PReLY6yapyTaEAtdTLqlv6ZPqO27lBFFDTGBxV 9uaCVvgP9/gDaM3+AFOgS5+iTjolQXHqaVKOUNwqfj5u6VySr8AOKCklswro1RpKh+me 2IAcjVrXlykElhEDirvop57xQniyr0VaMISCof2IIQ11jNshHnXBKTmp0lJ2utWz2w19 Pc2IWl2JofJZXRP5un+4y6daRGlVtZ7DY4tbUICqQy5zSZZjatNwDwf2i1BUlaCZsVv3 re3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=tOXSdJu6YW1NMnojmmPt1sLOzeWrAR6TXNbNZ8f4sYo=; b=kGFthg5GTLVwSdDPjJ1uzaVdTcyIaf53hT1p/dLX9U5GUDChKQbbMVslb3ks5YzsOQ qPdm2mZcVvlFojNepKlyL5uNf4rg3osro587ygc2vSWlwMGQpDFLReI/ncCDYqrL9pks nzGoqDB8wDTQBVutubSCCLBfyN6IcedjU5AO7Lru056TG0ewRs49VP+kTJlUVlVkc8wB fxFindWxwQn6lKAhASTemekgeK6S1w627mpNbI+eHpquW0U4e7Mf4y6Zc/voZunGF5Ry 34dtiQuXh9ZiymIw3FVcrdXWGqjGyWF5AMEV9eLIHupmxv4QUx85SRFk4yyj1weTmlou 2wcQ== X-Gm-Message-State: AFeK/H2Ch0oUWZLb4uZsMSU+gjgoVpZk1CZEHD7YG+v5d15dBf6jxN6hSOnLeFZut6L24A== X-Received: by 10.84.232.131 with SMTP id i3mr24137527plk.172.1491254568487; Mon, 03 Apr 2017 14:22:48 -0700 (PDT) Received: from Russ ([2620:119:5006:2006:c11c:8a59:f896:5e7]) by smtp.gmail.com with ESMTPSA id u75sm27638690pgc.31.2017.04.03.14.22.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 14:22:47 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Fred Baker'" , "'Philip Homburg'" Cc: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> In-Reply-To: <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> Date: Mon, 3 Apr 2017 14:22:44 -0700 Message-ID: <028201d2acc0$6ffb8aa0$4ff29fe0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGUGOSxNzsoaWXvJlCms908s6Kv+QIoETPKAkLKxe0CeG2aFgJtwZNGAmua4uIBkgytGwHrnBr/Am9e5B8BOBpt7AIs6oVxAY9MOgUCUZywTgHZ0WmVAkrFL+cCbJ06SQIMIWOaAl+LZ82hEesWoA== Content-Language: en-us Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 21:23:10 -0000 > Perhaps. I'm certainly willing to see that in the document. That said, = I also see > a lot of commentary about picking the writer's favorite. I'm perfectly fine with this -- if I can get a list of the docs to ref, = I'll add it to the next revision. =F0=9F=98=8A Russ From nobody Mon Apr 3 14:30: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 7E0D5128854 for ; Mon, 3 Apr 2017 14:30:24 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 dTUKJP9AXPIX for ; Mon, 3 Apr 2017 14:30:22 -0700 (PDT) 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 74C09127698 for ; Mon, 3 Apr 2017 14:30:22 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 21so132362880pgg.1 for ; Mon, 03 Apr 2017 14:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=0GPMcJgRTT6mCVIRcCCOxlxxPlK7BWSl3T/x4lWKD4w=; b=n0M90TwDNkq5eZbnMlGfvTZXjqc82dVMwpuYa+ieLo6F6djLp90y8OwOQtv15unAkD xN6rYxfUfmvN240gKNr9Cga9Ub50qpqrBdkJfH4HEfaq7fN1GnnE/D2y88G2eBa8HWCg g2qCoe32WCu02clPwUypYU8Sup64pFzOZJ6aoLaq5GM1kwrs6wyk3ORtNnIXE3vX/qha giYW0yqINdX3vNvepZlmCpU9PqMAsKMNzbMGN/EUZSzHA/D7YM8TFoxO5Z/uPJhOF/Ys qEpsS/MWV506eHDVs1oC+3bXYElfzkYZ+Lz1YB8NIo8iAWoFxzgvzkg68mZ0nam+Sni/ ef8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=0GPMcJgRTT6mCVIRcCCOxlxxPlK7BWSl3T/x4lWKD4w=; b=OEUyoSyvVtZLkxoxyrZqMhgI0jSnYGld5+uK9+x7kqtuoV1SpyMNIUi16LTJWmSu00 ejmZtXtSGmwCJLuE4sno2OVSDlCaXWGpCRRZ0a042Mg1Sxe7nfqA+XykMQlkuHy9XuZ3 Lg2gWpPGt6RIpNq11cLPGnm/MjVUMTnJG6IMkGHD4Oz+PePGyKBzHMR0H/dRu3IOPfF5 lXcOgvdqSBeo1h+gJktZH05+0FGPpOWwDpMdrWVd+5uK8NsLfsRXogzRazuUP5UC0SPw 8v5btb9gr/ssr7lzgrXUFwViMgGniu9eC9pNJiXZKzzMZ5ooFPyyDMCB1Ngp1ph80gd5 nu7g== X-Gm-Message-State: AFeK/H22lUGlR5xVNqBb+Q6Y3JTKbPWDcDlc0ttTW+nDZGBqJBRNzVUuIe36yXKQThpeuRm6 X-Received: by 10.84.254.5 with SMTP id b5mr24533460plm.76.1491255021815; Mon, 03 Apr 2017 14:30:21 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id t5sm27540101pgb.58.2017.04.03.14.30.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 14:30:21 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_1858A2A3-119A-4BF7-BC06-0D5DB35F7E43" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 3 Apr 2017 14:30:20 -0700 References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> <20170403210611.549AC6A7A930@rock.dv.isc.org> To: IPv6 Operations In-Reply-To: <20170403210611.549AC6A7A930@rock.dv.isc.org> Message-Id: <51ABF364-FD13-4CBD-A7F8-8ED8982A9EBF@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 21:30:24 -0000 --Apple-Mail=_1858A2A3-119A-4BF7-BC06-0D5DB35F7E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 3, 2017, at 14:06, Mark Andrews wrote: >=20 > Stuff "designed for homes" gets put on corprate nets all the time. It > should just work there. There is very little, if anything, that = doesn't > get connected to both types of nets. As I wrote in private to my correspondent off list, "compute resources = for things that add absolutely no customer value to the design = significantly increase recurring manufacture costs. I=E2=80=99m not = going to fight with senior vice presidents for DHCPv6 clients in home = appliances until I can explain to them in one slide and a 90 second demo = what actual customer value the costs will buy.=E2=80=9D What I went on further to say is that it=E2=80=99s a completely = different story when recommending how to other product teams might go = about design similar or related products for more general deployment, = for example where customers may need support for enterprise managed = networks where DHCPv6 is mandatory and RDNSS is not recommended by the = operator community. For what it=E2=80=99s worth, I would recommend RDNSS = clients in those hosts on technical grounds, and I would recommend = making the decision about whether to implement a DHCPv6 client based = entirely on prevailing business considerations. I would explain that = DHCPv6 is a matter of network operator taste, tastes vary, and they = should decide accordingly. (It=E2=80=99s my understanding that decision = has already been made, rather publicly, in some cases of specific = network deployment scenarios, with both YES and NO outcomes, using = business considerations I don=E2=80=99t think I understand very well, = and I=E2=80=99m happy to stay out of that contest.) --james woodyatt > --Apple-Mail=_1858A2A3-119A-4BF7-BC06-0D5DB35F7E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 3, 2017, at 14:06, Mark Andrews <marka@isc.org> = wrote:

Stuff = "designed for homes" gets put on corprate nets all the time.  It
should just work there. =  There is very little, if anything, that doesn't
get = connected to both types of nets.

As I wrote in private to my = correspondent off list, "compute resources for things that add = absolutely no customer value to the design significantly increase = recurring manufacture costs. I=E2=80=99m not going to fight with senior = vice presidents for DHCPv6 clients in home appliances until I can = explain to them in one slide and a 90 second demo what actual customer = value the costs will buy.=E2=80=9D

What I went on further to say is that = it=E2=80=99s a completely different story when recommending how to other = product teams might go about design similar or related products for more = general deployment, for example where customers may need support for = enterprise managed networks where DHCPv6 is mandatory and RDNSS is not = recommended by the operator community. For what it=E2=80=99s worth, I = would recommend RDNSS clients in those hosts on technical grounds, and I = would recommend making the decision about whether to implement a DHCPv6 = client based entirely on prevailing business considerations. I would = explain that DHCPv6 is a matter of network operator taste, tastes vary, = and they should decide accordingly. (It=E2=80=99s my understanding that = decision has already been made, rather publicly, in some cases of = specific network deployment scenarios, with both YES and NO outcomes, = using business considerations I don=E2=80=99t think I understand very = well, and I=E2=80=99m happy to stay out of that contest.)


--james woodyatt <jhw@google.com>



= --Apple-Mail=_1858A2A3-119A-4BF7-BC06-0D5DB35F7E43-- From nobody Mon Apr 3 14:45:24 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 E2FD0129329 for ; Mon, 3 Apr 2017 14:45:22 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=apple.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 LEKL55Rz7H14 for ; Mon, 3 Apr 2017 14:45:21 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 2D217128CD5 for ; Mon, 3 Apr 2017 14:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491255921; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2iCOnO8l3iklcELQ8IMtZUoq7nUCb7FF/S71rMbXxSY=; b=K43PhdtDBp5Qmea7Krro8mE+NbXsgbJIbVY00BMfdP0b9jWDRVxR4DcdSexJgZI2 urFshQi/CPzCTovxwLGSjcijS8oOWy4TEi/IQ4T4pomPilU8y2MNK9ynN2JwOQFe bsVCyjBkPm/txR0FFXnsgobSIaFIdVVH6yTxHBEuLT7uWHAs6hU1ey6n6WWZX2Lq 3M8U7I+48smTn0uP4bf08EVVdT/3T0657NZvHYbK5SIGwCEPpThMtjiHy+5ekCDb DET+IhzEph8hMFlSiIOsE2HhCHLWGjr1VMQURaCMJFvCtxYxpgQa6+6bZJjx4GhB O49yt4+ufDdV8hY49iS0GQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 3F.2F.25383.F62C2E85; Mon, 3 Apr 2017 14:45:21 -0700 (PDT) X-AuditID: 11973e12-ad7fb70000006327-4d-58e2c26f3f92 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay5.apple.com (Apple SCV relay) with SMTP id F2.C5.06491.E62C2E85; Mon, 3 Apr 2017 14:45:19 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_H9xZrPeQC46N/NDdmXbdhw)" Received: from dschinazi.apple.com (dschinazi.apple.com [17.226.40.22]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONU000DHSFIKY40@koseret.apple.com>; Mon, 03 Apr 2017 14:45:18 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <004EF04D-AA6F-4301-A003-83E900826F4B@apple.com> Date: Mon, 03 Apr 2017 14:45:17 -0700 In-reply-to: Cc: IPv6 Ops WG To: Ca By References: X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FAYoVt46FGEwfLLjBarvnxksjh9bC+z A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxc8Fr5oJOw4r7XT9YGhifaXYxcnJICJhI 7Jyxja2LkYtDSGAvo8SHrqPsMIn+D41MEIlVjBKPHvUwgyR4BQQlfky+xwJiMwuESUy9+YMR omgKk8TDO1fZQBLCAtISXRfusnYxcnCwCWhJHFhjBNFrI7Fk4lGoEnuJXfN2M4LYLAKqEvuu zmYFsTkFgiU6DvZAzVeQaHvXDlYjIiAn8ez1dLC4kECAxOEpS1khDpWV+PT8JzvIDRICR9gk jm7rYJrAKDQLya2zkNwKYWtJfH/UChTnALLlJQ6el4UIa0o8u/eJHcLWlnjy7gLrAka2VYxC uYmZObqZeSZ6iQUFOal6yfm5mxhBsTDdTmgH46lVVocYBTgYlXh4Fzg9ihBiTSwrrsw9xCjN waIkzhtw516EkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaoM4vuteofZ1GZ8r5DmXmyhdFf BdlJHZ1ehYtKFWc8lFzoF7L6Sd65tVH2hpuLPRmlJh2S4cpV/uC18NnT0G7HDfMqPsxQvrmt JIj5cleL7x6PszVf2gN2PDmy++vh8AWnJBtjg5elbUs/khwyJ3HfvS8ZTPrCfBd+hV2s44xY URF8/35qOrMSS3FGoqEWc1FxIgD4DfiqZgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUiON1OXTf/0KMIg7MvpC1WffnIZHH62F5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj54LXzAWdhhX3u36wNDA+0+xi5OSQEDCR 6P/QyNTFyMUhJLCKUeLRox5mkASvgKDEj8n3WEBsZoEwiak3fzBCFE1hknh45yobSEJYQFqi 68Jd1i5GDg42AS2JA2uMIHptJJZMPApVYi+xa95uRhCbRUBVYt/V2awgNqdAsETHwR6o+QoS be/awWpEBOQknr2eDhYXEgiQODxlKSvEobISn57/ZJ/AyD8LyXmzkJwHYWtJfH/UChTnALLl JQ6el4UIa0o8u/eJHcLWlnjy7gLrAka2VYwCRak5iZWmeokFBTmpesn5uZsYQaHbUBixg/H/ MqtDjAIcjEo8vAucHkUIsSaWFVfmHmKU4GBWEuG9MhEoxJuSWFmVWpQfX1Sak1p8iHEiI9CT E5mlRJPzgZGVVxJvaGJiYGJsbGZsbG5iTkthJXHenPJ7EUIC6YklqdmpqQWpRTBHMXFwSjUw Xk6U+c+9JWeZjdqsSctv/bHavEDZZtGmR3PXSFgW7DmXoGJgYin3rme22JJPl1jPpaXvaazK 6TPYmM4/x26D/7KLR5Zf6rsj+Hf6OvbViu38IYHsx+8JVH2L2LTVNbpLaVVA3pWkPX0b73ka F5151yu4M4gno1KtxvythXae630//ag3hnE2SizFGYmGWsxFxYkAqu2nMtACAAA= Archived-At: Subject: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 21:45:23 -0000 --Boundary_(ID_H9xZrPeQC46N/NDdmXbdhw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Cameron, Jordi was asking us to phase out Happy Eyeballs because it masks breakage in the network, and what plan we could build to gradually phase it out. My response was that if you, as a network operator, prefer to avoid Happy Eyeballs, you can deploy IPv6-only, as that will in effect disable HE. The scenario you describe is the opposite: you have a broken server and want HE to hide that breakage from users. The tradeoff here is slightly different since that breakage is much less widespread. It is something that a NAT64-aware HE stack could provide though. David > On Mar 29, 2017, at 13:22, Ca By wrote: > > Just a comment following up on Jordi's Mic comment > > Jordi said there was an issue with HE hiding IPv6 issues. > > David's response was something along the lines of "deploy ipv6-only". I did not really understand this. > > When folks deploy ipv6-only, they find they are all alone with a broken ipv6 scenarios that work on all their competitors IPv4-only networks and HE dual-stack networks. > > Also, friendly reminder that Dan Wing catalogs a subset of the websites that fail on ipv6-only http://www.employees.org/~dwing/aaaa-stats/ > > And, my customers still complain about www.fra.dot.gov ... this works for everyone but me... because of HE...and I am already on IPv6-only ... and nobody will fix it. This issues has been known by the USG DOT for over 3 months, noted to NANOG, nobody cares to fix it. > > So, perhaps there is room in the I-D for including NAT64 synthesized address candidate set. Meaning the HE algo on an IPv6-only host would include the set of available native IPv6 answers as well as a 500ms timer for attempting an A query with using whatever mechanism is available to the host for relaying IPv4 packets across an IPv6 only network (RFC6877, Bump in API, ...) > > Without this, IPv6-only networks are at a painful disadvantage since IPv6 must be perfect while every other scenario has HE to mask brokenness. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_H9xZrPeQC46N/NDdmXbdhw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi Cameron,

Jordi was asking us to phase out Happy Eyeballs because it = masks breakage in the network,
and what plan we = could build to gradually phase it out. My response was that if you, as = a
network operator, prefer to avoid Happy Eyeballs, = you can deploy IPv6-only, as that will
in effect = disable HE.

The = scenario you describe is the opposite: you have a broken server and want = HE to
hide that breakage from users. The tradeoff = here is slightly different since that breakage
is = much less widespread. It is something that a NAT64-aware HE stack could = provide though.

David


On Mar 29, 2017, at 13:22, Ca By <cb.list6@gmail.com> = wrote:

Just a comment following up on Jordi's Mic = comment

Jordi said = there was an issue with HE hiding IPv6 issues.

David's response was something along = the lines of "deploy ipv6-only".  I did not really understand = this.

When folks deploy ipv6-only, they find they are all alone = with a broken ipv6 scenarios that work on all their competitors = IPv4-only networks and HE dual-stack networks.

Also, friendly reminder that Dan Wing = catalogs a subset of the websites that fail on ipv6-only http://www.employees.org/~dwing/aaaa-stats/

And, my customers still = complain about www.fra.dot.gov ... this works for everyone but me... = because of HE...and I am already on IPv6-only ... and nobody will fix = it.  This issues has been known by the USG DOT for over 3 months, = noted to NANOG, nobody cares to fix it.

So, perhaps there is room in the I-D = for including NAT64 synthesized address candidate set.  Meaning the = HE algo on an IPv6-only host would include the set of available native = IPv6 answers as well as a 500ms timer for attempting an A query with = using whatever mechanism is available to the host for relaying IPv4 = packets across an IPv6 only network (RFC6877, Bump in API, = ...) 

Without this, IPv6-only networks are at a painful = disadvantage since IPv6 must be perfect while every other scenario has = HE to mask brokenness. 
_______________________________________________
v6ops = mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Boundary_(ID_H9xZrPeQC46N/NDdmXbdhw)-- From nobody Mon Apr 3 15:18: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 D433F12941A for ; Mon, 3 Apr 2017 15:18:51 -0700 (PDT) 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 S6CFsmm8UJiY for ; Mon, 3 Apr 2017 15:18:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3C57D128D8B for ; Mon, 3 Apr 2017 15:18:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvAJC-0000GCC; Tue, 4 Apr 2017 00:18:46 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB0E143@GAALPA1MSGUSRBF.ITServices.sbc.com> In-reply-to: Your message of "Mon, 3 Apr 2017 20:07:52 +0000 ." <2D09D61DDFA73D4C884805CC7865E6114DB0E143@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 04 Apr 2017 00:18:45 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:18:52 -0000 >The technical reasons have been stated by others: DHCPv6 client adds complexit >y and demands memory, CPU, and power. Stateful more so than stateless. I'm amazed at how horrible some IPv6 implementations must be. Even the tiniest devices can do stateful DHCPv4. But some how, writing compact code is a lost skill, so for IPv6, we cannot do this. Really? Everybody can include a DHCPv4 client, but a DHCPv6 client is a bridge too far. And that is a 'technical reason'? Of course ignoring that in the case of IPv6, it is actually the operator who decides if the additional memory, CPU and power are actually needed. When the 'M' and the 'O' bits are clear, you don't waste any of those resources. Yes, you always need a slightly bigger flash chip. Big deal. And, if a device is really constrained, there seems to be no opposition to the idea that if DHCPv6 really doesn't fit, you leave it out. From nobody Mon Apr 3 15:23: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 19F88128D8B for ; Mon, 3 Apr 2017 15:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv1pzzgFoh72 for ; Mon, 3 Apr 2017 15:23:01 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E4F1294DF for ; Mon, 3 Apr 2017 15:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491258179; x=1491862979; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=bBFFOogKCSySWUuqunyiTM40y WEpUEUP5SNGY4CYlIE=; b=lrwa7OOT8iHJANBd0yJUzo0xK1eILIvS3mg28tpjf 0ovk0uyxpFWW+cY/DJfuMRYovws7ZD1PhWqNhtHPGQFoKehT/+1RBOEammcCk4Kd fgdvJAMP2PDYwGJpg+Lm9nupppcFxDt9TMwMqEdeM6THVoMx99Ad5uXrA2tiNggc gw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ONbz4pJ7yRw9Ftpj9dx9PhTn9r2jHqMUdA/WEzHHhNc+B5nccCmAjcRGXTg2 y7iYQY+iiQiX3HkiRBMsKfQrLOhVz38mla1sqTen7VQ7qH3PRT/q5fbjB LCaJo0eTd6mh3zu+CKk6RKMIifkVxoyuMIwhYVVM1poGdzmTdCWzj8=; X-MDAV-Processed: mail.consulintel.es, Tue, 04 Apr 2017 00:22:59 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 04 Apr 2017 00:22:58 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005401734.msg for ; Tue, 04 Apr 2017 00:22:56 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170403:md50005401734::ZUOP/2Iw1hzSTWBx:0000FRn3 X-Return-Path: prvs=1266000cac=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 04 Apr 2017 00:22:54 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <82783B38-E60C-4815-B783-6E7F245BC0E3@consulintel.es> Thread-Topic: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01 References: <004EF04D-AA6F-4301-A003-83E900826F4B@apple.com> In-Reply-To: <004EF04D-AA6F-4301-A003-83E900826F4B@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:23:03 -0000 Hi David, I understand that a gradual phase out may be not feasible, or even difficul= t to standardize as I=E2=80=99m not even sure the IETF process provides tha= t path. So, maybe the only option is to come back in 1-2 years and declare = HE historic, maybe as part of the sunset4 WG work. On Friday, speaking about this with a colleague, we had an idea, which coul= d be part of the HE update. What if we can, not just improve HE, but also ensure that the operators get= reported those failures? May be by means of a well known IPv4+IPv6 anycast= address in operator networks with a collector to get the data about those = failures, or alternatively to the anycast, some DNS PTR, etc. Maybe I=E2=80=99m targeting too high, but we could take also the opportunit= y to signal to the same collector those failures that HE doesn=E2=80=99t so= rt out, such as PMTUD. Operators will decide if they implement it or not, but we can provide the t= ool at least, and seems to me that if we update HE, it may be the perfect p= lace to do so. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de David Schinazi Responder a: Fecha: lunes, 3 de abril de 2017, 23:45 Para: Ca By CC: IPv6 Ops WG Asunto: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01 Hi Cameron, Jordi was asking us to phase out Happy Eyeballs because it masks breaka= ge in the network, and what plan we could build to gradually phase it out. My response was= that if you, as a network operator, prefer to avoid Happy Eyeballs, you can deploy IPv6-o= nly, as that will in effect disable HE. =20 The scenario you describe is the opposite: you have a broken server and= want HE to hide that breakage from users. The tradeoff here is slightly different = since that breakage is much less widespread. It is something that a NAT64-aware HE stack co= uld provide though. =20 David =20 =20 =20 On Mar 29, 2017, at 13:22, Ca By wrote: =20 Just a comment following up on Jordi's Mic comment Jordi said there was an issue with HE hiding IPv6 issues. =20 David's response was something along the lines of "deploy ipv6-only". = I did not really understand this. =20 When folks deploy ipv6-only, they find they are all alone with a broken= ipv6 scenarios that work on all their competitors IPv4-only networks and H= E dual-stack networks. =20 Also, friendly reminder that Dan Wing catalogs a subset of the websites= that fail on ipv6-only http://www.employees.org/~dwing/aaaa-stats/ =20 And, my customers still complain about www.fra.dot.gov ... this works for everyone but me... because of HE...and I am al= ready on IPv6-only ... and nobody will fix it. This issues has been known = by the USG DOT for over 3 months, noted to NANOG, nobody cares to fix it. =20 So, perhaps there is room in the I-D for including NAT64 synthesized ad= dress candidate set. Meaning the HE algo on an IPv6-only host would includ= e the set of available native IPv6 answers as well as a 500ms timer for att= empting an A query with using whatever mechanism is available to the host f= or relaying IPv4 packets across an IPv6 only network (RFC6877, Bump in API,= ...)=20 =20 Without this, IPv6-only networks are at a painful disadvantage since IP= v6 must be perfect while every other scenario has HE to mask brokenness.=20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Apr 3 15:34: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 DD09812941A for ; Mon, 3 Apr 2017 15:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 yJplwWvm4O7y for ; Mon, 3 Apr 2017 15:34:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6754B128B44 for ; Mon, 3 Apr 2017 15:34:15 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v33MXCS6002254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2017 15:33:14 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: Date: Mon, 3 Apr 2017 15:33:09 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB0E143@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Philip Homburg X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Mon, 03 Apr 2017 15:33:15 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:34:17 -0000 > On Apr 3, 2017, at 3:18 PM, Philip Homburg = wrote: >=20 >> The technical reasons have been stated by others: DHCPv6 client adds = complexit >> y and demands memory, CPU, and power. Stateful more so than = stateless. >=20 > I'm amazed at how horrible some IPv6 implementations must be. >=20 > Even the tiniest devices can do stateful DHCPv4. But some how, writing > compact code is a lost skill, so for IPv6, we cannot do this. There are actually many tiny devices I=E2=80=99m aware of that can=E2=80=99= t do stateful DHCPv4. Beyond that, DHCP6 has a lot more overhead than DHCPv4. > Really? Everybody can include a DHCPv4 client, but a DHCPv6 client is = a=20 > bridge too far. And that is a 'technical reason=E2=80=99? Really. Take a long hard look at the differences in what it takes to = implement a client for DHCP4 (a minimal one) vs. a minimal conforming DHCP6 client. = There=E2=80=99s a whole lot more going on in the DHCP6 client. > Of course ignoring that in the case of IPv6, it is actually the = operator > who decides if the additional memory, CPU and power are actually = needed. > When the 'M' and the 'O' bits are clear, you don't waste any of those > resources. Yes, you always need a slightly bigger flash chip. Big = deal. >=20 > And, if a device is really constrained, there seems to be no = opposition to > the idea that if DHCPv6 really doesn't fit, you leave it out. But the opposition to mandating router vendors to implement RDNSS is = still a problem for these devices. Owen From nobody Mon Apr 3 15:34: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 02C091293FC for ; Mon, 3 Apr 2017 15:34:40 -0700 (PDT) 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 L_OLHN5DLWd3 for ; Mon, 3 Apr 2017 15:34:37 -0700 (PDT) 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 C3E111294AF for ; Mon, 3 Apr 2017 15:34:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 483674A; Tue, 4 Apr 2017 00:34:31 +0200 (CEST) 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=1491258868; bh=nxAZYzMj+3C5qzRdkeSejcZl5Euk eQxWgSiaRIQNZvA=; b=RPvvH6ipCbALFaqLpstY9pGUq3Z7oqMTBTCpxLJUcwap lY/HBG1PUGdKagqOsbCYICma4CyZseqfhJe+29TbvOpVb/+i6lv/Ti96fv8k//ZL FdfcLWaGlwCGe0R74A/a4/oDE83t6mB6wCaPtKUL0jGIgb0WTX9dAEwsBd1b+/E= 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 noNglDlQIweR; Tue, 4 Apr 2017 00:34:28 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:9300:38f1:f248:a9b:8935] (unknown [IPv6:2a02:a213:a300:9300:38f1:f248:a9b:8935]) (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 3D29349; Tue, 4 Apr 2017 00:34:27 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_E3BA0450-AFBD-4B91-9DF1-188129E1E6C9"; 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: <82783B38-E60C-4815-B783-6E7F245BC0E3@consulintel.es> Date: Tue, 4 Apr 2017 00:34:26 +0200 Cc: v6ops@ietf.org Message-Id: <44E2805D-0441-4FA4-A2BB-C8717CE2F69D@steffann.nl> References: <004EF04D-AA6F-4301-A003-83E900826F4B@apple.com> <82783B38-E60C-4815-B783-6E7F245BC0E3@consulintel.es> To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:34:40 -0000 --Apple-Mail=_E3BA0450-AFBD-4B91-9DF1-188129E1E6C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > I understand that a gradual phase out may be not feasible, or even = difficult to standardize as I=E2=80=99m not even sure the IETF process = provides that path. So, maybe the only option is to come back in 1-2 = years and declare HE historic, maybe as part of the sunset4 WG work. I once suggested to increase the HE timers to make broken IPv6 a bit = more noticeable without breaking stuff completely. In the cases where = the server is broken (I have seen insane AAAA records) it might be = slightly less pleasant for the user, but suddenly there is a tangible = incentive for the server to get fixed. "Unfortunately" the = implementation of HE is on the user's side and the software developer's = main goal is to provide a good user experience. But yeah, HE is hiding brokenness. On one hand this is a good thing = because it makes people less afraid of deploying IPv6 because the "risk" = is lower. On the other hand that lower risk also means that problems = don't get solved. My guess is that when more and more NAT64 networks get = deployed, and HE doesn't help anymore, the brokenness will get fixed. Cheers, Sander --Apple-Mail=_E3BA0450-AFBD-4B91-9DF1-188129E1E6C9 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----- iQEcBAEBCAAGBQJY4s3yAAoJEKAtA7D+JBO5BBsH/jRGZ/3c02F8+qN0DuyG9zRK CMi552RP66G7pyzApoTDULZQsMjQ9RPkvJRflUw0ubjGMN+JXlMd6WY9Uj5WBR3r okDTFUoru9h2dq/Jww3SNRFBlClf2/yMuEsTwMhVFgkSaBktVPnV37knhgrTdoPw qYh2cLcOJryd/nfweRAx4RujN96mm4pcre4hSsFIOWmTUpSjfhz5DEeyE7hUGF+p c7CRLMbMLx75D1LH7n+xQe+2j02n5FEhyVne7Okp0CZ/A2lplPNNBTh2OhjqMeR9 HvYklQoF/iLGJDwIkOefcq/YFMpAUUHlVttYwGTdMOIkUy852Jc+L8Q5dz9OXak= =iv3X -----END PGP SIGNATURE----- --Apple-Mail=_E3BA0450-AFBD-4B91-9DF1-188129E1E6C9-- From nobody Mon Apr 3 15:46: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 2A946129519 for ; Mon, 3 Apr 2017 15:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 euWoYQAbCnZw for ; Mon, 3 Apr 2017 15:46:44 -0700 (PDT) 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 49BFD1294AF for ; Mon, 3 Apr 2017 15:46:44 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id m133so44321665ybb.1 for ; Mon, 03 Apr 2017 15:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QiTylDScSpnBzYACqOkQsAL/kRPty6M3u6p7KJuwXVU=; b=Gf0x5bIpQEtqIikjemOMfgEo4WHNm0JMx+QqnQwrODImg8jXEO5HKm10Tck5w7GlPC XdV3m1UbjSh1GqqR6D4djtlGe9gQloh+Dgt2QUUcxgCTrb1I/0/gRtnUbC87l7gufY1h kHWaxEfD8IPORB6SqYlntRoF2m0IRKxQTzubECv03pCks98zuEpHSFdlrs3G0nM2FimU r+LpRdpOCfRKX9gXbGNjMCbS0lSRUDsjAKlHC0zPlMV9ZX1vARFNK65HLQd1FbAqNtTL Vg3UcNwdrSgxMyxFZpmoPBffh+LidP1/wwjpi8RrA6lxkStJBaCbMeHme45BbCzDXWIl N1pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QiTylDScSpnBzYACqOkQsAL/kRPty6M3u6p7KJuwXVU=; b=hkXGg48rEdgutd6rda0x/AabpQcqhNf+lKutjbb95JZPbHh3qIbTOA6fcb5MJQgPKD xw7vHukuUP0DRAExY/FjSPGTzzUD/r5orLcEXeH85XhgBd9xCo3BGoyFMQLOE25ezY21 twDU2/c+Zw4gN0VByrmWlhxM/DGArdZ9mqhA9Ru7kj21Hn07n6HdMTfkCpixszjaErFl 132x6YWxP+Ec0MN0fV1YSwW/8+BdmwEGH33+d+RHUvwaT2AYQCZFHAfaSEgBjdDK1zKV hpoMbeZQ4qzoWGNjVJV6DNm4hHNQCSQlgVRgth+WYD2UKonxlqISHmREpugsN65CZoyQ 6tVg== X-Gm-Message-State: AFeK/H2AMk9/8MJ2Xh1mZA6NUcorLYFG3jjU90IQA48ogWpwWvJVj+U8adJW1ge2PK+0RUFrOVxEhQKQOXyh0Q== X-Received: by 10.129.4.137 with SMTP id 131mr13123552ywe.78.1491259603517; Mon, 03 Apr 2017 15:46:43 -0700 (PDT) MIME-Version: 1.0 References: <004EF04D-AA6F-4301-A003-83E900826F4B@apple.com> <82783B38-E60C-4815-B783-6E7F245BC0E3@consulintel.es> <44E2805D-0441-4FA4-A2BB-C8717CE2F69D@steffann.nl> In-Reply-To: <44E2805D-0441-4FA4-A2BB-C8717CE2F69D@steffann.nl> From: Ca By Date: Mon, 03 Apr 2017 22:46:32 +0000 Message-ID: To: Sander Steffann , jordi.palet@consulintel.es Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary=001a113f1fa8ef8a78054c4aeec4 Archived-At: Subject: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:46:46 -0000 --001a113f1fa8ef8a78054c4aeec4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 3, 2017 at 3:34 PM Sander Steffann wrote: > Hi, > > > I understand that a gradual phase out may be not feasible, or even > difficult to standardize as I=E2=80=99m not even sure the IETF process pr= ovides > that path. So, maybe the only option is to come back in 1-2 years and > declare HE historic, maybe as part of the sunset4 WG work. > > I once suggested to increase the HE timers to make broken IPv6 a bit more > noticeable without breaking stuff completely. In the cases where the serv= er > is broken (I have seen insane AAAA records) it might be slightly less > pleasant for the user, but suddenly there is a tangible incentive for the > server to get fixed. "Unfortunately" the implementation of HE is on the > user's side and the software developer's main goal is to provide a good > user experience. > > But yeah, HE is hiding brokenness. On one hand this is a good thing > because it makes people less afraid of deploying IPv6 because the "risk" = is > lower. On the other hand that lower risk also means that problems don't g= et > solved. My guess is that when more and more NAT64 networks get deployed, > and HE doesn't help anymore, the brokenness will get fixed. > My experience is that when clients see failure due to broken severs, nat64 based solutions get rolled back or shelved completely After all, that website with the bad aaaa works on my DS competition's network and my ipv4 only competition's network. HE has created a situation where ipv6-only must be perfect (impossible) while ipv4 and ipv6 have a nonzero acceptable error budget. Note, 464xlat is effectively DS in this example and can tolerate misconfigured ipv6 > Cheers, > Sander > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113f1fa8ef8a78054c4aeec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 3, 2017 at 3:34 PM San= der Steffann <sander@steffann.nl> wrote:
Hi,

> I understand that a gradual phase out may be not feasible, or even dif= ficult to standardize as I=E2=80=99m not even sure the IETF process provide= s that path. So, maybe the only option is to come back in 1-2 years and dec= lare HE historic, maybe as part of the sunset4 WG work.

I once suggested to increase the HE timers to make broken IPv6 a bit more n= oticeable without breaking stuff completely. In the cases where the server = is broken (I have seen insane AAAA records) it might be slightly less pleas= ant for the user, but suddenly there is a tangible incentive for the server= to get fixed. "Unfortunately" the implementation of HE is on the= user's side and the software developer's main goal is to provide a= good user experience.

But yeah, HE is hiding brokenness. On one hand this is a good thing because= it makes people less afraid of deploying IPv6 because the "risk"= is lower. On the other hand that lower risk also means that problems don&#= 39;t get solved. My guess is that when more and more NAT64 networks get dep= loyed, and HE doesn't help anymore, the brokenness will get fixed.




--001a113f1fa8ef8a78054c4aeec4-- From nobody Mon Apr 3 15:58: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 862E31289C3 for ; Mon, 3 Apr 2017 15:58:41 -0700 (PDT) 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, HK_RANDOM_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 j_F8A1yOtdmq for ; Mon, 3 Apr 2017 15:58:39 -0700 (PDT) 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 71B14120724 for ; Mon, 3 Apr 2017 15:58:39 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id r69so156739034vke.2 for ; Mon, 03 Apr 2017 15:58:39 -0700 (PDT) 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=Gq6gmzbOAAqEOKNmf5FuKXO2CO4yoE5LqtdgkUz+hIc=; b=sc4HJUvE9d11U0XQoKvYu8lXiQeCDVUHIv4V3yQizqzkjY5YscW/cTpez39Cpz0umM iOLnD9BdfRMbOCvdIeMFXEhLOmOGxZK5CuyTIGNh13pnZtuTZfJ+Pil75cziFJAa1LZO uVIEpJgl7r2CICfgV7Ia06Og+rj3KHd56Zggehew1AjHcnlWVqu5rCrjGzOMUxVEkoLJ 3Fae9Dcqhs/jMqL8BKZv/6Q1EfsO/pDxDAChDax/+CAyFVUUzYlGBpy/rEsik8M5TeTs 121Zw2DlUpE17GTe5f3PBcqa4M/zkufWGlWUbSs4IBJuGkSPobIJ6LuoQ/fjLMMSfPj/ 78rA== 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=Gq6gmzbOAAqEOKNmf5FuKXO2CO4yoE5LqtdgkUz+hIc=; b=Z/M+pU0mF/1+9vQPkwUtOTl4T1IOhliPfOjbjYWqyjxo3yCRdWB/UmMB87m+k6jbfi NYiCJmhde4aihmvT+9/EEWha7fNHNXqsZXhltlS2pSIZiACyY33i8AHHuOXpuCzqKGms rIbQIgxS0+g+aC/JsKTWBOHcsmkxGc3JgS2rCy7F1u0DuvJyOpwDM+g/w/bV+3PeSpDw J6Ay/eYmPtpX++ifB4ZPG8ZvUc+Pz4tNru/wp1Ybi6YMAvRYzFRkQgAgBvL/uebzeYeS Rw0j4Yjy58m2L4t810zu9ZqgKuIvmUr1GBzQCBEZtfBTIlb9MFhTxPerYtBUGZLLKEAr DwfA== X-Gm-Message-State: AFeK/H0KfHoA/pGH+5+X+Aju7B6M/J3PIpYyK9jqZG7bw+oiHJ5Lb6CiXLJpNu1DY7BtlaAoTjkDJE0dZmMWAg== X-Received: by 10.159.48.20 with SMTP id h20mr8628861uab.49.1491260318198; Mon, 03 Apr 2017 15:58:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 15:58:07 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> From: Mark Smith Date: Tue, 4 Apr 2017 08:58:07 +1000 Message-ID: To: Ted Lemon Cc: IPv6 Ops WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:58:41 -0000 On 4 April 2017 at 03:21, Ted Lemon wrote: > My reaction to this long and very predictable high-bandwidth back-and-for= th is that I suspect the outcome will be the same as it was last time: no a= ction. > > This is frustrating. It seems clear to me that requiring support for RD= NSS would improve the situation. Possibly requiring support for DHCPv6 wo= uld also improve the situation if it were done correctly (which is not a gi= ven). But whenever anybody proposes requiring RDNSS, we get this demand f= or parity, and then a giant explosion of opinions, and then no action. > > Essentially what I see here is a viable solution being held hostage to de= mands for a controversial solution. It may be that the controversy isn't = valid, and that really requiring DHCPv6 is the right thing to do. But the= controversy exists, and makes requiring DHCPv6 problematic. > > I don't see any justification for a technical objection to RDNSS. So my= personal opinion is that despite the loud protests to the contrary, there = is consensus to require RDNSS. It may also be the case that there is cons= ensus to require DHCPv6, on the same basis. However, that would require a= document that describes what "require DHCPv6" actually means. > > It is of course entirely possible that the document authors are just plot= zing at this discussion, or perhaps have chosen to ignore it, since the doc= ument isn't explicitly mentioned anywhere in the thread. It would be vali= d for them to say that this is simply not an opportunity to re-open this is= sue. However, the section in the document on Zero Touch Configuration cer= tainly looks like a good place to insert a requirement. > > My personal preference would be that if there is any serious desire for D= HCPv6 to be required, that the proponents of this requirement write up in a= document what that support looks like. I don't think it makes sense to d= o that in this document. I think it does make sense to require RDNSS in t= his document, because I don't think there's any question as to what that lo= oks like. > > I realize that holding that hostage probably looks like a great way for p= roponents of DHCPv6 support to get their way, but I don't think that's what= would happen: what would happen would be that the authors of the document = would say nothing at all on this topic. So that's your choice: improve th= e situation, but don't get everything you want, or get nothing. For those= who do not want RDNSS, of course, the scorched earth approach will be fine= , but for the rest of us I think it's not fine. > The above all makes sense to me. I don't like that RDNSS exists, because it has caused all this trouble, discussion and interoperability problems. Just sticking to using stateless DHCPv6 for this purpose would have made much more sense to me. I've always had the view that hosts need more than layer 3 configuration information conveyed by RAs (prior to RDNSS optoins), and also need more than DNS information - most if not all devices have or maintain real time clocks in them that need or should be set accurately, and probably are informed of their timezone (having just switched from daylight savings time over the weekend, I still have about four more clocks to manually change ...). So I've assumed that stateless DHCPv6 (not stateful, address assigning, DHCPv6) was a necessity rather than an option, to do more than configure DNS information. However, now that RDNSS exists and is causing interoperability problems, I see value in hosts implementing both stateless (to be clear, not stateful) DHCPv6 and RDNSS to be able to adapt to what ever method the network they attach to is using to convey DNS information. The majority of hosts are mobile so it makes sense to me that they adapt to the current network they're attaching to, rather than the other way around. This is a compromise I'm willing to make to my views to make the current situation better. What I don't want to see is that then being used to justify importing DHCPv6 options into RAs and RA options into DHCPv6, as though there is and will be no problems and no additional costs in doing so. This discussion is a real and live demonstration of those sorts of problems and costs. I think having two similar methods for configuring DNS has been a mistake. We should call it out as such, work around it in the interest of operability, and then say and make sure we're not going to make that sort of mistake again (I think it has been already made twice - SLAAC vs stateful DHCP for address configuration, a view that seems to be commonly based on the flawed premise that DHCP provides an accurate record of MAC addresses and corresponding address use). I also think it is necessary to state whether stateless or stateful DHCP is being described or referred to. If I don't see any qualifier, I assume stateful, which I also think others do too, and that then creates a loaded discussion that implies that IPv6 addressing will also be handled by (stateful) DHCPv6. The conversation can then devolve into one that is also discussing the use of SLAAC vs stateful DHCPv6 for addressing too. Regards, Mark. From nobody Mon Apr 3 16:03: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 4F35C120724 for ; Mon, 3 Apr 2017 16:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 X-tecAUImx7X for ; Mon, 3 Apr 2017 16:03:06 -0700 (PDT) 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 4E4A0124D6C for ; Mon, 3 Apr 2017 16:03:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvAzs-0000EYC; Tue, 4 Apr 2017 01:02:52 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB0E143@GAALPA1MSGUSRBF.ITServices.sbc.com> In-reply-to: Your message of "Mon, 3 Apr 2017 15:33:09 -0700 ." Date: Tue, 04 Apr 2017 01:02:50 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 23:03:08 -0000 > Really. Take a long hard look at the differences in what it takes > to implement a client for DHCP4 (a minimal one) vs. a minimal > conforming DHCP6 client. Theres a whole lot more going on in the > DHCP6 client. I must have done something wrong then. The structure of my simple DHCPv6 client is roughly similar to what I expect from a DHCPv4 client. I have to admit, I never had to write a DHCPv4 client, so I may have missed something. In any case, a my standalone DHCPv6 client is about one quarter the code I need for ND. And we keep adding complexity to ND. > But the opposition to mandating router vendors to implement RDNSS > is still a problem for these devices. As far as I can tell, apart from the people who are never going to support DHCPv6, there is quite a bit of support for making both RDNSS and DHCPv6 DNS MTI. So tiny devices should be covered. From nobody Mon Apr 3 16:05: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 5C56912940D for ; Mon, 3 Apr 2017 16:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y89RGUWXyWuq for ; Mon, 3 Apr 2017 16:05:43 -0700 (PDT) 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 C99741294AF for ; Mon, 3 Apr 2017 16:05:42 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id 21so134208428pgg.1 for ; Mon, 03 Apr 2017 16:05:42 -0700 (PDT) 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=HFgauWaGNrkwmzu9Y1M9OCOOq1wzqmWF03/zvLux98o=; b=h8dcCdheo+0UvtT45tbC5EtDvGdMgoIE9oF7+KfIntLebvi3wEnFhFONU8QBAF6cb9 QsLd5v1Rbl20Jry3pLMX79+b+9diFZbZBhzPVm9e9JM5KsOmQ3ulRcGO8/0H8KHBrvOF M3Qiy6eWN+2VtdLWtHs+wmuOspedfWZgEdhm99SAh0RJ7oVxce91AFhd5hT3dUs7mOcT Jal3kkr8czIFtc6+vAH2qEyDe65CYuoEiv8HfQFMRtk/KZM3VXMWUKzv8ZFGquTtmEs9 MAyo5fuaWsLXLmYxBgOT6+ZjQ35wZElgIczV9y1XjGGQ/oBy+sju5I1TUxz+oB59kBjB 9Avw== 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=HFgauWaGNrkwmzu9Y1M9OCOOq1wzqmWF03/zvLux98o=; b=F1pw+OW9QIuQiTAM13y8pxdjFyrSoFdvdke1TZHc+cXaL5UQdSQ29ObPOBLRd4HamY IRB8IE0DIrPR6mxOiTFqGXu9kgasQ3/b51Y6jDft1WS8eeLLkv9UDpKCBuX0lQChAqjO vQvuRVej9YqxOgXWUr7zZC8GMSQp+LdzMFbfq0vmTTytruV9EvLA/NeUVI5ItROuW+7U rQqAl9e+6Qi294IcZE1QwiJ5TBDIFjTcKgm1dk0OEfss/Oh5qcKIwkPCQFKYV7HSzeGG KLyyb9SSo4/RJ/y0wmkeL5GG9m9Gmm7Xj4jUyVxgO1LD4PUG5u2Jv/YGqx4gZdonI1FE leMQ== X-Gm-Message-State: AFeK/H22ohj/N8z2HUWTaNRjGFrEcopWG8PCRsPTuI5zSHazARc1p2ourHrcSGM+EUqsOw== X-Received: by 10.98.51.198 with SMTP id z189mr20047547pfz.137.1491260742263; Mon, 03 Apr 2017 16:05:42 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-223-134.public.wayport.net. [64.134.223.134]) by smtp.gmail.com with ESMTPSA id x21sm27737612pfa.71.2017.04.03.16.05.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 16:05:41 -0700 (PDT) From: Ted Lemon Message-Id: <7F8DA115-0B8D-4542-8616-9CF375E89EA3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CDE2B03D-B92E-4829-8135-E231A6898D6C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Apr 2017 16:05:40 -0700 In-Reply-To: <20170403210611.549AC6A7A930@rock.dv.isc.org> Cc: james woodyatt , IPv6 Operations To: Mark Andrews References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> <20170403210611.549AC6A7A930@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 23:05:45 -0000 --Apple-Mail=_CDE2B03D-B92E-4829-8135-E231A6898D6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 3, 2017, at 2:06 PM, Mark Andrews wrote: > Stuff "designed for homes" gets put on corprate nets all the time. It > should just work there. There is very little, if anything, that = doesn't > get connected to both types of nets. Stuff might protect the end user's privacy by not doing certain = protocols. It might refuse to work if the network refuses to allow the = end user their privacy. This would seem to be correct behavior. = Correct behavior is sometimes "fail." E.g., you do not want a TLS = connection to succeed if the server cert doesn't validate.= --Apple-Mail=_CDE2B03D-B92E-4829-8135-E231A6898D6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 3, 2017, at 2:06 PM, Mark Andrews <marka@isc.org> = wrote:
Stuff "designed for = homes" gets put on corprate nets all the time.  It
should just work there.  There is very = little, if anything, that doesn't
get connected to = both types of nets.

Stuff might protect the end user's privacy by not doing = certain protocols.   It might refuse to work if the network refuses = to allow the end user their privacy.   This would seem to be = correct behavior.   Correct behavior is sometimes "fail."   = E.g., you do not want a TLS connection to succeed if the server cert = doesn't validate.
= --Apple-Mail=_CDE2B03D-B92E-4829-8135-E231A6898D6C-- From nobody Mon Apr 3 16:12: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 384C112940D for ; Mon, 3 Apr 2017 16:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 GbMfE6rN-Fh4 for ; Mon, 3 Apr 2017 16:12:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAC0120724 for ; Mon, 3 Apr 2017 16:12:11 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v33NA5ob005256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2017 16:10:06 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <3d7b844a-4be8-dfad-b7b9-b9816de6af50@bogus.com> Date: Mon, 3 Apr 2017 16:10:05 -0700 Cc: Fred Baker , Ted Lemon , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <65701C75-1785-4FD4-A912-A96DC527148D@delong.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <3d7b844a-4be8-dfad-b7b9-b9816de6af50@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Mon, 03 Apr 2017 16:10:07 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 23:12:13 -0000 > On Apr 3, 2017, at 11:53 AM, joel jaeggli wrote: >=20 > On 4/3/17 11:07, Fred Baker wrote: >> On Apr 3, 2017, at 10:21 AM, Ted Lemon wrote: >>> My reaction to this long and very predictable high-bandwidth = back-and-forth is that I suspect the outcome will be the same as it was = last time: no action. >> I'm not sure I disagree. =46rom my perspective, the best action would = be to select one methodology - use the RA or use DHCP in some form, but = not both. >>=20 >> What I don't see in this is an emerging consensus. I see two sets of = people, one with a consensus around the RA and the other with a = consensus around DHCP, and I don't see them convincing each other. > As the implmentor of an end system device one may have a different > vantage point then that of a network operator or the the designer of > routers. ultimately I think the demand to be able to signal = information > in an RA vs stateful DHCP reflects differing priorities for network > mobility. the fact taht router advertisement as a function doesn't not > exist in ipv4 necessarily constrains mobility in certain ways (e.g. > network operators have to account for information provided with a = lease > (life the default GW) being stable for the lifetime of the lease) > whereas with the RA and slack generally much shorter lifetimes are = feasible. More importantly, RA provides a mechanism to shorten the timer after the = =E2=80=9Clease=E2=80=9D has been issued. It is possible for an RA with desired=3D3600 valid=3D86400 to be = followed up with an RA with much smaller values (or even 0 values if an immediate change is desired for = some reason). In such a case, the smaller values would immediately take effect and then = reconfiguration could be reliably considered complete N seconds (where N =3D new valid lifetime = value in the previous RA) after the old information is removed from the RA = configuration. DHCP4 provides no such mechanism and RA in IPv4 which does exist, but = nobody uses also lacks this capability to the best of my knowledge. >> Absent consensus, I don't think we have a basis for action, and are = likely to therefore not act. > Imho I personally see them both as feasisble from a network equipment > standpoint. I can see cases where a network operator might support = only > one or the other, and in cases where there's a high degree of vertical > integration that seems easy enough, if you don't control what = equipment > is on your network however you may have limited choice afterall there > are legacy operating systems that either need to be configured = manually > or use well-know addresses, I don't personally have any of those > machines anymore, but I also don't run an airport or a railroad. Operator constraints for legacy systems aren=E2=80=99t really something = we can address here in a meaningful way. The question is can we get anywhere like consensus to = recommend or require both protocols in host and router implementations going forward, = or, will we allow the dichotomy of the Anti-DHCP camp and the Anti-RDNSS camp to continue = to paralyze progress in this area? Owen (Who is neither anti-DHCP nor anti-RDNSS, but does offer stronger = support for RDNSS than DHCP) From nobody Mon Apr 3 16:28: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 785E51294A5 for ; Mon, 3 Apr 2017 16:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 uOFtP7OBMHVX for ; Mon, 3 Apr 2017 16:28:35 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2997E124BE8 for ; Mon, 3 Apr 2017 16:28:35 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v33NRWe9006810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2017 16:27:33 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: Date: Mon, 3 Apr 2017 16:27:31 -0700 Cc: Ted Lemon , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> To: Mark Smith X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Mon, 03 Apr 2017 16:27:33 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 23:28:37 -0000 > On Apr 3, 2017, at 3:58 PM, Mark Smith wrote: >=20 > On 4 April 2017 at 03:21, Ted Lemon wrote: >> My reaction to this long and very predictable high-bandwidth = back-and-forth is that I suspect the outcome will be the same as it was = last time: no action. >>=20 >> This is frustrating. It seems clear to me that requiring support = for RDNSS would improve the situation. Possibly requiring support for = DHCPv6 would also improve the situation if it were done correctly (which = is not a given). But whenever anybody proposes requiring RDNSS, we get = this demand for parity, and then a giant explosion of opinions, and then = no action. >>=20 >> Essentially what I see here is a viable solution being held hostage = to demands for a controversial solution. It may be that the = controversy isn't valid, and that really requiring DHCPv6 is the right = thing to do. But the controversy exists, and makes requiring DHCPv6 = problematic. >>=20 >> I don't see any justification for a technical objection to RDNSS. = So my personal opinion is that despite the loud protests to the = contrary, there is consensus to require RDNSS. It may also be the case = that there is consensus to require DHCPv6, on the same basis. However, = that would require a document that describes what "require DHCPv6" = actually means. >>=20 >> It is of course entirely possible that the document authors are just = plotzing at this discussion, or perhaps have chosen to ignore it, since = the document isn't explicitly mentioned anywhere in the thread. It = would be valid for them to say that this is simply not an opportunity to = re-open this issue. However, the section in the document on Zero Touch = Configuration certainly looks like a good place to insert a requirement. >>=20 >> My personal preference would be that if there is any serious desire = for DHCPv6 to be required, that the proponents of this requirement write = up in a document what that support looks like. I don't think it makes = sense to do that in this document. I think it does make sense to = require RDNSS in this document, because I don't think there's any = question as to what that looks like. >>=20 >> I realize that holding that hostage probably looks like a great way = for proponents of DHCPv6 support to get their way, but I don't think = that's what would happen: what would happen would be that the authors of = the document would say nothing at all on this topic. So that's your = choice: improve the situation, but don't get everything you want, or get = nothing. For those who do not want RDNSS, of course, the scorched = earth approach will be fine, but for the rest of us I think it's not = fine. >>=20 >=20 > The above all makes sense to me. >=20 > I don't like that RDNSS exists, because it has caused all this > trouble, discussion and interoperability problems. Just sticking to > using stateless DHCPv6 for this purpose would have made much more > sense to me. I don=E2=80=99t think that=E2=80=99s a fair characterization. I think = that if you want to complain about the trouble, discussion, and interoperability problems, you have = to go back to the root of bifurcating SLAAC and DHCP and allowing multiple = zero configuration address assignment protocols in the first place. RDNSS is simply the minimum necessary modification to SLAAC to make it actually usable as a zero-conf protocol. Those that are opposed to RDNSS were mostly opposed to SLAAC without DHCP for at least O-bit purposes before RDNSS existed and are also mostly the same people still pushing for routing options in DHCP. > This is a compromise I'm willing to make to my views to make the > current situation better. What I don't want to see is that then being > used to justify importing DHCPv6 options into RAs and RA options into > DHCPv6, as though there is and will be no problems and no additional > costs in doing so. This discussion is a real and live demonstration of > those sorts of problems and costs. I don=E2=80=99t think that the former is being proposed at all and as to = the latter, the route information in DHCP6 option has been something some subset of the populace has been pushing for long before, so I don=E2=80=99t = think adding MTI RDNSS for routers and hosts will significantly change that = situation. > I think having two similar methods for configuring DNS has been a > mistake. We should call it out as such, work around it in the interest > of operability, and then say and make sure we're not going to make > that sort of mistake again (I think it has been already made twice - > SLAAC vs stateful DHCP for address configuration, a view that seems to > be commonly based on the flawed premise that DHCP provides an accurate > record of MAC addresses and corresponding address use). I think allowing incompatible subsets of the two mechanisms is the = mistake. Requiring the overhead of DHCP just to provide DNS server information = was a mistake and the original demand for RDNSS is sufficient proof of that = that I don=E2=80=99t feel the need to expand further. > I also think it is necessary to state whether stateless or stateful > DHCP is being described or referred to. If I don't see any qualifier, > I assume stateful, which I also think others do too, and that then > creates a loaded discussion that implies that IPv6 addressing will > also be handled by (stateful) DHCPv6. The conversation can then > devolve into one that is also discussing the use of SLAAC vs stateful > DHCPv6 for addressing too. I think it=E2=80=99s important to recognize that we are talking about a = MTI requirement, not a must use or must deploy requirement. IMHO, the MTI should, for = hosts, include SLAAC, RDNSS, and where practical/feasible stateless and = stateful DHCP6. For routers, it should include SLAAC, RDNSS, stateful and = stateless DHCP6. In this way, the routers and hosts ship with the ability for the = operator to choose the subset of SLAAC/RDNSS/Stateful/Stateless that best suits their = environment and best meets the needs of their hosts and users. Owen From nobody Mon Apr 3 16:36: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 C5F34129455 for ; Mon, 3 Apr 2017 16:36:49 -0700 (PDT) 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, HK_RANDOM_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 6uF1FGTxygeT for ; Mon, 3 Apr 2017 16:36:48 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 0BF711267BB for ; Mon, 3 Apr 2017 16:36:48 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r69so157466293vke.2 for ; Mon, 03 Apr 2017 16:36:47 -0700 (PDT) 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=JvJoxCqgkFdoRgAVloItuGFvN5/x35JK2cQhlDqiDGU=; b=QGCeLS4b9MLh9ljkG4dd7AaemrvdhxBvVFaK93Nn1qJpOZmS9Rq9EGG9cryIiceaVg VOWIu44PV/x3DBVjFE/oT4bP1hqnmu+U0vaZhHFOo0yhZ2VtA4D35F9tYL+W2SH93wxq EfHw0RG5LYsaKQY2Ume6WLEMyZFOW0EqbMVtphpYd+Wm4vUCUifF+GFj40J4IRaWxYTr DkXG4y+B10rnAWtfFx+p+a8LsS9dl0Lq0jFGkaz/nu5lq8yz5a+LhWOE6Zp7mspEnhtw K5i8gaieV03W00oVbot3LfCHkU4di65FFn9vvKHabstB0JnKwNkfHADzmPJ+GmaNPERB oIQw== 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=JvJoxCqgkFdoRgAVloItuGFvN5/x35JK2cQhlDqiDGU=; b=lROZpilZklO3C3Pb0+dca0y/Pqos969mmvOaU3YRuZ/oEWtlGY9BQsSI14zeax544b UPe0Fx9aO+syOCYrGXjUGCq8CiEYE0X0qKC47cAe8o1HyfKCMqu/fiGPKGUddWneU9Px cetsLysSIrx8ZqT4WI7H1SRj00UUQuMeJ5/hqG2QK3/JyemlGFut+xci7q8k4tUXyrAA OdIwGxe57sXVBS4nk1iAxqdOCicuk9LzVFn7SA1Sfk5ZeLWY590Vp+QBm8dzPJHntJpP tbXBVqdo/EYb0lj30M1PPGpKAcNxg0rj1mGkkH1l+Ph0E6XNydeDVCRR+j6PnWmfwSKz XmXA== X-Gm-Message-State: AFeK/H0vfSQ51cSg4fqTG888WpXT2+BKJzWu/qRMtPbrkB/uPEYQwQmLpST0vFewUO1tA8vxk+svSVOoojSQhQ== X-Received: by 10.31.51.12 with SMTP id z12mr9248414vkz.69.1491262607063; Mon, 03 Apr 2017 16:36:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 16:36:16 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB0E143@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Mark Smith Date: Tue, 4 Apr 2017 09:36:16 +1000 Message-ID: To: Philip Homburg Cc: v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 23:36:50 -0000 On 4 April 2017 at 09:02, Philip Homburg wrote: >> Really. Take a long hard look at the differences in what it takes >> to implement a client for DHCP4 (a minimal one) vs. a minimal >> conforming DHCP6 client. Theres a whole lot more going on in the >> DHCP6 client. > > I must have done something wrong then. The structure of my simple DHCPv6 > client is roughly similar to what I expect from a DHCPv4 client. I > have to admit, I never had to write a DHCPv4 client, so I may have missed > something. > > In any case, a my standalone DHCPv6 client is about one quarter the > code I need for ND. And we keep adding complexity to ND. > >> But the opposition to mandating router vendors to implement RDNSS >> is still a problem for these devices. > > As far as I can tell, apart from the people who are never going to support > DHCPv6, there is quite a bit of support for making both RDNSS and DHCPv6 DNS > MTI. So tiny devices should be covered. > I think the above is a perfect example of the problems of not stating whether stateful or stateless DHCPv6 is being referred to. I think stateless DHCPv6 implementations, limited to what is described in RFC3736 and RFC424, are going to be significantly simpler than stateful DHCPv4 ones. (I think it would be possible to implement a simpler stateless DHCPv4 client, however as there is no alternative way to automate address configuration, it is likely that there is no such thing has been specifically implemented.) Regards, Mark. From nobody Mon Apr 3 16:43: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 E9AA1129467 for ; Mon, 3 Apr 2017 16:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Cf8Wf5q2bEKT for ; Mon, 3 Apr 2017 16:43:27 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 30B06129455 for ; Mon, 3 Apr 2017 16:43:27 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v33NgNQq008002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2017 16:42:26 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: Date: Mon, 3 Apr 2017 16:42:23 -0700 Cc: IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <7CC14A93-86E4-4528-8A03-04900CAE05DD@delong.com> References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <20170331190440.GC25069@Space.Net> <95d85a60-c700-f3bc-9142-a150cc119a57@gmail.com> <022301d2aa8d$c725a750$5570f5f0$@gmail.com> <49A66D86-D916-475C-B8BC-A35111319275@thehobsons.co.uk> <6AE0263F-68C6-43C0-80E2-983F481AC575@delong.com> To: Michael H Lambert X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Mon, 03 Apr 2017 16:42:26 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 23:43:29 -0000 > On Apr 3, 2017, at 8:43 AM, Michael H Lambert wrote: >=20 >> On 2 Apr 2017, at 12:22, Owen DeLong wrote: >>=20 >> Perhaps we should break this into pieces with different mandates=E2=80=A6= >>=20 >> ... >>=20 >> Router: >> Must support Router Advertisements including=E2=80=A6 >> Ability to configure/support SLAAC >> Ability to configure/support =E2=80=9CO-bit =3D 1=E2=80=9D= stateless addressing with DHCP for other information >> Ability to configure/support =E2=80=9CM-bit =3D 1=E2=80=9D= stateful addressing using DHCP >> >>=20 >> Must support DHCP6 Relay including=E2=80=A6 >> >>=20 >> Should support DHCP6 Server including all requirements from = DHCP6 Server below. >=20 > I'm just considering this last line without prejudice for or against = the merits of RA/SLAAC, DHCPv6, etc. I would argue for MAY, not SHOULD. = In our environment, we operate DHCPv4 servers as separate middle boxes. = If and when we deploy DHCPv6, I would expect to do the same. Any = requirements or strong suggestions that DHCPv6 servers be deployed in a = network should be from the perspective that nodes on a given network = segment have reachability to DHCPv6 services, not that routers on the = network segment provide those services. I=E2=80=99m not requiring you to use the capability on the router, I=E2=80= =99m saying that the router vendor SHOULD make it available for you to = choose whether you want to use it or not. Owen From nobody Mon Apr 3 17:07: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 DE8301293F4 for ; Mon, 3 Apr 2017 17:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 I_yh4kgwk5E9 for ; Mon, 3 Apr 2017 17:07:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5751289C3 for ; Mon, 3 Apr 2017 17:07:09 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v34066CT010470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2017 17:06:07 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> Date: Mon, 3 Apr 2017 17:06:06 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delong.com> References: <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Mon, 03 Apr 2017 17:06:08 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 00:07:13 -0000 > On Apr 3, 2017, at 5:43 AM, Alexandre Petrescu = wrote: >=20 > Le 31/03/2017 =C3=A0 20:26, Fred Baker a =C3=A9crit : > [...] >> Something that would help me, in this discussion, would be a simple >> and incontrovertible statement of what breaks, or in which >> circumstances RDNSS would be inappropriate. >=20 > Not quite a breaking statement, and more implementation aspects: > - the main OS distribution on Raspberry Pi does not implement DNS in = RA > (other such distrib does, but it's rather marginally deployed). > - I understand Windows PCs and routers at IETF dont implement DNS in > RA, but rather DNS in DHCP. >=20 > A speculative breaking statement would be: resolver address delivered = by RA overwrites the one delivered by DHCP, despite M=3D=3D1 (or = vice-versa). But never tried it :-) A network with M=3D1 and RDNSS in the RA packet is, IMHO, misconfigured = by definition, so predictable behavior should not be expected. Owen From nobody Mon Apr 3 19:02: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 2EEE61294DC for ; Mon, 3 Apr 2017 19:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hnVGE8BafA4U for ; Mon, 3 Apr 2017 19:01:47 -0700 (PDT) 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 BA82B12943E for ; Mon, 3 Apr 2017 19:01:45 -0700 (PDT) Received: from [10.0.0.194] (unknown [80.12.33.88]) (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 B5E0A80D87; Tue, 4 Apr 2017 03:53:43 +0200 (CEST) To: Fred Baker , Nick Hilliard References: <449479D7-0626-4E06-93BE-EC3B43C55145@fugue.com> <4cc067b4-b69f-61f7-a85b-3e6098e51b36@gmail.com> <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> Cc: IPv6 Ops WG From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <1f7c48ef-e109-f31b-4385-0c52860f291e@si6networks.com> Date: Tue, 4 Apr 2017 01:42:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 02:01:49 -0000 On 03/31/2017 08:26 PM, Fred Baker wrote: > > My perception has been and is that the argument between DHCP and the > RA has been driven by political considerations more than anything > else. Some operators are happy with the RA, and some strongly prefer > DHCP. Telling either one "you're wrong" seems to me an unproductive > exercise - we may as well try to tell them what routing protocols to > run, or how to lay out their networks. They do it their way, and they > don't really care what we think about it. FWIW, somehow we're saying that. At this point, we're saying "do both", and if we make RDNSS (only) a MUST, we'd be saying "do SLAAC, which is the only one that you can expect to work with all nodes". > It turns out that there are reasons to support the RA approach and > reasons to support the DHCP approach. At least part of that has to do > with the fact that the sets of information elements differ, and when > one creates a new information element in either model, it has to be > duplicated in the other to maintain parity. It seems like a lot of > work. So far we've managed to get the most important bits duplicated into SLAAC (DNS info, and current effort on duplicating DHCPv6-PD), but have not done the same to replicate essential info into DHCPv6 (namely routes). > Something that would help me, in this discussion, would be a simple > and incontrovertible statement of what breaks, One option of "what breaks" would be: "nodes will not learn a DNS server, and since nodes generally access services via names rather than literals, they would be unable to access such services" > In this, I'm trying to avoid the rat-holes this list sometimes gets > into, in which proponents of different things spend time telling each > other they are wrong without reaching a consensus conclusion (and > without deciding that a consensus conclusion isn't needed). Mandating both RDNSS and stateless DHPv6 would seem to be the most impartial option.... > I think > there is a call for a single answer here; either RDNSS MUST be > supported, making the DHCP service interesting if present but mostly > irrelevant, the alternative being that it is OK for an operator to > decide how s/he wants to run their network for themselves, and > between them and their vendors. THe only alternative that lets operators decide is to mandate both. If you don't, then an operators is forced to do *both* RDNSS and stateless DHCP to cope with Android and Windws (one failing to do stateless DHCPv6, and the other failing to do RDNSS). > If we are deciding for technical > reasons, we're on solid ground; I worry that this is simply a > shouting match between proponents of different solutions. FWIW, our I-D was and is meant to avoid such shouting, by making both RDNSS and stateless DHCPv6 -- i.e., not taking sides with either protocol, and let folks decide which one they want to use in their own networks (while supporting all systems). 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 Apr 3 19:02: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 02A9A1294DC for ; Mon, 3 Apr 2017 19:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FgY9aefSphQK for ; Mon, 3 Apr 2017 19:01:48 -0700 (PDT) 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 2094612953A for ; Mon, 3 Apr 2017 19:01:46 -0700 (PDT) Received: from [10.0.0.194] (unknown [80.12.37.28]) (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 2508F80DBC; Tue, 4 Apr 2017 03:54:00 +0200 (CEST) To: Lorenzo Colitti , Mikael Abrahamsson References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> Cc: IPv6 Ops WG From: Fernando Gont Message-ID: <53b6f1e6-0563-d763-c75e-6f0090e574fb@si6networks.com> Date: Tue, 4 Apr 2017 01:49:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 02:01:50 -0000 On 04/03/2017 11:49 AM, Lorenzo Colitti wrote: > On Mon, Apr 3, 2017 at 4:20 PM, Mikael Abrahamsson > wrote: > > What I would like to see (this is not breakage though, only > potential breakage and cause of confusion) is what a host should do > if it gets RDNSS information and potentially DNS resolver > information via DHCP. > > > Per RFC 8106, it prefers DHCP. (Assuming it supports DHCP, which it is > not required to do.) Lovely. Nice outcome in an heterogeneous network. 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 Apr 3 20:55: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 DCE111270A7 for ; Mon, 3 Apr 2017 20:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 o3SRSNF3ui_6 for ; Mon, 3 Apr 2017 20:55:30 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3A481126C26 for ; Mon, 3 Apr 2017 20:55:29 -0700 (PDT) Received: from [172.17.87.40] (wan-218-southernlightfiber.com [69.85.218.68] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v343sRoq002597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2017 20:54:28 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Owen DeLong In-Reply-To: Date: Mon, 3 Apr 2017 20:54:26 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <94AB5851-466D-4FB2-B7BB-2A6AAC661748@delong.com> References: To: Philip Homburg X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Mon, 03 Apr 2017 20:54:29 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 03:55:32 -0000 > On Apr 3, 2017, at 5:20 AM, Philip Homburg = wrote: >=20 >> Just to be clear, I don't think it's a good idea to cripple IPv6 just = so=20 >> that people can make it look like IPv4 to suit their current = operational=20 >> practices. >=20 > I find 'cripple' a very odd choice in this context. >=20 > In my experience, IPv4 networks that have plenty of public IPv4 > addresses can work very well. There is absolutely no evidence that = using the > same techniques for IPv6 would cripple IPv6. >=20 > RA/SLAAC/RDNSS offer some benefits that are hard to realize with DHCP. > However, looking at the history of RA/SLAAC/RDNSS we can also see an = endless > number of RFCs that try to correct various mistakes that were made = initially. And there are no such RFCs for DHCPv4? I think not=E2=80=A6 Especially = if you consider that it started from BOOTP. Any new protocol is bound to have some corrective and at least a few = expansive RFCs to add features and/or correct errors. > In some networks, RA/SLAAC/RDNSS works really well and can do things = you > can't do with DHCP. In other networks, forcing people to deploy=20 > RA/SLAAC/RDNSS is hugely disruptive and brings no benefits because = those > networks are designed for DHCP. I think the term =E2=80=9Chugely disruptive=E2=80=9D is a bit of an = overstatement. First, nobody is forced to deploy SLAAC or RDNSS and nobody is proposing = that they should. What is being proposed is that the implementation of RDNSS in routers = and hosts be mandatory so that if an operator chooses, they are available options. This is = different from deployment which would happen as a result of the operator choice. Second, being forced to deploy RA is not particularly disruptive at all. = It comes built-in to almost every platform out there and an M=3D1, O=3D1, A=3D0 RA takes very little = configuration on the router to achieve. (which is all you need to do DHCP) > As far as I can tell, none of the two options is inherently better. = Both=20 > have their own strengths and weaknesses. On this, I completely agree, hence my pushing for both to be MTI and let = the operator decide what fits the needs in his/her particular situation. Owen From nobody Tue Apr 4 00:47: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 365A7129573 for ; Tue, 4 Apr 2017 00:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 M5eqysU6degp for ; Tue, 4 Apr 2017 00:47:07 -0700 (PDT) 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 7F44D129405 for ; Tue, 4 Apr 2017 00:47:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvJB7-0000GIC; Tue, 4 Apr 2017 09:47:01 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> In-reply-to: Your message of "Mon, 3 Apr 2017 16:27:31 -0700 ." Date: Tue, 04 Apr 2017 09:47:00 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 07:47:09 -0000 > I think allowing incompatible subsets of the two mechanisms is the > mistake. Requiring the overhead of DHCP just to provide DNS server > information was a mistake and the original demand for RDNSS is > sufficient proof of that that I dont feel the need to expand further. And this line of thinking let to RFC 7710 (captive portals) defining a RA option next to the DHCPv6 option. Does that make sense? Why not set the 'O' bit and let the host do a DHCP lookup. It does make sense if, as a vendor, you refuse to support DHCP. In a few years, no doubt we are going to a see a NTP option in RA. Just this last bit of missing information. Why require the overhead of DHCP for that? And somewhere, somebody is probably trying to do PXE boot using RAs. From nobody Tue Apr 4 01:01: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 94ADD12946C for ; Tue, 4 Apr 2017 01:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 SE3L0G1dncmG for ; Tue, 4 Apr 2017 01:01:48 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 F0352127097 for ; Tue, 4 Apr 2017 01:01:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v3481dBn102844; Tue, 4 Apr 2017 10:01:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4EBF4203437; Tue, 4 Apr 2017 10:01:39 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 41AC5203199; Tue, 4 Apr 2017 10:01:39 +0200 (CEST) Received: from [132.166.84.200] ([132.166.84.200]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v3481coT032205; Tue, 4 Apr 2017 10:01:39 +0200 To: Owen DeLong References: <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delong.com> Cc: v6ops@ietf.org From: Alexandre Petrescu Message-ID: <95816c5e-fcb1-c510-9f4c-ea2d29be4a18@gmail.com> Date: Tue, 4 Apr 2017 10:01:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 08:01:50 -0000 Le 04/04/2017 à 02:06, Owen DeLong a écrit : > >> On Apr 3, 2017, at 5:43 AM, Alexandre Petrescu >> wrote: >> >> Le 31/03/2017 à 20:26, Fred Baker a écrit : [...] >>> Something that would help me, in this discussion, would be a >>> simple and incontrovertible statement of what breaks, or in >>> which circumstances RDNSS would be inappropriate. >> >> Not quite a breaking statement, and more implementation aspects: - >> the main OS distribution on Raspberry Pi does not implement DNS in >> RA (other such distrib does, but it's rather marginally deployed). >> - I understand Windows PCs and routers at IETF dont implement DNS >> in RA, but rather DNS in DHCP. >> >> A speculative breaking statement would be: resolver address >> delivered by RA overwrites the one delivered by DHCP, despite M==1 >> (or vice-versa). But never tried it :-) > > A network with M=1 and RDNSS in the RA packet is, IMHO, misconfigured > by definition, so predictable behavior should not be expected. So, if I put RDNSS in RA then I can not deliver an address with DHCP? Sounds strange too. Alex > > Owen > > From nobody Tue Apr 4 01:55: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 ABB83127058 for ; Tue, 4 Apr 2017 01:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKSzRFCEKjoy for ; Tue, 4 Apr 2017 01:55:03 -0700 (PDT) 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 A0F171273B1 for ; Tue, 4 Apr 2017 01:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491296101; bh=25u+2CJDkgX7CskDVctgkZE4ydsgK5SjBPcOZrCgN2A=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=Htf1iCE2tj9FX3rkouVqB6t2bYjHYC7U0hCwn4Txasx3ItEV7So7STPtL8xtWjoQ7MViUgofDePzDripFYAkQ10PEdOCpwX4s8/lOAuOgE2m7j+It7+DNgpWRALMkOO/5SkSj/+pJ9VSicKD4dz9EPDl5/jxhjDq2yiGuMHbk0Y= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0242.outbound.protection.outlook.com [213.199.154.242]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-72-g3C-CmY8OYKcfzXW2QDAYg-1; Tue, 04 Apr 2017 09:54:57 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 08:54:56 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Tue, 4 Apr 2017 08:54:56 +0000 From: Tim Chown To: Mikael Abrahamsson CC: Philip Homburg , "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGuSN8AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ICAAA0U4IAADhwAgAEOBoA= Date: Tue, 4 Apr 2017 08:54:56 +0000 Message-ID: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> 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-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:bzd/6zqgtQDEbmHNnpyAFHk5SydBqArCu3OynWaMplnGt3ytHQJe+DlN2Lwls7MkrNgMVxQq/UYFZ5cQuAfhL59qK4uUkbNPkYhk0TUXHSgM5oh9TRwyayplT/IwVUb8w9A7PGK2Bo5Nbrp3QF4nKpVlNRZucz0QJdvKL1qOhgiYWk5/xndhj4wRzZE0dowLMP48b8B5X8C9qNFBZWyKzrlbrJaR1MPNDAWp/5SeM75pa/VE4QB0waUjXegUVEtZr++zi3K23udL2F8xcCv5xT9F0urdRFV0nTsvSLhjumKTM5cQiwazWisyZeUiPpZ5Zr6t3R0VLrUjlk2mbRiGWQ==; 20:Vc87Ked0EQwHzF2mB/ebFGFLGKsUjfDNvNxIBSDY25BYrmsG6BbXQyPkB4YxwsaKY3l4qbw1Y9ODi+IO4ey5ZFPlQoJ+OerrY3CSy3ZZ7Ne0qU5Do3i1Yv+PjsH0GYP0oZgDSCEib7ARF983F1wPAVvLprRoCnB2J36/HWiYzm8= x-ms-office365-filtering-correlation-id: 2cce87e1-aaaa-4134-5470-08d47b38447b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39840400002)(39450400003)(24454002)(53546009)(25786009)(8676002)(81166006)(189998001)(50226002)(83716003)(6246003)(82746002)(2950100002)(50986999)(74482002)(6916009)(76176999)(42882006)(7906003)(33656002)(53936002)(7736002)(93886004)(8936002)(2900100001)(57306001)(4326008)(66066001)(2906002)(110136004)(38730400002)(3280700002)(3660700001)(36756003)(6306002)(5250100002)(99286003)(229853002)(3846002)(5660300001)(236005)(6436002)(54896002)(6512007)(6506006)(606005)(102836003)(6486002)(86362001)(54906002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 08:54:56.2429 (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: g3C-CmY8OYKcfzXW2QDAYg-1 Content-Type: multipart/alternative; boundary="_000_DBB85084EA1E49099E5E34C835B201C0jiscacuk_" Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 08:55:07 -0000 --_000_DBB85084EA1E49099E5E34C835B201C0jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gMyBBcHIgMjAxNywgYXQgMTc6NDgsIE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtlQHN3bS5w cC5zZTxtYWlsdG86c3dtaWtlQHN3bS5wcC5zZT4+IHdyb3RlOg0KDQpXaGVuZXZlciBJIGFzayB0 byBleHRlbmQgTkQgb3IgcHV0IG5ldyB0aGluZ3MgaW50byBSQSwgSSBnZXQgbG90cyBvZiBwdXNo YmFjay4gQSBsb3QgbW9yZSBwdXNoYmFjayB0aGFuIHdoZW4gSSB3YW50IGEgbmV3IERIQ1Agb3B0 aW9uIGZvciBzb21ldGhpbmcgdGhhdCByZWxhdGVzIHRvIGluZm9ybWF0aW9uIGZvciB0aGUgZGV2 aWNlLg0KDQpZZXQgd2UgaGF2ZSBSRkM3NzEwIGFzIHJlY2VudGx5IGFzIERlY2VtYmVyIDIwMTUs IHdoaWNoIGFsbG93cyBhbnkgVVJJIHRvIGJlIHBsdWdnZWQgaW50byBhbiBSQSAtIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzEwI3NlY3Rpb24tMi4zLiAgSSB3YXMgcHJldHR5IHN1 cnByaXNlZCB0aGlzIG9uZSBnb3QgYWRvcHRlZC4NCg0KVGhlIG9ubHkgbWFqb3IgcHVzaGJhY2sg dGhhdCBJIGhhdmUgc2VlbiB0byBwdXQgaW50byBESENQdjYgaXMgdGhlIGRlZmF1bHQgcm91dGVy IG9wdGlvbiBmb3IgREhDUHY2LCBiZWNhdXNlIGlmIHdlIGFsbG93IHRoYXQgdGhlbiBJIHdvdWxk IHNheSB0aGF0IHRoZXJlIGFyZSBsb3RzIG9mIG90aGVyIG9wdGlvbnMgaW4gUkEgbm90IGN1cnJl bnRseSBhdmFpbGFibGUgaW4gREhDUHY2IHRoYXQgSSB3b3VsZCBiYXNpY2FsbHkgc2F5IHNob3Vs ZCBiZSBNVEkuIFRoZXNlIGFyZSBmb3IgaW5zdGFuY2UgTVRVLCBQSU9zIHdpdGggbGlmZXRpbWVz IGV0Yy4NCg0KSGF2ZSB5b3UgcmVhZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZHJvbXMtZGhjLWRoY3B2Ni1kZWZhdWx0LXJvdXRlci0wMCA/ICBUaGlzIHdhcyB3cml0dGVuIGJ5 IFJhbHBoIGluIDIwMDksIGJ1dCBlbmNvdW50ZXJlZCByb3VnaCBzZWFzIHNvb24gYWZ0ZXIgc2Fp bGluZyBmcm9tIHBvcnQuIEJ1dCB0aGVyZSB3YXMgbm8gc2hvcnRhZ2Ugb2YgcGVvcGxlIG9uIHRo YXQgYm9hdC4NCg0KSSB0aGluayBzYXlpbmcgZXZlcnl0aGluZyBzaG91bGQgYmUgY29uZmlndXJh YmxlIHVzaW5nIERIQ1AgaXMgc2hvcnQtc2lnaHRlZCBhbmQgcmVtb3ZlcyBhIGxvdCBvZiB0aGUg bmV3IGZ1bmN0aW9uYWxpdHkgdGhhdCBJUHY2IGFjdHVhbGx5IHN1cHBvcnRzIGluIGN1cnJlbnQg aW5jYXJuYXRpb24sIHRoYXQgSVB2NCBjdXJyZW50bHkgZG9lc27igJl0Lg0KDQpUaGVyZSBhcmUg Y2VydGFpbmx5IHRlY2huaWNhbCBtZXJpdHMgdG8gdGhlIFJBLWJhc2VkIGFwcHJvYWNoLg0KDQpU aW0NCg0K --_000_DBB85084EA1E49099E5E34C835B201C0jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <9DA14F59F873314AA3BDB5EF7638620D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAzIEFwciAyMDE3LCBhdCAxNzo0 OCwgTWlrYWVsIEFicmFoYW1zc29uICZsdDs8YSBocmVmPSJtYWlsdG86c3dtaWtlQHN3bS5wcC5z ZSIgY2xhc3M9IiI+c3dtaWtlQHN3bS5wcC5zZTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KV2hlbmV2ZXIgSSBhc2sgdG8g ZXh0ZW5kIE5EIG9yIHB1dCBuZXcgdGhpbmdzIGludG8gUkEsIEkgZ2V0IGxvdHMgb2YgcHVzaGJh Y2suIEEgbG90IG1vcmUgcHVzaGJhY2sgdGhhbiB3aGVuIEkgd2FudCBhIG5ldyBESENQIG9wdGlv biBmb3Igc29tZXRoaW5nIHRoYXQgcmVsYXRlcyB0byBpbmZvcm1hdGlvbiBmb3IgdGhlIGRldmlj ZS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCllldCB3ZSBoYXZlIFJGQzc3MTAgYXMgcmVjZW50bHkgYXMgRGVj ZW1iZXIgMjAxNSwgd2hpY2ggYWxsb3dzIGFueSBVUkkgdG8gYmUgcGx1Z2dlZCBpbnRvIGFuIFJB IC0mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzcxMCNzZWN0 aW9uLTIuMyIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3MTAjc2Vj dGlvbi0yLjM8L2E+LiAmbmJzcDtJIHdhcyBwcmV0dHkgc3VycHJpc2VkIHRoaXMgb25lIGdvdCBh ZG9wdGVkLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlRoZSBvbmx5IG1ham9y IHB1c2hiYWNrIHRoYXQgSSBoYXZlIHNlZW4gdG8gcHV0IGludG8gREhDUHY2IGlzIHRoZSBkZWZh dWx0IHJvdXRlciBvcHRpb24gZm9yIERIQ1B2NiwgYmVjYXVzZSBpZiB3ZSBhbGxvdyB0aGF0IHRo ZW4gSSB3b3VsZCBzYXkgdGhhdCB0aGVyZSBhcmUgbG90cyBvZiBvdGhlciBvcHRpb25zIGluIFJB IG5vdCBjdXJyZW50bHkgYXZhaWxhYmxlIGluIERIQ1B2NiB0aGF0IEkgd291bGQgYmFzaWNhbGx5 DQogc2F5IHNob3VsZCBiZSBNVEkuIFRoZXNlIGFyZSBmb3IgaW5zdGFuY2UgTVRVLCBQSU9zIHdp dGggbGlmZXRpbWVzIGV0Yy48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkhhdmUgeW91IHJlYWQmbmJzcDs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHJvbXMtZGhjLWRoY3B2Ni1k ZWZhdWx0LXJvdXRlci0wMCIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWRyb21zLWRoYy1kaGNwdjYtZGVmYXVsdC1yb3V0ZXItMDA8L2E+Jm5ic3A7PyAmbmJzcDtU aGlzIHdhcyB3cml0dGVuIGJ5IFJhbHBoIGluIDIwMDksIGJ1dCBlbmNvdW50ZXJlZCByb3VnaCBz ZWFzIHNvb24gYWZ0ZXIgc2FpbGluZw0KIGZyb20gcG9ydC4gQnV0IHRoZXJlIHdhcyBubyBzaG9y dGFnZSBvZiBwZW9wbGUgb24gdGhhdCBib2F0LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPkkgdGhpbmsgc2F5aW5nIGV2ZXJ5dGhpbmcgc2hvdWxkIGJlIGNvbmZpZ3VyYWJsZSB1 c2luZyBESENQIGlzIHNob3J0LXNpZ2h0ZWQgYW5kIHJlbW92ZXMgYSBsb3Qgb2YgdGhlIG5ldyBm dW5jdGlvbmFsaXR5IHRoYXQgSVB2NiBhY3R1YWxseSBzdXBwb3J0cyBpbiBjdXJyZW50IGluY2Fy bmF0aW9uLCB0aGF0IElQdjQgY3VycmVudGx5IGRvZXNu4oCZdC48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+VGhlcmUgYXJlIGNlcnRhaW5seSB0ZWNobmljYWwgbWVyaXRzIHRvIHRoZSBSQS1iYXNlZCBh cHByb2FjaC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpUaW08L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DBB85084EA1E49099E5E34C835B201C0jiscacuk_-- From nobody Tue Apr 4 02:00: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 9D2F41273B1 for ; Tue, 4 Apr 2017 02:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX9f025ICva1 for ; Tue, 4 Apr 2017 02:00:55 -0700 (PDT) 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 6F949127058 for ; Tue, 4 Apr 2017 02:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491296453; bh=NlK/5wey9oET/nfDMTxhve0rKBS9xAXd69vEPK8/ETo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HxkccddIx+Zw8uyolLrE1Wl1GW3Rfx1U2iVCuUF4dUjHfjDL3CiTWIAroJVwPi5zE+gkbqBcRwbsOXrQ5Ttvfs5jTN9fWJdW++PHs7hbKr8bHm7hAofDy8hPKPCOcGA2HKHhiyFq8h545DPlH1IvP/4vOLIaMuOzp4NiOfR5iYQ= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0180.outbound.protection.outlook.com [213.199.154.180]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-122-k1xTffTUNee-oSTE8Tfvig-1; Tue, 04 Apr 2017 10:00:42 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 09:00:40 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Tue, 4 Apr 2017 09:00:40 +0000 From: Tim Chown To: Ted Lemon CC: IPv6 Ops WG Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGuSN8AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ICAAA0U4IAADhwAgAAJQYCAAQZgAA== Date: Tue, 4 Apr 2017 09:00:40 +0000 Message-ID: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> 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-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:KTGSFJIrp9sA5EzshYMKl+qmGNDg0O7vZNEon+TtINr+B0ryCg/4W3H04pM718X7d8qlA8k0We2kPLaOC0yVNgeRDlFJyzs9xU2/T1ZmbPg7shBU2V+Wu804Hk+bFYuJk+RJ4ERIIn7BAnOeyLD1Qud1uvU3F+widOUB590n/bwPi3bOmHBeA9jqPtsDY4p+8aXhQfGDHfp1CfbeX9y76um4+/RJA2cE+DfgrZDl8bnp1kFWLy8tgsli1W7vqD9iIVQH87C84hYVooWsrrlvYst/v9WUuFXcuPZDkNy3j5WbKzQK/GOh6/Wj9ZAAC3+yg4YghruMdu+1JkUDynA0qA==; 20:gLIusRCDnUiQLRWM2mWee66pQzRYt9nUmKAayZ/wgDGDz2ukJeJBIZBCQKpiqVequdOMnZ8dsgo5mKqhbzigDjCYOxvtyjFCV+maFNKlHBoqGE7DPb4AlRPgA+FwUTHHCr0aWmvgKd68f043nkIB2sS4d5I5QDmYO0r5xGfYcKI= x-ms-office365-filtering-correlation-id: 51a8dbb1-1efa-472c-ec14-08d47b3911af x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39840400002)(39410400002)(24454002)(36756003)(2900100001)(3660700001)(3280700002)(6512007)(6116002)(189998001)(76176999)(5250100002)(8676002)(50986999)(93886004)(2906002)(8936002)(53936002)(33656002)(81166006)(50226002)(102836003)(6436002)(42882006)(2950100002)(5660300001)(6916009)(83716003)(229853002)(3846002)(74482002)(305945005)(7736002)(66066001)(99286003)(6246003)(86362001)(110136004)(57306001)(6506006)(25786009)(82746002)(38730400002)(6486002)(53546009)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <751ADF9DF45D88429D4E79656052C62A@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 09:00:40.3924 (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: k1xTffTUNee-oSTE8Tfvig-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 09:00:57 -0000 PiBPbiAzIEFwciAyMDE3LCBhdCAxODoyMSwgVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPiB3 cm90ZToNCj4gDQo+IE15IHJlYWN0aW9uIHRvIHRoaXMgbG9uZyBhbmQgdmVyeSBwcmVkaWN0YWJs ZSBoaWdoLWJhbmR3aWR0aCBiYWNrLWFuZC1mb3J0aCBpcyB0aGF0IEkgc3VzcGVjdCB0aGUgb3V0 Y29tZSB3aWxsIGJlIHRoZSBzYW1lIGFzIGl0IHdhcyBsYXN0IHRpbWU6IG5vIGFjdGlvbi4NCj4g DQo+IFRoaXMgaXMgZnJ1c3RyYXRpbmcuICAgSXQgc2VlbXMgY2xlYXIgdG8gbWUgdGhhdCByZXF1 aXJpbmcgc3VwcG9ydCBmb3IgUkROU1Mgd291bGQgaW1wcm92ZSB0aGUgc2l0dWF0aW9uLiAgIFBv c3NpYmx5IHJlcXVpcmluZyBzdXBwb3J0IGZvciBESENQdjYgd291bGQgYWxzbyBpbXByb3ZlIHRo ZSBzaXR1YXRpb24gaWYgaXQgd2VyZSBkb25lIGNvcnJlY3RseSAod2hpY2ggaXMgbm90IGEgZ2l2 ZW4pLiAgIEJ1dCB3aGVuZXZlciBhbnlib2R5IHByb3Bvc2VzIHJlcXVpcmluZyBSRE5TUywgd2Ug Z2V0IHRoaXMgZGVtYW5kIGZvciBwYXJpdHksIGFuZCB0aGVuIGEgZ2lhbnQgZXhwbG9zaW9uIG9m IG9waW5pb25zLCBhbmQgdGhlbiBubyBhY3Rpb24uDQo+IA0KPiBFc3NlbnRpYWxseSB3aGF0IEkg c2VlIGhlcmUgaXMgYSB2aWFibGUgc29sdXRpb24gYmVpbmcgaGVsZCBob3N0YWdlIHRvIGRlbWFu ZHMgZm9yIGEgY29udHJvdmVyc2lhbCBzb2x1dGlvbi4gICBJdCBtYXkgYmUgdGhhdCB0aGUgY29u dHJvdmVyc3kgaXNuJ3QgdmFsaWQsIGFuZCB0aGF0IHJlYWxseSByZXF1aXJpbmcgREhDUHY2IGlz IHRoZSByaWdodCB0aGluZyB0byBkby4gICBCdXQgdGhlIGNvbnRyb3ZlcnN5IGV4aXN0cywgYW5k IG1ha2VzIHJlcXVpcmluZyBESENQdjYgcHJvYmxlbWF0aWMuDQo+IA0KPiBJIGRvbid0IHNlZSBh bnkganVzdGlmaWNhdGlvbiBmb3IgYSB0ZWNobmljYWwgb2JqZWN0aW9uIHRvIFJETlNTLiAgIFNv IG15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCBkZXNwaXRlIHRoZSBsb3VkIHByb3Rlc3RzIHRv IHRoZSBjb250cmFyeSwgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHJlcXVpcmUgUkROU1MuICAgSXQg bWF5IGFsc28gYmUgdGhlIGNhc2UgdGhhdCB0aGVyZSBpcyBjb25zZW5zdXMgdG8gcmVxdWlyZSBE SENQdjYsIG9uIHRoZSBzYW1lIGJhc2lzLiAgIEhvd2V2ZXIsIHRoYXQgd291bGQgcmVxdWlyZSBh IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHdoYXQgInJlcXVpcmUgREhDUHY2IiBhY3R1YWxseSBt ZWFucy4NCj4gDQo+IEl0IGlzIG9mIGNvdXJzZSBlbnRpcmVseSBwb3NzaWJsZSB0aGF0IHRoZSBk b2N1bWVudCBhdXRob3JzIGFyZSBqdXN0IHBsb3R6aW5nIGF0IHRoaXMgZGlzY3Vzc2lvbiwgb3Ig cGVyaGFwcyBoYXZlIGNob3NlbiB0byBpZ25vcmUgaXQsIHNpbmNlIHRoZSBkb2N1bWVudCBpc24n dCBleHBsaWNpdGx5IG1lbnRpb25lZCBhbnl3aGVyZSBpbiB0aGUgdGhyZWFkLiAgIEl0IHdvdWxk IGJlIHZhbGlkIGZvciB0aGVtIHRvIHNheSB0aGF0IHRoaXMgaXMgc2ltcGx5IG5vdCBhbiBvcHBv cnR1bml0eSB0byByZS1vcGVuIHRoaXMgaXNzdWUuICAgSG93ZXZlciwgdGhlIHNlY3Rpb24gaW4g dGhlIGRvY3VtZW50IG9uIFplcm8gVG91Y2ggQ29uZmlndXJhdGlvbiBjZXJ0YWlubHkgbG9va3Mg bGlrZSBhIGdvb2QgcGxhY2UgdG8gaW5zZXJ0IGEgcmVxdWlyZW1lbnQuDQo+IA0KPiBNeSBwZXJz b25hbCBwcmVmZXJlbmNlIHdvdWxkIGJlIHRoYXQgaWYgdGhlcmUgaXMgYW55IHNlcmlvdXMgZGVz aXJlIGZvciBESENQdjYgdG8gYmUgcmVxdWlyZWQsIHRoYXQgdGhlIHByb3BvbmVudHMgb2YgdGhp cyByZXF1aXJlbWVudCB3cml0ZSB1cCBpbiBhIGRvY3VtZW50IHdoYXQgdGhhdCBzdXBwb3J0IGxv b2tzIGxpa2UuICAgSSBkb24ndCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBkbyB0aGF0IGluIHRo aXMgZG9jdW1lbnQuICAgSSB0aGluayBpdCBkb2VzIG1ha2Ugc2Vuc2UgdG8gcmVxdWlyZSBSRE5T UyBpbiB0aGlzIGRvY3VtZW50LCBiZWNhdXNlIEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBhbnkgcXVl c3Rpb24gYXMgdG8gd2hhdCB0aGF0IGxvb2tzIGxpa2UuDQo+IA0KPiBJIHJlYWxpemUgdGhhdCBo b2xkaW5nIHRoYXQgaG9zdGFnZSBwcm9iYWJseSBsb29rcyBsaWtlIGEgZ3JlYXQgd2F5IGZvciBw cm9wb25lbnRzIG9mIERIQ1B2NiBzdXBwb3J0IHRvIGdldCB0aGVpciB3YXksIGJ1dCBJIGRvbid0 IHRoaW5rIHRoYXQncyB3aGF0IHdvdWxkIGhhcHBlbjogd2hhdCB3b3VsZCBoYXBwZW4gd291bGQg YmUgdGhhdCB0aGUgYXV0aG9ycyBvZiB0aGUgZG9jdW1lbnQgd291bGQgc2F5IG5vdGhpbmcgYXQg YWxsIG9uIHRoaXMgdG9waWMuICAgU28gdGhhdCdzIHlvdXIgY2hvaWNlOiBpbXByb3ZlIHRoZSBz aXR1YXRpb24sIGJ1dCBkb24ndCBnZXQgZXZlcnl0aGluZyB5b3Ugd2FudCwgb3IgZ2V0IG5vdGhp bmcuICAgRm9yIHRob3NlIHdobyBkbyBub3Qgd2FudCBSRE5TUywgb2YgY291cnNlLCB0aGUgc2Nv cmNoZWQgZWFydGggYXBwcm9hY2ggd2lsbCBiZSBmaW5lLCBidXQgZm9yIHRoZSByZXN0IG9mIHVz IEkgdGhpbmsgaXQncyBub3QgZmluZS4NCg0KDQpUZWQsIEkgZG9u4oCZdCBkaXNhZ3JlZTsgd2hp bGUgdGhlcmUgYXJlIHNvbWUgdmVyeSBnb29kIHBvaW50cyBtYWRlIG9uIGJvdGggInNpZGVz4oCd LCBhIOKAnG5vIGFjdGlvbuKAnSBvdXRjb21lIGRvZXNu4oCZdCBtb3ZlIHVzIGZvcndhcmQuDQoN CkEgcmVtaW5kZXIgdGhhdCDigJxtYWtlIHN1cHBvcnQgZm9yIFJETlNTIGEgTVVTVOKAnSBpcyBh biBvcGVuIGlzc3VlIGluIFJGQzY0MzQtYmlzIChkcmFmdC1jbHctcmZjNjQzNC1iaXMtMDEpLCBh cyB3ZWxsIGFzIHRoZSBSZXF1aXJlbWVudHMgZm9yIElQdjYgUm91dGVycyBkcmFmdCAoZHJhZnQt YWxpLWlwdjZydHItcmVxcy0wMikuIA0KDQpUaW0= From nobody Tue Apr 4 02:25:29 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 839E1129642 for ; Tue, 4 Apr 2017 02:25:26 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bbNNmzwLP3S0 for ; Tue, 4 Apr 2017 02:25:24 -0700 (PDT) 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 EEE0A127201 for ; Tue, 4 Apr 2017 02:25:23 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CECFEA2; Tue, 4 Apr 2017 11:25:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491297921; bh=hfgiK1CaTYTcJqmyMuyk3jhieggSZToXrqLLfzUBb9s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nT4Fy+lLtm46djS0VnwmTjAkgf2YUfr8j2A8oMIsrbDqolEhq+lABoHPUlwijZmvc b7I/yGTuMisA4Y27C1SCc0rS6RV9Y9BHoqjsqbQriMCJtwA0WEnBZU2r/TpyKVKd2e q/kqmrZ0vif4AO8pw9HEsMWrKX0rDFLa3SlLNP3c= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C964B88; Tue, 4 Apr 2017 11:25:21 +0200 (CEST) Date: Tue, 4 Apr 2017 11:25:21 +0200 (CEST) From: Mikael Abrahamsson To: Tim Chown cc: "v6ops@ietf.org" In-Reply-To: Message-ID: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 09:25:27 -0000 On Tue, 4 Apr 2017, Tim Chown wrote: > Yet we have RFC7710 as recently as December 2015, which allows any URI > to be plugged into an RA - > https://tools.ietf.org/html/rfc7710#section-2.3. I was pretty surprised > this one got adopted. I have raised that in 6MAN, and my hope is that it won't happen again the way it did. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 4 05:44: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 7D5511272E1 for ; Tue, 4 Apr 2017 05:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_horHWuoFvQ for ; Tue, 4 Apr 2017 05:44:24 -0700 (PDT) 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 15A6A127735 for ; Tue, 4 Apr 2017 05:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491309862; bh=NN9+G+AFVe1pApdzlm7W+jQbk9iewYZCJlf7eHpQChs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P9NgS3cJWYlVcISSGlfl2SVbULIgF1dRsZeabXggHHwRHT1xChewKC3L/cHZL4v5bEudZOZzQlR9BxxQjFsaVCXdnNm/8/KJGSi0w91WCMz+aj4FzfYM4t8Zz0g+44d44r3kZtL+wZYZP73xA4ez0FhC//czsJVN2B7Jf+oppm8= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0246.outbound.protection.outlook.com [213.199.154.246]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-96-ReNwQQg8P0mlFHFavC6W6A-1; Tue, 04 Apr 2017 13:44:17 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 12:44:15 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Tue, 4 Apr 2017 12:44:15 +0000 From: Tim Chown To: Russ White <7riw77@gmail.com> CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 Thread-Index: AQHSqLu/JAUmSx69OkO5wODN0Nb9M6GtflIAgAeyigA= Date: Tue, 4 Apr 2017 12:44:15 +0000 Message-ID: <27A33147-2E96-438E-967C-C9A69B1F1AE6@jisc.ac.uk> References: <01e701d2a967$e6021ef0$b2065cd0$@gmail.com> In-Reply-To: <01e701d2a967$e6021ef0$b2065cd0$@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-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:4OE4cwMJWINpjWNd1YVFtoDhNwNF5f5dFZYtA0IY+PXfi9bwULzOmyS/mIdX5qyGNPSJ8/GDc/t1k2NFL2BYVpHb+Uog8PBNyCTm748Q6jtLz5zh2pXLxjgF4HIOPMQ9dnsnKgHIDn7vW7EK0pciqtM+4PwNGTb0kGGvcJXYm7Foi6vqTISkGcYjnYi9nwYjyB1pfs45YA+w/XIlbvqNF3AEydLa/uFRGEaUTbT33ilepmK3Tg9KNOnHwt8CUgR9N/rsJrXoHdG9icf+XSEdh94KnyU63ZbYW/C3y+t18lXYF4pAQ7rGv6uXTvYK3HnWutNijtB9ldUABG6zFob3SA==; 20:A3PCm/Seum57MGcoiSbswI9wnuSFa2efbepJkZImbRhZYBr3O8NEqUQC1JKRCaFBMTH9mChjiv8lwYN+GU4MTIBbxGLDFkpcXAOuJyh3Muk23F7T5Q6XnRPHDccpG9zbDfgUn6nPRBzOwK6Ruv2OpKiqBBJLb7iup8dJLN035nY= x-ms-office365-filtering-correlation-id: b5c69b1c-9465-48e4-46a8-08d47b584dce x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39840400002)(39410400002)(24454002)(102836003)(3846002)(2950100002)(6116002)(42882006)(6916009)(305945005)(7736002)(82746002)(6436002)(3660700001)(2906002)(5250100002)(2900100001)(6486002)(6506006)(74482002)(230783001)(50986999)(76176999)(99286003)(8936002)(66066001)(53546009)(83716003)(6512007)(189998001)(86362001)(6246003)(57306001)(110136004)(1411001)(38730400002)(25786009)(50226002)(97736004)(36756003)(4326008)(8676002)(53936002)(81166006)(229853002)(33656002)(5660300001)(39060400002)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 12:44:15.7043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: ReNwQQg8P0mlFHFavC6W6A-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:44:26 -0000 SGksDQoNCj4gT24gMzAgTWFyIDIwMTcsIGF0IDE2OjExLCBSdXNzIFdoaXRlIDw3cml3NzdAZ21h aWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPj4gT3ZlcmFsbCwgYSB2ZXJ5IG5pY2VseSB3cml0dGVu IGRvY3VtZW50LiBUaGUgaW50cm8gc2VjdGlvbnMgYXJlIHBhcnRpY3VsYXJseQ0KPj4gZ29vZCB0 byByZWFkLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4+IEkgc3VnZ2VzdCBhZGRpbmcgc2VjdGlvbnMg aW4gdGhlIGRyYWZ0IG9uOg0KPj4gYSkgTUxEdjIgLSBwZXJzb25hbGx5IEnigJlkIGxpa2UgdG8g c2VlIGEgTVVTVCBmb3IgTUxEdjIgc3VwcG9ydA0KPj4gYikgUkZDODEwNiBzdXBwb3J0IC0gbWFr ZSBSRE5TUyBvcHRpb24gc3VwcG9ydCBpbiBSQXMgYSBNVVNUDQo+IA0KPiBJIHdpbGwgdGFrZSBh IGxvb2sgYXQgdGhlc2UgLS0gSSB0aGluayB0aGV5IHdvdWxkIGJlIGdvb2QgdG8gYWRkLCBqdXN0 IGhhdmUgdG8gc2NhcmUgdXAgc29tZSB0ZXh0IGFyb3VuZCB0aGVtLg0KDQpJbiA2bWFuLCB0aGVy ZSB3YXMgc3VwcG9ydCBmb3IgTUxEdjIgYmVpbmcgYSBNVVNUIChub3RpbmcgdGhlIGlzc3VlcyBj YXVzZWQgYnkgYSBzaW5nbGUgTUxEdjEtb25seSBob3N0IG9uIGEgc3VibmV0KS4NCg0KQnV0IHlv deKAmXZlIHNlZW4gdGhlIDE0MCAoYW5kIGNvdW50aW5nKSBlbWFpbHMgb24gUkROU1MgYW5kIFJB cyBpbiB2Nm9wcyA6KSAgV2hhdGV2ZXIgY29tZXMgb2YgdGhhdCwgd2Ugc2hvdWxkIGJlIGNvbnNp c3RlbnQgaW4gdGhlIHR3byBkcmFmdHMgd2XigJlyZSBlZGl0aW5nLg0KDQo+PiBBbmQgYWxzbyBy ZXZpZXcgdGhlIHdvcmRpbmcgb24gU0xBQUMgaW4gU2VjdGlvbiAzLjMuDQo+PiBhKSBDaGFuZ2Ug U0xBQUMgYmVpbmcgZW5hYmxlZCBieSBkZWZhdWx0IGZyb20gYSBTSE9VTEQgdG8gYSBNVVNUDQo+ IA0KPiBUaGlzIGlzIG1vc3RseSBhIHJlc3VsdCBvZiBteSBub3Qga25vd2luZyB3aGF0IHRvIGRv IGhlcmUsIHNvIEkgd2VudCB3aXRoIHRoZSAiZ2VudGxlciIgcmVxdWlyZW1lbnQuIEknbSBoYXBw aWVyIHdpdGggTVVTVCBoZXJlIGlmIHRoZSBjb21tdW5pdHkgYWdyZWVzLg0KDQpJIHRoaW5rIHRo ZXJlIGhhdmUgYmVlbiBhIGNvdXBsZSBvZiBvdGhlciBzdXBwb3J0aW5nIGNvbW1lbnRzIG9uIHRo aXMuIEkgZ3Vlc3MgaWYgeW91IGNoYW5nZSBpdCB5b3XigJlsbCBmaW5kIG91dCB3aG8gc3F1ZWFs cy4NCg0KPj4gYikgUHJvYmFibHkgZ29vZCB0byBkaXN0aW5ndWlzaCBTTEFBQyBmb3IgTExzIGFu ZCBTTEFBQyBmb3IgZ2xvYmFsczsgUkZDNjQzNA0KPj4gc2F5cyByb3V0ZXJzIE1VU1QgYmUgYWJs ZSB0byBnZW5lcmF0ZSBMTCBhZGRyZXNzZXM7IHRoZSBkcmFmdCBjdXJyZW50bHkgb25seQ0KPj4g c2F5cyBTSE9VTEQ7IEnigJlkIG1ha2UgdGhhdCBhIE1VU1QuDQo+IA0KPiBPa2F5Lg0KPiANCj4+ IGMpIFJGQzQ4NjIgc2F5cyBEQUQgaXMgYSBNVVNULCBpbiB0aGUgZHJhZnQgaXTigJlzIGN1cnJl bnRseSBvbmx5IGEgU0hPVUxEOyBpcw0KPj4gdGhlcmUgYSByZWFzb24gZm9yIGl0IG5vdCB0byBi ZSBhIE1VU1Q/DQo+IA0KPiBOb3BlIC0tIGFnYWluLCBJJ20ganVzdCBzb21ldGltZXMgb3ZlcmNh dXRpb3VzLiBJIGNhbiBjaGFuZ2UgdGhpcyB0byBhIE1VU1QuDQoNCkl0IHdvdWxkIGJlIGdvb2Qg dG8gYmUgY29tcGxpYW50IHdpdGggUkZDNDg2MiwgdW5sZXNzIHRoZXJl4oCZcyBhIGdvb2QgcmVh c29uIG5vdCB0byBiZS4NCg0KPj4gVGhlIG9ubHkgc2lnbmlmaWNhbnQg4oCcY2xhc2jigJ0gd2l0 aCBSRkM2NDM0LWJpcyAod2hpY2ggaXMgaW4gNm5ldCB0b21vcnJvdykgaXMNCj4+IHRoZSBzZWN0 aW9uIDMgdGV4dDsgdGhlIHJlc3Qgc3luY3MgcHJldHR5IHdlbGwgYXMgaXQgaXMsIHdoaWNoIGlz IGdvb2QgbmV3cy4NCj4gDQo+IEknbGwgdGFrZSBhIGxvb2sgYXQgdGhpcyB0byBzZWUgd2hlcmUg d2UgbWlnaHQgY2xhc2gsIGFuZCB0cnkgdG8gZ2V0IHRob3NlIGJpdHMgd29ya2VkIG91dC4NCg0K T3ZlcmFsbCwgdGhlcmXigJlzIG1pbmltYWwgb3ZlcmxhcCAtIG1haW5seSBzZWN0aW9uIDMgYXMg YWJvdmUuDQoNClRpbQ0KDQo+IA0KPiDwn5iKIC9yDQo+IA0KDQo= From nobody Tue Apr 4 05:55: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 7D8CE1295EB for ; Tue, 4 Apr 2017 05:55:49 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 TvBDTcQslDtr for ; Tue, 4 Apr 2017 05:55:47 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 7521C1294A3 for ; Tue, 4 Apr 2017 05:55:47 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id s68so173492515vke.3 for ; Tue, 04 Apr 2017 05:55:47 -0700 (PDT) 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=8+u4RFmj0eAWd87aROpBzd6wSkAW39AuRy6JgMVBVKY=; b=NNFP09Nu1o5MQQi8KkD6C89jSRs6rgo2Bti85WVJIBO4DWxqQniO+rHZY2x7KgUHTY zFW8BsQD271pqlV3gzq2TyNIjQgyYx0dhd4eFSCw++Uk8Tb8c6hdTG9QyGgPQeWRBL5l iQM4C2TmtzvDzEg1rB0NXn9UzVsXZk/E/Z+VtrutRrQ0qHFw/0bfLOVtoOAHXSmp6uDn OdlJ2e0BmP3dIlxwZWm1th+cEIyAFtKSxh554D4IMqmDP9mh6m3iz4gZgrx8LuIf/RbB yp4NgdiXHFD3iwB3HYM+2f7UaM5y+0ue/eWYVyFBTbseYVcA6NHJI3vStGJO06cVV2IA 2u/A== 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=8+u4RFmj0eAWd87aROpBzd6wSkAW39AuRy6JgMVBVKY=; b=TPupT271h54c5v1yQtmPwAyQBIkP2zEUCU0GQR1FWUuLUaZkivZbB3pxnd1cukjgnd iEQsPZNl6HkLxLiuF6yq7zw8mFQ3p3/rN/gavGw4aFva34TTfODqb7OkN+plr5JHq79V 72mStHZ1aiWT0RmqcYs/JashBq/q0VtBgukgnEoOYw5D3y8WqBkhwRd+KaU9iEbr2zGM Juv33rK3Ut0ZEC+Iac8RnHvG/FJEue96Bw5orQQ/40+1KAUcgH67y84VmXluO0Pmp5fg jv7coZqI6fmCIHfoG167FV1MliMfnyDevnZxGwjRS6tIBHDqENn46O479jjAIQAxWNyE u1bg== X-Gm-Message-State: AFeK/H2826VqNkq/PLoBq/OrkuXrlUOnNmZEa6iX2UvnAOkmbA9SihavXMyO1rYZ1GD5Fv1Fn3VNjbbASAl6uYan X-Received: by 10.31.60.17 with SMTP id j17mr6313700vka.45.1491310546164; Tue, 04 Apr 2017 05:55:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Tue, 4 Apr 2017 05:55:25 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> From: Lorenzo Colitti Date: Tue, 4 Apr 2017 21:55:25 +0900 Message-ID: To: Ted Lemon Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11436e505b521f054c56cbce Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:55:49 -0000 --001a11436e505b521f054c56cbce Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 2:21 AM, Ted Lemon wrote: > This is frustrating. It seems clear to me that requiring support for > RDNSS would improve the situation. +1 As a reminder: the original question in this thread was very simple: do we have rough consensus to say that hosts MUST implement RDNSS? Given the strong opposition from major host OS developers, and others on this thread such as Barbara and James, I really don't see us getting to consensus that hosts MUST implement DHCPv6. Therefore, in practice there are only two feasible options: 1. Don't say anything, and have no mandatory mechanism that operators can rely on. Some network/device combinations won't work. 2. Say that RDNSS is a MUST, and provide a mandatory mechanism that network operators can rely on, even if it's not the one they like the most. The question is not whether we prefer DHCPv6 or RDNSS. The question is whether we want to do #1 or #2. --001a11436e505b521f054c56cbce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 4, 2017 at 2:21 AM, Ted Lemon <mellon@fugue.com> wrot= e:
This is frustrating= .=C2=A0 =C2=A0It seems clear to me that requiring support for RDNSS would i= mprove the situation.

+1

As a reminder: the original question in this thread was very simple:= do we have rough consensus to say that hosts MUST implement RDNSS?

Given the strong opposition from major host OS developers= , and others on this thread such as Barbara and James, I really don't s= ee us getting to consensus that hosts MUST implement DHCPv6. Therefore, in = practice there are only two feasible options:
  1. Don't s= ay anything, and have no mandatory mechanism that operators can rely on. So= me network/device combinations won't work.
  2. Say that RDNSS is a = MUST, and provide a mandatory mechanism that network operators can rely on,= even if it's not the one they like the most.
The questio= n is not whether we prefer DHCPv6 or RDNSS. The question is whether we want= to do #1 or #2.
--001a11436e505b521f054c56cbce-- From nobody Tue Apr 4 06:18: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 13827124282 for ; Tue, 4 Apr 2017 06:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjh4kq8GlJUK for ; Tue, 4 Apr 2017 06:18:44 -0700 (PDT) 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 239D5120725 for ; Tue, 4 Apr 2017 06:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491311544; bh=pwv1MmaZcBaxwRm+kgDkVE72Ls8/tP/J0TBaqQdtDkc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=hS6NsY4wLDEi8+pUiZgqcS+/dny/0vpAQ+TE93qYK3K9x0peJpDoIOkM3kFP0F1Hr8k2IhHLbXvqwBfWsE59n9fpo0xQ3nBAFRnef5tiYCwSzmkzcpQtbHqEzJXETPfXNo8+HK3laSy9Rq7CL0r04xB/aGBH+w6dZDMcp3sH8AA= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0049.outbound.protection.outlook.com [213.199.154.49]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-104-i0A3MB_PNmuYTqNehpWJ5w-1; Tue, 04 Apr 2017 14:12:20 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 13:12:19 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Tue, 4 Apr 2017 13:12:19 +0000 From: Tim Chown To: Lorenzo Colitti CC: Ted Lemon , IPv6 Ops WG Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGuSN8AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ICAAA0U4IAADhwAgAAJQYCAAUf3gIAABLgA Date: Tue, 4 Apr 2017 13:12:19 +0000 Message-ID: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> 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-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:6FvPMCyHbAmfuhpL1ZUb34HWptWEBhMZpg2EmxzQM0T0GsF77g3LEM1357cyOZ1uVWbJiIaBxI1JAXWgZPST8wjtAZN98omRH2yfGH796BB3wcbwVIALoMFyhYsuY1+EN+UCthvjnHr/DyvGKL3DxTftKvNQeXrQ2m4OtitYP7FhiUFyk0knp63c/kxqbFkgRY1kPemyPOGmgmTsrKZuZm6vwcyGaClO9NTRJ/nzC/1aq27YaOvCLSfh4TUjEvOiELtWxRd+MtGLMsHo3Zr/ksZD7Hz5GtP/Q5KsRy1VgrpejwjghSBkywsInUrhn/MG/TNbs+knq1V0Ea7h+Uzswg==; 20:zRpsKaJ2qejS26kIuc2AK35PjVzLvwYzZN1hQuGZt5D3ZVz8Ut4+INjzCENU0av0l7eDStwNoyWBZvpSZFa0CJYzyDKsYLirGA/BXsScob8EkAnQn/WV/pxKtPNzGbfz6CUMQlYMckLzXciB2dUKtvPZ4WhqBq9sbk9VWdXJbo4= x-ms-office365-filtering-correlation-id: ccd6edc0-aef7-4f2b-3f4a-08d47b5c3923 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39840400002)(39400400002)(39450400003)(24454002)(377454003)(38730400002)(189998001)(8936002)(66066001)(53546009)(6512007)(86362001)(57306001)(6246003)(53936002)(81166006)(4326008)(8676002)(3280700002)(33656002)(229853002)(5660300001)(50226002)(25786009)(36756003)(6436002)(54896002)(3660700001)(93886004)(2906002)(5250100002)(6916009)(42882006)(3846002)(2950100002)(102836003)(6116002)(7736002)(236005)(54906002)(99286003)(6486002)(2900100001)(6506006)(74482002)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 13:12:19.1290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: i0A3MB_PNmuYTqNehpWJ5w-1 Content-Type: multipart/alternative; boundary="_000_C5E7A978ADDE453092D7699316B8DA3Bjiscacuk_" Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:18:46 -0000 --_000_C5E7A978ADDE453092D7699316B8DA3Bjiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCk9uIDQgQXByIDIwMTcsIGF0IDEzOjU1LCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9A Z29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPj4gd3JvdGU6DQoNCk9uIFR1ZSwg QXByIDQsIDIwMTcgYXQgMjoyMSBBTSwgVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPG1haWx0 bzptZWxsb25AZnVndWUuY29tPj4gd3JvdGU6DQpUaGlzIGlzIGZydXN0cmF0aW5nLiAgIEl0IHNl ZW1zIGNsZWFyIHRvIG1lIHRoYXQgcmVxdWlyaW5nIHN1cHBvcnQgZm9yIFJETlNTIHdvdWxkIGlt cHJvdmUgdGhlIHNpdHVhdGlvbi4NCg0KKzENCg0KQXMgYSByZW1pbmRlcjogdGhlIG9yaWdpbmFs IHF1ZXN0aW9uIGluIHRoaXMgdGhyZWFkIHdhcyB2ZXJ5IHNpbXBsZTogZG8gd2UgaGF2ZSByb3Vn aCBjb25zZW5zdXMgdG8gc2F5IHRoYXQgaG9zdHMgTVVTVCBpbXBsZW1lbnQgUkROU1M/DQoNCkdp dmVuIHRoZSBzdHJvbmcgb3Bwb3NpdGlvbiBmcm9tIG1ham9yIGhvc3QgT1MgZGV2ZWxvcGVycywg YW5kIG90aGVycyBvbiB0aGlzIHRocmVhZCBzdWNoIGFzIEJhcmJhcmEgYW5kIEphbWVzLCBJIHJl YWxseSBkb24ndCBzZWUgdXMgZ2V0dGluZyB0byBjb25zZW5zdXMgdGhhdCBob3N0cyBNVVNUIGlt cGxlbWVudCBESENQdjYuIFRoZXJlZm9yZSwgaW4gcHJhY3RpY2UgdGhlcmUgYXJlIG9ubHkgdHdv IGZlYXNpYmxlIG9wdGlvbnM6DQoNCiAgMS4gIERvbid0IHNheSBhbnl0aGluZywgYW5kIGhhdmUg bm8gbWFuZGF0b3J5IG1lY2hhbmlzbSB0aGF0IG9wZXJhdG9ycyBjYW4gcmVseSBvbi4gU29tZSBu ZXR3b3JrL2RldmljZSBjb21iaW5hdGlvbnMgd29uJ3Qgd29yay4NCiAgMi4gIFNheSB0aGF0IFJE TlNTIGlzIGEgTVVTVCwgYW5kIHByb3ZpZGUgYSBtYW5kYXRvcnkgbWVjaGFuaXNtIHRoYXQgbmV0 d29yayBvcGVyYXRvcnMgY2FuIHJlbHkgb24sIGV2ZW4gaWYgaXQncyBub3QgdGhlIG9uZSB0aGV5 IGxpa2UgdGhlIG1vc3QuDQoNClRoZSBxdWVzdGlvbiBpcyBub3Qgd2hldGhlciB3ZSBwcmVmZXIg REhDUHY2IG9yIFJETlNTLiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3YW50IHRvIGRvICMx IG9yICMyLg0KDQpJ4oCZbSBzZWVpbmcgc3Ryb25nIHN1cHBvcnQgZm9yIFJGQzY4MDEgUkROU1Mg YXMgYSBNVVNULiBQZXJzb25hbGx5LCBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoaXMsIGZvciBjbGll bnRzIGFuZCByb3V0ZXJzLCBpbiBSRkM2NDM0LWJpcyBhbmQgZHJhZnQtYWxpLWlwdjZydHItcmVx cyByZXNwZWN0aXZlbHkuDQoNCkFuZCB0aGF0IHdvdWxkIGdpdmUgb25lIE1USSBtZXRob2QgdG8g KG9uIHBhcGVyIGF0IGxlYXN0ISkgYnJlYWsgdGhlIGN1cnJlbnQgZGVhZGxvY2suDQoNCkJ1dCB0 aGF0IGRvZXNu4oCZdCBydWxlIG91dCBhIHN0YXRlbWVudCBvbiAqc3RhdGVsZXNzKiBESENQdjYg c3VwcG9ydCwgZG9lcyBpdD8gUkZDODYwMSBleHBsaWNpdGx5IGRpc2N1c3NlcyB3aGF0IHRvIGRv IGluIHRoZSBwcmVzZW5jZSBvZiBib3RoIG1lY2hhbmlzbXMsIGFuZCBpaXJjIHNheXMgdG8gcGxh Y2UgYSByZXNvbHZlciBhZGRyZXNzIGxlYXJudCBieSBESENQIGFoZWFkIG9mIGFueSBsZWFybnQg YnkgdGhlIFJETlNTIG9wdGlvbiwgZWZmZWN0aXZlbHkgcHJlZmVycmluZyBzdGF0ZWxlc3MgREhD UHY2IGlmIHByZXNlbnQuIFdoaWxlIEkgcGVyc29uYWxseSBiZWxpZXZlIHRoZSBSQS1iYXNlZCBv cHRpb24gaXMgdGVjaG5pY2FsbHkgYmV0dGVyLCBJIGFsc28gc2VlIGVudGVycHJpc2UgbmV0d29y ayBhZG1pbnMgcnVubmluZyBJUHY2IHRvZGF5IHdobyBhcmUgd29uZGVyaW5nIGhvdyB0aGV54oCZ bGwgY29uZmlndXJlIChzYXkpIE5UUCBzZXJ2ZXIgc2V0dGluZ3MsIG9yIG90aGVyIHNldHRpbmdz IG9ubHkgYXZhaWxhYmxlIGJ5IHN0YXRlbGVzcyBESENQdjYgYW5kIG5vdCB2aWEgUkFzLiBXaGF0 4oCZcyB0aGUgYW5zd2VyIGZvciB0aGVtLCBhcyB3ZSBtb3ZlIHRvIElQdjYtb25seSBvcGVyYXRp b24/DQoNClRpbQ0K --_000_C5E7A978ADDE453092D7699316B8DA3Bjiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gNCBBcHIgMjAxNywgYXQgMTM6NTUsIExvcmVuem8gQ29saXR0aSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbSIgY2xhc3M9IiI+bG9yZW56b0Bnb29n bGUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwg QXByIDQsIDIwMTcgYXQgMjoyMSBBTSwgVGVkIExlbW9uIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0i Ij4NCiZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRp bmctbGVmdDoxZXgiPg0KVGhpcyBpcyBmcnVzdHJhdGluZy4mbmJzcDsgJm5ic3A7SXQgc2VlbXMg Y2xlYXIgdG8gbWUgdGhhdCByZXF1aXJpbmcgc3VwcG9ydCBmb3IgUkROU1Mgd291bGQgaW1wcm92 ZSB0aGUgc2l0dWF0aW9uLjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiYjNDM7MTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgYSByZW1pbmRlcjogdGhlIG9yaWdp bmFsIHF1ZXN0aW9uIGluIHRoaXMgdGhyZWFkIHdhcyB2ZXJ5IHNpbXBsZTogZG8gd2UgaGF2ZSBy b3VnaCBjb25zZW5zdXMgdG8gc2F5IHRoYXQgaG9zdHMgTVVTVCBpbXBsZW1lbnQgUkROU1M/PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5H aXZlbiB0aGUgc3Ryb25nIG9wcG9zaXRpb24gZnJvbSBtYWpvciBob3N0IE9TIGRldmVsb3BlcnMs IGFuZCBvdGhlcnMgb24gdGhpcyB0aHJlYWQgc3VjaCBhcyBCYXJiYXJhIGFuZCBKYW1lcywgSSBy ZWFsbHkgZG9uJ3Qgc2VlIHVzIGdldHRpbmcgdG8gY29uc2Vuc3VzIHRoYXQgaG9zdHMgTVVTVCBp bXBsZW1lbnQgREhDUHY2LiBUaGVyZWZvcmUsIGluIHByYWN0aWNlIHRoZXJlIGFyZSBvbmx5IHR3 byBmZWFzaWJsZSBvcHRpb25zOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxvbCBjbGFzcz0iIj4N CjxsaSBjbGFzcz0iIj5Eb24ndCBzYXkgYW55dGhpbmcsIGFuZCBoYXZlIG5vIG1hbmRhdG9yeSBt ZWNoYW5pc20gdGhhdCBvcGVyYXRvcnMgY2FuIHJlbHkgb24uIFNvbWUgbmV0d29yay9kZXZpY2Ug Y29tYmluYXRpb25zIHdvbid0IHdvcmsuPC9saT48bGkgY2xhc3M9IiI+U2F5IHRoYXQgUkROU1Mg aXMgYSBNVVNULCBhbmQgcHJvdmlkZSBhIG1hbmRhdG9yeSBtZWNoYW5pc20gdGhhdCBuZXR3b3Jr IG9wZXJhdG9ycyBjYW4gcmVseSBvbiwgZXZlbiBpZiBpdCdzIG5vdCB0aGUgb25lIHRoZXkgbGlr ZSB0aGUgbW9zdC48L2xpPjwvb2w+DQo8ZGl2IGNsYXNzPSIiPlRoZSBxdWVzdGlvbiBpcyBub3Qg d2hldGhlciB3ZSBwcmVmZXIgREhDUHY2IG9yIFJETlNTLiBUaGUgcXVlc3Rpb24gaXMgd2hldGhl ciB3ZSB3YW50IHRvIGRvICMxIG9yICMyLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2PknigJltIHNlZWluZyBzdHJvbmcgc3VwcG9ydCBmb3IgUkZDNjgwMSBSRE5TUyBh cyBhIE1VU1QuIFBlcnNvbmFsbHksIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcywgZm9yIGNsaWVu dHMgYW5kIHJvdXRlcnMsIGluIFJGQzY0MzQtYmlzIGFuZCZuYnNwO2RyYWZ0LWFsaS1pcHY2cnRy LXJlcXMgcmVzcGVjdGl2ZWx5LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+QW5kIHRoYXQgd291bGQgZ2l2ZSBvbmUgTVRJIG1ldGhvZCB0byAob24gcGFwZXIgYXQgbGVh c3QhKSBicmVhayB0aGUgY3VycmVudCBkZWFkbG9jay48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2PkJ1dCB0aGF0IGRvZXNu4oCZdCBydWxlIG91dCBhIHN0YXRlbWVudCBv biAqc3RhdGVsZXNzKiBESENQdjYgc3VwcG9ydCwgZG9lcyBpdD8gUkZDODYwMSBleHBsaWNpdGx5 IGRpc2N1c3NlcyB3aGF0IHRvIGRvIGluIHRoZSBwcmVzZW5jZSBvZiBib3RoIG1lY2hhbmlzbXMs IGFuZCBpaXJjIHNheXMgdG8gcGxhY2UgYSByZXNvbHZlciBhZGRyZXNzIGxlYXJudCBieSBESENQ IGFoZWFkIG9mIGFueSBsZWFybnQgYnkgdGhlIFJETlNTIG9wdGlvbiwNCiBlZmZlY3RpdmVseSBw cmVmZXJyaW5nIHN0YXRlbGVzcyBESENQdjYgaWYgcHJlc2VudC4gV2hpbGUgSSBwZXJzb25hbGx5 IGJlbGlldmUgdGhlIFJBLWJhc2VkIG9wdGlvbiBpcyB0ZWNobmljYWxseSBiZXR0ZXIsIEkgYWxz byBzZWUgZW50ZXJwcmlzZSBuZXR3b3JrIGFkbWlucyBydW5uaW5nIElQdjYgdG9kYXkgd2hvIGFy ZSB3b25kZXJpbmcgaG93IHRoZXnigJlsbCBjb25maWd1cmUgKHNheSkgTlRQIHNlcnZlciBzZXR0 aW5ncywgb3Igb3RoZXIgc2V0dGluZ3MNCiBvbmx5IGF2YWlsYWJsZSBieSBzdGF0ZWxlc3MgREhD UHY2IGFuZCBub3QgdmlhIFJBcy4gV2hhdOKAmXMgdGhlIGFuc3dlciBmb3IgdGhlbSwgYXMgd2Ug bW92ZSB0byBJUHY2LW9ubHkgb3BlcmF0aW9uPyAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2PlRpbTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C5E7A978ADDE453092D7699316B8DA3Bjiscacuk_-- From nobody Tue Apr 4 06:33: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 DF8D31296AA for ; Tue, 4 Apr 2017 06:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 sQHLFfAvV5Ab for ; Tue, 4 Apr 2017 06:33:14 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 B94E71296B4 for ; Tue, 4 Apr 2017 06:33:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v34DXA3d009496 for ; Tue, 4 Apr 2017 15:33:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 18A0A2042B5 for ; Tue, 4 Apr 2017 15:33:10 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 061BA2042AF for ; Tue, 4 Apr 2017 15:33:10 +0200 (CEST) Received: from [132.166.84.241] ([132.166.84.241]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v34DX8ug031823 for ; Tue, 4 Apr 2017 15:33:09 +0200 To: v6ops@ietf.org References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> From: Alexandre Petrescu Message-ID: Date: Tue, 4 Apr 2017 15:32:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:33:17 -0000 Le 04/04/2017 à 15:12, Tim Chown a écrit : > Hi, > >> On 4 Apr 2017, at 13:55, Lorenzo Colitti > > wrote: >> >> On Tue, Apr 4, 2017 at 2:21 AM, Ted Lemon > > wrote: >> >> This is frustrating. It seems clear to me that requiring support >> for RDNSS would improve the situation. >> >> >> +1 >> >> As a reminder: the original question in this thread was very simple: >> do we have rough consensus to say that hosts MUST implement RDNSS? >> >> Given the strong opposition from major host OS developers, and others >> on this thread such as Barbara and James, I really don't see us >> getting to consensus that hosts MUST implement DHCPv6. Therefore, in >> practice there are only two feasible options: >> >> 1. Don't say anything, and have no mandatory mechanism that operators >> can rely on. Some network/device combinations won't work. >> 2. Say that RDNSS is a MUST, and provide a mandatory mechanism that >> network operators can rely on, even if it's not the one they like >> the most. >> >> The question is not whether we prefer DHCPv6 or RDNSS. The question is >> whether we want to do #1 or #2. > > I’m seeing strong support for RFC6801 RDNSS as a MUST. Personally, I > would like to see this, for clients and routers, in RFC6434-bis > and draft-ali-ipv6rtr-reqs respectively. > > And that would give one MTI method to (on paper at least!) break the > current deadlock. > > But that doesn’t rule out a statement on *stateless* DHCPv6 support, > does it? RFC8601 explicitly discusses what to do in the presence of both > mechanisms, and iirc says to place a resolver address learnt by DHCP > ahead of any learnt by the RDNSS option, effectively preferring > stateless DHCPv6 if present. While I personally believe the RA-based > option is technically better, I also see enterprise network admins > running IPv6 today who are wondering how they’ll configure (say) NTP > server settings, or other settings only available by stateless DHCPv6 > and not via RAs. What’s the answer for them, as we move to IPv6-only > operation? I agree with the question. I would also like to suggest make clearer that any additional RA-specific recommendation (like DNS-in-RA) does not impede DHCPv6-PD, in addition to stateless DHCPv6. Alex > > Tim > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Apr 4 07:31: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 ECE181296CD for ; Tue, 4 Apr 2017 07:31:51 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 ai4A2QrzACRT for ; Tue, 4 Apr 2017 07:31:45 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 96B351296C6 for ; Tue, 4 Apr 2017 07:31:45 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v34EPepY015096; Tue, 4 Apr 2017 10:31:40 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 29m0n157kg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Apr 2017 10:31:40 -0400 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 v34EVdtW001700; Tue, 4 Apr 2017 10:31:39 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v34EVR4b001421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2017 10:31:31 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 4 Apr 2017 14:31:17 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Tue, 4 Apr 2017 10:31:17 -0400 From: "STARK, BARBARA H" To: Mark Andrews , james woodyatt CC: IPv6 Operations Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFt96tfihWCnUqZYstkvT6jfaGui+0AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ID//8n4MIAAUTgAgAAJQYCAAAzIAP//wss/gABGAgCAAA3HAP//2NP6ACPpKSA= Date: Tue, 4 Apr 2017 14:31:16 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> <20170403210611.549AC6A7A930@rock.dv.isc.org> In-Reply-To: <20170403210611.549AC6A7A930@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.235] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-04_12:, , 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-1702020001 definitions=main-1704040128 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:31:52 -0000 PiBTdHVmZiAiZGVzaWduZWQgZm9yIGhvbWVzIiBnZXRzIHB1dCBvbiBjb3JwcmF0ZSBuZXRzIGFs bCB0aGUgdGltZS4gIEl0IHNob3VsZA0KPiBqdXN0IHdvcmsgdGhlcmUuICBUaGVyZSBpcyB2ZXJ5 IGxpdHRsZSwgaWYgYW55dGhpbmcsIHRoYXQgZG9lc24ndCBnZXQgY29ubmVjdGVkDQo+IHRvIGJv dGggdHlwZXMgb2YgbmV0cy4NCg0KSSBndWVzcyBteSBlbXBsb3llcidzIGNvcnBvcmF0ZSBuZXR3 b3JrIG11c3QgYmUgdmVyeSBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mIG90aGVycy4gSGVyZSwgdGhl cmUgYXJlIHZlcnkgZXhwbGljaXQgcHJvaGliaXRpb25zICh3aXRoIGRpcmUgd2FybmluZ3MgZm9y IGNvbnNlcXVlbmNlcyByZSBjb250aW51ZWQgZW1wbG95bWVudCkgYWdhaW5zdCBhdHRhY2hpbmcg dW5hcHByb3ZlZCBkZXZpY2VzLiBUaGVyZSBpcyB6ZXJvIGV4cGVjdGF0aW9uIHRoYXQgIml0IHNo b3VsZCBqdXN0IHdvcmsiLiBJbiBmYWN0LCBJIHN1c3BlY3QgdGhhdCBmYWlsdXJlIG9mIHN1Y2gg ZGV2aWNlcyB0byBzdWNjZXNzZnVsbHkgYXR0YWNoIHdvdWxkIGJlIGNvbnNpZGVyZWQgYSBwb3Np dGl2ZSBmZWF0dXJlLiBPZiBjb3Vyc2UsIHRoZSBjb3Jwb3JhdGUgbmV0d29yayBpcyBjb21wbGV0 ZWx5IGRpc3RpbmN0IGZyb20gb3VyIHBlcnZhc2l2ZSAiaG90c3BvdCIgV2ktRmkgbmV0d29yayB0 aGF0IGxldHMgYW55dGhpbmcgYW5kIGFueW9uZSBhdHRhY2ggd2l0aCBlYXNlICh1c2VkIGJ5IGd1 ZXN0cyBhbmQgZW1wbG95ZWUgcGVyc29uYWwgZGV2aWNlcykuIEkgc3VzcGVjdCB0aGF0IHdoZW4g dGhlc2UgMiBuZXR3b3JrcyBkZXBsb3kgSVB2NiwgdGhlaXIgYWRkcmVzc2luZyBhcmNoaXRlY3R1 cmVzIHdpbGwgYmUgdmVyeSBkaWZmZXJlbnQgZnJvbSBvbmUgYW5vdGhlci4gWU1NVi4gTm90IGFs bCBjb3Jwb3JhdGUvZW50ZXJwcmlzZSBuZXR3b3JrcyBhcmUgdGhlIHNhbWUuIElNTywgYW55IGVu dGVycHJpc2UgbmV0d29yayB0aGF0IGFsbG93cyBhbnkgZGV2aWNlIHRvIGF0dGFjaCBpcyBub3Qg b3Zlcmx5IGNvbmNlcm5lZCB3aXRoIHNlY3VyaXR5IG9yIHdpdGggdHJhY2tpbmcgd2hvIGFuZCB3 aGF0IGF0dGFjaGVzIGFuZCBydW5zIHRyYWZmaWMgb3ZlciB0aGVpciBuZXR3b3JrLg0KQmFyYmFy YQ0K From nobody Tue Apr 4 07:53: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 02F7D1296CA for ; Tue, 4 Apr 2017 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NgX_kHSEgPn for ; Tue, 4 Apr 2017 07:53:39 -0700 (PDT) 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 EE3EF1294E7 for ; Tue, 4 Apr 2017 07:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491317617; bh=lI/bQkoeHrLUHU40yx21wbMaP2oGvxbuW6fCsdM1K8Q=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=Z4T/5bn0sMjd1RMwZQ8oiRC/rik+NFs7txWW7/yRx/svf4tnvPNWkec+T8U+Bzxgs6MBNkOz0Qtgt+FWVXq8O6vyZmD6uVD8loxQcLbMY8UD7/VCaf/Hz3Zfx1K6omFdnsxdaaTtGcov5KBdv4JQJqH0HW9U47nY9YBtuP/CR6U= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0240.outbound.protection.outlook.com [213.199.154.240]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-16-eulHoLKzPf6jxxH4YzQ_yA-1; Tue, 04 Apr 2017 15:53:31 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 14:53:30 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Tue, 4 Apr 2017 14:53:30 +0000 From: Tim Chown To: "STARK, BARBARA H" CC: Mark Andrews , james woodyatt , "IPv6 Operations" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGuSN8AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ICAAA0U4IAADhwAgAAJQYCAAAzIAIAABeQ0gAAC6QCAAA3GAIAAG+wigAEjeACAAAY0AA== Date: Tue, 4 Apr 2017 14:53:30 +0000 Message-ID: <1AAE39AC-97FC-4997-A579-0AA134CDB01F@jisc.ac.uk> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> <20170403210611.549AC6A7A930@rock.dv.isc.org> <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.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-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:Psskt32s0nlqW5ALNfEyCUR53VKc+ZIlJxOoy8Q9KpjU5NMVB9EwfmvUY+T4NiLCNUEnl07pk4dwebwthEf/7xwu6lXaYzoumJD9U6lWrBrsgUjU3t7xcmbYFnzXD/2hMn7mRAIPbOAyf2LLMOps/ebZlrJiVQTGEv7hywaZ4+9wonsfWNgSTmMYlgVud7+5zZyaM4B3/nZHbuRGuO06Tw+EOmI+mnmnf+uA1lfIYl3o0GDCDLxnRNjmSWx7rXDYfgTAWiPeF6yQLEEzdJiqFCXOiYAFMIunpmku78mtdAXCudNENwAuqEHBLf5J36V3u3b0Iswld8r/VuOzacm0sg==; 20:eZPgAQvxhcTdQcEnPrUyFc0NlaF4bmL1rr+NWmMVLgZIUWhjS124StHJymWV87JncXXn2D/fBrLCrxG39NJNS6k/s4FBoioxtBENlmipYx3255nWUr3jYH3fMP/ZybL3XKetqfCUv5qf7E/Q0wnf5qQF00KjrBlU2KfSZuNzMOs= x-ms-office365-filtering-correlation-id: bd4e8947-be1f-44ca-94f3-08d47b6a5bda x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123564025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39410400002)(39840400002)(39450400003)(24454002)(53546009)(25786009)(8676002)(81166006)(189998001)(50226002)(83716003)(82746002)(2950100002)(50986999)(6916009)(74482002)(76176999)(42882006)(7906003)(53936002)(33656002)(7736002)(93886004)(8936002)(2900100001)(6246003)(2906002)(66066001)(4326008)(110136004)(38730400002)(5890100001)(3280700002)(3660700001)(36756003)(6306002)(5250100002)(99286003)(3846002)(5660300001)(236005)(6436002)(16799955002)(6512007)(54896002)(6506006)(606005)(102836003)(86362001)(6486002)(6116002)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 14:53:30.1982 (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: eulHoLKzPf6jxxH4YzQ_yA-1 Content-Type: multipart/alternative; boundary="_000_1AAE39AC97FC4997A5790AA134CDB01Fjiscacuk_" Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:53:42 -0000 --_000_1AAE39AC97FC4997A5790AA134CDB01Fjiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgQmFyYmFyYSwNCg0KT24gNCBBcHIgMjAxNywgYXQgMTU6MzEsIFNUQVJLLCBCQVJCQVJBIEgg PGJzNzY1MkBhdHQuY29tPG1haWx0bzpiczc2NTJAYXR0LmNvbT4+IHdyb3RlOg0KDQpTdHVmZiAi ZGVzaWduZWQgZm9yIGhvbWVzIiBnZXRzIHB1dCBvbiBjb3JwcmF0ZSBuZXRzIGFsbCB0aGUgdGlt ZS4gIEl0IHNob3VsZA0KanVzdCB3b3JrIHRoZXJlLiAgVGhlcmUgaXMgdmVyeSBsaXR0bGUsIGlm IGFueXRoaW5nLCB0aGF0IGRvZXNuJ3QgZ2V0IGNvbm5lY3RlZA0KdG8gYm90aCB0eXBlcyBvZiBu ZXRzLg0KDQpJIGd1ZXNzIG15IGVtcGxveWVyJ3MgY29ycG9yYXRlIG5ldHdvcmsgbXVzdCBiZSB2 ZXJ5IGRpZmZlcmVudCBmcm9tIHRoYXQgb2Ygb3RoZXJzLiBIZXJlLCB0aGVyZSBhcmUgdmVyeSBl eHBsaWNpdCBwcm9oaWJpdGlvbnMgKHdpdGggZGlyZSB3YXJuaW5ncyBmb3IgY29uc2VxdWVuY2Vz IHJlIGNvbnRpbnVlZCBlbXBsb3ltZW50KSBhZ2FpbnN0IGF0dGFjaGluZyB1bmFwcHJvdmVkIGRl dmljZXMuIFRoZXJlIGlzIHplcm8gZXhwZWN0YXRpb24gdGhhdCAiaXQgc2hvdWxkIGp1c3Qgd29y ayIuIEluIGZhY3QsIEkgc3VzcGVjdCB0aGF0IGZhaWx1cmUgb2Ygc3VjaCBkZXZpY2VzIHRvIHN1 Y2Nlc3NmdWxseSBhdHRhY2ggd291bGQgYmUgY29uc2lkZXJlZCBhIHBvc2l0aXZlIGZlYXR1cmUu IE9mIGNvdXJzZSwgdGhlIGNvcnBvcmF0ZSBuZXR3b3JrIGlzIGNvbXBsZXRlbHkgZGlzdGluY3Qg ZnJvbSBvdXIgcGVydmFzaXZlICJob3RzcG90IiBXaS1GaSBuZXR3b3JrIHRoYXQgbGV0cyBhbnl0 aGluZyBhbmQgYW55b25lIGF0dGFjaCB3aXRoIGVhc2UgKHVzZWQgYnkgZ3Vlc3RzIGFuZCBlbXBs b3llZSBwZXJzb25hbCBkZXZpY2VzKS4gSSBzdXNwZWN0IHRoYXQgd2hlbiB0aGVzZSAyIG5ldHdv cmtzIGRlcGxveSBJUHY2LCB0aGVpciBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZXMgd2lsbCBiZSB2 ZXJ5IGRpZmZlcmVudCBmcm9tIG9uZSBhbm90aGVyLiBZTU1WLiBOb3QgYWxsIGNvcnBvcmF0ZS9l bnRlcnByaXNlIG5ldHdvcmtzIGFyZSB0aGUgc2FtZS4gSU1PLCBhbnkgZW50ZXJwcmlzZSBuZXR3 b3JrIHRoYXQgYWxsb3dzIGFueSBkZXZpY2UgdG8gYXR0YWNoIGlzIG5vdCBvdmVybHkgY29uY2Vy bmVkIHdpdGggc2VjdXJpdHkgb3Igd2l0aCB0cmFja2luZyB3aG8gYW5kIHdoYXQgYXR0YWNoZXMg YW5kIHJ1bnMgdHJhZmZpYyBvdmVyIHRoZWlyIG5ldHdvcmsuDQoNCkl04oCZcyBhIGJpdCBvZiBh biBhc2lkZSwgYnV0IHNpbmNlIHlvdSByYWlzZWQgaXTigKYgY29uc2lkZXIgYSB1bml2ZXJzaXR5 IGNhbXB1cywgd2hlcmUgdGhlIFdpRmkgYWxsb3dzIGFueSBzdGFmZiBvciBzdHVkZW50IGRldmlj ZSB0byBhdHRhY2guIEluIEV1cm9wZSwgYW5kIG1vcmUgc2xvd2x5IGVsc2V3aGVyZSwgZWR1cm9h bSBpcyBiZWNvbWluZyB0aGUgZG9taW5hbnQgU1NJRCBvbiBjYW1wdXNlcy4gVGhlIG1haW4gcmVh c29uIGlzIHRoYXQgaXQgYWxsb3dzIHJvYW1pbmcgYmV0d2VlbiB1c2VycyBvZiBhbnkgcGFydGlj aXBhbnQgdW5pdmVyc2l0eSwgYnkgdXNpbmcgODAyLjFYLWJhc2VkIHVzZXIgYXV0aGVudGljYXRp b24gYW5kIGFjY291bnRhYmlsaXR5LiAgQSBoaWVyYXJjaHkgb2YgUkFESVVTIHByb3hpZXMgZmFj aWxpdGF0ZXMgcmVsYXlpbmcgb2YgY3JlZGVudGlhbHMuIElmIGludGVyZXN0ZWQsIHlvdSBjYW4g c2VlIGRlcGxveW1lbnQgbWFwcyBhdCBodHRwczovL21vbml0b3IuZWR1cm9hbS5vcmcvbWFwX3Nl cnZpY2VfbG9jLnBocDsgdGhlIFVLIGhhcyBvdmVyIDE2MDAgc2l0ZXMgcnVubmluZyBlZHVyb2Ft LCBhbmQgaXQgZXh0ZW5kcyB0byBvdmVyIDcwIGNvdW50cmllcy4NCg0KVGhlcmUgd2lsbCBjZXJ0 YWlubHkgYWxzbyBiZSBhZG1pbmlzdHJhdGl2ZWx5IG1hbmFnZWQgc3lzdGVtcyBhdCB1bml2ZXJz aXR5IGNhbXB1c2VzLCBsb2NrZWQgZG93biBhcyB5b3UgZGVzY3JpYmUgYWJvdmUsIGJ1dCB0aGUg cG9pbnQgaXMgdGhhdCBCWU9EIGRvZXNu4oCZdCBoYXZlIHRvIGVxdWF0ZSB3aXRoIG5vIHNlY3Vy aXR5Lg0KDQpUaW0NCg0K --_000_1AAE39AC97FC4997A5790AA134CDB01Fjiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQmFyYmFyYSw8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDQgQXByIDIwMTcsIGF0IDE1OjMxLCBTVEFSSywgQkFSQkFS QSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iIGNsYXNzPSIiPmJzNzY1MkBh dHQuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj5TdHVmZiAmcXVvdDtkZXNpZ25lZCBmb3IgaG9tZXMmcXVvdDsg Z2V0cyBwdXQgb24gY29ycHJhdGUgbmV0cyBhbGwgdGhlIHRpbWUuICZuYnNwO0l0IHNob3VsZDxi ciBjbGFzcz0iIj4NCmp1c3Qgd29yayB0aGVyZS4gJm5ic3A7VGhlcmUgaXMgdmVyeSBsaXR0bGUs IGlmIGFueXRoaW5nLCB0aGF0IGRvZXNuJ3QgZ2V0IGNvbm5lY3RlZDxiciBjbGFzcz0iIj4NCnRv IGJvdGggdHlwZXMgb2YgbmV0cy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh c3M9IiI+DQpJIGd1ZXNzIG15IGVtcGxveWVyJ3MgY29ycG9yYXRlIG5ldHdvcmsgbXVzdCBiZSB2 ZXJ5IGRpZmZlcmVudCBmcm9tIHRoYXQgb2Ygb3RoZXJzLiBIZXJlLCB0aGVyZSBhcmUgdmVyeSBl eHBsaWNpdCBwcm9oaWJpdGlvbnMgKHdpdGggZGlyZSB3YXJuaW5ncyBmb3IgY29uc2VxdWVuY2Vz IHJlIGNvbnRpbnVlZCBlbXBsb3ltZW50KSBhZ2FpbnN0IGF0dGFjaGluZyB1bmFwcHJvdmVkIGRl dmljZXMuIFRoZXJlIGlzIHplcm8gZXhwZWN0YXRpb24gdGhhdA0KICZxdW90O2l0IHNob3VsZCBq dXN0IHdvcmsmcXVvdDsuIEluIGZhY3QsIEkgc3VzcGVjdCB0aGF0IGZhaWx1cmUgb2Ygc3VjaCBk ZXZpY2VzIHRvIHN1Y2Nlc3NmdWxseSBhdHRhY2ggd291bGQgYmUgY29uc2lkZXJlZCBhIHBvc2l0 aXZlIGZlYXR1cmUuIE9mIGNvdXJzZSwgdGhlIGNvcnBvcmF0ZSBuZXR3b3JrIGlzIGNvbXBsZXRl bHkgZGlzdGluY3QgZnJvbSBvdXIgcGVydmFzaXZlICZxdW90O2hvdHNwb3QmcXVvdDsgV2ktRmkg bmV0d29yayB0aGF0IGxldHMgYW55dGhpbmcgYW5kDQogYW55b25lIGF0dGFjaCB3aXRoIGVhc2Ug KHVzZWQgYnkgZ3Vlc3RzIGFuZCBlbXBsb3llZSBwZXJzb25hbCBkZXZpY2VzKS4gSSBzdXNwZWN0 IHRoYXQgd2hlbiB0aGVzZSAyIG5ldHdvcmtzIGRlcGxveSBJUHY2LCB0aGVpciBhZGRyZXNzaW5n IGFyY2hpdGVjdHVyZXMgd2lsbCBiZSB2ZXJ5IGRpZmZlcmVudCBmcm9tIG9uZSBhbm90aGVyLiBZ TU1WLiBOb3QgYWxsIGNvcnBvcmF0ZS9lbnRlcnByaXNlIG5ldHdvcmtzIGFyZSB0aGUgc2FtZS4g SU1PLA0KIGFueSBlbnRlcnByaXNlIG5ldHdvcmsgdGhhdCBhbGxvd3MgYW55IGRldmljZSB0byBh dHRhY2ggaXMgbm90IG92ZXJseSBjb25jZXJuZWQgd2l0aCBzZWN1cml0eSBvciB3aXRoIHRyYWNr aW5nIHdobyBhbmQgd2hhdCBhdHRhY2hlcyBhbmQgcnVucyB0cmFmZmljIG92ZXIgdGhlaXIgbmV0 d29yay48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pkl04oCZcyBhIGJpdCBvZiBhbiBhc2lkZSwgYnV0IHNpbmNl IHlvdSByYWlzZWQgaXTigKYgY29uc2lkZXIgYSB1bml2ZXJzaXR5IGNhbXB1cywgd2hlcmUgdGhl IFdpRmkgYWxsb3dzIGFueSBzdGFmZiBvciBzdHVkZW50IGRldmljZSB0byBhdHRhY2guIEluIEV1 cm9wZSwgYW5kIG1vcmUgc2xvd2x5IGVsc2V3aGVyZSwgZWR1cm9hbSBpcyBiZWNvbWluZyB0aGUg ZG9taW5hbnQgU1NJRCBvbiBjYW1wdXNlcy4gVGhlIG1haW4gcmVhc29uIGlzIHRoYXQNCiBpdCBh bGxvd3Mgcm9hbWluZyBiZXR3ZWVuIHVzZXJzIG9mIGFueSBwYXJ0aWNpcGFudCB1bml2ZXJzaXR5 LCBieSB1c2luZyA4MDIuMVgtYmFzZWQgdXNlciBhdXRoZW50aWNhdGlvbiBhbmQgYWNjb3VudGFi aWxpdHkuICZuYnNwO0EgaGllcmFyY2h5IG9mIFJBRElVUyBwcm94aWVzIGZhY2lsaXRhdGVzIHJl bGF5aW5nIG9mIGNyZWRlbnRpYWxzLiBJZiBpbnRlcmVzdGVkLCB5b3UgY2FuIHNlZSBkZXBsb3lt ZW50IG1hcHMgYXQmbmJzcDs8YSBocmVmPSJodHRwczovL21vbml0b3IuZWR1cm9hbS5vcmcvbWFw X3NlcnZpY2VfbG9jLnBocCIgY2xhc3M9IiI+aHR0cHM6Ly9tb25pdG9yLmVkdXJvYW0ub3JnL21h cF9zZXJ2aWNlX2xvYy5waHA8L2E+OyZuYnNwO3RoZQ0KIFVLIGhhcyBvdmVyIDE2MDAgc2l0ZXMg cnVubmluZyBlZHVyb2FtLCBhbmQgaXQgZXh0ZW5kcyB0byBvdmVyIDcwIGNvdW50cmllcy4mbmJz cDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIHdpbGwgY2Vy dGFpbmx5IGFsc28gYmUgYWRtaW5pc3RyYXRpdmVseSBtYW5hZ2VkIHN5c3RlbXMgYXQgdW5pdmVy c2l0eSBjYW1wdXNlcywgbG9ja2VkIGRvd24gYXMgeW91IGRlc2NyaWJlIGFib3ZlLCBidXQgdGhl IHBvaW50IGlzIHRoYXQgQllPRCBkb2VzbuKAmXQgaGF2ZSB0byBlcXVhdGUgd2l0aCBubyBzZWN1 cml0eS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRpbTwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1AAE39AC97FC4997A5790AA134CDB01Fjiscacuk_-- From nobody Tue Apr 4 08:34: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 4D0101296E3 for ; Tue, 4 Apr 2017 08:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 jUyJSYoyCBaa for ; Tue, 4 Apr 2017 08:34:37 -0700 (PDT) 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 AD9641292CE for ; Tue, 4 Apr 2017 08:34:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvQTY-0000H3C; Tue, 4 Apr 2017 17:34:32 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> <20170403210611.549AC6A7A930@rock.dv.isc.org> <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> In-reply-to: Your message of "Tue, 4 Apr 2017 14:31:16 +0000 ." <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 04 Apr 2017 17:34:31 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:34:39 -0000 In your letter dated Tue, 4 Apr 2017 14:31:16 +0000 you wrote: >I guess my employer's corporate network must be very different from that of ot >hers. Here, there are very explicit prohibitions (with dire warnings for conse >quences re continued employment) against attaching unapproved devices. 'approved' doesn't always mean that the network team gets to veto a device. Say somebody has decided on a particular model of internet connected light bulbs. So now you have across the building hundreds of light bulbs that all use privacy extensions. If you are really lucky, they also use MAC randomization. One of them behaves weird, good luck. Of course in 99% of the cases there is a simple way out: just don't deploy IPv6. If IPv4 does what you want and IPv6 doesn't, then why bother. On a smaller scale, ignoring enterprise requirements, if you have to debug a network problem, do you really want to keep track of a large collection of random 64-bit IIDs? (Of course nobody bothered to set up reverse DNS). Maybe that's when you want to set up a DHCP server that allocates address from a relatively small range. Just to restore some kind of sanity. Too bad, you didn't bother to buy only enterprise ready devices, so most of them won't cooperate. From nobody Tue Apr 4 09:04: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 DEF96128DE5 for ; Tue, 4 Apr 2017 09:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GgH0QEdhWVUQ for ; Tue, 4 Apr 2017 09:04:01 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30108.outbound.protection.outlook.com [40.107.3.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5B4127775 for ; Tue, 4 Apr 2017 09:04:00 -0700 (PDT) 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=JFp5FOp7xM38gZc6A223Ndb7PtzN6bWATyUmVma049w=; b=G82eS2BxJxDrSKfhNa3fOanFQDUBq9+Htz/MdKImvzdFsjoc5gDkHvpQ5JrWMsf5+twBVrIgeL6td7tOxc+f8PSuo8LRK6Mf1MQMXC1gdd7VQyxHyAzUKpNc8Ae8CewtW8T1u7Jx1b5hDcKMAGpfE1HbXrFQdxDKuo4and5u5x8= Authentication-Results: att.com; dkim=none (message not signed) header.d=none;att.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by AM5PR0701MB2993.eurprd07.prod.outlook.com (10.168.156.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 16:03:58 +0000 Message-ID: <01c501d2ad5c$cdc4f800$4001a8c0@gateway.2wire.net> From: t.petch To: "STARK, BARBARA H" CC: IPv6 Operations References: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> <20170403210611.549AC6A7A930@rock.dv.isc.org> <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 4 Apr 2017 16:59:47 +0100 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: [86.169.157.161] X-ClientProxiedBy: AM4PR05CA0025.eurprd05.prod.outlook.com (10.171.184.166) To AM5PR0701MB2993.eurprd07.prod.outlook.com (10.168.156.143) X-MS-Office365-Filtering-Correlation-Id: 7f315df1-e81a-4490-1946-08d47b743445 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:I/yVavvLgPisJUWXan+UYC4JFlELuufzY7opc8EOAaqvpFeyZssd44Pr/kliTpu8z1VvkOjqRbDtfB1DsreMCttRf18M+zQIAWO/okUw1BmBx7VKt7RAQpiZtMpTuza1KIP7bGvKX9uxDMSi6A9JOj4FNNABD+9Xrj2BiSD7kAydY4MzuSkSklDZp8JEk9NZWSftRh5CkJsgrQFS+9P7RTUqgVdfGoJxyU1BLa5/1/KutjdasFuGN+xLK5DSF2ZSSPGfYC2gRAaNDDxGqeZH2WM6MuTT9lrbtSXOQeZvzmm9hUp4jOkMtMSHvYqT2mGN1/JIC94C7t6ETPhBH4U48g==; 25:0vFDAo3qblUBlMiy1o82HcnkpTquxbzaa4VneOrDT6djBKCCkWrEQKrb2A3W8802Vf6MkUW4QF8fbR1lwPcp1HQnFqNtc/8fifjtcG783KhR9jGtuXAOeu9RXO4HtX7r4oAF6AxQFxi/TcCg+UoO487GvYR5PcW4z73xYHFNntjfPO1yBCU6GeXFZfQseqNpww2C3hKwRZ4CFt1m+OL/mCEdtpOzadhyMfospz444pv1JmsKqgV/CoF9t4WDZH0nZ5/V8aWAdnfChBpv+zV9cF8SBNRmX/fljMDHV9LBsyrdqlJ9dYyDWl+2og7a2t8z+RIbNvxQsQVom73TxaNRVkTp32NigdNHzeMbsYhjYr2pe+s5DBDkcuY9kyzHhj3A/vAAOcLPIyKjE75l8kcmBK1mwFTmFtjIJAIP720kxMU3n7kCJEtgU2uM9GpH8lwdjbr47rhSDfNF3rOw9EprcQ== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 31:WCBsshTEEy32PWnFEJwsyFnGXViQjwbJ5cvnkaLvP7AtGkngNURendj745x47G2HjzuuUd3Q5ec9ryTPj32DNc5A+nY9zkx/sA8QzJI42UvzloObnVEkIDGGpnHkpIr6RKYDegmKCevM0Bf8Qb+miYzSpBRosizjBo/XDgJhG6KPjWxEKZBg77U8VORwiHMyLHczb34G4O/UyPt+z9/Hc4lNOzQzkSYnJMEEQY93Fjz5KU9uwoLuUdt1tk7F1lzkZU0+BmljVeJmcu9r//hzRy4prXN+eVKgnTvqLKap1F0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(97927398514766); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 4:VKEbxGwvkhDy5SfEmNtXZ4Ksh2gnVB520ch2llaUUrt3bTnWwOA8rQLz1V3XNAzfrCEvOsbr49A2Qrg0EchyYKtmtsDGynV5Y7PFgzmLPHQvM6Fe+Qf2zMZuYGx+JELH/azROe4cW0zlayCyd2Oa1zbszkCgGatvVh0qlgvGiuTFNi3YpMpWGPfdk5AGn+5I2GryEBIxF/C7wcxNVBMREJ3JjhEevcYtiFQotz6uI5pz5MyTmkbb4+jbZvqNhygG3oltpKmFmrl5HhixxAUZKCoG+rygEnV3rsjIlh3iASLSklucAjIR4KWjXpQcYYgf6FieyStd6W5GByR6CWcOJSNZHMBDrdnJtDgOtc/Ya63/LP0ab3/qjF8C8kZ4sy6/epKxs6W6vrXQCHL5tdHhCQYZIJRrdnxKsN58kuB3bFZr/rHGGyEswDghsTACt/0ajdwzdRtZuv/9WFJ58E7Y0VYgjyrYJFUllMaSPRkMwsXl3TYvMLtVj8dTocOVYfHFKd0go6uTIai7zYwauFCOUF0KoosUxVjFNxHzydVKgX54ZHaViiuD6fn34fNsm7Zf23N7wAyCK5b1Gu261gz7gTZMgDzTRvNuozevCwjuVjpwtbu0Cn4FWj8lynWc6d0jbWtXsRVj2SSYOXQst8L+SdMds/lvt5Ltuj7H0YRje1QXC4XejuP92hd9p77xCgvkUYPa2I4N3vJ7J3tA+rP4Q/4NVjl3vrYclb7eFC6hDqvsjSx46kTR3LiZ317tYFL8y3rDX6rc3rFTU5juga4hGZQyalv8111Wz7nzdsADd1g= X-Forefront-PRVS: 0267E514F9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(39400400002)(377454003)(13464003)(53936002)(44736005)(6486002)(62236002)(66066001)(33646002)(50466002)(4326008)(5890100001)(9686003)(6306002)(25786009)(47776003)(6916009)(110136004)(84392002)(6666003)(42186005)(61296003)(2906002)(44716002)(6246003)(38730400002)(4720700003)(305945005)(7736002)(551544002)(5660300001)(14496001)(50226002)(93886004)(116806002)(23756003)(76176999)(81686999)(3846002)(6116002)(81166006)(230700001)(81816999)(86362001)(8676002)(50986999)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2993; 23:EcocC9HlMYIV4JDqYUbfo3Hpp3Jg46O7c6qKB?= =?iso-8859-1?Q?llLs3++YuCJZ6UHNX/ADPv6UXWBh5ihaVHeONRfjhI/zkyPZw04EY6ZobM?= =?iso-8859-1?Q?xGPvd9Xb+M24n5nY576yEUR/QUaso9cjMrLlT5p3XE8NKwE8rPUb3ft2VM?= =?iso-8859-1?Q?eY4A6KnU1VPGqDcVTNFu46L3IsRrrTjkI91Zdm0b4U6gKuqqhxnIsddxpS?= =?iso-8859-1?Q?MukJIRJRyCIfXSNGheCw+haYzOO1R3+Mb+CoXP0/EWTJPS8uVoeZK95I9T?= =?iso-8859-1?Q?7Wm1l3fRERoTxj8SyiPIEHvxe63W4Q9K7XxjMIC/EIPUqcPWb1fLasyEXR?= =?iso-8859-1?Q?V6vyPsopCb+s2MPd9G3Q5BEQhhh4yDTcV5FQOLXZNlYenae4Uo2hgy7Yd6?= =?iso-8859-1?Q?8Ytst8awyse0RU1ojNkV9/nfyJWrzbXtde+zrtM6Hqoo/9+ux8uVnjnDjF?= =?iso-8859-1?Q?0iHKSh4UGGHz9y4VUQWVHQ1keR2fCqajsBKLVWV6uka4dUw9MnGgYkKUTb?= =?iso-8859-1?Q?mKnamVxH5vCnZzFf5MD32XvE7SMdexc7CGBi/0EWpgFYrwTmHCOnZ0bBMC?= =?iso-8859-1?Q?h1dJwG5DXJEDk8ryEsQq/8Zg3eHiusBGmNC+nzwUViRVIA0qB3rOb7+D2q?= =?iso-8859-1?Q?N43r/SuvJQpkrQmv1EUat0XMevitP1R2doAh3u8/EoNRCs5grysPmw+Jah?= =?iso-8859-1?Q?NoDTHBuGqNaCI+EcfXWqLaz0Zxcpdz1e9Z30YvZnMnsw50AdIBV2osEMsK?= =?iso-8859-1?Q?BpC1XK/LpmTjN3+JhdVPym1Nh9Q6+hgzLVrtB+Qja7dMrGjd7zCOBOWEWR?= =?iso-8859-1?Q?R5DTEOAmrkMqu4zVNTgwP97kwkI5ePsZgVVtyIrqFWcFVeSBPD/cuW5CPZ?= =?iso-8859-1?Q?eUEYc01i8BHnwiE6CL/n3mARZe1ILO61lj68m7w9X8LlHnKNyKRv1VIATg?= =?iso-8859-1?Q?s4Uums6ZRNahcpx3wJH8KmU+gXJ5B1EY3pesCYpGvAUFJb8EYPpWpj4vEk?= =?iso-8859-1?Q?PgV+KEibf/baj/xceqJAS9UExhyRg4ABF3vV4Ap087OeyUsF+5v5G/PfiH?= =?iso-8859-1?Q?lLsyOO35Y4suZffP1u84gy31zJ2spNzbLLO/vE8FybyQliAFBxAFJasFK8?= =?iso-8859-1?Q?oqLeOLSofFGfSdGgxeGYZDWJxw5eJpI9RfJntC3ywQ8Xsrh1lSK67Jhw5G?= =?iso-8859-1?Q?L3dC6bZFPoXMBhYWeYNUr7P09A/1zzrilvmb3M7YWin/ycYYh0iOLNAhXW?= =?iso-8859-1?Q?hgRu+42flIcMInA3WBXDtkEUkCdvg4PYVs71W4I6eeSq+KBth8SUrFuBeI?= =?iso-8859-1?Q?ZJuRniJfU7Zl0MffrZEYkvwFcVddna/yOeNEHVsSW0yrd5td+O7FTVzjJV?= =?iso-8859-1?Q?la8XarHYGdL0f9AojxtcCfJRGmngl21?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:ITBWbayON8Uc5BNQZcBeUBv70qmgHknoRw7iJvTsXg1SpNO8munPvjhRR050OjB8qq4zv43KeT3uZUM9dPzwwTDvn/hJWgHw+fr1KKN/QYEIH+RrQMa3SbyIMahGyeIk8O6dXt9wv6pJT3IxJsJQp9letBuy23/+zPM1mCrr/+A73vmjb1bd6vfjru6TnXhhh1Q0m6Jcl5phHZPhsSLd+oQKOE4uAx2Qu/ssmMGq/LMXzYgYlvGynGLyMh0nbKoE+0m/UCjl/3jOVS234dBT+R2YoeWxqizihrXM5q+MP63qA7oF1fOh1464d81nqTs2eJubemC5L9pu+E/uQOVpftVvD86qGWKarIlv4XpW3oBJUhraelSUn3Bgk6RCGrBSJY2bqF1vayjzLkg4oj791w==; 5:lX/oFLDsDtukv6jzTLW3W6qWH957ufnavakX4GXfeEx4R3hNddbzErnZWXsystWVJl3y/sevwkKrhtXPv/f/SPfYeFYf/2Xup9MpyZZ/fKmIk/dM0xw0vTheyqZQFgV843ahGyMLeSxeq6LBykrsoA==; 24:r70/ZVtjroDCCOGAOxKMgBMKuaev5aVNStSaUYYtJ2sURcvKfOVYZ1OmXWfMKu+D0BFHdwCTgbTnk1vgw6twau8cfy/J8/6rKhwAUI3RS80= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 7:g1nhvhlVocurM5XMiM3EP/pLIomoS4ue8YXl0cJyzg2511m+wTOkEYey/GfiFd1CYXVReuF56wW1tocwoWp+K8EBfZwBC8pOFSLpV/48chk0/5d+NTnq72DH1pLNGup3KP4XOiSPqKXaR/VfSNDcx87tV66kWeRRZQJU84xkAHJnLUszFUXb1p5YHSyN4mAEi9oUnKwihI3bsNdOuwvdII1OZmQyjk47FNW463W8ibyY/geZHi9s8yLqD0bsD9D9roo1iO2zlrQ/LTE/r4g4o5R7TRq2hKQfUhDp3/Kwr70b0EOZwK36Ind4f55vjtParzOKEBHr0ZKQ7g2WxL/QXQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2017 16:03:58.7267 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:04:04 -0000 ----- Original Message ----- From: "STARK, BARBARA H" Sent: Tuesday, April 04, 2017 3:31 PM > > Stuff "designed for homes" gets put on corprate nets all the time. It should > > just work there. There is very little, if anything, that doesn't get connected > > to both types of nets. > > I guess my employer's corporate network must be very different from that of others. Here, there are very explicit prohibitions (with dire warnings for consequences re continued employment) against attaching unapproved devices. There is zero expectation that "it should just work". In fact, I suspect that failure of such devices to successfully attach would be considered a positive feature. Of course, the corporate network is completely distinct from our pervasive "hotspot" Wi-Fi network that lets anything and anyone attach with ease (used by guests and employee personal devices). I suspect that when these 2 networks deploy IPv6, their addressing architectures will be very different from one another. YMMV. Not all corporate/enterprise networks are the same. IMO, any enterprise network that allows any device to attach is not overly concerned with security or with tracking who and what attaches and runs traffic over their network. Barbara Yup, very different. I use a large campus network (probably tens of thousands of users) where it is basically Bring Your Own (laptop etc). And yes there are periodical outages because a virus got loose. WiFi is available but the buildings have, historically, made wired more reliable On the other hand, it is the only network I know where the constraints on passwords remotely approach the entropy needed for present day security. And I just failed to access e.g. the Irish state Mapping Agency because MacAfee decided that that that site is unsafe; most access is to internal corporate servers, not external ones. I suspect it knows every external web site I have accessed but I have no knowledge yet of its view of DHCP v RDNSS. Tom Petch > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 4 12:10: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 1C100127275 for ; Tue, 4 Apr 2017 12:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mu7r4yy5Z1ip for ; Tue, 4 Apr 2017 12:09:59 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 584DD126B7F for ; Tue, 4 Apr 2017 12:09:59 -0700 (PDT) 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.ams1.isc.org (Postfix) with ESMTPS id 1DBC224AE09; Tue, 4 Apr 2017 19:08:38 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 15C68160071; Tue, 4 Apr 2017 19:08:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 04DA5160073; Tue, 4 Apr 2017 19:08:38 +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 mWVsGmWXqueW; Tue, 4 Apr 2017 19:08:37 +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 7534B160071; Tue, 4 Apr 2017 19:08:37 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 06CB36A8A72D; Wed, 5 Apr 2017 05:08:34 +1000 (AEST) To: "STARK, BARBARA H" Cc: james woodyatt , IPv6 Operations From: Mark Andrews References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> <20170403210611.549AC6A7A930@rock.dv.isc.org> <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> In-reply-to: Your message of "Tue, 04 Apr 2017 14:31:16 +0000." <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 05 Apr 2017 05:08:34 +1000 Message-Id: <20170404190834.06CB36A8A72D@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 19:10:01 -0000 In message <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com>, "STARK, BARBARA H" writes: > > Stuff "designed for homes" gets put on corprate nets all the time. It > > should just work there. There is very little, if anything, that doesn't > > get connected to both types of nets. > > I guess my employer's corporate network must be very different from that > of others. No. You are confusing "management permission to connect a device" with "will that device work when connected". Is a "Apple TV" a "home device" or just a "device"? Is a "Amazon Echo" a "home device" or just a "device"? Is a "Smart TV" a "home device" or just a "device"? Is a "Refrigerator" a "home device" or just a "device"? One can go down lists of so-called "home devices" and find that they have corporate uses. They should be capable of working when connected to corporate nets. > Here, there are very explicit prohibitions (with dire warnings > for consequences re continued employment) against attaching unapproved > devices. There is zero expectation that "it should just work". In fact, I > suspect that failure of such devices to successfully attach would be > considered a positive feature. Of course, the corporate network is > completely distinct from our pervasive "hotspot" Wi-Fi network that lets > anything and anyone attach with ease (used by guests and employee > personal devices). I suspect that when these 2 networks deploy IPv6, > their addressing architectures will be very different from one another. > YMMV. Not all corporate/enterprise networks are the same. IMO, any > enterprise network that allows any device to attach is not overly > concerned with security or with tracking who and what attaches and runs > traffic over their network. > Barbara -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Apr 4 13:10: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 3D89712945E for ; Tue, 4 Apr 2017 13:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q4i2PjUfxnaG for ; Tue, 4 Apr 2017 13:10:14 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::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 961A51294CF for ; Tue, 4 Apr 2017 13:10:12 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id a140so6021557ita.3 for ; Tue, 04 Apr 2017 13:10:12 -0700 (PDT) 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=EUk8HyUKzwWUYPHMDsYdbjroblvjOeUGvLMkpZ9fuLk=; b=uUBLhPGif4yuWLMVXzhphyutPvWrVy+2N9owR2Abc2Zt+kpYELvwD1fHimNRkm+CN8 Pe0STl5HkEejnOLg6gmlsv+wKz0ruxwBMOGLS3d09wzX8MLfb5IqdFcT5Sf0Ye+ChTPj VbY2buO6+UmIA3vmQjZ+9OhvfzREqrn4lNv+kafeACTJOCjhMgvgb3dklcRXgkPVtO1x HyuucuicdrXMJF9ulZZF9nO/FYFvJIx0DmilpNMsOl+JB/7wa+PNgyYh7wN8jZ1LXV6Q Hto1NfK5O37v3XNuqLBYrDZWVLB4suxswe8DTxp5pFwjAgQ7vpOJkoEtfI+HhG8JDsAZ 0RXA== 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=EUk8HyUKzwWUYPHMDsYdbjroblvjOeUGvLMkpZ9fuLk=; b=iQo/wwdggDhlNQUwlCQsi2+oK3lErFFWFyYaNt0Aqu7O0L871gXo7XX8hPy5ItEGGk 4rq8MgOQJLORKUmgAW9tq4dECW5zm8UJv5PwVHu1YE9ul28Vn+CKqi/cEFpcAY+LHyIP VYa4CvYkbB24rwzGEbCSU72W20tJweAjcN9HHeHNtEmbIZsJWyf7bGZhGx3C/6JQFMqc zq6TMxvL7gSMbskwfh50vpJmSp5WBjgzrSOhZJRIhhKDrHpxTZ/JP/jhKfAHwfBuZPWL 2hezlmrPYcd9eGDnbCgnu0urCxNnHIlF38eXjy7nmT+nC6AHe8p/hI6ZPvwP5RaRpzzj eZGQ== X-Gm-Message-State: AFeK/H1sZzZV6HF5oCBFUMhJeJcQsLN+D+ALErPl5mtZMefq/sMRhGiqX0F8m+cwnTgbDA== X-Received: by 10.36.83.67 with SMTP id n64mr17264882itb.81.1491336612012; Tue, 04 Apr 2017 13:10:12 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id k16sm7703201itk.2.2017.04.04.13.10.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 13:10:11 -0700 (PDT) To: "STARK, BARBARA H" , Mark Andrews , james woodyatt References: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <1A475F7A-5D4E-46BB-8097-50C456ACD70A@gmail.com> <163004E6-4E64-4D68-B5CB-88A292EB478C@gmail.com> <20170403210611.549AC6A7A930@rock.dv.isc.org> <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: IPv6 Operations From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 5 Apr 2017 08:10:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB0F466@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:10:16 -0000 On 05/04/2017 02:31, STARK, BARBARA H wrote: >> Stuff "designed for homes" gets put on corprate nets all the time. It should >> just work there. There is very little, if anything, that doesn't get connected >> to both types of nets. > > I guess my employer's corporate network must be very different from that of others. Yes. There are lots of enterprise networks, for example probably every university that supports IPv6, where BYOD is the norm. There are also lots of enterprise networks that are strict. One size definitely does not fit all. "MUST implement" is very different from "MUST enable". I believe we're talking about "MUST implement." Brian >Here, there are very explicit prohibitions (with dire warnings for consequences re continued employment) against attaching unapproved devices. There is zero expectation that "it should just work". In fact, I suspect that failure of such devices to successfully attach would be considered a positive feature. Of course, the corporate network is completely distinct from our pervasive "hotspot" Wi-Fi network that lets anything and anyone attach with ease (used by guests and employee personal devices). I suspect that when these 2 networks deploy IPv6, their addressing architectures will be very different from one another. YMMV. Not all corporate/enterprise networks are the same. IMO, any enterprise network that allows any device to attach is not overly concerned with security or with tracking who and what attaches and runs traffic over their network. > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Apr 4 13:20: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 543A71279EB for ; Tue, 4 Apr 2017 13:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 u9mRxFkHYzL3 for ; Tue, 4 Apr 2017 13:20:24 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 33DD5126E3A for ; Tue, 4 Apr 2017 13:20:24 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id y18so12241755itc.2 for ; Tue, 04 Apr 2017 13:20:24 -0700 (PDT) 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=nqib/qMcxj15TbH1Tp677KZ8JT7I843cDBEfrRf8D8Q=; b=Vd5JJk1388Md9XQ3pDq/RnEivi5snc6SkQenedLOI82U+UpuHxrJ1NXfAi/A/Yw5DO aonGwl14gaCSzFx6nt69oS96RILDp77AV0tDyEqbIbt+MsnxtP0Sr7mv1n/RibbZ4OlA 68FTvF5umzb6MC8H63arOPiXyChjUl4j4Blkn8vZYh1cVohn62S2m3GNYBjmEbzUHYbf ur4YMQ/b6U4Ob/dmxH9vlIl3WPX5bZsaxIMx/7px260E/pTRoJ6vqBfs2k8QVh6+Lksv wOEi+rwkXE/DDYjGpHDk5tYwCVOR2FgM3zQF0VK65guAdatR9uwa0d0yJNAPsG0Rgw0B D3dQ== 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=nqib/qMcxj15TbH1Tp677KZ8JT7I843cDBEfrRf8D8Q=; b=PrNLbb8BbeMH6R+wXwnzz3VmUdkE+KbRcWETpk3BY8wKe1IQItmWZW4F9/hhq+pWi0 70bgNJVXRwQBUD55afrZtNTnkRgJ3LLSU1Iu6M3LrAIW4cuoYzreKAi/xkUCi0upZa4C 8ZOVJ4n8+hJIZfGLOIysmS1vB5CpCcDpnoynSR0pSmMaRaPaRu8N7ScyJwkAkbwInfJN ESDeET11pXfzF8LW/AfDNfFkWqeYc7kLx0ZfXvaFqxb528tB0r89v5srmrFGc0VJe0EM ckYgNOxEPaNFrCOH4SO4fVqMOwmKyCJ9kb97iFQCFjgBt5Qo/JTKC5JrkkPZMNRxZmP4 DULA== X-Gm-Message-State: AFeK/H2kzEf20G0Jhay5Npk158im1HEWCMGKIfL9wJhJWU5cwBG+shlr8icGWF+3SPAsDw== X-Received: by 10.36.233.66 with SMTP id f63mr18032542ith.55.1491337223447; Tue, 04 Apr 2017 13:20:23 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id o72sm7715481ite.10.2017.04.04.13.20.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 13:20:22 -0700 (PDT) To: Owen DeLong , Alexandre Petrescu References: <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delong.com> Cc: v6ops@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> Date: Wed, 5 Apr 2017 08:20:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delong.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:20:26 -0000 On 04/04/2017 12:06, Owen DeLong wrote: >=20 >> On Apr 3, 2017, at 5:43 AM, Alexandre Petrescu wrote: >> >> Le 31/03/2017 =C3=A0 20:26, Fred Baker a =C3=A9crit : >> [...] >>> Something that would help me, in this discussion, would be a simple >>> and incontrovertible statement of what breaks, or in which >>> circumstances RDNSS would be inappropriate. >> >> Not quite a breaking statement, and more implementation aspects: >> - the main OS distribution on Raspberry Pi does not implement DNS in R= A >> (other such distrib does, but it's rather marginally deployed). >> - I understand Windows PCs and routers at IETF dont implement DNS in >> RA, but rather DNS in DHCP. >> >> A speculative breaking statement would be: resolver address delivered = by RA overwrites the one delivered by DHCP, despite M=3D=3D1 (or vice-ve= rsa). But never tried it :-) >=20 > A network with M=3D1 and RDNSS in the RA packet is, IMHO, misconfigured= by definition,=20 I don't understand that assertion. There's nothing in the definition of M to suggest that. And even for the O bit, DNS info is only given as an example use. [RFC4861] Certainly there's *potential* for misconfiguration, if RDNSS and (statele= ss) DHCPv6 supply different DNS server addresses. But if they supply the same= address, so what? > so predictable behavior should not be expected. Only to the extent discussed in=20 https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem which people seem to have lost interest in. Brian >=20 > Owen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Apr 4 13:23: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 89A901294C5 for ; Tue, 4 Apr 2017 13:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 cmhz3zRdti6W for ; Tue, 4 Apr 2017 13:23:39 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 256B21294BF for ; Tue, 4 Apr 2017 13:23:39 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id d10so152863700qke.1 for ; Tue, 04 Apr 2017 13:23:39 -0700 (PDT) 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=oopB55JGjt7KPuep6TcEcC4XWEf2fsh+s1CnFJv7KJM=; b=ge+SsJKUh8G+fJLODxlkM/TaC3AiTSxHl2IpwDZJNWBFClXWPUKbFM4J5Wri/KviP7 ajYHViYTckkraS1Of3kElUomXoS/8georKshWOtYkRELVL07RhCpibyhMlH6Xyf7K2fJ 3oHgb2aYkIwW0+nlw8XnPUzc+TgFi5p194+cc94ZuHVUkm1457XS9ZzY5RlY3FQKhQJy HlLDYZIEy4Q9XE14Z1QfgXSbmYRBnbi28Pzfsckn/apnYyyOAWSjQ42MpC3HSxafVzS9 FnM/uoWMleZqIQNNlzHLTuH06bcB3UGUJ0U2e3IFJY0xNRKC8Dn/btxx1IGLodgiFis/ M+XA== 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=oopB55JGjt7KPuep6TcEcC4XWEf2fsh+s1CnFJv7KJM=; b=pmoB43zH6bqLzGIaB0aXALYfGmA22rZq05Fz572Kr3SVvlK5IIgDsKkzXnV6bzBmOh vxfLNWnc8B2GUIwGfoQ9cTHg/5H+jkSzCHIBMp04LIo8icHjkBMeCUKb8ZqVooAH2FGQ 9gHytljp8ySrIMtO9e/miXAENiSOohwSuQHktkmhVchhSrmYQNtDTEEZAzB/hBuHyKyl WhO0EM6ZJJyXax3hRW8XMKE45vFZVkEsGD++YOg5K1Z3bm/MBQzZfwgrXbv6UqJhXtvG 5WNsyPmBSgMBAySYk6IYyRyKw7jx7rA19sF/zSAfo25gk9rT58hGS7eZU+0KPmloqYCj jwPQ== X-Gm-Message-State: AFeK/H0W7HfjEQAvFus5yskhJRANur/10DQsT64sKkAIuZQztS3Ib6C455eF+wF/FYlWS6Wp3J9gYCoWOYnUAw== X-Received: by 10.55.189.130 with SMTP id n124mr25229318qkf.235.1491337418246; Tue, 04 Apr 2017 13:23:38 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Tue, 4 Apr 2017 13:23:36 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 4 Apr 2017 13:23:36 -0700 X-Google-Sender-Auth: yotmXEMWObPYUlqMfewngKYunkI Message-ID: To: Lorenzo Colitti Cc: Ted Lemon , IPv6 Ops WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:23:41 -0000 At Tue, 4 Apr 2017 21:55:25 +0900, Lorenzo Colitti wrote: > > This is frustrating. It seems clear to me that requiring support for > > RDNSS would improve the situation. > > +1 > > As a reminder: the original question in this thread was very simple: do we > have rough consensus to say that hosts MUST implement RDNSS? [...] > 1. Don't say anything, and have no mandatory mechanism that operators > can rely on. Some network/device combinations won't work. > 2. Say that RDNSS is a MUST, and provide a mandatory mechanism that > network operators can rely on, even if it's not the one they like the most. > > The question is not whether we prefer DHCPv6 or RDNSS. The question is > whether we want to do #1 or #2. Right, and we should really stop discussing in this thread - whether we should deprecate DNS-related options from DHCPv6 in addition to choice #2 above - whether stateless DHCPv6 for DNS configuration MUST be implemented - whether both (RDDNS and DHCPv6 for DNS config) MUST be supported - whether we should provide default router information via DHCPv6 etc. It's quite obvious that these points are a distraction for the main question of the thread, which itself is even very contentious already. If we really want to discuss these additional matters we should separate the thread. Now, focusing on the main question, I see some level of support for option #2, although I also see a non-marginal number of objections. I'm not sure if we can call it a rough consensus, but if not, I don't see a possibility to reach one just by continuing this thread. Maybe this is the point where we should ask the wg chairs to assess the sense of the wg. If the conclusion is that it's a rough consensus, we'd basically wrap up the document with it and send it to the IESG (people who oppose the conclusion can still make objection at the time of the IETF last call). If it's that we fail to reach a rough consensus, I think we should accept the reality that we'll never reach one, and use our time for other issues. BTW, I can also support choice #2, even though I'm not necessarily a fan of RDNSS and I see this MUST may have its own adverse effects. -- JINMEI, Tatuya From nobody Tue Apr 4 13:26: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 CD5811294C5 for ; Tue, 4 Apr 2017 13:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Fa4lyuyMdBOa for ; Tue, 4 Apr 2017 13:26:55 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8117128B88 for ; Tue, 4 Apr 2017 13:26:54 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id CDE272732A for ; Tue, 4 Apr 2017 22:26:46 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 0A15C33F7C8 for ; Tue, 4 Apr 2017 22:26:52 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 12C1139F12; Tue, 4 Apr 2017 22:26:53 +0200 (CEST) Date: Tue, 4 Apr 2017 22:26:53 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20170404202653.GC21163@ernw.de> References: <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delong.com> <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:26:58 -0000 Hi, > Certainly there's *potential* for misconfiguration, if RDNSS and (stateless) > DHCPv6 supply different DNS server addresses. But if they supply the same > address, so what? > > > so predictable behavior should not be expected. > > Only to the extent discussed in > https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem > which people seem to have lost interest in. there's slightly more detailed results (from 2015) in https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf For Win10 there's some update in: https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/ Those results are not exactly encouraging (re: predictable behavior) and I don't see the situation to get better, now that RFC 8106 is there. We will release an updated version of the above paper incl. current Android and iOS releases in the next weeks, probably before RIPE74. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Tue Apr 4 13:54: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 B441A1294E6 for ; Tue, 4 Apr 2017 13:54:04 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 4Xd-kGWruw4l for ; Tue, 4 Apr 2017 13:54:02 -0700 (PDT) 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 8BAED12441E for ; Tue, 4 Apr 2017 13:54:01 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3588961789 for ; Tue, 4 Apr 2017 22:53:59 +0200 (CEST) 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 E7276603D6; Tue, 4 Apr 2017 22:53:58 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id D92566F827; Tue, 4 Apr 2017 22:53:58 +0200 (CEST) Date: Tue, 4 Apr 2017 22:53:58 +0200 From: Gert Doering To: Owen DeLong Cc: Doug Barton , v6ops@ietf.org Message-ID: <20170404205358.GV25069@Space.Net> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <58DE38D5.4050802@foobar.org> <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:54:05 -0000 Hi, On Sun, Apr 02, 2017 at 03:22:49PM -0700, Owen DeLong wrote: > Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD supports RDNSS??? Cisco? For a small fraction of their platforms. Last time I looked, "IOS XE on ASR1000" - not classic IOS, not IOS XR, not NX-OS. So, one customer paid enough to make them add it for their use-case, but "Cisco the company" doesn't seem to believe RDNSS is useful (which is reflected in comments that you can find online, "why should we implement RDNSS if everything important can do DHCPv6?"). Annoying, this. 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 Tue Apr 4 14:08: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 9630D129564 for ; Tue, 4 Apr 2017 14:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 LptEJ50eK7Ua for ; Tue, 4 Apr 2017 14:08:28 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3B5129548 for ; Tue, 4 Apr 2017 14:08:28 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 7970C27327 for ; Tue, 4 Apr 2017 23:08:20 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 67B5733FA48 for ; Tue, 4 Apr 2017 23:08:25 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 7889F39F32; Tue, 4 Apr 2017 23:08:26 +0200 (CEST) Date: Tue, 4 Apr 2017 23:08:26 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20170404210826.GF21163@ernw.de> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <58DE38D5.4050802@foobar.org> <2126F29E-438F-4933-A6C1-4BD34CD971EF@delong.com> <20170404205358.GV25069@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170404205358.GV25069@Space.Net> User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 21:08:31 -0000 Hi Gerd, On Tue, Apr 04, 2017 at 10:53:58PM +0200, Gert Doering wrote: > Hi, > > On Sun, Apr 02, 2017 at 03:22:49PM -0700, Owen DeLong wrote: > > Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD supports RDNSS??? > > Cisco? For a small fraction of their platforms. Last time I looked, > "IOS XE on ASR1000" - not classic IOS, not IOS XR, not NX-OS. not sure if this correct (or I understand your statement correctly), but see here: http://blog.ipspace.net/2014/03/cisco-ios-xe-supports-rfc-6106-rdnss.html [in the comments some more detail on IOS trains] cheers Enno > > So, one customer paid enough to make them add it for their use-case, > but "Cisco the company" doesn't seem to believe RDNSS is useful (which > is reflected in comments that you can find online, "why should we > implement RDNSS if everything important can do DHCPv6?"). > > Annoying, this. > > 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 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Tue Apr 4 14:35: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 4D104127698 for ; Tue, 4 Apr 2017 14:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 ZJ6r9XgUHyq5 for ; Tue, 4 Apr 2017 14:35:23 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2382912967E for ; Tue, 4 Apr 2017 14:35:20 -0700 (PDT) Received: from [IPv6:2001:500:30::cc55:2b3a:1b55:c53b] ([IPv6:2001:500:30:0:cc55:2b3a:1b55:c53b]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v34LYG4v011300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Apr 2017 14:34:17 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPad Mail (14E277) In-Reply-To: <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> Date: Tue, 4 Apr 2017 16:34:16 -0500 Cc: Alexandre Petrescu , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <023E7744-9003-4064-8AFD-1A93A75EDFCA@jisc.ac.uk> <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delo! ng.com> <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> To: Brian E Carpenter X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 04 Apr 2017 14:34:18 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 21:35:25 -0000 > On Apr 4, 2017, at 15:20, Brian E Carpenter w= rote: >=20 >> On 04/04/2017 12:06, Owen DeLong wrote: >>=20 >>> On Apr 3, 2017, at 5:43 AM, Alexandre Petrescu wrote: >>>=20 >>> Le 31/03/2017 =C3=A0 20:26, Fred Baker a =C3=A9crit : >>> [...] >>>> Something that would help me, in this discussion, would be a simple >>>> and incontrovertible statement of what breaks, or in which >>>> circumstances RDNSS would be inappropriate. >>>=20 >>> Not quite a breaking statement, and more implementation aspects: >>> - the main OS distribution on Raspberry Pi does not implement DNS in RA >>> (other such distrib does, but it's rather marginally deployed). >>> - I understand Windows PCs and routers at IETF dont implement DNS in >>> RA, but rather DNS in DHCP. >>>=20 >>> A speculative breaking statement would be: resolver address delivered by= RA overwrites the one delivered by DHCP, despite M=3D=3D1 (or vice-versa).= But never tried it :-) >>=20 >> A network with M=3D1 and RDNSS in the RA packet is, IMHO, misconfigured b= y definition,=20 >=20 > I don't understand that assertion. There's nothing in the definition > of M to suggest that. And even for the O bit, DNS info is only given > as an example use. [RFC4861] AIUI, M=3D1 says "This network is managed and information in RAs should not b= e used for anything other than routing information." I specifically stated M=3D1 rather than O=3D1 because I agree that O=3D1 wit= h RDNSS may be a perfectly valid combination so long as the RDNSS data in th= e RA (if present) agrees with the DNS information in the DHCP6 respons(es) (= if present). > Certainly there's *potential* for misconfiguration, if RDNSS and (stateles= s) > DHCPv6 supply different DNS server addresses. But if they supply the same > address, so what? Yes, but in the case of stateless, that's a different more specific criteria= needed to constitute misconfiguration. I specifically addressed the statefu= l case (M=3D1) where I believe that M=3D1 effectively instructs the host to i= gnore any RDNSS data even if it is present. I believe that placing known unu= sable data in an RA packet constitutes misconfiguration. Owen From nobody Tue Apr 4 14:45: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 0FADA124C27 for ; Tue, 4 Apr 2017 14:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 w1w_nA0n41fC for ; Tue, 4 Apr 2017 14:45:29 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42101293E0 for ; Tue, 4 Apr 2017 14:45:28 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id E2DFA27329 for ; Tue, 4 Apr 2017 23:45:21 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 2B44233FCDE for ; Tue, 4 Apr 2017 23:45:27 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 42DD639F59; Tue, 4 Apr 2017 23:45:28 +0200 (CEST) Date: Tue, 4 Apr 2017 23:45:28 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20170404214528.GI21163@ernw.de> References: <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delo!ng.com> <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 21:45:32 -0000 On Tue, Apr 04, 2017 at 04:34:16PM -0500, Owen DeLong wrote: > > > > On Apr 4, 2017, at 15:20, Brian E Carpenter wrote: > > > >> On 04/04/2017 12:06, Owen DeLong wrote: > >> > >>> On Apr 3, 2017, at 5:43 AM, Alexandre Petrescu wrote: > >>> > >>> Le 31/03/2017 ?? 20:26, Fred Baker a ??crit : > >>> [...] > >>>> Something that would help me, in this discussion, would be a simple > >>>> and incontrovertible statement of what breaks, or in which > >>>> circumstances RDNSS would be inappropriate. > >>> > >>> Not quite a breaking statement, and more implementation aspects: > >>> - the main OS distribution on Raspberry Pi does not implement DNS in RA > >>> (other such distrib does, but it's rather marginally deployed). > >>> - I understand Windows PCs and routers at IETF dont implement DNS in > >>> RA, but rather DNS in DHCP. > >>> > >>> A speculative breaking statement would be: resolver address delivered by RA overwrites the one delivered by DHCP, despite M==1 (or vice-versa). But never tried it :-) > >> > >> A network with M=1 and RDNSS in the RA packet is, IMHO, misconfigured by definition, > > > > I don't understand that assertion. There's nothing in the definition > > of M to suggest that. And even for the O bit, DNS info is only given > > as an example use. [RFC4861] > > AIUI, M=1 says "This network is managed and information in RAs should not be used for anything other than routing information." huh? All (DHCPv6-capable) OSs I know and I've tested (quite a few) perform a stateful DHCPv6 exchange when M=1 AND fully process the RA incl. namely the PIO (hence they have several addresses once A=1). This is, afaik, perfectly valid as of RFC 4862 et al. > > I specifically stated M=1 rather than O=1 because I agree that O=1 with RDNSS may be a perfectly valid combination so long as the RDNSS data in the RA (if present) agrees with the DNS information in the DHCP6 respons(es) (if present). > > > Certainly there's *potential* for misconfiguration, if RDNSS and (stateless) > > DHCPv6 supply different DNS server addresses. But if they supply the same > > address, so what? > > Yes, but in the case of stateless, that's a different more specific criteria needed to constitute misconfiguration. I specifically addressed the stateful case (M=1) where I believe that M=1 effectively instructs the host to ignore any RDNSS data even if it is present. that's not correct. Many OSs take RDNSS information from *both* sources (but behave differently when it comes to prioritize/order those). See https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf, p. 13. Also section 5.3.1 of both RFCs 6106 and 8106 wouldn't be needed if your assertion was correct. > I believe that placing known unusable data in an RA packet constitutes misconfiguration. It may also constitute the network operator's will to properly support different clients in a heterogenuous environment, say a Guest WLAN serving both Android and Windows clients. best Enno > > Owen > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Tue Apr 4 14:56: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 DCF43129409 for ; Tue, 4 Apr 2017 14:56:40 -0700 (PDT) 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 Amtr2hGixyIL for ; Tue, 4 Apr 2017 14:56:39 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001: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 23F22129705 for ; Tue, 4 Apr 2017 14:56:39 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id f103so16307909ioi.2 for ; Tue, 04 Apr 2017 14:56:39 -0700 (PDT) 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=T41qYCwkepV9a6k4kRRj9NV+JqtQ50TBQm5bO82Gv2Y=; b=F//mq9E6/tgF6Z/Gb3aY7x+3EsvvCq5hqGWuJr4HvHKyZVk+/9kdqiRUPSUFeigKzg 2xHOJbHZmHHun3DSj+fMHBSuUOIElTOuo57JyPMGENfxfutrBpPZ/WbDYYhYdH1eWF5+ lP7FWLTeVKjb4mfPpQKGbWKeZ7Aj6hdA0nmbqOhhZsqnybQl7yWRLCG2YyFchN9skzza 90RHSvimLcFGPwaB+AymmRQMGN93q454/hVjXsVzusjZEI9xtE+eGQDfpfhJuyHwUqx8 c7hgyFTCQXHJoBPh+POlFvP/Xe/XPhPXMvE/vqvTC+D6Dcnh9p+L9a2COWOR+VfyualK /L9w== 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=T41qYCwkepV9a6k4kRRj9NV+JqtQ50TBQm5bO82Gv2Y=; b=lprlqwUZYkuohTamtLKBihy67zpnQIkd69LIsxGm8h439rSqC7B3491KRM4ny9ilel sklxbwjGEN3nMJEMoQKiv3JnLKwfHQhU2Lhol3TMkNLsCHpU5rLOwLqETL9LcPj8BMaK FLpPaYtC8tCO1i3RI37+zCtKKeq1cN1VxSaoiGBHGOxu0N/D68Ru4h3d05Yvq9kQIhAk y17/YBRlO+OdTjiU6sNnMkk4PodQtLXyu2bY6m8z4Qi/xpA4ckl25hMznDAt87wJD7Yz VQtv+Dwpxz4HcNdXSYBKDGiNnzsaGLHatrG+343KGGGZTCevbHV7vnMJCQMkYEk4fcGx Q8OA== X-Gm-Message-State: AFeK/H3rrvseQKwVWm2kecLnnY0pX1Tt8VkhffxN0AWoJ/Xx9S74I19EUCDYGDWGeO3bow== X-Received: by 10.107.169.37 with SMTP id s37mr24591471ioe.1.1491342998271; Tue, 04 Apr 2017 14:56:38 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 123sm9704358iow.28.2017.04.04.14.56.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 14:56:37 -0700 (PDT) To: Owen DeLong References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delo! ng.com> <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> Cc: Alexandre Petrescu , v6ops@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <4a6e779c-f9bc-462a-7fb1-abb5d2ee9aec@gmail.com> Date: Wed, 5 Apr 2017 09:56:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 21:56:41 -0000 On 05/04/2017 09:34, Owen DeLong wrote: >=20 >=20 >> On Apr 4, 2017, at 15:20, Brian E Carpenter wrote: >> >>> On 04/04/2017 12:06, Owen DeLong wrote: >>> >>>> On Apr 3, 2017, at 5:43 AM, Alexandre Petrescu wrote: >>>> >>>> Le 31/03/2017 =C3=A0 20:26, Fred Baker a =C3=A9crit : >>>> [...] >>>>> Something that would help me, in this discussion, would be a simple= >>>>> and incontrovertible statement of what breaks, or in which >>>>> circumstances RDNSS would be inappropriate. >>>> >>>> Not quite a breaking statement, and more implementation aspects: >>>> - the main OS distribution on Raspberry Pi does not implement DNS in= RA >>>> (other such distrib does, but it's rather marginally deployed). >>>> - I understand Windows PCs and routers at IETF dont implement DNS in= >>>> RA, but rather DNS in DHCP. >>>> >>>> A speculative breaking statement would be: resolver address delivere= d by RA overwrites the one delivered by DHCP, despite M=3D=3D1 (or vice-= versa). But never tried it :-) >>> >>> A network with M=3D1 and RDNSS in the RA packet is, IMHO, misconfigur= ed by definition,=20 >> >> I don't understand that assertion. There's nothing in the definition >> of M to suggest that. And even for the O bit, DNS info is only given >> as an example use. [RFC4861] >=20 > AIUI, M=3D1 says "This network is managed and information in RAs should= not be used for anything other than routing information." That is not, however, what RFC4861 says. Brian >=20 > I specifically stated M=3D1 rather than O=3D1 because I agree that O=3D= 1 with RDNSS may be a perfectly valid combination so long as the RDNSS da= ta in the RA (if present) agrees with the DNS information in the DHCP6 re= spons(es) (if present). >=20 >> Certainly there's *potential* for misconfiguration, if RDNSS and (stat= eless) >> DHCPv6 supply different DNS server addresses. But if they supply the s= ame >> address, so what? >=20 > Yes, but in the case of stateless, that's a different more specific cri= teria needed to constitute misconfiguration. I specifically addressed the= stateful case (M=3D1) where I believe that M=3D1 effectively instructs t= he host to ignore any RDNSS data even if it is present. I believe that pl= acing known unusable data in an RA packet constitutes misconfiguration. >=20 > Owen >=20 >=20 >=20 From nobody Tue Apr 4 17:45: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 81A771204DA for ; Tue, 4 Apr 2017 17:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, HK_RANDOM_FROM=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=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 CSiP9hBbg0mS for ; Tue, 4 Apr 2017 17:44:55 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 A58B71270A3 for ; Tue, 4 Apr 2017 17:44:55 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id s68so192821715vke.3 for ; Tue, 04 Apr 2017 17:44:55 -0700 (PDT) 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=2igKUhOC4n1Zlm8o6ZW80OG3KlqpJDYEaA3IORNHgTU=; b=IEc+m44tvXgC4Q1yOFuqAQ4DFr4H7D3WHAK55bkSzqqMK6w+XhIrQ+blgL99XZp5GI Z3JPObHfv1il71w+H470gSeVMP2j1GZolCCGAqvJWYrA51oHbUHA7AU0KRHSG1hEOUQt xW0K4g/24Gm3yqrgESDWOnwaNgxnvi2ykzI1kqL5VoJM/XPnRk2QmpnuKdHPIVML5jsy s+pTmsyl6QFVF33iVxEoTJSh0nje+f//Ft1T3B51DYbf47+0++okRVlxVRze3JLjP6qZ bscHoKsuFy52YpaeVQm2WjLZqnM1OjUcdhDLYc1glEuVdk8J+P2ht1sQLsVXDlXjsZCp HzNA== 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=2igKUhOC4n1Zlm8o6ZW80OG3KlqpJDYEaA3IORNHgTU=; b=N/7stAIlJsYfG/yxdjlvYXmlRv/cHCvVFgpdifYHal//oeGtCtMt/K9i+XX0qzYFNo Sj0m+3G5ODs0zFL9ak9EG/F5bsoYxtq8WZsxD2e/lw/Exe/MmQP/HkcnwplZMdNP4h8J gB/HH4sLcRhuKAviiwQIrGoDdGwgkbgTpdKJxbDetk2uQR82SfORKyVwn7J4ycDq8csy 8+SVNt02Pg5TC7ERoiU4QeCX6zXIAx4FDmvZ+TnLrTvwcBh2cew3m3K1bnlnjghxiXeF zl93nOzvWhhyalVyhPvMSfp7e4MnYdAHOFiXdgucv//0LKFQ9gYXDE1Ed2SzAWf75TlS Nt5Q== X-Gm-Message-State: AFeK/H1xzyUvv+HT0wNMPUhJNOt5iRk2LWbCCIFhjzV7qHs/gOFIMf5qxticcYbrgD4trl/8L/kds/3r2B3hxg== X-Received: by 10.31.0.9 with SMTP id 9mr2797813vka.69.1491353094472; Tue, 04 Apr 2017 17:44:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 4 Apr 2017 17:44:23 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> From: Mark Smith Date: Wed, 5 Apr 2017 10:44:23 +1000 Message-ID: To: Owen DeLong Cc: Ted Lemon , IPv6 Ops WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 00:44:58 -0000 On 4 April 2017 at 09:27, Owen DeLong wrote: > >> On Apr 3, 2017, at 3:58 PM, Mark Smith wrote: >> >> On 4 April 2017 at 03:21, Ted Lemon wrote: >>> My reaction to this long and very predictable high-bandwidth back-and-f= orth is that I suspect the outcome will be the same as it was last time: no= action. >> >> The above all makes sense to me. >> >> I don't like that RDNSS exists, because it has caused all this >> trouble, discussion and interoperability problems. Just sticking to >> using stateless DHCPv6 for this purpose would have made much more >> sense to me. > > I don=E2=80=99t think that=E2=80=99s a fair characterization. I think tha= t if you want to complain > about the trouble, discussion, and interoperability problems, you have to= go > back to the root of bifurcating SLAAC and DHCP and allowing multiple zero > configuration address assignment protocols in the first place. RDNSS is > simply the minimum necessary modification to SLAAC to make it actually > usable as a zero-conf protocol. > Being pedantic and in the interests of accuracy, SLAAC has nothing to do with this and using that term will confuse the discussion. SLAAC is an address configuration method that that uses the RA PIO options, and is not involved in DNS configuration. RDNSS and DNSSL information is also conveyed via RA options that are independent of PIO options that are used for SLAAC, so I think it is better to use the general terms "RA RDNSS" or RDNSS to describe the use of these RA options for DNS configuration. > Those that are opposed to RDNSS were mostly opposed to SLAAC without > DHCP for at least O-bit purposes before RDNSS existed and are also > mostly the same people still pushing for routing options in DHCP. > I'm for using SLAAC for addressing and using stateless DHCPv6 for configuring upper layer host parameters such as DNS, NTP, timezone etc. options. I think the problems are different enough that there should be two solution= s. Link specific network layer IPv6 parameters such as what the link's address space is, what available default routers are, what address space is on-link, and what the ND operational parameters are is a separate and link specific problem. A different instance of that problem exists on each link in the network, so the problem is local to a link. A local solution to a local problem is going to be more robust than a remote solution to a link local problem. Upper layer host parameters are host specific and have values that are independent of the link. While it might be useful to have sets of these parameters that are grouped according to a link, there is no inherent requirement to do so - each host on a link can have different upper layer parameters, and it won't prevent them from communicating on the link or beyond it. Flipping that example around, it is error prone for a host to be able to learn of a default gateway that is off-link. That is always a risk if the default gateway information has come from an off-link source such as via DHCP. >> This is a compromise I'm willing to make to my views to make the >> current situation better. What I don't want to see is that then being >> used to justify importing DHCPv6 options into RAs and RA options into >> DHCPv6, as though there is and will be no problems and no additional >> costs in doing so. This discussion is a real and live demonstration of >> those sorts of problems and costs. > > I don=E2=80=99t think that the former is being proposed at all and as to = the latter, > the route information in DHCP6 option has been something some subset > of the populace has been pushing for long before, so I don=E2=80=99t thin= k adding > MTI RDNSS for routers and hosts will significantly change that situation. > It has already happened at least once, and RDNSS was used to justify it. "The IPv6 Router Advertisement Option for NTP Configuration" https://tools.ietf.org/id/draft-chen-ntps-ra-opt-00.txt "The reasons of using RAs to transport the prefix information option based on the ND protocol [RFC4861] are very similar with those of using RAs to transport the information of DNS servers [RFC5006]:" This RA NTP option proposal is what prompted me to mention limiting upper layer RA options to RDNSS in the "Internet Transparency and Application Configuration" section of this draft: "IPv6 CE Device DHCPv6 Option Transparency" https://tools.ietf.org/id/draft-smith-v6ops-ce-dhcpv6-transparency-00.txt >> I think having two similar methods for configuring DNS has been a >> mistake. We should call it out as such, work around it in the interest >> of operability, and then say and make sure we're not going to make >> that sort of mistake again (I think it has been already made twice - >> SLAAC vs stateful DHCP for address configuration, a view that seems to >> be commonly based on the flawed premise that DHCP provides an accurate >> record of MAC addresses and corresponding address use). > > I think allowing incompatible subsets of the two mechanisms is the mistak= e. > Requiring the overhead of DHCP just to provide DNS server information was > a mistake and the original demand for RDNSS is sufficient proof of that t= hat I > don=E2=80=99t feel the need to expand further. > I don't understand this view that DNS information is the only additional information a host needs over its addresses and default gateways. How does a host set its real time clock correctly in an automated fashion? I find pages like this one to be ridiculous when it is possible to buy an off-the-shelf near self driving car. http://www.internode.on.net/support/guides/general_settings/ When I configured the DHCPv6-PD server on the BRAS at that organisation, I put all of those parameters in as DHCPv6 parameters, so that they could be configured automatically, rather than the customer having to manually cut-and-paste them, a possibly error prone procedure. The reason I wrote the above draft was that even though the DHCPv6-PD server might support providing those options, the down stream hosts which would want and use those options may not be able to successfully ask for them, because the CPE's combined DHCPv6 WAN side client and LAN side server might not support the DHCPv6 options that the up stream DHCPv6-PD server and the downstream host client supported. >> I also think it is necessary to state whether stateless or stateful >> DHCP is being described or referred to. If I don't see any qualifier, >> I assume stateful, which I also think others do too, and that then >> creates a loaded discussion that implies that IPv6 addressing will >> also be handled by (stateful) DHCPv6. The conversation can then >> devolve into one that is also discussing the use of SLAAC vs stateful >> DHCPv6 for addressing too. > > I think it=E2=80=99s important to recognize that we are talking about a M= TI requirement, > not a must use or must deploy requirement. IMHO, the MTI should, for host= s, > include SLAAC, RDNSS, and where practical/feasible stateless and stateful > DHCP6. For routers, it should include SLAAC, RDNSS, stateful and stateles= s > DHCP6. > > In this way, the routers and hosts ship with the ability for the operator= to choose > the subset of SLAAC/RDNSS/Stateful/Stateless that best suits their enviro= nment > and best meets the needs of their hosts and users. > I think one of the major causes of the gap we're now encountering is because operators of networks, including and more recently enterprises, don't have as much control over the features and options of the devices/host implementations that expect to attach to the network as they used to. End-users expect the mobile device that they've bought independently of their employer to be able to be seamlessly be attached to their employer's network. Retail of the shelf devices such as Apple TVs are expected to just work when they're plugged into the corporate network (assuming the person buying it has permission to use it). Regards, Mark. From nobody Tue Apr 4 20:48: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 C9208127011 for ; Tue, 4 Apr 2017 20:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 PDPD5l2ydOe3 for ; Tue, 4 Apr 2017 20:48:21 -0700 (PDT) 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 5B3AC1204DA for ; Tue, 4 Apr 2017 20:48:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DC99BA2; Wed, 5 Apr 2017 05:48:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491364096; bh=vad2lgU0TO6FE88r8IX/Veua8UqBB5BHysn60/p/KQQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=VFFXxMtl5LZPDRtGWOMg5zPM0/P/JPAKOC9NxwtXrMf78BTsd20ZgfekqNhrEn67Y MvZaEkl4KYYEnso/RxlYX20vzepI++8brrFsBm4LoslxbDqEmvhZrkEzm9Ue2KoVPs wZ2lXVWwOUHu0mf52jsrYF0kQOY9UfVcau2bM42I= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C3DB588; Wed, 5 Apr 2017 05:48:16 +0200 (CEST) Date: Wed, 5 Apr 2017 05:48:16 +0200 (CEST) From: Mikael Abrahamsson To: Owen DeLong cc: Brian E Carpenter , v6ops@ietf.org In-Reply-To: Message-ID: References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <9F1FB8F4-BBAE-4D76-8D1B-E621E1140024@delo! ng.com> <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 03:48:24 -0000 On Tue, 4 Apr 2017, Owen DeLong wrote: > AIUI, M=1 says "This network is managed and information in RAs should > not be used for anything other than routing information." Nope, the only thing it indicates is a hint to devices on the link that there might be additional addresses available using DHCPv6. Btw, from a MIF scenario, what happens if there are two routers on the link advertising different PIOs, and both of them have DHCPv6 IA_NA providing servers. Does this even work? What about stateless information, can they each provide a resolver (so a MIF aware host can use each resolver depending on if it's going to use an address out of PIO1 or PIO2). R1 announces PIO1 and M=1 R2 announces PIO2 and M=1 R1 --- H1 R2 -/ (all devices are on the same LAN) Both R1 and R2 has a built in DHCPv6 server. Does getting one IA_NA out of each PIO work? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 5 00:34: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 431F31292FD for ; Wed, 5 Apr 2017 00:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 HYvcZUUa9WRV for ; Wed, 5 Apr 2017 00:34:12 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 7ACEE129438 for ; Wed, 5 Apr 2017 00:34:07 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id z204so2583145vkd.1 for ; Wed, 05 Apr 2017 00:34:07 -0700 (PDT) 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=Fl1v0H/09qbqtfTaadpAHXh3NSC33OcruhNpGVzfdiY=; b=cSX+dsVd7qviwoJ2rq/+CIgpAadr4IaIKUKBzWA+PYfKFnY0f7/WvRy4kTDHrFkeqs se5IXUYiuer6sLP6kmcIofI1RrHaF3jNVJhLwJLUD1XkSfSpjnq7NwoNiviHYDzojv/F rtVvRixuIczA/Wd9IJf2NbuWJBZ8f6psMqJv4y0++W1nFleA+MysPnC4VZvc39QyA1Pp ihEIowqiLV5BoJp4nPibSrFGabwvEcPOKdDqGsk/MXootSYld9Hvyop09MLGaaEOkY/b xzP50ztxSz6Io2ai4DTsPFIZDNf7FfCE6MKPOn8r4RW7QQ22Y51uS0Ss1Sm+ZYS27XxJ zp4Q== 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=Fl1v0H/09qbqtfTaadpAHXh3NSC33OcruhNpGVzfdiY=; b=flNelpclNTnFEo1oFJGxOmqQbcEp7qeOdSKQ7InxSXDeZU0ROV8gMVjGFBlhOvninC XQTufgIH53cckHda0Bh4WZbsArpPyaZNdDpvpZyIbrR8k3R4vo00fZuakH3V5mnG7bIU oHVaZ/C8sxOzNVLq0BBu/l7uZ/4uns+GPY/d1ZRQmmzJ06REQs0SG7Y287naQCi7/ihP 5vcqK9b372efBKc1GfURUz8lq8qcY6P8bGBU207LJ/jH9+hW6FD7W1pH9r8wRi7N2k23 D7BarUwtiCOQeXozld4/agcTmi1ol1bdZhojNXejNJqQoLVJxT0EeRp/sgQpYfkTP40z rTrg== X-Gm-Message-State: AFeK/H1qKBmVy6q4K1lAu2Ay+zaM7he0UyxQBDFuK/RD9ep9yef+5nVe9OEbDzgVLZK+U5MOBH5O5z93jIfsvxJc X-Received: by 10.31.107.93 with SMTP id g90mr12473094vkc.155.1491377646272; Wed, 05 Apr 2017 00:34:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 00:33:45 -0700 (PDT) In-Reply-To: References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> From: Lorenzo Colitti Date: Wed, 5 Apr 2017 16:33:45 +0900 Message-ID: To: Mikael Abrahamsson Cc: Owen DeLong , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11478dd0d56d20054c666a1d Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 07:34:14 -0000 --001a11478dd0d56d20054c666a1d Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 12:48 PM, Mikael Abrahamsson wrote: > Both R1 and R2 has a built in DHCPv6 server. Does getting one IA_NA out of > each PIO work? In theory, maybe. In practice, no, because clients use the first OFFER they receive. DHCPv6 is pretty fundamentally incompatible with having multiple sources of information. Even if clients chose between multiple offers, and were thus able to select from multiple sources of information at the time the SOLICIT was sent, how would you deal with introducing a new source of information? This is one of the many reasons why DHCPv6 does not work well in dynamic networks, and of course, it is a problem that RAs and RDNSS do not have. The only reason why DHCP works well today is because in IPv4 you only have one address and one default route, and most networks are NATed so nothing needs to change. In fact, I personally think the biggest lie in DHCP is the D. It should have been called SHCP - where S is for Static. :-) --001a11478dd0d56d20054c666a1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 5, 2017 at 12:48 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
Both R1 a= nd R2 has a built in DHCPv6 server. Does getting one IA_NA out of each PIO = work?

In theory, maybe. In practice, no, be= cause clients use the first OFFER they receive.

DH= CPv6 is pretty fundamentally incompatible with having multiple sources of i= nformation. Even if clients chose between multiple offers, and were thus ab= le to select from multiple sources of information at the time the SOLICIT w= as sent, how would you deal with introducing a new source of information?

This is one of the many reasons why DHCPv6 does not= work well in dynamic networks, and of course, it is a problem that RAs and= RDNSS do not have.

The only reason why DHCP works= well today is because in IPv4 you only have one address and one default ro= ute, and most networks are NATed so nothing needs to change. In fact, I per= sonally think the biggest lie in DHCP is the D. It should have been called = SHCP - where S is for Static. :-)
--001a11478dd0d56d20054c666a1d-- From nobody Wed Apr 5 00:36: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 A15C412940F for ; Wed, 5 Apr 2017 00:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 DLo84p7V-_Ci for ; Wed, 5 Apr 2017 00:36:31 -0700 (PDT) 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 35EA31243F6 for ; Wed, 5 Apr 2017 00:36:27 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id s68so2592991vke.3 for ; Wed, 05 Apr 2017 00:36:27 -0700 (PDT) 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=zZlfKWg159nKDzpschBGARMS82P5YYNVf9SjyQjzrpg=; b=Y0fJVNx5LPfyAdb71+/inRr4sdEaaumdE+Xt2jEu2XBjAW5A9vqv3cyMgZ3uRZjY19 6sS0noU9qsORvT6yHU1Ry8ICtiF87g7Ie6J0kr0c+yR6WD5ZlsvC77ITIG27GJPyT6VS Fcv57rxHBipXu4QY4WnZCes9bmEzxw51Tk8wTk/qXYMVcWeF6omHwZ3KhLtSl4p4xlSv nKvNFIpvDf+Th5yMpAUEaKjiwJbLSUeYLtJLIoVCZ2fpdG5q/vj/Kvo9WBTnfob6fCFb 9nMkHTzvFoirZ2AwEnCAT2uEDEPKS9MwkqKYlnfNz+2iMVQ1vOxJCnZniwfOmHGvfLSC kU2A== 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=zZlfKWg159nKDzpschBGARMS82P5YYNVf9SjyQjzrpg=; b=jmuysWmlns+aDcwCmNMZiLdPpOPxi6PI/rnHB1NfuY9YzJqX0b6su1r/MYgDFNySTL xsBOGsESSv30EQMljkKUOBgNgj3pv+seC/mBoyK0pRt56LQdHJIDmru92GqB1DJlz7XP p1AaIBGSBpb0TICVErL6qJdf5L8FFqQfZfrEdr8DrDoH16vrSOR4tPbkcUCFJQgMHt/C m6LNHhAtBuS20Z21q5tSPOQiJyELpbQLDk43kCzzr9COKb72LT4iWCdeWWLNY+jG4+sm EH91IDjQQdOtEhdtA/v3DV869mo/YjNIhi+N3iQ9IsKEA1t3otWRKz1XE0bfYUgSXH3v IxYQ== X-Gm-Message-State: AFeK/H3ex6JjtN7k+664XWDcNzUCpgK11mmaZBE0BJfD+qfqpYYaBnqjxwLRgRs47ofr2gpopKEelias3kM5CxM8 X-Received: by 10.31.60.17 with SMTP id j17mr8043324vka.45.1491377786064; Wed, 05 Apr 2017 00:36:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 00:36:04 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> From: Lorenzo Colitti Date: Wed, 5 Apr 2017 16:36:04 +0900 Message-ID: To: Tim Chown Cc: Ted Lemon , IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11436e502a7394054c667391 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 07:36:34 -0000 --001a11436e502a7394054c667391 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 4, 2017 at 10:12 PM, Tim Chown wrote: > I also see enterprise network admins running IPv6 today who are wondering > how they=E2=80=99ll configure (say) NTP server settings, or other setting= s only > available by stateless DHCPv6 and not via RAs. What=E2=80=99s the answer = for them, > as we move to IPv6-only operation? > Speaking for the Android implementation only - Android has never supported any of those options anyway, even in IPv4: /* package */ static final byte[] REQUESTED_PARAMS =3D new byte[] { DHCP_SUBNET_MASK, DHCP_ROUTER, DHCP_DNS_SERVER, DHCP_DOMAIN_NAME, DHCP_MTU, DHCP_BROADCAST_ADDRESS, // TODO: currently ignored. DHCP_LEASE_TIME, DHCP_RENEWAL_TIME, DHCP_REBINDING_TIME, DHCP_VENDOR_INFO, }; --001a11436e502a7394054c667391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 4, 2017 at 10:12 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
I also see enterprise network admi= ns running IPv6 today who are wondering how they=E2=80=99ll configure (say)= NTP server settings, or other settings only available by stateless DHCPv6 and not via RAs. What=E2=80=99s the ans= wer for them, as we move to IPv6-only operation? =C2=A0

Speaking for the Android implementation only - And= roid has never supported any of those options anyway, even in IPv4:

=C2=A0 =C2=A0 /* package */ static final byte[] REQU= ESTED_PARAMS =3D new byte[] {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCP_SU= BNET_MASK,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCP_ROUTER,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 DHCP_DNS_SERVER,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 DHCP_DOMAIN_NAME,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCP_MTU,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCP_BROADCAST_ADDRESS, =C2=A0// TODO: = currently ignored.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCP_LEASE_TIME,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCP_RENEWAL_TIME,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 DHCP_REBINDING_TIME,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 DHCP_VENDOR_INFO,
=C2=A0 =C2=A0 };
=
--001a11436e502a7394054c667391-- From nobody Wed Apr 5 01:58: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 2E1DF129426 for ; Wed, 5 Apr 2017 01:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfN8IOkqKuvM for ; Wed, 5 Apr 2017 01:58:24 -0700 (PDT) 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 EA730129418 for ; Wed, 5 Apr 2017 01:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491382702; bh=zCW+elTHH4aLdxPmNt07IGr3fsk29f7pCoh7SFWEgRA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=INZJWOEplp51A0vx7YVyf5bUn878nNnVfaQL0ifCdSAKoCEWN80Hnh6INYGq9PlXg5PVII4Tyt04mzKU5ZP9ME5M4VputOtRjP2sAJmDr3dKzc0vEP6RGNwIAXml7Y1PheQgecUSxw+sVg1nBd4zzagTG4Yo4/F2t5LDuUkrQB4= 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-111-gEl0JzatMBC_VmM_nLHXYg-1; Wed, 05 Apr 2017 09:58:19 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Wed, 5 Apr 2017 08:58:18 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Wed, 5 Apr 2017 08:58:18 +0000 From: Tim Chown To: Lorenzo Colitti CC: Mikael Abrahamsson , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGtY7oAgAAYnICAAAT9AIAAZM8AgAAOCQCAAMuvfYAAJiQAgAAFCe+AAA2VAIAACV1hgAADj4CAAAObUYAAAIjugAASD4CAACtCgIAEVx0AgAC+pgCAAVNDAIAAFKYAgABofwCAAD7/gIAAF54A Date: Wed, 5 Apr 2017 08:58:18 +0000 Message-ID: <619931BD-8884-47F2-B744-8ADA095E52F2@jisc.ac.uk> References: <99e762f3-5246-2039-4b22-83e36293e61a@nlogic.no> <58DE7B25.7020409@foobar.org> <7D55CAB4-0581-47AD-9BCF-CF511E57E3DA@gmail.com> <8d4da708-e7e6-2d36-42f6-cfc4e772b201@gmail.com> <259b5ccb-9f19-71e5-92c1-942fa6b28d40@gmail.com> 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-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:e4qa4yoBJ2TF4Un/nXGcVewLHWqHwJ/vJBi9aNcXA7y5+UKs0pjMKHYjM1NpyQZ7TgGI7m03L1hecpKhK/No59On8c/EkUQ4PDGun2UvyKFHg19/YxUzjjlBlawMIm3PnN2KNHBrlnmruNdAjDDon1px0Plf6904cUKklr4URzye8jklP1TuDD4oRplj1v2yCIdGfZ+8WMgyQNYZ/uaJSHfoqpUXVw86AiDadziJxFCrWw+HXpmxoCG96W108NEOluv3q+fU803votwsNibprxdH7qINg+HnDv9dsA9YzkaezjnV38Y9zNz24BJ64zs7oL6ElMc1kDgExToc4fS06w==; 20:OOHcUGw6iclBv+U9YoUeGgFPIi7v+dqbra3+C/FBNlTlp0s27UeQ7bF4+zhUfm8HzFjzA00rLK37IltRdDolXjAcpPQBnTwwmxmf6n7lbo6jIYthSYGshgD0R7/K0bkr3EyDr85NljxRB2ms6JC4R9fp7y/IGlr1ZeHszc4EQFs= x-ms-office365-filtering-correlation-id: 79deaee1-657e-40ab-5930-08d47c01e72c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(377454003)(24454002)(53936002)(2906002)(102836003)(6116002)(3846002)(81166006)(50226002)(8676002)(8936002)(6246003)(305945005)(3660700001)(3280700002)(7736002)(5660300001)(5250100002)(189998001)(2900100001)(99286003)(93886004)(66066001)(86362001)(6486002)(25786009)(4326008)(54906002)(53546009)(6506006)(38730400002)(110136004)(83716003)(6436002)(82746002)(6512007)(229853002)(76176999)(50986999)(74482002)(2950100002)(6916009)(42882006)(36756003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 08:58:18.0306 (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: gEl0JzatMBC_VmM_nLHXYg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 08:58:27 -0000 PiBPbiA1IEFwciAyMDE3LCBhdCAwODozMywgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2ds ZS5jb20+IHdyb3RlOg0KPiANCj4gT24gV2VkLCBBcHIgNSwgMjAxNyBhdCAxMjo0OCBQTSwgTWlr YWVsIEFicmFoYW1zc29uIDxzd21pa2VAc3dtLnBwLnNlPiB3cm90ZToNCj4gQm90aCBSMSBhbmQg UjIgaGFzIGEgYnVpbHQgaW4gREhDUHY2IHNlcnZlci4gRG9lcyBnZXR0aW5nIG9uZSBJQV9OQSBv dXQgb2YgZWFjaCBQSU8gd29yaz8NCj4gDQo+IEluIHRoZW9yeSwgbWF5YmUuIEluIHByYWN0aWNl LCBubywgYmVjYXVzZSBjbGllbnRzIHVzZSB0aGUgZmlyc3QgT0ZGRVIgdGhleSByZWNlaXZlLg0K PiANCj4gREhDUHY2IGlzIHByZXR0eSBmdW5kYW1lbnRhbGx5IGluY29tcGF0aWJsZSB3aXRoIGhh dmluZyBtdWx0aXBsZSBzb3VyY2VzIG9mIGluZm9ybWF0aW9uLiBFdmVuIGlmIGNsaWVudHMgY2hv c2UgYmV0d2VlbiBtdWx0aXBsZSBvZmZlcnMsIGFuZCB3ZXJlIHRodXMgYWJsZSB0byBzZWxlY3Qg ZnJvbSBtdWx0aXBsZSBzb3VyY2VzIG9mIGluZm9ybWF0aW9uIGF0IHRoZSB0aW1lIHRoZSBTT0xJ Q0lUIHdhcyBzZW50LCBob3cgd291bGQgeW91IGRlYWwgd2l0aCBpbnRyb2R1Y2luZyBhIG5ldyBz b3VyY2Ugb2YgaW5mb3JtYXRpb24/DQoNCldlbGwsIHdlIGJhdHRlZCBhcm91bmQgdGhvdWdodHMg b24gdGhpcyBzb21lIHRpbWUgYWdvIGluIFJGQzQ0NzcsIGluIHRoZSBjb250ZXh0IG9mIERIQ1B2 NCBhbmQgREhDUHY2IGNvLWV4aXN0aW5nOyBubyBjbGFzaCBvbiBhZGRyZXNzZXMsIGJ1dCBwb3Rl bnRpYWxseSBhIGNsYXNoIG9uIG90aGVyIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uICBJZiBp dOKAmXMgb25lIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgaXQgc2hvdWxkIGJlIGNvbnNpc3RlbnQg aW5mb3JtYXRpb24uDQoNCj4gVGhpcyBpcyBvbmUgb2YgdGhlIG1hbnkgcmVhc29ucyB3aHkgREhD UHY2IGRvZXMgbm90IHdvcmsgd2VsbCBpbiBkeW5hbWljIG5ldHdvcmtzLCBhbmQgb2YgY291cnNl LCBpdCBpcyBhIHByb2JsZW0gdGhhdCBSQXMgYW5kIFJETlNTIGRvIG5vdCBoYXZlLg0KDQpJIGFn cmVlIG9uIHRoZSB0ZWNobmljYWwgbWVyaXRzIG9mIFJBLWJhc2VkIGNvbmZpZywgYnV0IGluIGEg dHlwaWNhbCBlbnRlcnByaXNlIHRoZSBhZGRyZXNzZXMgb2YgdGhlIEROUywgTlRQIGFuZCBvdGhl ciBzZXJ2ZXJzIGlzIHByZXR0eSBzdGFibGUuIEkgZG9u4oCZdCByZW1lbWJlciBjaGFuZ2luZyB0 aGVtIGF0IG91ciB1bmkgZm9yIG1hbnkgeWVhcnMuICANCg0KPiBUaGUgb25seSByZWFzb24gd2h5 IERIQ1Agd29ya3Mgd2VsbCB0b2RheSBpcyBiZWNhdXNlIGluIElQdjQgeW91IG9ubHkgaGF2ZSBv bmUgYWRkcmVzcyBhbmQgb25lIGRlZmF1bHQgcm91dGUsIGFuZCBtb3N0IG5ldHdvcmtzIGFyZSBO QVRlZCBzbyBub3RoaW5nIG5lZWRzIHRvIGNoYW5nZS4gSW4gZmFjdCwgSSBwZXJzb25hbGx5IHRo aW5rIHRoZSBiaWdnZXN0IGxpZSBpbiBESENQIGlzIHRoZSBELiBJdCBzaG91bGQgaGF2ZSBiZWVu IGNhbGxlZCBTSENQIC0gd2hlcmUgUyBpcyBmb3IgU3RhdGljLiA6LSkNCg0KU28gZmlsZSBhbiBl cnJhdHVtIDopDQoNClRpbQ0KDQo= From nobody Wed Apr 5 02:03: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 981781293E4 for ; Wed, 5 Apr 2017 02:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q79RKWXuNbOr for ; Wed, 5 Apr 2017 02:03:24 -0700 (PDT) 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 A8831128CDC for ; Wed, 5 Apr 2017 02:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491383002; bh=SEyrcmhEJ8CJxM3zSyLqOXcysMDSTEtd+wEEA7A9E3o=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VV6S10HK7DCCx65o5WhrFUHTQxYVtL4eEVHU/rO6EI/X9plZqpCHBREK433thocsvvClS0UXApayQZiN/92eFhjB/V27BEhu3liPDNazue3RmlsdNYEBlV086FTDZyMmgpAI0MshIWndI8dhnBShIqokz18ePuqvcXbwvpvHx2I= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0115.outbound.protection.outlook.com [213.199.154.115]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-5-aYyQuxXbPtO5wy2u21AcUQ-1; Wed, 05 Apr 2017 10:03:14 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Wed, 5 Apr 2017 09:03:13 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Wed, 5 Apr 2017 09:03:12 +0000 From: Tim Chown To: Lorenzo Colitti CC: Ted Lemon , IPv6 Ops WG Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGuSN8AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ICAAA0U4IAADhwAgAAJQYCAAUf3gIAABLgAgAE0YwCAABhYAA== Date: Wed, 5 Apr 2017 09:03:12 +0000 Message-ID: <76ECFCA3-60EF-4CAA-8075-F7E2747935B6@jisc.ac.uk> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> 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-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:C8MvdnqZh5fijr9CVagcHeYHZl7wNxMJKeAv/py4eDpT8hQzXU6TZa1nuXhwzlfR50dhn1FDVddow2/VU/oNODkZLXcvvpDPyHStiGJ4yZ7122+Lc9+rTq2gKtrNShWj0lKjRb5Z9rsdFCdHK1UjfqIfB071b7ZqQcMg/Grj87z0XOx5gsreuBpOTtJVjL8WepWyZkioqZi4o98q79/6pxrxcNvJUd7UuNQfE90GgQaQ3+jWZhz2tpFrDnpZKufpxMWORvdZgz3SgCrgbTLkTugT0uf3pfrzci93UrZLd6+ix15L+gbeG8EFje9Vu6jvXvm00tQvVZBY3CBxc36ngg==; 20:lvGAuOsVusyX9UEMSa9f/uoVCUr9vosU+4+CPAl8TfG2AO+bALO2+c62rPveL9DUk0Ukwf/ZeYK/MMeBJUpMckNYENZAhOneLBHut+2hAtkfkIqNO7hOZAXXypMIQ7u0vjdhHdPwc+iZlSoMjtRlR0Tge0nb6+vmWSJXnfdhAeI= x-ms-office365-filtering-correlation-id: 7f8f7cbf-01ff-4e52-f8e9-08d47c0296e9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(158342451672863)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39840400002)(39450400003)(52314003)(24454002)(377454003)(53546009)(81166006)(25786009)(8676002)(50226002)(189998001)(83716003)(86362001)(82746002)(6246003)(74482002)(6916009)(76176999)(42882006)(2950100002)(50986999)(53936002)(7736002)(33656002)(93886004)(2900100001)(8936002)(305945005)(66066001)(38730400002)(110136004)(3280700002)(3660700001)(2906002)(36756003)(5250100002)(6486002)(4326008)(99286003)(229853002)(3846002)(6512007)(5660300001)(6436002)(6506006)(6116002)(54906002)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 09:03:12.8856 (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: aYyQuxXbPtO5wy2u21AcUQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 09:03:27 -0000 PiBPbiA1IEFwciAyMDE3LCBhdCAwODozNiwgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2ds ZS5jb20+IHdyb3RlOg0KPiANCj4gT24gVHVlLCBBcHIgNCwgMjAxNyBhdCAxMDoxMiBQTSwgVGlt IENob3duIDxUaW0uQ2hvd25AamlzYy5hYy51az4gd3JvdGU6DQo+IEkgYWxzbyBzZWUgZW50ZXJw cmlzZSBuZXR3b3JrIGFkbWlucyBydW5uaW5nIElQdjYgdG9kYXkgd2hvIGFyZSB3b25kZXJpbmcg aG93IHRoZXnigJlsbCBjb25maWd1cmUgKHNheSkgTlRQIHNlcnZlciBzZXR0aW5ncywgb3Igb3Ro ZXIgc2V0dGluZ3Mgb25seSBhdmFpbGFibGUgYnkgc3RhdGVsZXNzIERIQ1B2NiBhbmQgbm90IHZp YSBSQXMuIFdoYXTigJlzIHRoZSBhbnN3ZXIgZm9yIHRoZW0sIGFzIHdlIG1vdmUgdG8gSVB2Ni1v bmx5IG9wZXJhdGlvbj8gIA0KPiANCj4gU3BlYWtpbmcgZm9yIHRoZSBBbmRyb2lkIGltcGxlbWVu dGF0aW9uIG9ubHkgLSBBbmRyb2lkIGhhcyBuZXZlciBzdXBwb3J0ZWQgYW55IG9mIHRob3NlIG9w dGlvbnMgYW55d2F5LCBldmVuIGluIElQdjQ6DQo+IA0KPiAgICAgLyogcGFja2FnZSAqLyBzdGF0 aWMgZmluYWwgYnl0ZVtdIFJFUVVFU1RFRF9QQVJBTVMgPSBuZXcgYnl0ZVtdIHsNCj4gICAgICAg ICBESENQX1NVQk5FVF9NQVNLLA0KPiAgICAgICAgIERIQ1BfUk9VVEVSLA0KPiAgICAgICAgIERI Q1BfRE5TX1NFUlZFUiwNCj4gICAgICAgICBESENQX0RPTUFJTl9OQU1FLA0KPiAgICAgICAgIERI Q1BfTVRVLA0KPiAgICAgICAgIERIQ1BfQlJPQURDQVNUX0FERFJFU1MsICAvLyBUT0RPOiBjdXJy ZW50bHkgaWdub3JlZC4NCj4gICAgICAgICBESENQX0xFQVNFX1RJTUUsDQo+ICAgICAgICAgREhD UF9SRU5FV0FMX1RJTUUsDQo+ICAgICAgICAgREhDUF9SRUJJTkRJTkdfVElNRSwNCj4gICAgICAg ICBESENQX1ZFTkRPUl9JTkZPLA0KPiAgICAgfTsNCg0KVGhhdOKAmXMgYWN0dWFsbHkgYSB2ZXJ5 IGhhbmR5IHRoaW5nIHRvIGtub3csIHRoYW5rcy4NCg0KVGlt From nobody Wed Apr 5 02:23: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 8B247126D05 for ; Wed, 5 Apr 2017 02:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 YBu3f-grf4zJ for ; Wed, 5 Apr 2017 02:23:33 -0700 (PDT) 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 220F2129412 for ; Wed, 5 Apr 2017 02:23:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvhA2-0000G1C; Wed, 5 Apr 2017 11:23:30 +0200 Message-Id: To: v6ops@ietf.org Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> In-reply-to: Your message of "Tue, 4 Apr 2017 13:23:36 -0700 ." Date: Wed, 05 Apr 2017 11:23:27 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 09:23:35 -0000 >Now, focusing on the main question, I see some level of support for >option #2, although I also see a non-marginal number of objections. If the question is "Do you support making RDNSS a MUST, saying nothing about DHCP DNS" then my answer is that I oppose that. From nobody Wed Apr 5 02:38: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 123BC129454 for ; Wed, 5 Apr 2017 02:38:10 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 dFMP0e0vdrPd for ; Wed, 5 Apr 2017 02:38:08 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 4020D126D05 for ; Wed, 5 Apr 2017 02:38:08 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id g30so4548224uab.0 for ; Wed, 05 Apr 2017 02:38:08 -0700 (PDT) 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=M62JsDAJFyIhS/+lfy5U63FRQ0eHdfmAt5CC5GIQeMs=; b=tzmmqoUuXmPcc7qjYU+0r1tmpfgxw9WmNrLHNVFq7EP+JWoJtYDzLTotXxXvZ3XPvR 5/76ahrPxUwGYD4HYgXn6Rd4FT568F/6jKiH2e5EVPX3Twz9FYKcFUnMVBipU/QEsW/I 5959CZhm1lupUSoDWkSVzJRJAwC72OwUY3FOHK8Kggy9Bdl52StgCWjDeuo4eSe9yYqQ /JcjUIbTQ+842ahBRBLDvmG153khQL+hMT/M+sao5BQzpWrNbRbBl8dZJZ5KVetV5us6 6DWnysfhPdmxq5mE0aLZyVje650Xm7eqy9/GtDpf3zgar1rowpEqOfrHSqpHbcK2sjnd 6OJA== 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=M62JsDAJFyIhS/+lfy5U63FRQ0eHdfmAt5CC5GIQeMs=; b=JJScdCCG+sRX6MuL2K8qOALKF9dD/eCz7Rq6ibfICT+G/FGtdzvKcK+n3yCoPQlINE yZO5kLOqDPvl9H1ZDu0dvRfbui3t/6VNKNUQq8LpgSI+zp0BeLFDQdBrm7gs2R3kfpqo 8JvumDfRwxpfVSDwHeZGNfwXAggato98SmHQKCxIyqbTfZoqkEVrsw8CQN4QuMbe+a9T 5MUQsELyev90q95HOJ6p8rygbY0kEO6L7AGfVptVwgUf1OD8zTXpfKNq5iFzNO0vBZi7 m0+w94iwKdfONRioA8B110nORSRxOyRtiBCmLTKCd3CG2eeOnnwynJPDcReY24T9IQbg pElg== X-Gm-Message-State: AFeK/H0S9EQvpH0s+znzcLP9Mxgg1Buag7eRuJ9q2+9A4eB6LoD0zgfPEg4Ms/0Sxmf15ST1yqOVQPrwnzRJi7Hi X-Received: by 10.159.36.77 with SMTP id 71mr14922391uaq.124.1491385087007; Wed, 05 Apr 2017 02:38:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 02:37:45 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> From: Lorenzo Colitti Date: Wed, 5 Apr 2017 18:37:45 +0900 Message-ID: To: Philip Homburg Cc: "v6ops@ietf.org WG" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a113dc80e562235054c68269b Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 09:38:10 -0000 --001a113dc80e562235054c68269b Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 6:23 PM, Philip Homburg wrote: > If the question is "Do you support making RDNSS a MUST, saying nothing > about DHCP DNS" then my answer is that I oppose that. Ok, so you're saying that of the two options, you choose option #1: do nothing and keep the current situation where there no method is required to be supported. --001a113dc80e562235054c68269b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 5, 2017 at 6:23 PM, Philip Homburg <pch-v6ops-7@u-1.phico= h.com> wrote:
If the questi= on is "Do you support making RDNSS a MUST, saying nothing
about DHCP DNS" then my answer is that I oppose that.

Ok, so you're saying that of the two options, you choos= e option #1: do nothing and keep the current situation where there no metho= d is required to be supported.
--001a113dc80e562235054c68269b-- From nobody Wed Apr 5 05:23: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 33919127863 for ; Wed, 5 Apr 2017 05:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dkRlX498-mFQ for ; Wed, 5 Apr 2017 05:23:26 -0700 (PDT) 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 7CE7112773A for ; Wed, 5 Apr 2017 05:23:26 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id x125so7326842pgb.0 for ; Wed, 05 Apr 2017 05:23:26 -0700 (PDT) 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=yVgpeYL88QrxpddXQ84G6Vqbgal/1xkLltxj56sII8w=; b=MY8fnBpzmOSbhkt0Lp1A5pnB4PR1REmcvA81kbzpegvkzvxyi482ZS0OnLEhCKT5Zx 0Dt2je1mvKIq4fgyRPOeDcTrbp31lsgkIzO21F/Y/Kyx4Ce8Dq2gufbEsWxQxGf7ADyi br5ot0XDyIK9XE6/MhdtdnscCkB8DCPSiXVaqyvt8IOe8rvF4VfEw+XDvYJPWYiFtave S9/8VudmipP1oIknbPOV7BMH0tirxhm4xETXUoSB9g/wSne8Pb73iOVXlEzEXNnYbC7p pnyBEMipzTKlxbNEP485cdw7IOfl6x7NLTIFyETid2qIZwb9lIVOoe5bT4DEiKCIJKYK +vrA== 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=yVgpeYL88QrxpddXQ84G6Vqbgal/1xkLltxj56sII8w=; b=Y8JJV/27p4SIDq60Uj6528G8MbZnEBDb5i39vmZUH64F7YLuvdRCwkZWOZ9eget6FK CxGQSf2uY5UTm3N/8OLZHrQ7eV9nTQwo+/uR/KePxrFmcwG72hsZ29XGeqnLHhzj4Pnc Ubcii7FG3bpSLmW2qMaTsx2gAQpIniIGqB/rfJGfLpiYrMIdWUibNHKJa2bU/bANNGEM 16OwEDNBf7rSRRsK2kXypzphjZDbh8kXyt2n5hfnWo3pO+U0NpGvmnCR2ON47W5XBnDt 2CB/MKa7EUTohD0g1LACbhjdVmW2KbsGcgqXQH+wuhNBwe8wwW1pTU1RI7CcJOplZQ8t CAew== X-Gm-Message-State: AFeK/H3Uxugcw5K2HXHVcFvGvJrhab1O9tzbYisuplaX3LN842pJYGC3f8XRyjqwYEaL/Q== X-Received: by 10.98.105.134 with SMTP id e128mr28514952pfc.19.1491395006152; Wed, 05 Apr 2017 05:23:26 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-223-134.public.wayport.net. [64.134.223.134]) by smtp.gmail.com with ESMTPSA id y7sm37469412pfk.93.2017.04.05.05.23.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 05:23:25 -0700 (PDT) From: Ted Lemon Message-Id: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_093F8D6A-5DF0-4DAC-8D1D-0D870666944B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Apr 2017 05:23:24 -0700 In-Reply-To: Cc: IPv6 Operations , =?utf-8?B?56We5piO6YGU5ZOJ?= To: Philip Homburg References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:23:28 -0000 --Apple-Mail=_093F8D6A-5DF0-4DAC-8D1D-0D870666944B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2017, at 2:23 AM, Philip Homburg = wrote: > If the question is "Do you support making RDNSS a MUST, saying nothing > about DHCP DNS" then my answer is that I oppose that. Because it would cause what problem? --Apple-Mail=_093F8D6A-5DF0-4DAC-8D1D-0D870666944B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 5, 2017, at 2:23 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
If the question is "Do you support making = RDNSS a MUST, saying nothing
about DHCP DNS" = then my answer is that I oppose that.

Because= it would cause what problem?

= --Apple-Mail=_093F8D6A-5DF0-4DAC-8D1D-0D870666944B-- From nobody Wed Apr 5 05:40: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 97865127B31 for ; Wed, 5 Apr 2017 05:40:15 -0700 (PDT) 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 aS_PI4dMENbw for ; Wed, 5 Apr 2017 05:40:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4410D124B0A for ; Wed, 5 Apr 2017 05:40:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvkEL-0000GUC; Wed, 5 Apr 2017 14:40:09 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A 4-4130-8B90-6371100D619D@fugue.com> In-reply-to: Your message of "Wed, 5 Apr 2017 05:23:24 -0700 ." <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> Date: Wed, 05 Apr 2017 14:40:07 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:40:16 -0000 >On Apr 5, 2017, at 2:23 AM, Philip Homburg >wrote: >> If the question is "Do you support making RDNSS a MUST, saying nothing >> about DHCP DNS" then my answer is that I oppose that. > >Because it would cause what problem? If we have two mechanisms and make only one a MUST, then we implicitly send a message that the other one is optional, and given that it's a duplicate, ready to be deprecated. In the long run giving preferential treatment to RDNSS and telling vendors that it is ok to not support DHCP, will lead to more RA options for values that are better served by DHCP, but have to be included in RA because there is no support for DHCP. Do we really want a RA option for NTP servers? One way forward is to duplicate lots of DHCP options in RA, just because some vendors refuse to support DHCP. That doesn't strike a good protocol design to me. RFC 7710 shows that that process has already started. So the way forward is that everywhere where we require some RA/SLAAC feature and there is a corresponding DHCP feature, we require that feature as well. From nobody Wed Apr 5 05:46: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 C2E7E124217 for ; Wed, 5 Apr 2017 05:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9nFWzvNGZvBR for ; Wed, 5 Apr 2017 05:46:22 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 8FA12127B31 for ; Wed, 5 Apr 2017 05:46:17 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id o126so7041558pfb.3 for ; Wed, 05 Apr 2017 05:46:17 -0700 (PDT) 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=Y9ONXvu0PemNZjih6qFXxumMEpF8auT4pq1Djf7UF/0=; b=RNXuggJglKNOTlJBsQXakZZtNCgfzDIGB5/2/AGw0QtsBL8KDm0sofOeoXb4bJjDh1 R34GEo/0BPkQKC5kGKCXYYOL5x+ejpteb5xJNqka0aTzSnnDKd/+e8XzDIgxBx6rFYHZ 4e01tFWi2Z0if7qDWW9Z6G7Ss8Fs1ubHXWBzZ/IR4rhBPvqabCJZSFZ/Pa4B4YqbDeKo /WsVX7MJtmdnhIPTZs0Uv6w6nwepR04MXuCcpHytCcJpVFWuY6ldixNy+OhwZFXv60Rx UnHPelT+AGKRj3NsL+/Mz0953Z3EzT9yohWVS0qU6i0XDUGcrVNxwuI4uxufIlTsTtt6 7isQ== 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=Y9ONXvu0PemNZjih6qFXxumMEpF8auT4pq1Djf7UF/0=; b=KYUteJw2HyQ050rk9WqeBTEF85OLVXYQ+OhaV48JrTQCo1TNAvHUw6+ESbMkPnTnvb rncmFmT4zqnfcb2GDl51hLUuMF4qBowJV2EDWHdwLMwAPFfsvDbi3Aw+hAyyJ4rLoFwF 647OSe1qKN8Zq1u+hKKY6av8ggj5+ruL8Qc4JeqkfK+hfvsuVwEoLOX0glKrKdiLPEWl KD5tOVAO+H3kZnpCL5sgb0tFBLAps9xFn+7G3+c2HOg0bmYqsRlZCR4iLHl/pTDKgzGo b+ZandJAaazoWZsnt74EPC1ROsdKBHfDkczKxV7WUFJBOU/WOZvFxjaT772I8Z9mqLKi WSXw== X-Gm-Message-State: AFeK/H0oCnu7qDrhCzi99/5F+cYBavLuIs7l+0n0KRE9L+6dZU+R7DDPX/2m84fTKYIfzQ== X-Received: by 10.98.7.203 with SMTP id 72mr28940063pfh.197.1491396377103; Wed, 05 Apr 2017 05:46:17 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-223-134.public.wayport.net. [64.134.223.134]) by smtp.gmail.com with ESMTPSA id b128sm10128266pgc.16.2017.04.05.05.46.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 05:46:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: Date: Wed, 5 Apr 2017 05:46:15 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> To: Philip Homburg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:46:24 -0000 On Apr 5, 2017, at 5:40 AM, Philip Homburg = wrote: > If we have two mechanisms and make only one a MUST, then we implicitly = send > a message that the other one is optional, and given that it's a = duplicate, > ready to be deprecated. >=20 > In the long run giving preferential treatment to RDNSS and telling = vendors > that it is ok to not support DHCP, will lead to more RA options for = values > that are better served by DHCP, but have to be included in RA because = there > is no support for DHCP. >=20 > Do we really want a RA option for NTP servers? One way forward is to = duplicate > lots of DHCP options in RA, just because some vendors refuse to = support DHCP. > That doesn't strike a good protocol design to me. RFC 7710 shows that = that > process has already started. >=20 > So the way forward is that everywhere where we require some RA/SLAAC = feature > and there is a corresponding DHCP feature, we require that feature as = well. This is very tight, but the premise that you are assuming is that people = won't implement DHCP because it's not required. They are already doing = that. So I don't think it serves as a valid downside. As for not = putting DHCP in the router, do you really think that's realistic? Do = you know of any routers that don't have it? It's there because there's = a clear demand for it. The problem we have is that RDNSS is not on an = equal footing with DHCP right now, because people who decide what = features to implement don't realize that it's important. Right now, if you want DHCP on the host side, it's there on the network = side, or at least can be; if it's not there, it's because the network = doesn't need to tell you about NTP servers (and, by the way, you are = _insane_ if you trust the DHCP server to tell you what NTP server to = talk to, but that's a side issue). So a host that doesn't do DHCP = isn't doing it because all it needs is RDNSS. But if the network = doesn't provide RDNSS, the host can't get it. _This is the problem_. The problem is not that router vendors aren't = implementing DHCP.= From nobody Wed Apr 5 05:59: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 7BDE4127076 for ; Wed, 5 Apr 2017 05:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 aDNFuEzMLpwo for ; Wed, 5 Apr 2017 05:59:23 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 541951250B8 for ; Wed, 5 Apr 2017 05:59:23 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id B37A6E6065; Wed, 5 Apr 2017 14:59:21 +0200 (CEST) Date: Wed, 05 Apr 2017 14:59:21 +0200 (CEST) Message-Id: <20170405.145921.74683020.sthaug@nethelp.no> To: mellon@fugue.com Cc: pch-v6ops-7@u-1.phicoh.com, v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:59:25 -0000 > This is very tight, but the premise that you are assuming is that > people won't implement DHCP because it's not required. >From my point of view it looks more like some people don't want to implement DHCPv6 for political reasons. As Nick Hilliard said on 31. March: > 3. using the IETF policy process as a stick with which to beat everyone > else into compliance with your own internal policies, disregarding the > consequences - often scorched earth - for the rest of the v6 internet. > > Given the extensive practice of option #3 on v6ops, 6man and dhc in > relation to SLAAC vs DHCPv6, I'm inclined to think that this will be the > inevitable outcome of MUST for RDNSS, and that it will be used as > ammunition in future both to shout down and block future consensus on > dhcpv6 protocol development and to force vendors and operators down one > particular protocol deployment path. There is unfortunately a significant lack of trust in the intentions of those who want to make RDNSS a MUST. Steinar Haug, AS2116 From nobody Wed Apr 5 06:13: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 B2762128CDB for ; Wed, 5 Apr 2017 06:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXFHfmTVGFDT for ; Wed, 5 Apr 2017 06:13:24 -0700 (PDT) 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 909EF128854 for ; Wed, 5 Apr 2017 06:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491398002; bh=0e203RNL0nh5hKseFUt7UfvonbBc1MgNXr26vDJaI1c=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HNrEZcuoEieNXuveuVyhke1FC3mv6moaUwBWXSGHxmlF2MLUeJ+uzVQ4gufzP1HP+LPlH+iM05qVKk97pLysZEhYU7Xs9VlgkS9i/q9Y6bKNL1JXfzIonuta4Cptm7jPfq1b1SLIeE/NA4Ad57aHkc4g7N6gdWFJogqI2aK3Phk= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0049.outbound.protection.outlook.com [213.199.154.49]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-96-4oR6Q9trP2WDCrilBZCiEQ-1; Wed, 05 Apr 2017 14:13:19 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Wed, 5 Apr 2017 13:13:17 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Wed, 5 Apr 2017 13:13:17 +0000 From: Tim Chown To: "sthaug@nethelp.no" CC: Ted Lemon , "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGuSN8AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ICAAA0U4IAADhwAgAAJQYCAAUf3gIAAfTkAgADaCbGAADb054AAAY+AgAADqYCAAAPkAA== Date: Wed, 5 Apr 2017 13:13:17 +0000 Message-ID: <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> In-Reply-To: <20170405.145921.74683020.sthaug@nethelp.no> 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-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:8RFfectCk+Kj6n1RW9UgesJ9ZrLXlGV3XBsHonyqSzHoZ1aKBWk5wlPl7Yh4otDS1g96xJ5trMLj+vTF76CGTtKZeLkISmalBw2Gb/uqishyVApfe3NjIn1xvimMb0YlJ+TLY/9RWpaIMI83GC+Hyn3OL4dGASeAK0BaU5LGaZcC2AOvRA+5VtdkGI3o/k+TtD3qbFJldY5dJ2zNXl4yJn16vKNItJKuFCTL02Z2DbE001qljdiZvucFk6X3do3WdIcUTJiOhYgfmQl1LVAqBsESoT/m+CbsWVja1pBhxBeedUrOsBFWrcGSEClZGcB7DHKcbyWxlIHDjpZCv4FfIw==; 20:0OShXE2Ff6wh3sasr8CkIkjS/JcsiicbFw/yvVpVxr2QrpQRlVcR01RKiTwmJpEOSsR6/2F5BxbRsEXRE77HbE44h9HMK+Itr/bCT3LJV5igZLsmpFPy+/uDfwpQj7frS79W7si5dEPh5vAjLzCS8UttCv1Qy923X990UFUKJJ4= x-ms-office365-filtering-correlation-id: 85ffa1a0-e3ff-43ce-c45f-08d47c258669 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(24454002)(2351001)(5250100002)(6486002)(36756003)(4326008)(66066001)(2501003)(110136004)(3660700001)(3280700002)(38730400002)(6116002)(54906002)(102836003)(6512007)(3846002)(229853002)(99286003)(5640700003)(6506006)(6436002)(6246003)(83716003)(86362001)(82746002)(76176999)(74482002)(50986999)(2950100002)(42882006)(6916009)(25786009)(8676002)(50226002)(53546009)(1730700003)(81166006)(189998001)(93886004)(305945005)(8936002)(2900100001)(53936002)(33656002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 13:13:17.5834 (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: 4oR6Q9trP2WDCrilBZCiEQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:13:27 -0000 PiBPbiA1IEFwciAyMDE3LCBhdCAxMzo1OSwgc3RoYXVnQG5ldGhlbHAubm8gd3JvdGU6DQo+IA0K Pj4gVGhpcyBpcyB2ZXJ5IHRpZ2h0LCBidXQgdGhlIHByZW1pc2UgdGhhdCB5b3UgYXJlIGFzc3Vt aW5nIGlzIHRoYXQNCj4+IHBlb3BsZSB3b24ndCBpbXBsZW1lbnQgREhDUCBiZWNhdXNlIGl0J3Mg bm90IHJlcXVpcmVkLg0KPiANCj4+IEZyb20gbXkgcG9pbnQgb2YgdmlldyBpdCBsb29rcyBtb3Jl IGxpa2Ugc29tZSBwZW9wbGUgZG9uJ3Qgd2FudCB0bw0KPiBpbXBsZW1lbnQgREhDUHY2IGZvciBw b2xpdGljYWwgcmVhc29ucy4gQXMgTmljayBIaWxsaWFyZCBzYWlkIG9uDQo+IDMxLiBNYXJjaDoN Cj4gDQo+PiAzLiB1c2luZyB0aGUgSUVURiBwb2xpY3kgcHJvY2VzcyBhcyBhIHN0aWNrIHdpdGgg d2hpY2ggdG8gYmVhdCBldmVyeW9uZQ0KPj4gZWxzZSBpbnRvIGNvbXBsaWFuY2Ugd2l0aCB5b3Vy IG93biBpbnRlcm5hbCBwb2xpY2llcywgZGlzcmVnYXJkaW5nIHRoZQ0KPj4gY29uc2VxdWVuY2Vz IC0gb2Z0ZW4gc2NvcmNoZWQgZWFydGggLSBmb3IgdGhlIHJlc3Qgb2YgdGhlIHY2IGludGVybmV0 Lg0KPj4gDQo+PiBHaXZlbiB0aGUgZXh0ZW5zaXZlIHByYWN0aWNlIG9mIG9wdGlvbiAjMyBvbiB2 Nm9wcywgNm1hbiBhbmQgZGhjIGluDQo+PiByZWxhdGlvbiB0byBTTEFBQyB2cyBESENQdjYsIEkn bSBpbmNsaW5lZCB0byB0aGluayB0aGF0IHRoaXMgd2lsbCBiZSB0aGUNCj4+IGluZXZpdGFibGUg b3V0Y29tZSBvZiBNVVNUIGZvciBSRE5TUywgYW5kIHRoYXQgaXQgd2lsbCBiZSB1c2VkIGFzDQo+ PiBhbW11bml0aW9uIGluIGZ1dHVyZSBib3RoIHRvIHNob3V0IGRvd24gYW5kIGJsb2NrIGZ1dHVy ZSBjb25zZW5zdXMgb24NCj4+IGRoY3B2NiBwcm90b2NvbCBkZXZlbG9wbWVudCBhbmQgdG8gZm9y Y2UgdmVuZG9ycyBhbmQgb3BlcmF0b3JzIGRvd24gb25lDQo+PiBwYXJ0aWN1bGFyIHByb3RvY29s IGRlcGxveW1lbnQgcGF0aC4NCj4gDQo+IFRoZXJlIGlzIHVuZm9ydHVuYXRlbHkgYSBzaWduaWZp Y2FudCBsYWNrIG9mIHRydXN0IGluIHRoZSBpbnRlbnRpb25zDQo+IG9mIHRob3NlIHdobyB3YW50 IHRvIG1ha2UgUkROU1MgYSBNVVNULg0KDQpJcyBhIHdheSBmb3J3YXJkIHRvIHNheQ0KDQphKSBS RkM4NjAxIFJBLWJhc2VkIHN1cHBvcnQgZm9yIFJETlNTICYgRE5TU0wgaXMgYSBNVVNUIGluIGhv c3RzIGFuZCByb3V0ZXJzOyBpdOKAmXMgbm90IGEgc2lnbmlmaWNhbnQgaW1wbGVtZW50YXRpb24g b3IgcnVubmluZyBjb3N0IHRvIGFueSBkZXZpY2UsIGFuZCBhbiBvcGVyYXRvciBtYXkgc3RpbGwg Y2hvb3NlIHdoZXRoZXIgdG8gdXNlIGl0IG9yIG5vdA0KDQpiKSBSRkMzNzM2IHN0YXRlbGVzcyBE SENQIHN1cHBvcnQgaXMgYSBTSE9VTEQgaW4gaG9zdHMgYW5kIGEgTVVTVCBpbiByb3V0ZXJzLCBu b3RpbmcgaW1wbGVtZW50YXRpb24gb24gSW9UIGFuZCBjb25zdHJhaW5lZCBkZXZpY2VzIG1heSBu b3QgYmUgcmVhbGlzdGljIChub3RpbmcgT3dlbuKAmXMgcG9zdGVkIGZpZ3VyZXMpLCBidXQgdGhh dCBtYW5hZ2VkIGVudGVycHJpc2UgZW52aXJvbm1lbnRzIHdpbGwgZXhwZWN0IG90aGVyIGNvbmZp Z3VyYXRpb24gaW5mb3JtYXRpb24gYmV5b25kIFJETlNTIGFuZCBETlNTTCB0byBiZSBhdmFpbGFi bGUsIHNvIHRoYXQgbG9jYWwgc2VydmljZXMgY2FuIGJlIHVzZWQgKHJhdGhlciB0aGFuLCBzYXks IEdvb2dsZSBETlMgb3IgdGltZSBzZXJ2ZXJzKS4gIEFnYWluLCBpdOKAmXMgdXAgdG8gdGhlIG9w ZXJhdG9yIHRvIGVuYWJsZSBpdA0KDQpUaGlzIGdpdmVzIGEgY29tbW9uIE1USSBtZXRob2QsIGFu ZCBhY2tub3dsZWRnbWVudCB0aGF0IHN0YXRlbGVzcyBESENQIG1heSBiZSBvbWl0dGVkIGluIElv VCwgYnV0IGlzIGV4cGVjdGVkIGluIG1hbmFnZWQgZW50ZXJwcmlzZXMuDQogDQpBbmQgd2UgaGF2 ZSBhbiBSRkMgdGhhdCBkZXNjcmliZXMgaG93IHRvIGhhbmRsZSB0aGUgY2FzZSBvZiBib3RoIGJl aW5nIGVuYWJsZWQgKGkuZS4sIHByZWZlciBESENQIGJ5IGluc2VydGluZyBhIHJlc29sdmVyIGxl YXJudCBieSBESENQIGF0IHRoZSB0b3Agb2YgdGhlIHJlc29sdmVyIGxpc3QpDQoNClRpbQ== From nobody Wed Apr 5 06:17: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 8E20B128854 for ; Wed, 5 Apr 2017 06:17:51 -0700 (PDT) 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 9QQcgk5Py9OL for ; Wed, 5 Apr 2017 06:17:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A26DE12871F for ; Wed, 5 Apr 2017 06:17:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvkom-0000FCC; Wed, 5 Apr 2017 15:17:48 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A 4-4130-8B90-6371100D619D@fugue.com> In-reply-to: Your message of "Wed, 5 Apr 2017 05:46:15 -0700 ." Date: Wed, 05 Apr 2017 15:17:47 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:17:51 -0000 > This is very tight, but the premise that you are assuming is that > people won't implement DHCP because it's not required. They are > already doing that. So I don't think it serves as a valid downside. > As for not putting DHCP in the router, do you really think that's > realistic? Do you know of any routers that don't have it? It's > there because there's a clear demand for it. The problem we have > is that RDNSS is not on an equal footing with DHCP right now, > because people who decide what features to implement don't realize If all routers already support DHCP and want to continue to support DHCP, then adding a requirement to implement both DHCP and RDNSS is no problem right? Just add both as a requirement, problem solved. > Right now, if you want DHCP on the host side, it's there on the > network side, or at least can be; if it's not there, it's because > the network doesn't need to tell you about NTP servers (and, by > the way, you are _insane_ if you trust the DHCP server to tell you > what NTP server to talk to, but that's a side issue). So a host > that doesn't do DHCP isn't doing it because all it needs is RDNSS. > But if the network doesn't provide RDNSS, the host can't get it. Secure NTP is a huge problem, so by and large NTP data is not authenticated. Beyond that, you either have to manually configure NTP servers or you use pool. If you trust pool more than your local network admins, you probably have bigger issues than NTP. > _This is the problem_. The problem is not that router vendors > aren't implementing DHCP. So, you have a host operating system. You know that there is universal support for DHCP by routers, and you still leave out DHCP and wait for a BCP that makes RDNSS mandatory in routers. Does that make sense? Note that where this incompatibility happens in practice is with hosts that have a quad core processor and 4 gig memory. From nobody Wed Apr 5 06:21: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 92453127B57 for ; Wed, 5 Apr 2017 06:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.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 8DOCd-oHO2rc for ; Wed, 5 Apr 2017 06:21:43 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 F24011250B8 for ; Wed, 5 Apr 2017 06:21:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 76E1B940 for ; Wed, 5 Apr 2017 13:21:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFmH9Mg9qIgC for ; Wed, 5 Apr 2017 08:21:42 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 456B95C2 for ; Wed, 5 Apr 2017 08:21:42 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id j29so2388200uaa.16 for ; Wed, 05 Apr 2017 06:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nk+yRmAGkadOl4HhEaltVnMmhIEovK2dU8CuDq8gvXU=; b=cjeO0QsgFu3XxvP0LxhN6pE3in5SeVSU9n2IUTlh5JX8U1zWx9xP3iKVOoqslrQzcl KrKp9UGJZ72x8rhF/C7g5vqcpAoaeDaVMAROX00T6qZJnDff+KsUvcgIKgeSaOSIxJs0 yRc4F0WicMhLRlHbYcou+Tu7T6RER06ACTMmqunav2svAtx6/wClIvlVcyJ2TYpzNE0E lTuz01keAofrO4nv35GkMh1J2Ff947/ZjlakwMkepQQFi/UlugvXGY6CBF/48Hrv65Ro 9G50kUgdtDuHy266x036ZQP922d28nVVmOpiux/6ufYNe+3lWQ082GhYUDtU8Ct4EUaq Zq/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=nk+yRmAGkadOl4HhEaltVnMmhIEovK2dU8CuDq8gvXU=; b=JP6WqY4IyDtoFw6SlA5AS4t2IIUoxFDgjefd/n/xjL3E1VAHKGhgOMCXmfF0Kx4TvK PVtQyMTt3dHKTRtCLB6meznMoJfRL7O1Pm0eKfMBLU3A1TqLC/71RA03gq8/GHYYU+v9 U5/jT4Kls0TBTpLTchzWS8+8N7KFgLlUrtEVSBSO6pUwcbtsLQoNUM3VQEGpRtpFICIo FSYDmB3pvAVDSSgcSw8oh8GVIdkXtF/fpn4wmk7ZPHNyijpBM+h2yRRDPDHMoF2fmyqr vXnAYuLsXlNRMJM+PYjepK/UTQadfbYDCKye5/phj6xtLZc5BoJrArWDKrkU6dO2tzjU /e+A== X-Gm-Message-State: AFeK/H0Ciu1XqQssVaY6XQV5eTh0xjy4hl0kPhU+9khZRIQdtwgiYEzwahz8MmfZpytUM1qPrmSCN27bwqPYlU9MlDpUFEunT9jgFWKWko1MT/ts3NBmnvCi24/Cc6DmIXkVV1Q94DssHKmq1XBH X-Received: by 10.176.4.102 with SMTP id 93mr2042864uav.151.1491398501503; Wed, 05 Apr 2017 06:21:41 -0700 (PDT) X-Received: by 10.176.4.102 with SMTP id 93mr2042852uav.151.1491398501198; Wed, 05 Apr 2017 06:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.144.27 with HTTP; Wed, 5 Apr 2017 06:21:40 -0700 (PDT) In-Reply-To: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> From: David Farmer Date: Wed, 5 Apr 2017 08:21:40 -0500 Message-ID: To: Ted Lemon Cc: Philip Homburg , IPv6 Operations , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c000bece2077d054c6b45fd Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:21:45 -0000 --94eb2c000bece2077d054c6b45fd Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 7:23 AM, Ted Lemon wrote: > On Apr 5, 2017, at 2:23 AM, Philip Homburg > wrote: > > If the question is "Do you support making RDNSS a MUST, saying nothing > about DHCP DNS" then my answer is that I oppose that. > > > Because it would cause what problem? > Because it delays maximal effectiveness of the solution. Yes, eventually all non-compliment host and routers will be replaced. However, If we require both RDNSS and DHCPv6 for both routers and host, we reach maximal effectiveness sooner. Within any environment by requiring by both for both, once all non-compliment hosts or all non-compliment routers are upgraded the site is guaranteed to be good. And with both for both, the probability of a site achieving functional compliance before a guarantee of compliance is much higher. Otherwise, if you only require RDNS for both hosts and routers then both all non-compliment hosts and routers need to be upgraded to guarantee of compliance, and the probably of rechaing functional compliance is lower. In some situations and sites the difference between these will be negligible, however in other situations and sites the difference could be many years. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c000bece2077d054c6b45fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 7:23 AM, Ted Lemon <mellon@fugue.com> wrote:
On Apr 5, 2017, at 2:23 AM, Philip Homburg <pch-v6ops-7@u= -1.phicoh.com> wrote:
If the question is "Do you support making RDNSS a = MUST, saying nothing
about DHCP DNS= " then my answer is that I oppose that.

Because it would cause what problem?
<= div>
Because it delays maximal effectiveness of the solution.= Yes, eventually all non-compliment host and routers will be replaced.

However, If we require both RDNSS and DHCPv6 for both = routers and host, we reach maximal effectiveness sooner.=C2=A0 Within any e= nvironment by requiring by both for both, once all non-compliment hosts or = all non-compliment routers are upgraded the site is guaranteed to be good. = And with both for both, the probability of a site achieving functional comp= liance before a guarantee of compliance is much higher. =C2=A0 Otherwise, i= f you only require RDNS for both hosts and routers then both all non-compli= ment=C2=A0hosts and routers need to be upgraded to guarantee of compliance,= and the probably of rechaing functional compliance is lower.=C2=A0

In some situations and sites the difference between these= will be negligible, however in other situations and sites the difference c= ould be many years. =C2=A0 =C2=A0=C2=A0

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication ServicesOffice of Information Technology
University of Minnesota=C2=A0=C2=A0 <= br>2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c000bece2077d054c6b45fd-- From nobody Wed Apr 5 06:28: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 8A3D5129440 for ; Wed, 5 Apr 2017 06:28:43 -0700 (PDT) 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, 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 (1024-bit key) header.d=iol.unh.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 RwE0xl0v5-On for ; Wed, 5 Apr 2017 06:28:40 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 0A29F129437 for ; Wed, 5 Apr 2017 06:28:39 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p22so10536062qka.3 for ; Wed, 05 Apr 2017 06:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9YA8uve5Yox37qh/Xj7reCOPTeOeD1F3m6Px8BVW+hU=; b=RbR0lS8jOX2XSexuT0mDUZCu8DWXj30Fr1S9hTVRTYHLlcwwqnK/Xks1G41YtH1aqv cV1nuMPWoZNujyaT2dWII3WvBSNKAI087lpw3rH5DwgrCr+X/bclV/zDUO/gFS7nZRO+ ZNkH58p8yx2ZwNBOXB25fMm9iDjwU2C17CW2g= 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=9YA8uve5Yox37qh/Xj7reCOPTeOeD1F3m6Px8BVW+hU=; b=OA2JqF2AnUPnSGFay4YOYmmh6IvdnpVtfkjboImIL2aTkEU68C6B1b5SFTKS0CevPW Lj+sBzuDUbBg6T8TubXxAFOUeOO9OIXz3TPZT8E24rpPjGk+2Mfjd/4pclrDPYzBOu0N nGAtxQqLa499r7XRxDvNrh4qWx+33RuRAKL7YUOMGrzrRKsrEPlYeIWf7oR5xtuv+YM6 zRf7Cf3BOf+SoV9U87T5MJEFFyyLHtGJ8CzLS8xqoNBNN/01qGmw9n/O3BItB95gMWTI SxEWDLyt0A8WCmGNqDdVzfbluBY1ysu4UwU2nv7F+Nbv+RVQAk8psd3rZsV54cRs6nBG ltsQ== X-Gm-Message-State: AFeK/H1N7dMAdQaDMUdmBtZBPFzJpVmNhY2lCzISazOYckKekSCOH5pn30Yn3DtmuO/2r5W2f8CIxpJ5JLEHnFKe X-Received: by 10.55.99.16 with SMTP id x16mr26511374qkb.317.1491398918066; Wed, 05 Apr 2017 06:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Wed, 5 Apr 2017 06:28:37 -0700 (PDT) In-Reply-To: <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> From: Timothy Winters Date: Wed, 5 Apr 2017 09:28:37 -0400 Message-ID: To: Tim Chown Cc: "sthaug@nethelp.no" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0581a6bb0ed3054c6b5e5d Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:28:44 -0000 --94eb2c0581a6bb0ed3054c6b5e5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tim, I would add that supporting 3736 as Relay Agent. I'm guessing that many routers will just use the relay function to send the DHCP messages to a central server. ~Tim On Wed, Apr 5, 2017 at 9:13 AM, Tim Chown wrote: > > On 5 Apr 2017, at 13:59, sthaug@nethelp.no wrote: > > > >> This is very tight, but the premise that you are assuming is that > >> people won't implement DHCP because it's not required. > > > >> From my point of view it looks more like some people don't want to > > implement DHCPv6 for political reasons. As Nick Hilliard said on > > 31. March: > > > >> 3. using the IETF policy process as a stick with which to beat everyon= e > >> else into compliance with your own internal policies, disregarding the > >> consequences - often scorched earth - for the rest of the v6 internet. > >> > >> Given the extensive practice of option #3 on v6ops, 6man and dhc in > >> relation to SLAAC vs DHCPv6, I'm inclined to think that this will be t= he > >> inevitable outcome of MUST for RDNSS, and that it will be used as > >> ammunition in future both to shout down and block future consensus on > >> dhcpv6 protocol development and to force vendors and operators down on= e > >> particular protocol deployment path. > > > > There is unfortunately a significant lack of trust in the intentions > > of those who want to make RDNSS a MUST. > > Is a way forward to say > > a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and > routers; it=E2=80=99s not a significant implementation or running cost to= any > device, and an operator may still choose whether to use it or not > > b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in > routers, noting implementation on IoT and constrained devices may not be > realistic (noting Owen=E2=80=99s posted figures), but that managed enterp= rise > environments will expect other configuration information beyond RDNSS and > DNSSL to be available, so that local services can be used (rather than, > say, Google DNS or time servers). Again, it=E2=80=99s up to the operator= to enable > it > > This gives a common MTI method, and acknowledgment that stateless DHCP ma= y > be omitted in IoT, but is expected in managed enterprises. > > And we have an RFC that describes how to handle the case of both being > enabled (i.e., prefer DHCP by inserting a resolver learnt by DHCP at the > top of the resolver list) > > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --94eb2c0581a6bb0ed3054c6b5e5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

I would add that supporting 373= 6 as Relay Agent. =C2=A0 I'm guessing that many routers will just use t= he relay function to send the DHCP messages to a central server. =C2=A0

~Tim

On Wed, Apr 5, 2017 at 9:13 AM, Tim Chown <Tim.Cho= wn@jisc.ac.uk> wrote:
> On 5 Apr 2017, at 13:59, sthaug@nethelp.no wrote:
>
>> This is very tight, but the premise that you are assuming is that<= br> >> people won't implement DHCP because it's not required.
>
>> From my point of view it looks more like some people don't wan= t to
> implement DHCPv6 for political reasons. As Nick Hilliard said on
> 31. March:
>
>> 3. using the IETF policy process as a stick with which to beat eve= ryone
>> else into compliance with your own internal policies, disregarding= the
>> consequences - often scorched earth - for the rest of the v6 inter= net.
>>
>> Given the extensive practice of option #3 on v6ops, 6man and dhc i= n
>> relation to SLAAC vs DHCPv6, I'm inclined to think that this w= ill be the
>> inevitable outcome of MUST for RDNSS, and that it will be used as<= br> >> ammunition in future both to shout down and block future consensus= on
>> dhcpv6 protocol development and to force vendors and operators dow= n one
>> particular protocol deployment path.
>
> There is unfortunately a significant lack of trust in the intentions > of those who want to make RDNSS a MUST.

Is a way forward to say

a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and ro= uters; it=E2=80=99s not a significant implementation or running cost to any= device, and an operator may still choose whether to use it or not

b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in router= s, noting implementation on IoT and constrained devices may not be realisti= c (noting Owen=E2=80=99s posted figures), but that managed enterprise envir= onments will expect other configuration information beyond RDNSS and DNSSL = to be available, so that local services can be used (rather than, say, Goog= le DNS or time servers).=C2=A0 Again, it=E2=80=99s up to the operator to en= able it

This gives a common MTI method, and acknowledgment that stateless DHCP may = be omitted in IoT, but is expected in managed enterprises.

And we have an RFC that describes how to handle the case of both being enab= led (i.e., prefer DHCP by inserting a resolver learnt by DHCP at the top of= the resolver list)

Tim
_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



--
=

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--94eb2c0581a6bb0ed3054c6b5e5d-- From nobody Wed Apr 5 06: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 69117129405 for ; Wed, 5 Apr 2017 06:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 pg74YUTLeXsk for ; Wed, 5 Apr 2017 06:31:19 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id AE1D0129457 for ; Wed, 5 Apr 2017 06:31:14 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 1DDD4E6065; Wed, 5 Apr 2017 15:31:13 +0200 (CEST) Date: Wed, 05 Apr 2017 15:31:13 +0200 (CEST) Message-Id: <20170405.153113.41701172.sthaug@nethelp.no> To: pch-v6ops-7@u-1.phicoh.com Cc: v6ops@ietf.org 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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:31:21 -0000 > So, you have a host operating system. You know that there is universal > support for DHCP by routers, and you still leave out DHCP and wait for a BCP > that makes RDNSS mandatory in routers. Does that make sense? > > Note that where this incompatibility happens in practice is with hosts > that have a quad core processor and 4 gig memory. I believe the lack of DHCPv6 in Android is a political descision. It certainly isn't due to lack of hardware resources. Steinar Haug, AS2116 From nobody Wed Apr 5 06:35: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 EC93B12944A for ; Wed, 5 Apr 2017 06:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 6agwHSYPxP5p for ; Wed, 5 Apr 2017 06:35:44 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 20131129405 for ; Wed, 5 Apr 2017 06:35:44 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id w11so1384942itb.0 for ; Wed, 05 Apr 2017 06:35:44 -0700 (PDT) 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=g5uOKKrSdqTnDkyQyBs2jdjLBWDTQSyRF9nMftQLMS8=; b=Puy6S4OZCQsSLRZnG5JfTTmzMGdMhyA1spuErMPktgp/ng66SzY9ro3IzH4k1dEqCA IbRNOQO2hHbqUqboCFBrKdDcI2ZEEDH271zaLhQN88kkH7swqaxYiDMyRVp+7nCzBDns p7sOZHrta7wJRdO/O89zHHalgiOX1fa4JGrk3pUtQVD/8Btbhhfid1repnFTElFk+Spw +3wRhyUfiU6ZrQoNmCsiyL4+OxHTT5GLf9w25ZqpXj1y13k+zwlvenGwyXliqwzc4ggU TPcjXAWn2Xtv0EISIHVZLWXA9VUakkkbTHpSgmWQobKoNjiSwr+hVJlWnHivzPKkB6uw 9CBw== 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=g5uOKKrSdqTnDkyQyBs2jdjLBWDTQSyRF9nMftQLMS8=; b=GhHQUj2C7aCc8TLGjBuYZTi2bmBIE0LMpdVcTaNcu0fMsimDFf2U9VQMC0tsNGLmSF kPt2NO9SZIUlDEOgQVhUoMAhEfW4roiEzaEDkosJZ4xQUxCSoh4SlyUoUYi+lK5UrwJF SmXH0IMQeIrbdGyiI0vYaJzJeAA2WmEaKVh6gFrUsRIuQQpjGzR8KvtgaT9d+JePThQs 7ENh5nUtXWL46bzl5Oa4NLNX6+DnKxHu1gunxy+Fqr1hCL2Xx8aowpgnesC2I/RFIQDG e3eDZRvVaTRDWM7cK6WJyO5fKU8A9/yrAMsHim5I4tJa1UGqpPnfGVl3pw3CtLM2EZX7 rFzg== X-Gm-Message-State: AFeK/H0QNY4TnDTWLb47LrkgpmjrLPlvyI3qF/MdEpmCPLtlUsp2DMsdDnqyyDy5ePeFIA== X-Received: by 10.36.71.203 with SMTP id t194mr2044711itb.43.1491399343404; Wed, 05 Apr 2017 06:35:43 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id n184sm8707016itn.25.2017.04.05.06.35.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 06:35:42 -0700 (PDT) To: Mark Smith , Owen DeLong References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> Cc: IPv6 Ops WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 6 Apr 2017 01:35:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:35:46 -0000 On 05/04/2017 12:44, Mark Smith wrote: ... > I don't understand this view that DNS information is the only > additional information a host needs over its addresses and default > gateways. That isn't the assertion. It's that DNS information is the only additional information a host needs *in order to get basic connectivity to the Internet*. Brian From nobody Wed Apr 5 06:51: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 6CE3E129437 for ; Wed, 5 Apr 2017 06:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 CA9QT2kbHjPW for ; Wed, 5 Apr 2017 06:51:33 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001: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 88D4A128854 for ; Wed, 5 Apr 2017 06:51:32 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id n76so1421245ioe.1 for ; Wed, 05 Apr 2017 06:51:32 -0700 (PDT) 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=DTOG3ahvmUwH7fn5Ag18Vv2RAqaJn21Nd0Rsyhi6UFA=; b=ZN8Yljy/4dQh/VfY7UcBZ88Snk3h7kkghX0aUFhZXKpGjuT3GQHRAdx0Q+myRq+dsE Anbfg1DtfTEmb3UAuNRgS1M8HIS45ISzviq4uUTTPQ0FaNJz6SWy2RFEfQ7ydUogmx/B oKIe4glOP+kJWlnmssV/7UXvsNvMRjMtMhtwFASdPckyQFSoge7YLu9OHAOlfVKzl5Fn bWy04Qcxg8NCv3u9JfXV20E8XPoQNB5h5BW19X+Z2AglAJRQ5f9Or6yiOjTQaLp3YfFW LbIgTmYm7Y6lXjNF+95AaxnZxv8vh0KYK71LY+c84OdRbUq/hzPY4dir601b4tit97eX PN6A== 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=DTOG3ahvmUwH7fn5Ag18Vv2RAqaJn21Nd0Rsyhi6UFA=; b=Yo6hVHwNDZTRlFwnlpv4Ihsomuct8GWutynmWvS+AiMKHxTyZSZo7cYsP8gNmt7LeE dL60wYB3fwX9GjpFI/EBtXlWEZRwG5YV4a1otoaXi33c+YQUhX/jiwuNE4VeyN0JHbie kCSYufR0x0Cusn45/1bpuecm+PXCU/74x9HI4S/DIT7MH2lGRWtIphaBFdF9GfRVmZ28 htHkNHrJid1eUR55us2vs0RtmamLcsrTb5GpqQ+ppQAXg9t2Ka7iwjI2kPOUMLIz0060 hRmcKowxHdz5a6PgCwPs7q2pQwxRpzUUEEqWXIzgVthp6ro5V7yu5ZHPmXi7Fs8CSdle 33jw== X-Gm-Message-State: AFeK/H2fMlWT5nhqmbpMx3+IT237VhPYudUlcWOrgernaAuBHdM2W8Se2/RAkGL9i9HdWg== X-Received: by 10.107.58.68 with SMTP id h65mr26542270ioa.221.1491400291710; Wed, 05 Apr 2017 06:51:31 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id y124sm8744458itd.19.2017.04.05.06.51.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 06:51:31 -0700 (PDT) To: sthaug@nethelp.no References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> Cc: v6ops@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 6 Apr 2017 01:51:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170405.145921.74683020.sthaug@nethelp.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:51:34 -0000 On 06/04/2017 00:59, sthaug@nethelp.no wrote: ... > There is unfortunately a significant lack of trust in the intentions > of those who want to make RDNSS a MUST. On 06/04/2017 01:31, sthaug@nethelp.no wrote: ... > I believe the lack of DHCPv6 in Android is a political descision. I don't believe we will get the right answer based on that sort of argument. It shouldn't matter what the motivations of implementers or operators are; what matters is what we observe in running networks. And that is a mixture of two solutions. The rational response to that is that our BCP should say "everybody, implement both". (If you doubt that, imagine a world in which some cities deploy traffic lights and other cities deploy Stop signs. Some drivers stop only at red lights and others stop only at Stop signs.) Brian From nobody Wed Apr 5 07:06: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 D13861250B8 for ; Wed, 5 Apr 2017 07:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B6kWrMPusMG for ; Wed, 5 Apr 2017 07:06:50 -0700 (PDT) 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 3FD3D124282 for ; Wed, 5 Apr 2017 07:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491401208; bh=IcWKFl5WnBuYRVnrxLv4Xs2iLr5cQFAZHpivNLTqXjE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LeloFHAiFz56UFGgmqDzFA23d+VTV/FA9uv4Qtn217UZ5KbawmsuTc9X6Msyp7XgJjF8JZrZAuGieok1mxST55PDmyoEWbhDXN8hh50HqZjw8WhVvn15gLelnJyr3Xc3gFCKm3xefK1XYK94BAJC+IJ5UeL49o1grO1l8Eer55E= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0175.outbound.protection.outlook.com [213.199.180.175]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-64-GqmKIi9rNsCdBKDuYXzB3w-1; Wed, 05 Apr 2017 15:06:42 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Wed, 5 Apr 2017 14:06:41 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Wed, 5 Apr 2017 14:06:41 +0000 From: Tim Chown To: Timothy Winters CC: "sthaug@nethelp.no" , "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFocyuY5KS/Ck2Z1SdTJY6HuaGuSN8AgABDRwCAA/sWgIAAKaaAgAANfgCAAAjfgIAABE4AgAA2LICAAKwLgIAAA6UAgAAV4ICAAA0U4IAADhwAgAAJQYCAAUf3gIAAfTkAgADaCbGAADb054AAAY+AgAADqYCAAAPkAIAABEmAgAAKoYA= Date: Wed, 5 Apr 2017 14:06:40 +0000 Message-ID: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> 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-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:YjMeyXNsCJgtIOueDmZHlqiddtCN/upaCxbvMSZeCdq3JaHuHLhc+SS1difpqL4at2z+9LDglBr2e29p0ar8PfLJx5M9VGSXB5+wuDj/9bN/Dr7qbMi0herL8xJu/CfrRP+MegjZ35Qq5HYinUUjVd3CqBmI17H/fOGuabBVNLQVt164/hUPrDFwdAyS+gtBbDtUc7JC2e8TrdyDQYGyAERi5UZltm9bmUCfqH4cZHh2ABUiTk2vXamWCtm4RQIAMtNixa3lBbMxxAQGkGlWP8hIoc5NYvYZPO7cmEQwdf8XFyFMf7HTOpQM5ArJnQbGcR4Os5dHpazDPLx7KFaIaw==; 20:k87E8hjM/XZ8aSy33Jf1J3DjXOPtkqmsilArm6y+yV8CAUTvpr1RBN0iBryz3IwYca+rAk/WnHx0etDEBBYVu6STuQE/opq1jmpyh0mQyNwMs5cB2yGtwOnmBoE8/h3ocwL3Dhr1iB/gRJH7q3TU+t+eoAX8rb2CSoOZlzXw2tc= x-ms-office365-filtering-correlation-id: 36bd08e5-ac3c-4cba-4a45-08d47c2cfbc8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(278428928389397)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39450400003)(39840400002)(24454002)(377454003)(53376002)(3660700001)(53366004)(38730400002)(53936002)(110136004)(86362001)(189998001)(102836003)(6506006)(33656002)(6246003)(99286003)(7736002)(93886004)(8936002)(305945005)(6436002)(8676002)(6306002)(42882006)(74482002)(966004)(2950100002)(6916009)(54906002)(4326008)(6512007)(76176999)(3846002)(6116002)(2171002)(66066001)(1720100001)(5250100002)(81166006)(25786009)(6486002)(53546009)(50226002)(229853002)(36756003)(82746002)(83716003)(3280700002)(50986999)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <84F476747993D74194752E7D33583D69@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 14:06:40.9624 (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: GqmKIi9rNsCdBKDuYXzB3w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:06:54 -0000 PiBPbiA1IEFwciAyMDE3LCBhdCAxNDoyOCwgVGltb3RoeSBXaW50ZXJzIDx0d2ludGVyc0Bpb2wu dW5oLmVkdT4gd3JvdGU6DQo+IA0KPiBIaSBUaW0sDQo+IA0KPiBJIHdvdWxkIGFkZCB0aGF0IHN1 cHBvcnRpbmcgMzczNiBhcyBSZWxheSBBZ2VudC4gICBJJ20gZ3Vlc3NpbmcgdGhhdCBtYW55IHJv dXRlcnMgd2lsbCBqdXN0IHVzZSB0aGUgcmVsYXkgZnVuY3Rpb24gdG8gc2VuZCB0aGUgREhDUCBt ZXNzYWdlcyB0byBhIGNlbnRyYWwgc2VydmVyLiAgDQoNClllcywgaW5kZWVkLg0KDQpJdOKAmXMg YmFzaWNhbGx5IHdoYXQgT3dlbiB3YXMgcHJvcG9zaW5nIHdoYXQgZmVlbHMgbGlrZSBhIGZldyBo dW5kcmVkIGVtYWlscyBhZ287IGEgY2xlYXIgbW9kZWwgZm9yIGhvc3RzIGFuZCByb3V0ZXJzLCBi dXQgYWRkaW5nIHF1YWxpZmljYXRpb25zIGZvciB0aGUgU0hPVUxELiBJIHRoaW5rIG15IE1VU1Rz IGFuZCBTSE9VTERzIGFyZSB0aGUgc2FtZSBhcyBoZSBwcm9wb3NlZC4NCg0KVGltDQoNCj4gflRp bQ0KPiANCj4gT24gV2VkLCBBcHIgNSwgMjAxNyBhdCA5OjEzIEFNLCBUaW0gQ2hvd24gPFRpbS5D aG93bkBqaXNjLmFjLnVrPiB3cm90ZToNCj4gPiBPbiA1IEFwciAyMDE3LCBhdCAxMzo1OSwgc3Ro YXVnQG5ldGhlbHAubm8gd3JvdGU6DQo+ID4NCj4gPj4gVGhpcyBpcyB2ZXJ5IHRpZ2h0LCBidXQg dGhlIHByZW1pc2UgdGhhdCB5b3UgYXJlIGFzc3VtaW5nIGlzIHRoYXQNCj4gPj4gcGVvcGxlIHdv bid0IGltcGxlbWVudCBESENQIGJlY2F1c2UgaXQncyBub3QgcmVxdWlyZWQuDQo+ID4NCj4gPj4g RnJvbSBteSBwb2ludCBvZiB2aWV3IGl0IGxvb2tzIG1vcmUgbGlrZSBzb21lIHBlb3BsZSBkb24n dCB3YW50IHRvDQo+ID4gaW1wbGVtZW50IERIQ1B2NiBmb3IgcG9saXRpY2FsIHJlYXNvbnMuIEFz IE5pY2sgSGlsbGlhcmQgc2FpZCBvbg0KPiA+IDMxLiBNYXJjaDoNCj4gPg0KPiA+PiAzLiB1c2lu ZyB0aGUgSUVURiBwb2xpY3kgcHJvY2VzcyBhcyBhIHN0aWNrIHdpdGggd2hpY2ggdG8gYmVhdCBl dmVyeW9uZQ0KPiA+PiBlbHNlIGludG8gY29tcGxpYW5jZSB3aXRoIHlvdXIgb3duIGludGVybmFs IHBvbGljaWVzLCBkaXNyZWdhcmRpbmcgdGhlDQo+ID4+IGNvbnNlcXVlbmNlcyAtIG9mdGVuIHNj b3JjaGVkIGVhcnRoIC0gZm9yIHRoZSByZXN0IG9mIHRoZSB2NiBpbnRlcm5ldC4NCj4gPj4NCj4g Pj4gR2l2ZW4gdGhlIGV4dGVuc2l2ZSBwcmFjdGljZSBvZiBvcHRpb24gIzMgb24gdjZvcHMsIDZt YW4gYW5kIGRoYyBpbg0KPiA+PiByZWxhdGlvbiB0byBTTEFBQyB2cyBESENQdjYsIEknbSBpbmNs aW5lZCB0byB0aGluayB0aGF0IHRoaXMgd2lsbCBiZSB0aGUNCj4gPj4gaW5ldml0YWJsZSBvdXRj b21lIG9mIE1VU1QgZm9yIFJETlNTLCBhbmQgdGhhdCBpdCB3aWxsIGJlIHVzZWQgYXMNCj4gPj4g YW1tdW5pdGlvbiBpbiBmdXR1cmUgYm90aCB0byBzaG91dCBkb3duIGFuZCBibG9jayBmdXR1cmUg Y29uc2Vuc3VzIG9uDQo+ID4+IGRoY3B2NiBwcm90b2NvbCBkZXZlbG9wbWVudCBhbmQgdG8gZm9y Y2UgdmVuZG9ycyBhbmQgb3BlcmF0b3JzIGRvd24gb25lDQo+ID4+IHBhcnRpY3VsYXIgcHJvdG9j b2wgZGVwbG95bWVudCBwYXRoLg0KPiA+DQo+ID4gVGhlcmUgaXMgdW5mb3J0dW5hdGVseSBhIHNp Z25pZmljYW50IGxhY2sgb2YgdHJ1c3QgaW4gdGhlIGludGVudGlvbnMNCj4gPiBvZiB0aG9zZSB3 aG8gd2FudCB0byBtYWtlIFJETlNTIGEgTVVTVC4NCj4gDQo+IElzIGEgd2F5IGZvcndhcmQgdG8g c2F5DQo+IA0KPiBhKSBSRkM4NjAxIFJBLWJhc2VkIHN1cHBvcnQgZm9yIFJETlNTICYgRE5TU0wg aXMgYSBNVVNUIGluIGhvc3RzIGFuZCByb3V0ZXJzOyBpdOKAmXMgbm90IGEgc2lnbmlmaWNhbnQg aW1wbGVtZW50YXRpb24gb3IgcnVubmluZyBjb3N0IHRvIGFueSBkZXZpY2UsIGFuZCBhbiBvcGVy YXRvciBtYXkgc3RpbGwgY2hvb3NlIHdoZXRoZXIgdG8gdXNlIGl0IG9yIG5vdA0KPiANCj4gYikg UkZDMzczNiBzdGF0ZWxlc3MgREhDUCBzdXBwb3J0IGlzIGEgU0hPVUxEIGluIGhvc3RzIGFuZCBh IE1VU1QgaW4gcm91dGVycywgbm90aW5nIGltcGxlbWVudGF0aW9uIG9uIElvVCBhbmQgY29uc3Ry YWluZWQgZGV2aWNlcyBtYXkgbm90IGJlIHJlYWxpc3RpYyAobm90aW5nIE93ZW7igJlzIHBvc3Rl ZCBmaWd1cmVzKSwgYnV0IHRoYXQgbWFuYWdlZCBlbnRlcnByaXNlIGVudmlyb25tZW50cyB3aWxs IGV4cGVjdCBvdGhlciBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGJleW9uZCBSRE5TUyBhbmQg RE5TU0wgdG8gYmUgYXZhaWxhYmxlLCBzbyB0aGF0IGxvY2FsIHNlcnZpY2VzIGNhbiBiZSB1c2Vk IChyYXRoZXIgdGhhbiwgc2F5LCBHb29nbGUgRE5TIG9yIHRpbWUgc2VydmVycykuICBBZ2Fpbiwg aXTigJlzIHVwIHRvIHRoZSBvcGVyYXRvciB0byBlbmFibGUgaXQNCj4gDQo+IFRoaXMgZ2l2ZXMg YSBjb21tb24gTVRJIG1ldGhvZCwgYW5kIGFja25vd2xlZGdtZW50IHRoYXQgc3RhdGVsZXNzIERI Q1AgbWF5IGJlIG9taXR0ZWQgaW4gSW9ULCBidXQgaXMgZXhwZWN0ZWQgaW4gbWFuYWdlZCBlbnRl cnByaXNlcy4NCj4gDQo+IEFuZCB3ZSBoYXZlIGFuIFJGQyB0aGF0IGRlc2NyaWJlcyBob3cgdG8g aGFuZGxlIHRoZSBjYXNlIG9mIGJvdGggYmVpbmcgZW5hYmxlZCAoaS5lLiwgcHJlZmVyIERIQ1Ag YnkgaW5zZXJ0aW5nIGEgcmVzb2x2ZXIgbGVhcm50IGJ5IERIQ1AgYXQgdGhlIHRvcCBvZiB0aGUg cmVzb2x2ZXIgbGlzdCkNCj4gDQo+IFRpbQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4g DQo+IA0KPiAtLSANCj4gTm93IG9mZmVyaW5nIHRlc3RpbmcgZm9yIFNETiBhcHBsaWNhdGlvbnMg YW5kIGNvbnRyb2xsZXJzIGluIG91ciBTRE4gc3dpdGNoIHRlc3QgYmVkLiBMZWFybiBtb3JlIHRv ZGF5IGh0dHA6Ly9iaXQubHkvU0ROX0lPTFBSDQo+IA0KDQo= From nobody Wed Apr 5 07:15: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 099281250B8 for ; Wed, 5 Apr 2017 07:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 o2KmGjU3PFnF for ; Wed, 5 Apr 2017 07:15:42 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 047C7124282 for ; Wed, 5 Apr 2017 07:15:42 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id p77so6564440ywg.1 for ; Wed, 05 Apr 2017 07:15:41 -0700 (PDT) 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=q7Q+HF8s27zMOAZ0IWmqmDKvyldK7MGWYAE6HbNewQU=; b=qIHSR74apuPmIXjWI5xhHBrVGXIbDAdLwVjOXSmTNkb7GgqA3oz5Zfpqv+d5CAkJTI YMm/WxKxp+AQDb1yoAvy/+a4BE27SMqz+zLIC5cogTuNAKTBafJTrYlcqSAHZpD8GrcO EtaVkCWaq/InSten5bSBIPp2uSApjcEJl1Maz4f9ok2+GfWihfPQSVpmHgQdD8I6zNae VejTmKOpVdCGVphvIDxDGLvzGNs3QI4PVApuLHjlBtGSf4u3bps2xDgZsMgBIZ0z1baJ FNByvgwx3xxTKT5kEuMdSURx3RvnrDgGyGo04S0FBGdBvG0zAc30Y7ddPPTi9YZ/pYVI Hx4Q== 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=q7Q+HF8s27zMOAZ0IWmqmDKvyldK7MGWYAE6HbNewQU=; b=Ut7Jlssp3DeG2Sc/7atmuEHpyL6YCDPKtlh5wNRllSnpx0NFdS5wjxql+Vnq+BUI7W wp2IO16DaqWAWo1R15STJazILTT5JI4VzEkLNkBwEOFKCoeIACW+kUgqD4sc+ss8Rxlp duJXrrvH8uZSTZgUdhzlcXEeNHUvelGbcuPzBJVk/P0UadH2UcHAhoYzluwkl66dqUdZ wSRHl5dKdAjRH3eYx+ZxYBW/4ddbDpwm01wkaSdSN5iaAiyKdsbir/SICvKoIIwWVsvj LMHQrJlTIeW28yAKNuhUWlZZ6KeRPTbTJaZaXCaaujamlEgs+vJSvxof7WPIvlKNAEDy KMcw== X-Gm-Message-State: AFeK/H3XLGI9BEVee4Kf2gpd0qfFKbMEUTF2D3rGiMT4jSmTaztC9rUa3mGexrcbmGrMZ7+zKSxCEdWm3EIP2wPp X-Received: by 10.129.115.68 with SMTP id o65mr20971687ywc.55.1491401740798; Wed, 05 Apr 2017 07:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.220.12 with HTTP; Wed, 5 Apr 2017 07:15:20 -0700 (PDT) In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> From: Erik Kline Date: Wed, 5 Apr 2017 23:15:20 +0900 Message-ID: To: Tim Chown Cc: Timothy Winters , "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1149359c02e1cd054c6c071c" Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:15:49 -0000 --001a1149359c02e1cd054c6c071c Content-Type: multipart/alternative; boundary=001a1149359cfad04c054c6c0605 --001a1149359cfad04c054c6c0605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5 April 2017 at 23:06, Tim Chown wrote: > > On 5 Apr 2017, at 14:28, Timothy Winters wrote: > > > > Hi Tim, > > > > I would add that supporting 3736 as Relay Agent. I'm guessing that > many routers will just use the relay function to send the DHCP messages t= o > a central server. > > Yes, indeed. > > It=E2=80=99s basically what Owen was proposing what feels like a few hund= red > emails ago; a clear model for hosts and routers, but adding qualification= s > for the SHOULD. I think my MUSTs and SHOULDs are the same as he proposed. > > Tim We shouldn't pretend, though, that DHCPv6 DNS and RA DNS are the same and the choice is between two equal things. >From my point of view, RA DNS is way more expressive and useful than DHCPv6 DNS. Specifically, consider the case where 2 RAs are sent on the network each with different PIOs, RIOs, and RDNSS sets. End nodes can associate all this information with each next hop, and make better, logically consistent use of essentially two different networks a la RFCs 7556 and 8028. I don't think DHCPv6 DNS can do that. --001a1149359cfad04c054c6c0605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 5 April 2017 at 23:06, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> On 5 Apr 2= 017, at 14:28, Timothy Winters <= twinters@iol.unh.edu> wrote:
>
> Hi Tim,
>
> I would add that supporting 3736 as Relay Agent.=C2=A0 =C2=A0I'm g= uessing that many routers will just use the relay function to send the DHCP= messages to a central server.

Yes, indeed.

It=E2=80=99s basically what Owen was proposing what feels like a few hundre= d emails ago; a clear model for hosts and routers, but adding qualification= s for the SHOULD. I think my MUSTs and SHOULDs are the same as he proposed.=

Tim

We shouldn't pretend,= though, that DHCPv6 DNS and RA DNS are the same and the choice is between = two equal things.

From my point of view, RA DNS is= way more expressive and useful than DHCPv6 DNS.

S= pecifically, consider the case where 2 RAs are sent on the network each wit= h different PIOs, RIOs, and RDNSS sets.=C2=A0 End nodes can associate all t= his information with each next hop, and make better, logically consistent u= se of essentially two different networks a la RFCs 7556 and 8028.

I don't think DHCPv6 DNS can do that.
=
--001a1149359cfad04c054c6c0605-- --001a1149359c02e1cd054c6c071c 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgRzCs35kW4jp/j9oQbmTxZe0f0+ZXsmiu F92Mo/rslRAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA1 MTQxNTQxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAELQpdKdFePCq96m492USKQstwj0sI0SW7kyfuOT/SNl9JIJGnts tL83Bo3/2Et4SDrama2CtUhzyJwBKkR0NyPY3XOOyua8FkqTyG/I/EXJ30HBtfHstZshlpJFo48A a/MRsuym/mhzsD77Cf06bKoo6sDhYEp/YTGWIb5SeystllBMdUxYtklU2wKyFg6QFEpNVl30mIFF VV7uVYNtejSaPFGuEx7UdypWOalBkla8EjQ5bjSAZ8aKCeas+0yJGoY2BvUM1Du0KB291i9/NICE kH+YyOUu4APUNMpoJ6gSvqGFVNMFJu2uKu4IxTnSP1KFy87syav9VFP7IEtiWAw= --001a1149359c02e1cd054c6c071c-- From nobody Wed Apr 5 07:25: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 05A18126DC2 for ; Wed, 5 Apr 2017 07:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, 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 AUjba78VmyuO for ; Wed, 5 Apr 2017 07:25:44 -0700 (PDT) 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 44F7B127601 for ; Wed, 5 Apr 2017 07:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13684; q=dns/txt; s=iport; t=1491402344; x=1492611944; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kkKL4f54S0wa6L9PWj9eJVxbSrTxH36S1MLVFgOrY/g=; b=UZ8FuBfiTmH+pUZEWDtH88VK1f6oId5ETP37V6lIvQx6rWC5nsZ1m1AI jIgSipxQiWgjGEhg2nJbJSSHQWhLXQOpXfynzvpYO5L9tsJkEc6n6wag5 MITZRSnGqz8CYNddn+lZH8QaAowHrksFhs0woWLWzKAjTUT6zw4oGPfob 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvAgAN/eRY/5hdJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuZmGBCweDXIoSkR0fkCGFNIIOKoV4AhqDMz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECASMKTAULAgEIDgMDAQIBJwMCAgIwFAkIAgQBDQWKBggOq0iCJ?= =?us-ascii?q?iuKQAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFiFMJgmKEQCQSFgKCTi6CMQWccAG?= =?us-ascii?q?GfYtUkTyTdQEfOEs6WxVBEQGGCj11iDyBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,278,1486425600"; d="scan'208,217";a="229171975" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2017 14:25:43 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v35EPhu5020507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Apr 2017 14:25:43 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; Wed, 5 Apr 2017 09:25:42 -0500 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; Wed, 5 Apr 2017 09:25:42 -0500 From: "Bernie Volz (volz)" To: Erik Kline , Tim Chown CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSqOFtcCIh4JqwF0K0H7rCJjQ0haGunLAAgABDSACAA/sWgIAAKaaAgAANfQCAAAjfgIAABE8AgAA2LICAAHAg2YAADplOgABgLwCAAAlBgIACS1yrgAA4z+WAAFVpgIAAA6mAgAAD5ICAAARJgIAACqIAgAACbAD//7/WgA== Date: Wed, 5 Apr 2017 14:25:42 +0000 Message-ID: <4E12D1F6-8272-4BAD-846D-A4E0FEE70E8B@cisco.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.107] Content-Type: multipart/alternative; boundary="_000_4E12D1F682724BAD846DA4E0FEE70E8Bciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:25:47 -0000 --_000_4E12D1F682724BAD846DA4E0FEE70E8Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBpcyBjb3JyZWN0IGFzIERIQ1AgYXNzdW1lcyBhIHNpbmdsZSBwcm92aXNpb25pbmcgZG9t YWluIGFuZCBpZiB0aGUgdHdvIFJBcyBhcmUgZnJvbSBkaWZmZXJlbnQgb25lcywgdGhlcmXigJlz IG5vIHdheSB0byBpbmRpY2F0ZSB0aGF0LiBESENQIGNvdWxkIHNlbmQgYSBjb21iaW5lZCBsaXN0 LCBidXQgbm90IG9uZXMgc3BlY2lmaWMgdG8gYW4gaW50ZXJuZXQuDQoNClRoZXJlIHdhcyBNSUYg d29yayBvbiBQVkQgb3B0aW9uIGZvciBESENQdjYsIGJ1dCBhIHBhdGVudCBpc3N1ZSBwcmV0dHkg bXVjaCBraWxsZWQgdGhhdC4gU2VlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtbWlmLW1wdmQtZGhjcC1zdXBwb3J0Ly4NCg0KDQotICAgICAgICAgIEJlcm5pZQ0K DQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEVyaWsg S2xpbmUgPGVrQGdvb2dsZS5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDUsIDIwMTcgYXQg MTA6MTUgQU0NClRvOiBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFjLnVrPg0KQ2M6ICJ2Nm9w c0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gTWFraW5n IFJETlNTIGEgTVVTVD8NCg0KDQpPbiA1IEFwcmlsIDIwMTcgYXQgMjM6MDYsIFRpbSBDaG93biA8 VGltLkNob3duQGppc2MuYWMudWs8bWFpbHRvOlRpbS5DaG93bkBqaXNjLmFjLnVrPj4gd3JvdGU6 DQo+IE9uIDUgQXByIDIwMTcsIGF0IDE0OjI4LCBUaW1vdGh5IFdpbnRlcnMgPHR3aW50ZXJzQGlv bC51bmguZWR1PG1haWx0bzp0d2ludGVyc0Bpb2wudW5oLmVkdT4+IHdyb3RlOg0KPg0KPiBIaSBU aW0sDQo+DQo+IEkgd291bGQgYWRkIHRoYXQgc3VwcG9ydGluZyAzNzM2IGFzIFJlbGF5IEFnZW50 LiAgIEknbSBndWVzc2luZyB0aGF0IG1hbnkgcm91dGVycyB3aWxsIGp1c3QgdXNlIHRoZSByZWxh eSBmdW5jdGlvbiB0byBzZW5kIHRoZSBESENQIG1lc3NhZ2VzIHRvIGEgY2VudHJhbCBzZXJ2ZXIu DQoNClllcywgaW5kZWVkLg0KDQpJdOKAmXMgYmFzaWNhbGx5IHdoYXQgT3dlbiB3YXMgcHJvcG9z aW5nIHdoYXQgZmVlbHMgbGlrZSBhIGZldyBodW5kcmVkIGVtYWlscyBhZ287IGEgY2xlYXIgbW9k ZWwgZm9yIGhvc3RzIGFuZCByb3V0ZXJzLCBidXQgYWRkaW5nIHF1YWxpZmljYXRpb25zIGZvciB0 aGUgU0hPVUxELiBJIHRoaW5rIG15IE1VU1RzIGFuZCBTSE9VTERzIGFyZSB0aGUgc2FtZSBhcyBo ZSBwcm9wb3NlZC4NCg0KVGltDQoNCldlIHNob3VsZG4ndCBwcmV0ZW5kLCB0aG91Z2gsIHRoYXQg REhDUHY2IEROUyBhbmQgUkEgRE5TIGFyZSB0aGUgc2FtZSBhbmQgdGhlIGNob2ljZSBpcyBiZXR3 ZWVuIHR3byBlcXVhbCB0aGluZ3MuDQoNCkZyb20gbXkgcG9pbnQgb2YgdmlldywgUkEgRE5TIGlz IHdheSBtb3JlIGV4cHJlc3NpdmUgYW5kIHVzZWZ1bCB0aGFuIERIQ1B2NiBETlMuDQoNClNwZWNp ZmljYWxseSwgY29uc2lkZXIgdGhlIGNhc2Ugd2hlcmUgMiBSQXMgYXJlIHNlbnQgb24gdGhlIG5l dHdvcmsgZWFjaCB3aXRoIGRpZmZlcmVudCBQSU9zLCBSSU9zLCBhbmQgUkROU1Mgc2V0cy4gIEVu ZCBub2RlcyBjYW4gYXNzb2NpYXRlIGFsbCB0aGlzIGluZm9ybWF0aW9uIHdpdGggZWFjaCBuZXh0 IGhvcCwgYW5kIG1ha2UgYmV0dGVyLCBsb2dpY2FsbHkgY29uc2lzdGVudCB1c2Ugb2YgZXNzZW50 aWFsbHkgdHdvIGRpZmZlcmVudCBuZXR3b3JrcyBhIGxhIFJGQ3MgNzU1NiBhbmQgODAyOC4NCg0K SSBkb24ndCB0aGluayBESENQdjYgRE5TIGNhbiBkbyB0aGF0Lg0K --_000_4E12D1F682724BAD846DA4E0FEE70E8Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3FE50E1067E65440912FA94FCF7F7FDD@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFu LmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJ Y29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoxMTQ5OTA1NjQyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczo0MDM5Njk2NzIgOTI3ODY4NTg4IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGF0IGlz IGNvcnJlY3QgYXMgREhDUCBhc3N1bWVzIGEgc2luZ2xlIHByb3Zpc2lvbmluZyBkb21haW4gYW5k IGlmIHRoZSB0d28gUkFzIGFyZSBmcm9tIGRpZmZlcmVudCBvbmVzLCB0aGVyZeKAmXMgbm8gd2F5 IHRvIGluZGljYXRlIHRoYXQuIERIQ1AgY291bGQgc2VuZCBhIGNvbWJpbmVkIGxpc3QsIGJ1dCBu b3Qgb25lcyBzcGVjaWZpYw0KIHRvIGFuIGludGVybmV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPlRoZXJlIHdhcyBNSUYgd29yayBvbiBQVkQgb3B0aW9uIGZvciBESENQdjYsIGJ1dCBhIHBh dGVudCBpc3N1ZSBwcmV0dHkgbXVjaCBraWxsZWQgdGhhdC4gU2VlIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWlmLW1wdmQtZGhjcC1zdXBwb3J0Ly48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QmVybmllPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+djZvcHMgJmx0O3Y2 b3BzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBFcmlrIEtsaW5lICZsdDtla0Bn b29nbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEFwcmlsIDUsIDIwMTcg YXQgMTA6MTUgQU08YnI+DQo8Yj5UbzogPC9iPlRpbSBDaG93biAmbHQ7VGltLkNob3duQGppc2Mu YWMudWsmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDt2Nm9wc0BpZXRmLm9yZyZxdW90OyAmbHQ7 djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbdjZvcHNdIE1ha2lu ZyBSRE5TUyBhIE1VU1Q/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNSBBcHJpbCAyMDE3IGF0IDIzOjA2LCBUaW0gQ2hvd24g Jmx0OzxhIGhyZWY9Im1haWx0bzpUaW0uQ2hvd25AamlzYy5hYy51ayIgdGFyZ2V0PSJfYmxhbmsi PlRpbS5DaG93bkBqaXNjLmFjLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBPbiA1IEFwciAyMDE3LCBhdCAxNDoy OCwgVGltb3RoeSBXaW50ZXJzICZsdDs8YSBocmVmPSJtYWlsdG86dHdpbnRlcnNAaW9sLnVuaC5l ZHUiPnR3aW50ZXJzQGlvbC51bmguZWR1PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZn dDsgSGkgVGltLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgd291bGQgYWRkIHRoYXQgc3VwcG9ydGlu ZyAzNzM2IGFzIFJlbGF5IEFnZW50LiZuYnNwOyAmbmJzcDtJJ20gZ3Vlc3NpbmcgdGhhdCBtYW55 IHJvdXRlcnMgd2lsbCBqdXN0IHVzZSB0aGUgcmVsYXkgZnVuY3Rpb24gdG8gc2VuZCB0aGUgREhD UCBtZXNzYWdlcyB0byBhIGNlbnRyYWwgc2VydmVyLjxicj4NCjxicj4NClllcywgaW5kZWVkLjxi cj4NCjxicj4NCkl04oCZcyBiYXNpY2FsbHkgd2hhdCBPd2VuIHdhcyBwcm9wb3Npbmcgd2hhdCBm ZWVscyBsaWtlIGEgZmV3IGh1bmRyZWQgZW1haWxzIGFnbzsgYSBjbGVhciBtb2RlbCBmb3IgaG9z dHMgYW5kIHJvdXRlcnMsIGJ1dCBhZGRpbmcgcXVhbGlmaWNhdGlvbnMgZm9yIHRoZSBTSE9VTEQu IEkgdGhpbmsgbXkgTVVTVHMgYW5kIFNIT1VMRHMgYXJlIHRoZSBzYW1lIGFzIGhlIHByb3Bvc2Vk Ljxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9l bnpiIj5UaW08L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugc2hvdWxkbid0IHByZXRlbmQsIHRob3VnaCwg dGhhdCBESENQdjYgRE5TIGFuZCBSQSBETlMgYXJlIHRoZSBzYW1lIGFuZCB0aGUgY2hvaWNlIGlz IGJldHdlZW4gdHdvIGVxdWFsIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBteSBwb2ludCBvZiB2aWV3LCBSQSBETlMgaXMg d2F5IG1vcmUgZXhwcmVzc2l2ZSBhbmQgdXNlZnVsIHRoYW4gREhDUHY2IEROUy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlY2lmaWNhbGx5 LCBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSAyIFJBcyBhcmUgc2VudCBvbiB0aGUgbmV0d29yayBl YWNoIHdpdGggZGlmZmVyZW50IFBJT3MsIFJJT3MsIGFuZCBSRE5TUyBzZXRzLiZuYnNwOyBFbmQg bm9kZXMgY2FuIGFzc29jaWF0ZSBhbGwgdGhpcyBpbmZvcm1hdGlvbiB3aXRoIGVhY2ggbmV4dCBo b3AsIGFuZCBtYWtlIGJldHRlciwgbG9naWNhbGx5IGNvbnNpc3RlbnQgdXNlIG9mIGVzc2VudGlh bGx5DQogdHdvIGRpZmZlcmVudCBuZXR3b3JrcyBhIGxhIFJGQ3MgNzU1NiBhbmQgODAyOC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24n dCB0aGluayBESENQdjYgRE5TIGNhbiBkbyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E12D1F682724BAD846DA4E0FEE70E8Bciscocom_-- From nobody Wed Apr 5 07:30: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 1CAD8126DC2 for ; Wed, 5 Apr 2017 07:30:42 -0700 (PDT) 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 YsNNREhFLQI6 for ; Wed, 5 Apr 2017 07:30:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A68AC128B38 for ; Wed, 5 Apr 2017 07:30:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvlxF-0000FUC; Wed, 5 Apr 2017 16:30:37 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> In-reply-to: Your message of "Wed, 5 Apr 2017 23:15:20 +0900 ." Date: Wed, 05 Apr 2017 16:30:37 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:30:42 -0000 >Specifically, consider the case where 2 RAs are sent on the network each >with different PIOs, RIOs, and RDNSS sets. End nodes can associate all >this information with each next hop, and make better, logically consistent >use of essentially two different networks a la RFCs 7556 and 8028. > >I don't think DHCPv6 DNS can do that. In the context of IA_NA, each Advertise message may have its own set of DNS resolvers (and default router, if some people would stop blocking that option). No difference there. In addition, DHCP can tailer responses per client. So you can give some clients a different set of resolvers, even based on the device vendor. With support for Reconfigure, DHCP can also support quickly changing configuration without waiting for a timeout. From nobody Wed Apr 5 07:31: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 264C612944A for ; Wed, 5 Apr 2017 07:31:29 -0700 (PDT) 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 vU6C15lGwqgc for ; Wed, 5 Apr 2017 07:31:27 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 8B87E129447 for ; Wed, 5 Apr 2017 07:31:20 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p22so12320983qka.3 for ; Wed, 05 Apr 2017 07:31:20 -0700 (PDT) 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=rHzhH/bEE62AXX+skLlrbuJL1MMTcSTktHgBdsKXwAc=; b=n+oBxXBgY80q1ytGnTTcX/azZwlB/dALZX+32wDIeMSAG+DuFaqmSaRL/BBcZdmIfL IQ6yUyzrEnq81KZ9U/+aPoumtAho56xq4n6VCPXtLsVjfLB4Df0tYXuKOkjFqA9DQkf+ RQq+BnsmF+/OHHk+C7uppX/Svn8P3lbJH9G0eWkG7UXIy17x2yURnyt2ewpU/HQR369B g1clULXCl+n78m+SlLMAMsKUi6phGnXGnk1VpQVmRYjT8ko3vo2Z+5HFxbErRFF63BQR PmQjVNAzZ1RBmbdSJck3gZyHoyx5eY7y2gidgEWe7ASI4Sv2ZtnNraZTHwK64YFZfu/Y Mn4g== 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=rHzhH/bEE62AXX+skLlrbuJL1MMTcSTktHgBdsKXwAc=; b=eGnYJuMHgqyIRq3RH42RCu5PXC3wQ3u/RyeYIgTiHWBMc+9ONTIinnrOgT5VXAoQ// rXZwdKLzSO8bVUMRXQbuIBrcOiAqgGg3K5rKgb7SXNdWyYK5dN2jRdABe2zL+0jG298V uvmpycUuqIqOMewbECphEZJ09ZL+dWj8eud8u5duA+WdjD+LODWD61cnyQqq3DvajdAA UAdT8Rwy4eF2ofacmPv3ZRRzrVsSSCeHWn5w/1y3uAhRS9lgT59DSfz5R5Kg7yEknD1B SIfK3WSXeKrD6sjArv47aGoaAp9SVSTigb/+7VeGC1PYqYpk/UrvqXq3qZb6f9dLeMXV 6UqQ== X-Gm-Message-State: AFeK/H23UAP7MdXIQh7b5szqHLfyDLAJVu3We9zHNzRDNS/32zzfEazCDK5IxuEVv1CJj/hcGsb4TOW5aT9ePA== X-Received: by 10.55.41.37 with SMTP id p37mr21676291qkh.51.1491402679698; Wed, 05 Apr 2017 07:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.32.226 with HTTP; Wed, 5 Apr 2017 07:30:59 -0700 (PDT) In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> From: Richard Hartmann Date: Wed, 5 Apr 2017 16:30:59 +0200 Message-ID: To: Brian E Carpenter Cc: sthaug@nethelp.no, IPv6 Operations Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:31:29 -0000 I don't write often, even if I lurk extensively. Also, please note that I quote out of order in this reply. On Wed, Apr 5, 2017 at 3:51 PM, Brian E Carpenter wrote: > And that is a mixture of two solutions. The rational response to > that is that our BCP should say "everybody, implement both". And that's what could, and should, end this and similar threads forevermore. > I don't believe we will get the right answer based on that sort of > argument. It shouldn't matter what the motivations of implementers > or operators are; what matters is what we observe in running networks. Leaving the realms of technical solutions and delving into the depths of humanity, this and similar threads are blocked by a stand-off in which neither side of an old argument is willing to cede that one last bit which could make the other one feature complete and thus "win". And that's why even having both at once seems not to be able to reach consensus. Two more points: Having two full implementations at my disposal, I would probably use the smaller, light-weight one for larger network segments and server setups (i.e. ISP, colo, CPEs, etc) and the more feature-rich one for end user networks (i.e. enterprise and whatever's behind the CPE). Choosing what fits a particular and specific set of engineering constraints and requirements seems like a good approach. Also, from lurking the TLS and related lists, I can say that the implementors on very low powered devices will do what they want (or need) to do anyway. Catering to them specifically and holding the standards at large back due to those considerations might not be the best of ideas and TLS thankfully stopped doing that. And yes, I know, none of this is new or surprising to anyone on this list. Back to lurking, Richard From nobody Wed Apr 5 07:35: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 462E4129446 for ; Wed, 5 Apr 2017 07:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 bx0geJ-kNfdT for ; Wed, 5 Apr 2017 07:35:25 -0700 (PDT) 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 65E1E128B38 for ; Wed, 5 Apr 2017 07:35:23 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1BAFEA2; Wed, 5 Apr 2017 16:35:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491402921; bh=BHjRIf7L1MJTuEN3WNgFrsFF/RanCmQRzkRXN39tF0I=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WfN8p2Hbi7eUm0LElbiZaK0TpKtiADi+gylzlPEkP+YRErjxXRTefIcjqSWWFm6jf H+MgnN5uWXuXNkvGrq0aJGICwuxs64OfJonF7Gkm/tYv+v6RFyNgFbTNKrpYjp+dVi 0jeI7PrjEKYlvJ7cI8pGxBhElwMb+PWGpcAKzZLI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 18D8188; Wed, 5 Apr 2017 16:35:21 +0200 (CEST) Date: Wed, 5 Apr 2017 16:35:21 +0200 (CEST) From: Mikael Abrahamsson To: Philip Homburg cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> 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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:35:27 -0000 On Wed, 5 Apr 2017, Philip Homburg wrote: >> Specifically, consider the case where 2 RAs are sent on the network each >> with different PIOs, RIOs, and RDNSS sets. End nodes can associate all >> this information with each next hop, and make better, logically consistent >> use of essentially two different networks a la RFCs 7556 and 8028. >> >> I don't think DHCPv6 DNS can do that. > > In the context of IA_NA, each Advertise message may have its own set of > DNS resolvers (and default router, if some people would stop blocking that > option). No difference there. > > In addition, DHCP can tailer responses per client. So you can give some > clients a different set of resolvers, even based on the device vendor. > > With support for Reconfigure, DHCP can also support quickly changing > configuration without waiting for a timeout. This sounds like one DHCP server. I was talking about a LAN with multiple DHCP servers (for instance, built into two separate routers). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 5 07:46: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 6B2E3126BF7 for ; Wed, 5 Apr 2017 07:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 VLo-SDRHKpDN for ; Wed, 5 Apr 2017 07:46:12 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B3129489 for ; Wed, 5 Apr 2017 07:46:02 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id B6D4DE6065; Wed, 5 Apr 2017 16:46:01 +0200 (CEST) Date: Wed, 05 Apr 2017 16:46:01 +0200 (CEST) Message-Id: <20170405.164601.74682422.sthaug@nethelp.no> To: Tim.Chown@jisc.ac.uk Cc: mellon@fugue.com, v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> References: <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> 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: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:46:15 -0000 > Is a way forward to say > > a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and routers; it's not a significant implementation or running cost to any device, and an operator may still choose whether to use it or not > > b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in routers, noting implementation on IoT and constrained devices may not be realistic (noting Owen's posted figures), but that managed enterprise environments will expect other configuration information beyond RDNSS and DNSSL to be available, so that local services can be used (rather than, say, Google DNS or time servers). Again, it's up to the operator to enable it I'd actually like to explore a slightly different scenario for hosts: RFC3736 stateless DHCP *and* RFC3633 Prefix Delegation both being MUST for hosts (but not RFC3315 IA_NA/IA_TA). I'm suggesting this because my impression is that at least some of the resistance against DHCPv6 for hosts is the fact that IA_NA only gives you *one* address. Prefix delegation can hand out a /56 or a /48 if needed. Yes, prefix delegation is supposed to be for routers - but in my book an Android with several other devices tethered behind it is definitely a router. It's of course entirely possible that prefix delegation doesn't make DHCPv6 any more interesting for those who are opposed today. Having some idea of the status here would be interesting. Steinar Haug, AS2116 From nobody Wed Apr 5 07:48: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 6926712944A for ; Wed, 5 Apr 2017 07:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 X804VktA-Igv for ; Wed, 5 Apr 2017 07:48:40 -0700 (PDT) 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 9C6E4126DC2 for ; Wed, 5 Apr 2017 07:48:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvmEf-0000H7C; Wed, 5 Apr 2017 16:48:37 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> In-reply-to: Your message of "Wed, 5 Apr 2017 16:35:21 +0200 (CEST) ." Date: Wed, 05 Apr 2017 16:48:36 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:48:42 -0000 >This sounds like one DHCP server. I was talking about a LAN with multiple >DHCP servers (for instance, built into two separate routers). The DHCP protocol supports multiple servers. See Section 17.1.3 of RFC 3315 (https://tools.ietf.org/html/rfc3315#section-17.1.3) Traditionally, a host gets one address from one server. So there may be corner cases that would need to be addressed. From nobody Wed Apr 5 07:52: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 31A16129440 for ; Wed, 5 Apr 2017 07:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 MY9s801aQWJF for ; Wed, 5 Apr 2017 07:52:55 -0700 (PDT) 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 7075D129482 for ; Wed, 5 Apr 2017 07:52:50 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 100so9509891uaj.3 for ; Wed, 05 Apr 2017 07:52:50 -0700 (PDT) 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=sj4v2mHUk8GPnrWNR+txn4Wj88sf2Qig6gfwaVG+V3I=; b=m+5ecXs1IVX8n+C3Bni152wQPDCPFPZNZSoAY0zdwoQckC42knjC+YCtwUrN93sRCo /Utt5sGGftuIFGAZTz6X02eJ7Xir1C3nMaOBkmoPzl0uYasKsnUzjlyXqK9mGPkBFtCe wU3DBJvvl5RbPAxF7qpiY0tBH/1FDALNC1lzfkPb5NMVp0B8E5vZHJ/77uYojWspxsjT /mCQVgSW3E48rcaZmZNORAfp+OJXVWP/kDNcHTBPOsB+j7ua2RxWnyQfTu6ajWfhyYnX dnnVX1MLLOqbX+MuYOuSoREWW4711hS5nr7+O6LFIGI6g0TUErP1cNQXg5pEJOhPegJC hOZw== 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=sj4v2mHUk8GPnrWNR+txn4Wj88sf2Qig6gfwaVG+V3I=; b=WYvb83RuqHQDNloiEBCXumA9F4vBWqJMsUeDwMMCB2n6nzv6gbrU+0M/NIHQSO6q7y 7Fc/GEhHmcMyd3Ir2kWpZmn2eJWHzcrKWWv3yOjqLEE8Ct118QoLxEBd1OUM2OPU9wwG jFWt04qs0suk+RW8H0ItIBZcJF/Bs6joL9iJmSgNPMV2as6mluqSQrzw1i3CFyH8eQZx bxMjrA7IhbpgRwemKdKrbaDhEVJZ5/cnvZ7nms1n6o63z6yZ22kybkR18lZaQjI+6OJv fj386FxvkgZCgdfzt8o6XuHf9uDCKO5RxNB3pLEBf4jQK+jjNfc560AkaD8AH3+rOcw/ 8L8w== X-Gm-Message-State: AFeK/H2N1h8LyHO1+/u1roOS8uC6aA0WPtomLeG5ewK1RnhBTVPCYiz4PGmyre1j785B/RkPriHWVW0hu24ihA== X-Received: by 10.176.7.38 with SMTP id h35mr1397368uah.68.1491403969217; Wed, 05 Apr 2017 07:52:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.10.195 with HTTP; Wed, 5 Apr 2017 07:52:48 -0700 (PDT) From: Scott Morizot Date: Wed, 5 Apr 2017 09:52:48 -0500 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0ccd84cd4e46054c6c8b84 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:52:57 -0000 --94eb2c0ccd84cd4e46054c6c8b84 Content-Type: text/plain; charset=UTF-8 Steinar Haug wrote: I believe the lack of DHCPv6 in Android is a political descision. > It certainly isn't due to lack of hardware resources. Agreed. If there's no consensus to say that both MUST be implemented in routers and hosts, and it does appear that politics will prevent even a rough consensus in that direction, then leave it all either unspecified or SHOULD. It will be interesting to see in the long term if Google can actually impose its perspective on other enterprises, regardless of what the IETF publishes. I don't even know that I personally feel that strongly one way or another. But I do know that our core enterprise data networks (as opposed to guest or other constrained networks) will continue to use dhcpv6 only (m=1 and a=0) with no RDNSS configured for the foreseeable future. Devices that won't play in that environment won't be on our procurement list. Scott --94eb2c0ccd84cd4e46054c6c8b84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Steinar Haug wrote:
I believe the lack of DHCPv6 in Android is a politi=
cal descision.
It certainly isn't due t=
o lack of hardware resources.
Agreed. If there'=
;s no consensus to say that both MUST be implemented in routers and hosts, =
and it does appear that politics will prevent even a rough consensus in tha=
t direction, then leave it all either unspecified or SHOULD. It will be int=
eresting to see in the long term if Google can actually impose its perspect=
ive on other enterprises, regardless of what the IETF publishes. I don'=
t even know that I personally feel that strongly one way or another. But I =
do know that our core enterprise data networks (as opposed to guest or othe=
r constrained networks) will continue to use dhcpv6 only (m=3D1 and a=3D0) =
with no RDNSS configured for the foreseeable future. Devices that won't=
 play in that environment won't be on our procurement list.

Scott


--94eb2c0ccd84cd4e46054c6c8b84--


From nobody Wed Apr  5 08:12: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 D0A6F126DC2 for ; Wed,  5 Apr 2017 08:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y5WTG15TIajR for ; Wed,  5 Apr 2017 08:12:42 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 EB27212869B for ; Wed,  5 Apr 2017 08:12:41 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id o126so8856559pfb.3 for ; Wed, 05 Apr 2017 08:12:41 -0700 (PDT)
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=nJvVXAnWpOZCg4obkgy6fxU7r0r/Mflnf8smaP1GLk8=; b=pz594B2bZxUvkdfjQujEgS49pz/3R5HVBN/yfMVkEjHAaUKzK/iuWJDtQJGtNyIb63 gJTrEzKOgUd/GbA6v1T5zrmI4CFDbtD8LKZGsGtcbze21UEeyFgGaLQZvEwgUHPOjf6B 9MDX5Va2Fxdo6voBNoxJRxnX1NItTiTOA4XkyzCsBnjH9m5N/G0P0IOVsJWB8LkuCxhj TUOEok/Q1iep1Mdub57ezURViWhD7Lq7H8ricd9ggaLpwC+mHYaF63fdyWBZQHsODfAU PY+1D+9ZLqNZ6DfHkNB+EhdGM8DyHtd5LFaimfphLq5JTay+N25FbyhxvsMmoRoJ68lQ z0yw==
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=nJvVXAnWpOZCg4obkgy6fxU7r0r/Mflnf8smaP1GLk8=; b=fOUPwT3Qsu+f5X3JfTCwKc1DElDkVsYn/ZvAEp/rFWbJbpo2ybRdvdfDz8uZ662guU Vex6hVGlqVrq9XjYC8dtO4u5A9/wVwzTJH1cVNNOHdruNNgoGsPeJKvAoti+wxthY44M L6imBRZx866xwnEbsbs3brO/ZOWpppcURjyvOq13nc851p2QfaSj/UZ3o5wWB5O/2uQ9 bP6IwAiL0MTicEawUnPGqOYG/K10de6G+FoGowKQNw2+UIfxfd5UD7EkzHAvDQqz5vNa Jb0OjZNGfFqnMcia+o9Gaw/4NKDfNvoZy88feqzFaZBJeuvtLo8MG+DGNnLDRkmRm6GI 8g0g==
X-Gm-Message-State: AFeK/H2f0fJJC1If6I4zDmTikBHyItnwRr2IwRFL0NZel6ZXTpPAlsreUhGh98qR/rutLQ==
X-Received: by 10.84.141.164 with SMTP id 33mr36462783plv.166.1491405161558; Wed, 05 Apr 2017 08:12:41 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:dd21:d7e9:3052:708f? ([2620:0:b60:17:dd21:d7e9:3052:708f]) by smtp.gmail.com with ESMTPSA id u23sm31471197pfi.120.2017.04.05.08.12.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 08:12:40 -0700 (PDT)
From: Ted Lemon 
Message-Id: <88CD2CA6-3FDF-4ACD-A427-287E8CE6E40D@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_526C81AF-A5A1-4524-A589-DBBAC32D9F0A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 08:12:37 -0700
In-Reply-To: <20170405.145921.74683020.sthaug@nethelp.no>
Cc: pch-v6ops-7@u-1.phicoh.com, v6ops@ietf.org
To: "" 
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:12:44 -0000

--Apple-Mail=_526C81AF-A5A1-4524-A589-DBBAC32D9F0A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 5:59 AM, sthaug@nethelp.no wrote:
> =46rom my point of view it looks more like some people don't want to
> implement DHCPv6 for political reasons.

What, they are trying to get elected, and by taking this political =
position they hope to appeal to their demographic?   They are competing =
in a marketplace.   If they can say "no, I won't implement this" and not =
lose market share, then saying it's "political" is just a way of =
applying a pejorative label to a design decision you don't like.


--Apple-Mail=_526C81AF-A5A1-4524-A589-DBBAC32D9F0A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 5:59 AM, sthaug@nethelp.no =
wrote:
=46rom my point of =
view it looks more like some people don't want to
implement DHCPv6 for political =
reasons.

What, they are trying to get elected, and by taking this =
political position they hope to appeal to their demographic?   They =
are competing in a marketplace.   If they can say "no, I won't =
implement this" and not lose market share, then saying it's "political" =
is just a way of applying a pejorative label to a design decision you =
don't like.

=

--Apple-Mail=_526C81AF-A5A1-4524-A589-DBBAC32D9F0A--


From nobody Wed Apr  5 08: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 AC8E3126DC2 for ; Wed,  5 Apr 2017 08:13:46 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 XNE-QelPd_E2 for ; Wed,  5 Apr 2017 08:13:45 -0700 (PDT)
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 EB3AF127241 for ; Wed,  5 Apr 2017 08:13:44 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id x125so9554337pgb.0 for ; Wed, 05 Apr 2017 08:13:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ZX+BQT6FHg8Bn6+156z6hkQSmZGghdyBRac9kwr4Wo4=; b=eLA5nVFs6+7ZX2lNTwz7ggYHdq1qilGMIU19KcJk0w8lYuFSKN0UGwOWVaJJ5zbPX9 M1SM3Sve0Cnnj3HhCRLF4ZMPEydRDha+3400kDr2M05UWbl7oywz0eBGNXvtHivNSLiJ guSOkkti0jBhE6HZcSFKaGRvdQ9ejW3p71+x4k22NfVUeLZ4w/jfuLHC7ElkkgTNWE+7 twDoW7ANKU/JbF4Td94bItDUiJgo9TjEjA9nXuOF/vluyKiX3MwLtbz3lOhaq5NYF1WI q1x2QAmDXc8qbE2X0/Ae+s/j9K59YxD5qw4j5VQWfXmGuB+cNyRqHKuLtC59Iez0yV8+ wjfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=ZX+BQT6FHg8Bn6+156z6hkQSmZGghdyBRac9kwr4Wo4=; b=fmRWc3MkdLOtI0ok4Ka7zY6ahJAT9OQbWQ22b/tSyu0y/lOFoS3bvEUiSE+GJePBHv /PN5z5ymEI/YHoxSmSZTXy9o9J9V0BwXmJyoTqWP0ROZ7TGIcj5vAJk2ku7y27YtMuxb mhsqSqqUhO+giQKktbKMgviMgmeUk04FB9DjhwTuK3AZawzz8PH6g+e0gLDihH4MliUl jwWDETPfcvCq6sfnEZEbzFpgDtpHzsKI9QL8Rl3V7Ppr//qe+r1ug0v/TvHOq4ftxAuu NCHPT2vKSiyOVUMVl9BXQsDzFolq7aYA6ChF0fE0Xuh+VSF3AtkN7cbhezGT8RuE41VG vnYw==
X-Gm-Message-State: AFeK/H0er/RVdoVD7qDVndK+HPpk9m8Fb9SX3Op+qOhW6ssnd46mHt81MzbAEz9tcURUQX1y
X-Received: by 10.99.163.2 with SMTP id s2mr30545447pge.43.1491405224305; Wed, 05 Apr 2017 08:13:44 -0700 (PDT)
Received: from ?IPv6:2001:5a8:4:2290:7433:4774:2e9f:7427? ([2001:5a8:4:2290:7433:4774:2e9f:7427]) by smtp.gmail.com with ESMTPSA id b8sm18249311pgn.51.2017.04.05.08.13.43 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 08:13:43 -0700 (PDT)
From: james woodyatt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7B31F017-7633-4683-A47E-523FA3F0659C"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 5 Apr 2017 08:13:42 -0700
References:  <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405.164601.74682422.sthaug@nethelp.no>
To: IPv6 Operations 
In-Reply-To: <20170405.164601.74682422.sthaug@nethelp.no>
Message-Id: <85D3A1AB-6991-477E-A67F-E0BE8321AD0B@google.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:13:47 -0000

--Apple-Mail=_7B31F017-7633-4683-A47E-523FA3F0659C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 07:46, sthaug@nethelp.no wrote:
>=20
> It's of course entirely possible that prefix delegation doesn't make =
[Stateless] DHCPv6 any more interesting for those who are opposed today. =
Having some idea of the status here would be interesting.

My principle long-standing criticism of Stateless DHCPv6 [RFC 3736] has =
always been for its lack of adequate methods for immediately =
reconfiguring hosts when the network configuration parameters change. I =
think Lorenzo has often made the same criticism, but I think he has a =
longer list of additional technical objections.


--james woodyatt >




--Apple-Mail=_7B31F017-7633-4683-A47E-523FA3F0659C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 07:46, sthaug@nethelp.no wrote:

It's of course entirely possible that =
prefix delegation doesn't make [Stateless] DHCPv6 =
any more interesting for those who are opposed today. =
Having some idea of the status here =
would be interesting.

My principle long-standing criticism of Stateless =
DHCPv6 [RFC 3736] has always been for its lack of adequate methods for =
immediately reconfiguring hosts when the network configuration =
parameters change. I think Lorenzo has often made the same criticism, =
but I think he has a longer list of additional technical =
objections.


=


--james woodyatt <jhw@google.com>







=

--Apple-Mail=_7B31F017-7633-4683-A47E-523FA3F0659C--


From nobody Wed Apr  5 08:15: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 4FB1F127241 for ; Wed,  5 Apr 2017 08:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0-bfUdjBCXET for ; Wed,  5 Apr 2017 08:15:16 -0700 (PDT)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 01CF1129481 for ; Wed,  5 Apr 2017 08:15:12 -0700 (PDT)
Received: by mail-pg0-x231.google.com with SMTP id 21so9563514pgg.1 for ; Wed, 05 Apr 2017 08:15:11 -0700 (PDT)
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=TVUBfO9mbOgPbVWkxcRVjBi0Ru4bScW/Lrz6gR6z6pM=; b=ii5n5K/aO1raCALkIoRFdWF+ZWkyj6czrdtwImLHDo3HEQH4gWPc8GmffApdsqP4eF MHb7ZN07KURM/6KGVsg2I86y8PS9G62CSzoQMa28EnX9DgtlcYeDlt+2cwu6kWU3Jdc0 iKCDYGGwVfbaDIdyvGkEp1+AU4K/WWQxPVXJoYziHg6kv7B4xvKuTlgYv7PR+bagdvQk lvdHjkaBMkyG2qFnyVRcTa+ITC8mOPqBF1uP+AJEPa5ZAO1WWGq1xMqa4sYR6RxDZya5 FFmt/niUfx3bfyqk6fBtM4F22KkHOV55q0NSeozWHY71Td1zXLyYvcpnDKnH3dJdo7Ib 7GoQ==
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=TVUBfO9mbOgPbVWkxcRVjBi0Ru4bScW/Lrz6gR6z6pM=; b=LtEF52ApmGhuhTthRWR8XvUv5ExVF+TzDzVEtXoUxKzVmPrnXDPGTiTkaMkbDlc2Mf cwNV7m06X+PlDEvSHwwj4Gml/j+F/GrS+cfGKN3PxZo0ZPmBCzRM7O6BgdTyhI59TiDo Mpkt+M7z7e5wr420Ig1nvpDDLnsI06UqPZaaDQ4Linectsio37jqDLwP0goXlgL8S1Fi 71DE6LXBvGYy+BeqaBYfZklXHG0DhgfrgryivQ2th1vsC3JQo55UlT/FWTMQtqpTXBwt 4iRw7BevCIA01me265T6a5rRIQEPWJWBJIjxV9oHyV7vf7H8FAn3pVyGr23jJp+8EFpf jvog==
X-Gm-Message-State: AFeK/H1ua/kLplAozw/saQ0yfHKG+1BnChq1dFwCHJylPs527GtclJATMJ+RiECblyV28g==
X-Received: by 10.99.51.200 with SMTP id z191mr30371355pgz.137.1491405311657;  Wed, 05 Apr 2017 08:15:11 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:dd21:d7e9:3052:708f? ([2620:0:b60:17:dd21:d7e9:3052:708f]) by smtp.gmail.com with ESMTPSA id s65sm29237614pgb.34.2017.04.05.08.15.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 08:15:10 -0700 (PDT)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_6BE3D647-3D5A-47CB-ABD1-E882675468FC"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 08:15:06 -0700
In-Reply-To: 
Cc: Philip Homburg , IPv6 Operations , =?utf-8?B?56We5piO6YGU5ZOJ?= 
To: David Farmer 
References:  <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us>    <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>        <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:15:19 -0000

--Apple-Mail=_6BE3D647-3D5A-47CB-ABD1-E882675468FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 6:21 AM, David Farmer  wrote:
> However, If we require both RDNSS and DHCPv6 for both routers and =
host, we reach maximal effectiveness sooner.

Right, but if we do neither, we reach maximal effectiveness later.   =
That is the status quo.


--Apple-Mail=_6BE3D647-3D5A-47CB-ABD1-E882675468FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 6:21 AM, David Farmer <farmer@umn.edu> =
wrote:
However, If we require both =
RDNSS and DHCPv6 for both routers and host, we reach maximal =
effectiveness sooner.

Right, but if we do neither, we reach maximal effectiveness =
later.   That is the status quo.

=

--Apple-Mail=_6BE3D647-3D5A-47CB-ABD1-E882675468FC--


From nobody Wed Apr  5 08:20: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 1F000129481 for ; Wed,  5 Apr 2017 08:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 c1gFMmNryxrN for ; Wed,  5 Apr 2017 08:20:20 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 0F6EF12948F for ; Wed,  5 Apr 2017 08:20:16 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id 81so9630041pgh.2 for ; Wed, 05 Apr 2017 08:20:16 -0700 (PDT)
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=JjvfYfPE9YecxNHQZ+o8nEI62nisJNxhQz+d47MYsxM=; b=W28QmIliUPmNtyBD9fsHnRDprtPkT+DenBQLI5aNl4PTh+q4yuwyquwHQlBCMNrVuf dInJ6+1Gajte/3KxBZaUkFVtuDZSN76VFLcikkiWoFBGIkGKTq0grpE/zvq63dG4fUfF b+EgIbtuhH2ns9mEsCAWJLg6f22g/tPsuibmTGF0iZ+xnxhacl1+FdnvAGaDo7JG6/wM +MskYlO9oIpSnZ7fFqeM9d4tDF8gEKe0n3/5gS5hxvNsBc8RvZOTqXwJ9HUyZdK68VQt ilhdRBly2r9z4yguJvYYGz+Fiza5BxwNag4iRb2H/i5WNQtecQvyAG+5f+BFIWDxUgRi 37VA==
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=JjvfYfPE9YecxNHQZ+o8nEI62nisJNxhQz+d47MYsxM=; b=kHkGFZHUknH6LSvjcgfcAXnj1vdX6l5LXDe72EWJLNnc94mUykFg6TYrQ4mpcPh4Jp 74Vd+kIhfNJGtayniywykIPT3nU/nFmNV4fp7ZM9aeeh+uWBBh+byP8t7Th2Ro9fDY1I A7QZASJ4qKzek/jdkMh79bZ8u8IMl01eCcqkthB1nfpOEbxej3iBfRM8Hqu8b6zmOU1q rZ5FX4Kr0r9vz1ClPdJr72JVRChoEGuo0Gw0LkjltXhVHAVRdT0sRMmAKT5cT40aJweA YlmiYcHLogNm0kXVHAusMxGWyquBosuoOqUNW5I5PDEXgCxlJFf+cvujicgJSP6Cf9ze FvTA==
X-Gm-Message-State: AFeK/H0Wck5EituHLMUIHIR35X0pNHOimyPMU3PQGGfGSNqfqhYcrEzyLTBAQjXF3eY2sg==
X-Received: by 10.99.175.66 with SMTP id s2mr30614838pgo.30.1491405615515; Wed, 05 Apr 2017 08:20:15 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:dd21:d7e9:3052:708f? ([2620:0:b60:17:dd21:d7e9:3052:708f]) by smtp.gmail.com with ESMTPSA id a5sm38252850pfh.124.2017.04.05.08.20.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 08:20:14 -0700 (PDT)
From: Ted Lemon 
Message-Id: <0C4D032C-7FED-4B4A-B15A-1DF1CA6ECB5B@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E08581E-CB75-4CBA-89FC-9A412378FEFE"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 08:20:11 -0700
In-Reply-To: 
Cc: v6ops@ietf.org
To: Philip Homburg 
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>      
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:20:22 -0000

--Apple-Mail=_8E08581E-CB75-4CBA-89FC-9A412378FEFE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 7:48 AM, Philip Homburg  =
wrote:
> The DHCP protocol supports multiple servers. See Section 17.1.3 of RFC =
3315
> (https://tools.ietf.org/html/rfc3315#section-17.1.3 =
)
>=20
> Traditionally, a host gets one address from one server. So there may =
be
> corner cases that would need to be addressed.

DHCP clients don't typically talk to more than one DHCP server per =
interface at the same time, so this model totally breaks down when you =
try to get the behavior that Erik is describing.   In principal you can =
have a DHCP server provide a different DNS server per IA_NA, but in =
practice I don't see that happening, and I doubt it would be reliable to =
try to count on it working.

Of course, the same can be said for what Erik described, but I suspect =
Erik was describing a particular and rather widespread implementation, =
and perhaps motivating his reasoning for preferring this solution in =
that implementation.


--Apple-Mail=_8E08581E-CB75-4CBA-89FC-9A412378FEFE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 7:48 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
The DHCP protocol supports multiple =
servers. See Section 17.1.3 of RFC 3315
(https://tools.ietf.org/html/rfc3315#section-17.1.3)

Traditionally, a host gets one address =
from one server. So there may be
corner cases that =
would need to be addressed.

DHCP clients don't typically talk to more =
than one DHCP server per interface at the same time, so this model =
totally breaks down when you try to get the behavior that Erik is =
describing.   In principal you can have a DHCP server provide a =
different DNS server per IA_NA, but in practice I don't see that =
happening, and I doubt it would be reliable to try to count on it =
working.

Of =
course, the same can be said for what Erik described, but I suspect Erik =
was describing a particular and rather widespread implementation, and =
perhaps motivating his reasoning for preferring this solution in that =
implementation.

=

--Apple-Mail=_8E08581E-CB75-4CBA-89FC-9A412378FEFE--


From nobody Wed Apr  5 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 7D7DC129477 for ; Wed,  5 Apr 2017 08:36:53 -0700 (PDT)
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 NgOP2sgsgwVx for ; Wed,  5 Apr 2017 08:36:51 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 776A8127241 for ; Wed,  5 Apr 2017 08:36:50 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvmzI-0000GLC; Wed, 5 Apr 2017 17:36:48 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bF054DD66@u-1.phicoh.com
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>       <0C4D032C-7FED-4B4A-B15A-1DF1CA6ECB5B@fugue.com> 
In-reply-to: Your message of "Wed, 5 Apr 2017 08:20:11 -0700 ." <0C4D032C-7FED-4B4A-B15A-1DF1CA6ECB5B@fugue.com> 
Date: Wed, 05 Apr 2017 17:36:48 +0200
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:36:53 -0000

>    DHCP clients don't typically talk to more than one DHCP server
>    per interface at the same time, so this model totally breaks
>    down when you try to get the behavior that Erik is describing.
>    In principal you can have a DHCP server provide a different DNS
>    server per IA_NA, but in practice I don't see that happening,
>    and I doubt it would be reliable to try to count on it working.

Prior to RFC 8028 (First-Hop Router Selection by Hosts in a
Multi-Prefix Network) hosts were not really aware of multiple default
routers and how they relate to source addresses.

Additional requirement for hosts get published all the time. If we think that
supporting multiple DHCP servers is important, then we can just as well
publish a BCP that says that.

Even today, it is very unlikely that hosts will keep DNS resolver information
received from different routers apart. Most hosts already have trouble keeping
DNS resolvers on different interfaces separate.

So we are talking protocols and what hosts can do potentially. Not what
operators can rely on that most host implementations already do. For an
operator it doesn't really help to use a feature that is supported by
only one vendor (unless you are willing to limit yourself to only products
from that vendor).

And I guess you are not going to tell me that Erik's employer cannot affort
to fix a DHCP client implementation to support multiple DHCP servers.



From nobody Wed Apr  5 08:39: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 E578C127241 for ; Wed,  5 Apr 2017 08:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 5GEA3fgYArD9 for ; Wed,  5 Apr 2017 08:39:45 -0700 (PDT)
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 D833F12704B for ; Wed,  5 Apr 2017 08:39:44 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id r69so9635679vke.2 for ; Wed, 05 Apr 2017 08:39:44 -0700 (PDT)
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=JBbPcrymoo2uSdLTQcihmN/FDbjXRAX4G7jH5umCeqg=; b=UTpKK5bPPwMvFAbIW5r5uUQkvpyUwumTPAA2LsVucV+aFGPz/Hi12v1YjHz34NiICZ CcEUIGbtdBqZLalL+IUupvY0s1O9Nd1tJIG9pENye/yBZd5xOxuLom3xlv4wCVaLD5Le 0xD113QtJ/5LgB2dD75RBfa0Ct7crWfw5oUbJre0pgYQFqG7bZJg2Vs1mFF2LfcmDQrQ eVk3R5AJHYt1s7PxHWwbNp6j40whLIIkrePLr+6l6amvhWjRC1YR3SkiR+4dwCj4XT6O gslv5jTy60F0seqdV0KGl/mDPEUSZQ2cgWwElrFOW3SETGaWibaXKAt38Un/9Ty8XFkK mIbA==
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=JBbPcrymoo2uSdLTQcihmN/FDbjXRAX4G7jH5umCeqg=; b=bZSh6UNUjf5oWr+A5w2Xr4eqmF5xGTsHz55UT1rrWshhvsSjw1xU9zAra/AYrJAVY4 MyJCg7pXTe0ZSre4AW+y5N/86mRkHZLM/sc77Ofe59svOdFpWLwr7mREeGf7PewMxrKg +2Zk1HLbEL7yp4xC6/0FEB5ZUusoZ/MDNYunqHezoXEOv/zY+BtofyhrFTS209/dhJhQ vKmsOSkc1ZYZt/hxEkdLZrtZjtAsqAORD3gT6nQ+MxgXt/tJadKoO1MmnBYM8dReH2EJ nNSKYCHAzaVV3HPOKqxAhfyIAe0ftDQnKVPQJtllznW8YN154oerQ3kdG7uA9jWUuCHG /6Tg==
X-Gm-Message-State: AFeK/H1wO3fzCFCj0YTw36ilxqRVRH7dJAOmIobVxUzOHRbkDb27Ps6YMG3aztn/Rre+hdMq/Ypf2FniHZs45ol7
X-Received: by 10.159.52.198 with SMTP id b6mr12957655uac.155.1491406783540; Wed, 05 Apr 2017 08:39:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 08:39:22 -0700 (PDT)
In-Reply-To: <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>
From: Lorenzo Colitti 
Date: Thu, 6 Apr 2017 00:39:22 +0900
Message-ID: 
To: Tim Chown 
Cc: "sthaug@nethelp.no" , "v6ops@ietf.org" 
Content-Type: multipart/alternative; boundary=f403045e2a5a8d2a6a054c6d338e
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:39:48 -0000

--f403045e2a5a8d2a6a054c6d338e
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 5, 2017 at 10:13 PM, Tim Chown  wrote:

> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in
> routers


I don't think we should recommend stateless DHCP support in hosts because
it is technically inferior to RDNSS. (For a list of reasons why, see
https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html , and
also see what James just wrote) Taking a host that is capable of doing
RDNSS and forcing it to also implement a less-capable protocol is a bad
tradeoff for that host's users.

That is why host OS developers are opposed to DHCPv6, and I'm afraid that
opposition is not going to go away. "My network, my choice" (as Job
succinctly described a similar position in IEPG), is certainly not
sufficient justification to change it. "This is what we do in IPv4" is also
not - mass deployment of IPv4 will eventually go away, but the choices we
make now are going to shape IPv6 for several decades after that.

We should all be providing what's best for our users.

--f403045e2a5a8d2a6a054c6d338e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Apr 5, 2017 at 10:13 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
b) RFC3736=
 stateless DHCP support is a SHOULD in hosts and a MUST in routers

I don't think we should recommend stateless DHC=
P support in hosts because it is technically inferior to RDNSS. (For a list=
 of reasons why, see https://www.ietf.org/mail-archive/web/v6ops/current=
/msg26068.html , and also see what James just wrote)=C2=A0Taking a host=
 that is capable of doing RDNSS and forcing it to also implement a less-cap=
able protocol is a bad tradeoff for that host's users.

That is why host OS developers are opposed to DHCPv6, and I'm =
afraid that opposition is not going to go away. "My network, my choice=
" (as Job succinctly described a similar position in IEPG), is certain=
ly not sufficient justification to change it. "This is what we do in I=
Pv4" is also not - mass deployment of IPv4 will eventually go away, bu=
t the choices we make now are going to shape IPv6 for several decades after=
 that.

We should all be providing what's best =
for our users.


--f403045e2a5a8d2a6a054c6d338e--


From nobody Wed Apr  5 08:42: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 786FE12941C for ; Wed,  5 Apr 2017 08:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 KFbFqZqim4A9 for ; Wed,  5 Apr 2017 08:42:18 -0700 (PDT)
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 D98AE12704B for ; Wed,  5 Apr 2017 08:42:17 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id z204so9757594vkd.1 for ; Wed, 05 Apr 2017 08:42:17 -0700 (PDT)
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=lx80FMZaWQ0kW4JVqT/ExnXTD5eB1ZozP/MaUTkta9Q=; b=q3xRP47qH2iteTslLNTwW/LdzGzt0u6W9pf/0NBk5H/Qx1JUCpa51zYVoyVkDB4jt3 Vh3xph26puHtuoyKgBHI80M/Gj08M4Uj2cflRJUzCdKlyL/EIjUqA3H04+JbfFqbhVgs ukby3KMqwXTb5PTHAAtHcVOXdrHtZq9b0AQAmuheY6Eg92AvNc69/MbgEEod/6UdQD+I raFL4fY8kblQlvFPplNVxtQVvT7v+d4+yS//HbanwLzmrL0m4m56MdOZiutHP3soHq2D nX3rd8GlzfdMKWAYvGitkmpREbYIcpdqElvlcp74icJF3IqmGhj0KH/SfkMZ6KPY6v0b 7xFw==
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=lx80FMZaWQ0kW4JVqT/ExnXTD5eB1ZozP/MaUTkta9Q=; b=bLaJ/GSOS/z/O2sytgDHtxFOGrlakvcYVxDlZSf1PUwPBKGqgewbqiEY50y05o7doO ilK0usxLs9006BXoMkyC3F7309kiFRqDpb4zx5EVbBwNUpl6vUjkXddRMppEi44+wjmq XOjquWClQiPB7bRZGYnkA8wHtk5G2FfEEN5GX2zboULRzkkvMOa3sD9UBtbUTICyJXGy M5uJNJbmKsKE+t36/hfA9kVkBzhiX4ffmgqvj1ggSxbCVelwTQccqRNrkmgl8OiSWE8g Tdv2XEsydX9cbUue5jlHY3OItnA1JNsDl5GEAWmMrsZ1WvpQUrGur9NczAh6Z6l4Ff2a saDQ==
X-Gm-Message-State: AFeK/H1Wodn4mM4lClQMAtp23MDrkQu3c3xf0uspeSoDSG6YtNvcqjKUraiO4+Nxjp2PVhtB/R5C1KIWpS2VuiNQ
X-Received: by 10.31.185.73 with SMTP id j70mr11903338vkf.102.1491406936732; Wed, 05 Apr 2017 08:42:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 08:41:55 -0700 (PDT)
In-Reply-To: 
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>       <0C4D032C-7FED-4B4A-B15A-1DF1CA6ECB5B@fugue.com> 
From: Lorenzo Colitti 
Date: Thu, 6 Apr 2017 00:41:55 +0900
Message-ID: 
To: Philip Homburg 
Cc: "v6ops@ietf.org WG" 
Content-Type: multipart/alternative; boundary=001a11439f3cae769d054c6d3cbb
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:42:19 -0000

--001a11439f3cae769d054c6d3cbb
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 6, 2017 at 12:36 AM, Philip Homburg 
wrote:

> Additional requirement for hosts get published all the time. If we think
> that
> supporting multiple DHCP servers is important, then we can just as well
> publish a BCP that says that.
>

Even if you do, you still have the problem that it is impossible to add a
new DHCPv6 server to add more information while the client already has a
lease. DHCPv6 is a request-response protocol, and those protocols are
fundamentally not good ad distributing new information efficiently.

You also have the problem that if a server crashes nobody can tell the
client that something has changed because the nonce is gone.

--001a11439f3cae769d054c6d3cbb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Apr 6, 2017 at 12:36 AM, Philip Homburg <pch-v6ops-7@u-1.ph=
icoh.com> wrote:
Additional requirement for hosts get published all the time. If =
we think that

supporting multiple DHCP servers is important, then we can just as well

publish a BCP that says that.

Even if y=
ou do, you still have the problem that it is impossible to add a new DHCPv6=
 server to add more information while the client already has a lease. DHCPv=
6 is a request-response protocol, and those protocols are fundamentally not=
 good ad distributing new information efficiently.

You also have the problem that if a server crashes nobody can tell the cli=
ent that something has changed because the nonce is gone.
=



--001a11439f3cae769d054c6d3cbb--


From nobody Wed Apr  5 08:47: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 CB1AF129420 for ; Wed,  5 Apr 2017 08:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 W3M8nreaP5_W for ; Wed,  5 Apr 2017 08:47:03 -0700 (PDT)
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 EB12412704B for ; Wed,  5 Apr 2017 08:47:02 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id o126so9281274pfb.3 for ; Wed, 05 Apr 2017 08:47:02 -0700 (PDT)
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=p9T7KB6yC/e3D1TcQwgVUbU8NlrfDqLJJihy66c6KL8=; b=jhIowjrnrjPSZ6WpjYxLV7PXpEqUxSE59ctin1iOEVTh6LAKkDNpwPmdypcoc6FsOc 5QjRS90QP5kUl1OCS19n457StVO6+eoQzAkzTvZS9/eqmZuyiY5Nik4sYl9Bdp0997Pw IQLFa6kQLBRDwIOH8wMjzhux66JAwrRxHiTvXQMaVuafTlxm/S+i0JGZmzKv0N21onw5 BSlPK4okYuQT9FqHr1XxACWXWX0lWmomuHp9gjZU9SY4x+lEoKS8FJU91RAF0VEqef3v BrnfaEyYk2OqVVNnGEMqvXEWsctKGDtFJkVAWm46atNxQ7PCl0IkzUtX7TdujTyI0RyH v1Yw==
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=p9T7KB6yC/e3D1TcQwgVUbU8NlrfDqLJJihy66c6KL8=; b=nThR8RGoiioMbzE+7DNk3MT8Zg+jy7yQLqLYD052xJSay+Mr7JcVgfr5jf07NTk4V0 iOO7lekQOBRSumhlsUVI1YS5hM73uwdAw0gdilXxpNaeLfzfSO4BMRQ5mPnxvymzhwn7 ZOpJos7lA6YJSqKvKsJeJGU8byKi74TVXxpkzKCKLujD8K2Xs8D4U8m4iLTE8xAkEs17 v+dwiO+Ll/49z+zKhfwXP9woQSoJQ2gfg8DVltNAbjUcnR6upAuARyY3zfkVCElg96qr uy71sOuFQpsXfyJ+T0GDXV/3Lzu7ywrnVy5MaKXZkPSVQlbwxSp3kpnBKUUGRyAqcsrv Q7jg==
X-Gm-Message-State: AFeK/H2QVXQW51mPcwWkqmUP++1U+v5G6WJwXn7ZfEVcr45/qUk7gecmJ6b2xod9wWIVnw==
X-Received: by 10.99.95.73 with SMTP id t70mr30171202pgb.84.1491407222599; Wed, 05 Apr 2017 08:47:02 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:dd21:d7e9:3052:708f? ([2620:0:b60:17:dd21:d7e9:3052:708f]) by smtp.gmail.com with ESMTPSA id r66sm38343584pfi.49.2017.04.05.08.47.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 08:47:01 -0700 (PDT)
From: Ted Lemon 
Message-Id: <13AD106F-6813-4B41-AA15-F653A5B21FA0@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D59D1412-F672-4671-8503-4C72114F1683"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 08:46:58 -0700
In-Reply-To: 
Cc: v6ops@ietf.org
To: Philip Homburg 
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>       <0C4D032C-7FED-4B4A-B15A-1DF1CA6ECB5B@fugue.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:47:05 -0000

--Apple-Mail=_D59D1412-F672-4671-8503-4C72114F1683
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Apr 5, 2017, at 8:36 AM, Philip Homburg  =
wrote:
> Additional requirement for hosts get published all the time. If we =
think that
> supporting multiple DHCP servers is important, then we can just as =
well
> publish a BCP that says that.

This is directed reasoning.   Speaking as someone who should probably =
know, what you are describing is a new standards track document, which =
would take a year at least to publish if we started right now, and if =
there were consensus to do it.   Getting DHCP to do what you are saying =
is not trivial. This isn't a small tweak=E2=80=94it's a substantial =
change in the flow of the protocol.   We certainly envisioned this =
possibility when we wrote RFC 3315, but it turns out that we didn't =
specify it clearly enough, and nobody implemented anything like it.   To =
fix that would be real work, not a line in a requirements doc.


--Apple-Mail=_D59D1412-F672-4671-8503-4C72114F1683
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Apr 5, 2017, at 8:36 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
Additional requirement for hosts get =
published all the time. If we think that
supporting multiple =
DHCP servers is important, then we can just as well
publish a BCP that says that.

This =
is directed reasoning.   Speaking as someone who should probably =
know, what you are describing is a new standards track document, which =
would take a year at least to publish if we started right now, and if =
there were consensus to do it.   Getting DHCP to do what you are =
saying is not trivial. This isn't a small tweak=E2=80=94it's a =
substantial change in the flow of the protocol.   We certainly =
envisioned this possibility when we wrote RFC 3315, but it turns out =
that we didn't specify it clearly enough, and nobody implemented =
anything like it.   To fix that would be real work, not a line in a =
requirements doc.

=

--Apple-Mail=_D59D1412-F672-4671-8503-4C72114F1683--


From nobody Wed Apr  5 08:49: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 B31571289B5 for ; Wed,  5 Apr 2017 08:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.303
X-Spam-Level: 
X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 zvsnT8Y5ubvj for ; Wed,  5 Apr 2017 08:49:08 -0700 (PDT)
Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id EF593128D40 for ; Wed,  5 Apr 2017 08:48:55 -0700 (PDT)
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 v35FmtX5027169 for ; Wed, 5 Apr 2017 11:48:55 -0400
DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v35FmtX5027169
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1491407335; bh=8wpysciZlrQSNpA47LJem8WpUtw2kRMzmPd0yOfUhUk=; h=Date:From:To:Subject:References:In-Reply-To; b=NZzVwsfJQV6ZX6O1T28RUxn+nTav6npEtAacNJXVmktafLX8FHv1MiP/0EzKojGOk E5ZBTzeHgDlPYJyRH7v9u8f0fFXAA0MkvdZqN+pM13czufJ2KmeItshsROlHPaJ54M ugzrgFTW6zd0LR2Em17oPE8CWp4llNrKbgxV3ytE=
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 v35FmtYB027166 for ; Wed, 5 Apr 2017 11:48:55 -0400
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 v35Fmsvn006238 for ; Wed, 5 Apr 2017 11:48:54 -0400 (envelope-from cra@WPI.EDU)
Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 343EAE114E; Wed,  5 Apr 2017 11:48:54 -0400 (EDT)
Date: Wed, 5 Apr 2017 11:48:54 -0400
From: Chuck Anderson 
To: v6ops@ietf.org
Message-ID: <20170405154854.GA28135@angus.ind.wpi.edu>
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> 
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=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODYTEXTP_SIZE_400_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_200_299 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, SMALL_BODY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 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_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0,  __TO_NO_NAME 0, __USER_AGENT 0'
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:49:10 -0000

Why are DNS resolvers a link-specific parameter that needs to be
distributed to clients at all?  Can't they just use some other
discovery mechanism to find a resolver or do full-recursion w/DNSSEC
validation?


From nobody Wed Apr  5 08: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 C2F251289B5 for ; Wed,  5 Apr 2017 08:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kOmsTVxJ8t4g for ; Wed,  5 Apr 2017 08:53:52 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 05F4E124234 for ; Wed,  5 Apr 2017 08:53:52 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id x125so10085220pgb.0 for ; Wed, 05 Apr 2017 08:53:52 -0700 (PDT)
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=B237cmyPp24oB94ycJaAJ3tRRYyZ0J782SwVRD0ooYE=; b=fWBrfXlqJXKSLNyztCbF3Tpd41eCdH1VLSUuwKd+AnFyNIghruj8Pcmt2TatOkGnnS /u8EgCVebNjze/7zDj2lbbzobTQkN448ckD2ipZ9d8KFfewBepAnxvCQFzK7ldRZKh14 aAuXQETRxosdfM4l+ZY/zsGQtllDfShCyPP3r98HLTBQrI30ZLDU2ehVbJx6vs5Jlhfd yPMsEKS17xnGUB2V5w50JbxkeF+YkcMwpNpBMvlB1fO5v/MEv1wYL9o411pK3v5FYcVB cnGTT1SDsH06ay5Q69Kzrn2NX3Lv1dh/5fRP2f0edF9uaF7MNef2vHf/BerhvfgxR9PR ScfQ==
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=B237cmyPp24oB94ycJaAJ3tRRYyZ0J782SwVRD0ooYE=; b=uA/4VZNMnS/vgHQbmqBtTnflZaLVzdYwSfRSTzABsflSucuDqyJskTqdKJFd245wbA dSmgCvASs2CfgCSLJjkvMSV2u8A8QlyaZwV3Sswl0IdRRrx6luyMZixJX9PKoVtRpfNs EoTVQP9S+ZpPrddr0J4eP8Z/GB1QIHq++h9gvSGZgkmLh+O01Qm6k//S1PAZkhUDi+aP KXno4Imv//k75SIuY9FUsd/sJe0pHNY7MiBr+N5dAu6AZETBIZHUvDvm6xTyNjO2YVGU E/a/QVnzz/mbkJT/L77TyVhUWt8TdFb90lXkWUIl0Dq2QeMaDotTiwVwXyq5umDQiYC+ tX5g==
X-Gm-Message-State: AFeK/H1GcWQHn2QuYL2RDPWDv1kqJPBNrknYuozMkksjjlZwh22EAXYKL6tVSzqGwPTH5Q==
X-Received: by 10.84.129.131 with SMTP id b3mr37315955plb.160.1491407631578; Wed, 05 Apr 2017 08:53:51 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:dd21:d7e9:3052:708f? ([2620:0:b60:17:dd21:d7e9:3052:708f]) by smtp.gmail.com with ESMTPSA id u69sm38399035pfg.121.2017.04.05.08.53.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 08:53:50 -0700 (PDT)
From: Ted Lemon 
Message-Id: <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F3752D4E-FC8A-45EB-873B-383DE1CE4C6A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 08:53:47 -0700
In-Reply-To: <20170405154854.GA28135@angus.ind.wpi.edu>
Cc: v6ops@ietf.org
To: Chuck Anderson 
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>  <20170405154854.GA28135@angus.ind.wpi.edu>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 15:53:54 -0000

--Apple-Mail=_F3752D4E-FC8A-45EB-873B-383DE1CE4C6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 8:48 AM, Chuck Anderson  wrote:
> Why are DNS resolvers a link-specific parameter that needs to be
> distributed to clients at all?  Can't they just use some other
> discovery mechanism to find a resolver or do full-recursion w/DNSSEC
> validation?

Because end-users would suffer if they didn't use the configured =
resolver: the DNS protocol is designed with caching in mind, and at this =
point CDNs use DNS extensively.   So if you don't use the local =
resolver, you will see major performance issues.   But yeah, aside from =
that quibble, what you are saying makes a lot of sense (seriously!).   =
:)


--Apple-Mail=_F3752D4E-FC8A-45EB-873B-383DE1CE4C6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 8:48 AM, Chuck Anderson <cra@WPI.EDU> =
wrote:
Why are DNS =
resolvers a link-specific parameter that needs to be
distributed to clients at all?  Can't they =
just use some other
discovery mechanism =
to find a resolver or do full-recursion w/DNSSEC
validation?

Because end-users would suffer if they didn't =
use the configured resolver: the DNS protocol is designed with caching =
in mind, and at this point CDNs use DNS extensively.   So if you =
don't use the local resolver, you will see major performance issues. =
  But yeah, aside from that quibble, what you are saying makes a =
lot of sense (seriously!).   :)

=

--Apple-Mail=_F3752D4E-FC8A-45EB-873B-383DE1CE4C6A--


From nobody Wed Apr  5 09:01: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 433D2124234 for ; Wed,  5 Apr 2017 09:01:00 -0700 (PDT)
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 VrUkVuwWbjXd for ; Wed,  5 Apr 2017 09:00:58 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1B79D1273E2 for ; Wed,  5 Apr 2017 09:00:58 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvnMe-0000HmC; Wed, 5 Apr 2017 18:00:56 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bF054DD66@u-1.phicoh.com
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>       <0C4D032C-7FED-4B4A-B15A-1DF1CA6ECB5B@fugue.com>   
In-reply-to: Your message of "Thu, 6 Apr 2017 00:41:55 +0900 ."  
Date: Wed, 05 Apr 2017 18:00:56 +0200
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:01:00 -0000

>Even if you do, you still have the problem that it is impossible to add a
>new DHCPv6 server to add more information while the client already has a
>lease. DHCPv6 is a request-response protocol, and those protocols are
>fundamentally not good ad distributing new information efficiently.

Of course you can. If a new router pops up and sends a RA with the M bit set
then the host can retry obtaining DHCP leases. We currently don't have
that specified. But that's only a few lines in a BCP.

>You also have the problem that if a server crashes nobody can tell the
>client that something has changed because the nonce is gone.

Yes, and using RAs it is very hard to have host specific configuration.

It is not clear to me what server you are talking about. If you are talking
about a DHCP server, then at the time scale DHCP server operate, certainly in
small networks, there are plenty of options of storing state persistently.

(Note that just about all IPv4 DHCP servers store DHCP leases persistently).

In bigger networks, it is way more efficient to have a cluster of DNS
resolvers, than to try to update all hosts and hope that all hosts also
support reloading DNS resolvers in running processes.

By all means, if you think that in your network it is likely that your DNS
resolvers change addresses, use RDNSS. However, that is very poor argument
for refusing to support DHCP in networks where the DNS resolvers will never
change addresses and people want the ability direct select hosts to different
resolvers. Or want to use DHCP to pass additional options to some hosts
and do not want to configure RDNSS on all routers just because some hosts
refuse to support DHCP.



From nobody Wed Apr  5 09:04:29 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 A4F731200C5 for ; Wed,  5 Apr 2017 09:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.303
X-Spam-Level: 
X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 P4std8f_rIlg for ; Wed,  5 Apr 2017 09:04:25 -0700 (PDT)
Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id AB304129465 for ; Wed,  5 Apr 2017 09:04:23 -0700 (PDT)
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 v35G4Nl9013368 for ; Wed, 5 Apr 2017 12:04:23 -0400
DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v35G4Nl9013368
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1491408263; bh=H9ybhNgU2thizhw8qsA8SVRXw0V3ikDJdAntdeDPUUQ=; h=Date:From:To:Subject:References:In-Reply-To; b=Z14NjUf++xN3ZaymG2K4jBasbeZMhMy9cNgJ3A5hzssPJZo4ZsLw16mdHXb4WS3B1 kjz6rxzhlmiXpvooAjijdmsvhhQhGQvX+VtI0qiTCvCJ+yMl/5MyRTMFLtshxe1KcW nxB4mC3mqsut+nZigW9kViCR5Wvui4Tteah0k5VY=
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 v35G4Nx4013363 for ; Wed, 5 Apr 2017 12:04:23 -0400
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 v35G4LDG026065 for ; Wed, 5 Apr 2017 12:04:22 -0400 (envelope-from cra@WPI.EDU)
Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id D402FE114E; Wed,  5 Apr 2017 12:04:21 -0400 (EDT)
Date: Wed, 5 Apr 2017 12:04:21 -0400
From: Chuck Anderson 
To: v6ops@ietf.org
Message-ID: <20170405160421.GB28135@angus.ind.wpi.edu>
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>  <20170405154854.GA28135@angus.ind.wpi.edu> <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.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, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1400_1499 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, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 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_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:04:27 -0000

On Wed, Apr 05, 2017 at 08:53:47AM -0700, Ted Lemon wrote:
> On Apr 5, 2017, at 8:48 AM, Chuck Anderson  wrote:
> > Why are DNS resolvers a link-specific parameter that needs to be
> > distributed to clients at all?  Can't they just use some other
> > discovery mechanism to find a resolver or do full-recursion w/DNSSEC
> > validation?
> 
> Because end-users would suffer if they didn't use the configured resolver: the DNS protocol is designed with caching in mind, and at this point CDNs use DNS extensively.   So if you don't use the local resolver, you will see major performance issues.   But yeah, aside from that quibble, what you are saying makes a lot of sense (seriously!).   :)

Okay, so can't clients just do a mDNS request to find a local resolver?

I have a strong dislike of involving the router in distributing
higher-layer parameters like RDNSS and DNSSL.  It causes real
operational problems when the DNS infrastructure and routers are
maintained by different teams.  Also, having DNS resolvers distributed
by routers means there is no fate-sharing between the provider of the
service and the distributor of the configuration.  If a DNS server
goes down, how do all the routers in the network magically get updated
with new DNS server configuration to distribute to the clients?

With DHCP, the DNS server can and often is co-located with the DHCP
server.


From nobody Wed Apr  5 09:05: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 0276D127871 for ; Wed,  5 Apr 2017 09:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KLLcmutc9x8d for ; Wed,  5 Apr 2017 09:05:25 -0700 (PDT)
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 1AA39124234 for ; Wed,  5 Apr 2017 09:05:25 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id g2so10105467pge.3 for ; Wed, 05 Apr 2017 09:05:25 -0700 (PDT)
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=K+yK8kq6TCPx8WS40o/k+/93CbGwTulkArtycyK73S0=; b=rPi144NtREJwctpPJl6AhQU4BArKI4Obxd5J4UKrfuYvwnVk2C/wTESBIIusAQjKLF HNhxMhSQfZCFOi/ZrfWHT9qpYcipOTl0bN6M1UCHNBiv+Za+rJvEQSJ5U/sUNY2e4CRp 7U1RST8TRYx9AbgPPGg6iD+cSh4z1Lnm9gKCx+8u5/CDHgwGYw+r8xfs+52zalc2WDZb pKc4SLC6RpteCumENqcnxscPYNOFbEqsRmFhUILqcNJNWJr0LKPkWZII+FC23YXLbJ7K e1tCA+8rp2URq9KvEW1fo2yd0mwOXh09iB3SVyszk9e3DRdh2rq5XiiRp8Yz/qXRgkLn BNzA==
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=K+yK8kq6TCPx8WS40o/k+/93CbGwTulkArtycyK73S0=; b=DV0uXOZkx37JOvNaMcMsyEHxHKV4A9aMX0h855nIcL0beEhhdvjqbK8/8ZzW6NwR5o 5InCGbbN3v5V9f8x2kheGW1v/DofhIS2cpNs1v9d4sW0YF2jIiqRDGA+LsUJnYCpaoSG 5rNl1C67P3s1SK9G+bHPyOWxPQMU1gzZbchYJm+0jQpOFiyu4uyxMihw2rsTHl5ujQFR bgDIwxeidADrnYUSU+4YjXZPQALDoiu3RBbWio1LUjRV09tbXLtSb9s04ibmot1f3wgl xekT/TlhYEWmL8yrKW5BSw+aEnhdZPBSTNI8DJtSbYxCVu++3F6UJVvTduo1GxjGka3/ 894A==
X-Gm-Message-State: AFeK/H02tGqO2zBMvp7Dj4xtAo5EAYg9KqOO6/PaXObK1aqDoCyU9cyBmx9BwnLfllu4Ag==
X-Received: by 10.98.15.91 with SMTP id x88mr5143183pfi.86.1491408324742; Wed, 05 Apr 2017 09:05:24 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:dd21:d7e9:3052:708f? ([2620:0:b60:17:dd21:d7e9:3052:708f]) by smtp.gmail.com with ESMTPSA id v86sm38441625pfa.86.2017.04.05.09.05.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 09:05:23 -0700 (PDT)
From: Ted Lemon 
Message-Id: <6A449F1E-81BA-4B1A-8A6F-0825EA354366@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6B59D83B-21A4-4DFB-BB73-0A6848D96BDF"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 09:05:20 -0700
In-Reply-To: <20170405160421.GB28135@angus.ind.wpi.edu>
Cc: v6ops@ietf.org
To: Chuck Anderson 
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>  <20170405154854.GA28135@angus.ind.wpi.edu> <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:05:27 -0000

--Apple-Mail=_6B59D83B-21A4-4DFB-BB73-0A6848D96BDF
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 9:04 AM, Chuck Anderson  wrote:
> Okay, so can't clients just do a mDNS request to find a local resolver?

https://xkcd.com/927/ 


--Apple-Mail=_6B59D83B-21A4-4DFB-BB73-0A6848D96BDF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 9:04 AM, Chuck Anderson <cra@WPI.EDU> =
wrote:
Okay, so can't =
clients just do a mDNS request to find a local resolver?

https://xkcd.com/927/

=

--Apple-Mail=_6B59D83B-21A4-4DFB-BB73-0A6848D96BDF--


From nobody Wed Apr  5 09:07: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 E8E181293FD for ; Wed,  5 Apr 2017 09:07:51 -0700 (PDT)
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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 ZTDNevK_NvzE for ; Wed,  5 Apr 2017 09:07:49 -0700 (PDT)
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 96BF31293EC for ; Wed,  5 Apr 2017 09:07:48 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B22A961928 for ; Wed,  5 Apr 2017 18:07:46 +0200 (CEST)
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 82A0660BCB; Wed,  5 Apr 2017 18:07:46 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 74AD33301; Wed,  5 Apr 2017 18:07:46 +0200 (CEST)
Date: Wed, 5 Apr 2017 18:07:46 +0200
From: Gert Doering 
To: Chuck Anderson 
Cc: v6ops@ietf.org
Message-ID: <20170405160746.GI25069@Space.Net>
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>  <20170405154854.GA28135@angus.ind.wpi.edu> <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170405160421.GB28135@angus.ind.wpi.edu>
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:07:52 -0000

Hi,

On Wed, Apr 05, 2017 at 12:04:21PM -0400, Chuck Anderson wrote:
> I have a strong dislike of involving the router in distributing
> higher-layer parameters like RDNSS and DNSSL.  It causes real
> operational problems when the DNS infrastructure and routers are
> maintained by different teams.  Also, having DNS resolvers distributed
> by routers means there is no fate-sharing between the provider of the
> service and the distributor of the configuration.  If a DNS server
> goes down, how do all the routers in the network magically get updated
> with new DNS server configuration to distribute to the clients?

I really wonder if anyone does it that way.  

"Our DNS server has died, so let's quickly provide new recursor addresses
to EVERYTHING"

instead of

"Our DNS server has died, let's put that address on the secondary box, 
so clients can just happily continue using the address they have learned
by whatever means"

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 Wed Apr  5 09:13: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 578901293EC for ; Wed,  5 Apr 2017 09:13:55 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 AJ4n6ulXw_14 for ; Wed,  5 Apr 2017 09:13:53 -0700 (PDT)
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 D11551286CA for ; Wed,  5 Apr 2017 09:13:52 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id 21so10346268pgg.1 for ; Wed, 05 Apr 2017 09:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=2cM78GEtXLU/e0F0t6qRx1H30xqagl8HLbwvOTC4lB8=; b=cLptP+6aUKTVNT3FNsYs0s7H3oNA+BZZ18IeprkAz508JyIVeA+N6sxKKN8597x8Ba mLIfAxpayarlHFGFfFzipDZQffqwxeWSBlleWjijZeG7EcVtoMr+HNpMT4uqQWkhH4BC wrzvUVpBSqGaW9d3y72RFWIZhJmhhjxDKKCq8mIVAo1Ellm921Y6ECs7fIcsaDmhZyJu h7O4Bzlx+s29BznynZpeKw9WW8bzmalol4c47vSVCh7IBciJuBYkheH6T0f5DAGlpgku Sux4wYEjDGj3d/rBlsXkS27STVyC+N3l2Ta/yYDgToJ6SlFft959LF9W27mI5ZEExRmy HwFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=2cM78GEtXLU/e0F0t6qRx1H30xqagl8HLbwvOTC4lB8=; b=mNDdcCLfUCdTLk4Vv2CJDWBIw/XtLAmd5UBMNRGHgSd0JTVRDidc1rG5i8kIPCCW4t oUqq+huX8HLbHrLRITIcxbwjnvqfDExZL4XOFxVcKL1rEfJFOPLrwZs5m2FTxtW/WRr8 lOOfnuntdHGq4fB1YRtj6mp81wjStoh6p/KFwnWoYSWOEkGXfaaS1fw8hoVT+VE9mhp7 lvZ6D9uCWE5Nmwp5loch0YEhPZ+4V2D3MWZ9cJX7677N16Y4B62p3ThhIwML4o7O6OMn Sf9Xeq3B2ukhCovfcebPU0m4YYKjEi46iBEy3MqEnQdodjwwnGrXZG4lJPRl89gc2NqD PHvw==
X-Gm-Message-State: AFeK/H1sCAa5BXzvR8UK9H66Q1iPfeoYx6mFG6XCiObc/we2+vonctMmEYh1R+Fp8rfrXsox
X-Received: by 10.84.213.144 with SMTP id g16mr36885203pli.28.1491408832225; Wed, 05 Apr 2017 09:13:52 -0700 (PDT)
Received: from ?IPv6:2001:5a8:4:2290:7433:4774:2e9f:7427? ([2001:5a8:4:2290:7433:4774:2e9f:7427]) by smtp.gmail.com with ESMTPSA id a21sm38445818pfc.36.2017.04.05.09.13.51 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 09:13:51 -0700 (PDT)
From: james woodyatt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_175ADEC6-B8CD-4269-966B-5E377521FC67"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 5 Apr 2017 09:13:50 -0700
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>  <20170405154854.GA28135@angus.ind.wpi.edu> <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu>
To: IPv6 Operations 
In-Reply-To: <20170405160421.GB28135@angus.ind.wpi.edu>
Message-Id: 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:13:55 -0000

--Apple-Mail=_175ADEC6-B8CD-4269-966B-5E377521FC67
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Apr 5, 2017, at 09:04, Chuck Anderson  wrote:
>=20
> Okay, so can't clients just do a mDNS request to find a local =
resolver?


Too expensive. Let=E2=80=99s just use link-local multicast CoAP to send =
a CoRE-RD query for rt=3D=E2=80=9Cdns=E2=80=9D instead.


--james woodyatt >




--Apple-Mail=_175ADEC6-B8CD-4269-966B-5E377521FC67
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Apr 5, 2017, at 09:04, Chuck Anderson <cra@WPI.EDU> wrote:

Okay, so can't clients just do a mDNS request to =
find a local resolver?

Too expensive. Let=E2=80=99s just use =
link-local multicast CoAP to send a CoRE-RD query for rt=3D=E2=80=9Cdns=E2=
=80=9D instead.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_175ADEC6-B8CD-4269-966B-5E377521FC67--


From nobody Wed Apr  5 09:27: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 D1D9B1286CA for ; Wed,  5 Apr 2017 09:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 6iWQlr3rhHlV for ; Wed,  5 Apr 2017 09:27:17 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5E8129445 for ; Wed,  5 Apr 2017 09:27:17 -0700 (PDT)
Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id DFB8EE6065; Wed,  5 Apr 2017 18:27:15 +0200 (CEST)
Date: Wed, 05 Apr 2017 18:27:15 +0200 (CEST)
Message-Id: <20170405.182715.41700611.sthaug@nethelp.no>
To: gert@space.net
Cc: cra@WPI.EDU, v6ops@ietf.org
From: sthaug@nethelp.no
In-Reply-To: <20170405160746.GI25069@Space.Net>
References: <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu> <20170405160746.GI25069@Space.Net>
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: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:27:20 -0000

> "Our DNS server has died, let's put that address on the secondary box, 
> so clients can just happily continue using the address they have learned
> by whatever means"

"One of our anycast DNS servers has died. While we work to get that
server up and running again, clients will happily continue using the
same anycast server address - but may experience slightly increased
latency."

Steinar Haug, AS2116


From nobody Wed Apr  5 09:35: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 5CCDF12894E for ; Wed,  5 Apr 2017 09:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 9EirJr2ARy1Y for ; Wed,  5 Apr 2017 09:35:16 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 97CB8127871 for ; Wed,  5 Apr 2017 09:35:16 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id z204so11691053vkd.1 for ; Wed, 05 Apr 2017 09:35:16 -0700 (PDT)
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=MF80bTLCRraqsl9zNqBs+gcuzQ7Ry9QPdYOoCiWvcFc=; b=gq8N2xNIODSTy20coaIgysetxlMiXaaxgH0m7LOflOHX3Io21AFuDy2nJO29Hq3J1L pXQUIFxNbTbvLe3XiTK/xiVrKHg1QESRNpTDQc5pAyI13Jotpv7AKJltlw++RwBLEWk0 rFLift5MZbqiIEqY9mtXCwihmQrke9fyvUeDZEbtXsy4wkvjB2ZMztL+2kMjuog/DQmg 9O8apW83CQ6NEShr88+QjdP8m2QW4Lq50B0D2Jmn2yIffTDtLcsJytgT3+iLzxtyUPoC wHWw/KPPNGLgOAZikGHP7vJa7iUGfVGXn/isx7LaNLNfIiZgX0VHPEg5kGCoAsvE1rCk RaPw==
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=MF80bTLCRraqsl9zNqBs+gcuzQ7Ry9QPdYOoCiWvcFc=; b=FTonwP1xlJPcggHWDMXOgEQbkSLLppXucvZNYjX2plvSbeSYywE09ia1pinlQPDyq4 maaC+ve8tK+ZxRf/8vDvlSrCYGyxrxQj/cSGQlo19yltXuUBOrYWKl+adzqg8Fwi3MMu qrEPz8OiyY3KFcS10L86SZCCUMIDLvOgIFOhQ1aAloQSp/kd/GHhbKc6NZ6IQOk1yYCn q+zTRu4FZ2P4ss7sGPAutvBUD0U1bdlVFXZTeMf0Cy4ZNgqMnK9UedWfvgWM0fdYrg6P 8rIY9NVr5+wBU7B7bzs6Qu0+aXHpxxHxmD2D+GCATUlxNt2TneZGCwMKYh3BpEbITZaD 9LYg==
X-Gm-Message-State: AFeK/H1D7MWUqI3mdHFpbR6JXhPKUZQdSMrhHMPqILL8sxvu+eyJZ0YRPYkDk5dPLdxpIT3x1Cp4cLcGk/yH7vSb
X-Received: by 10.31.63.2 with SMTP id m2mr11816153vka.6.1491410115426; Wed, 05 Apr 2017 09:35:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 09:34:54 -0700 (PDT)
In-Reply-To: <20170405.182715.41700611.sthaug@nethelp.no>
References: <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu> <20170405160746.GI25069@Space.Net> <20170405.182715.41700611.sthaug@nethelp.no>
From: Lorenzo Colitti 
Date: Thu, 6 Apr 2017 01:34:54 +0900
Message-ID: 
To: sthaug@nethelp.no
Cc: Gert Doering , "v6ops@ietf.org WG" 
Content-Type: multipart/alternative; boundary=001a114dafea255fb9054c6dfa89
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:35:18 -0000

--001a114dafea255fb9054c6dfa89
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 6, 2017 at 1:27 AM,  wrote:

> "One of our anycast DNS servers has died. While we work to get that
> server up and running again, clients will happily continue using the
> same anycast server address - but may experience slightly increased
> latency."
>

Well, but that's not a useful argument. Just because certain networks don't
take advantage of RDNSS being better doesn't mean it's not better.

--001a114dafea255fb9054c6dfa89
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Apr 6, 2017 at 1:27 AM,  <sthaug@nethelp.no> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">"One of our anycast DNS servers has died=
. While we work to get that

server up and running again, clients will happily continue using the

same anycast server address - but may experience slightly increased

latency."

Well, but that's not=
 a useful argument. Just because certain networks don't take advantage =
of RDNSS being better doesn't mean it's not better.


--001a114dafea255fb9054c6dfa89--


From nobody Wed Apr  5 09:38: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 AC31112894E for ; Wed,  5 Apr 2017 09:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 s5Nki6QOtN8N for ; Wed,  5 Apr 2017 09:38:17 -0700 (PDT)
Received: from mta04.svc.cra.dublin.eircom.net (mta04.svc.cra.dublin.eircom.net [159.134.118.171]) by ietfa.amsl.com (Postfix) with SMTP id 6DFA812948F for ; Wed,  5 Apr 2017 09:38:17 -0700 (PDT)
Received: (qmail 13939 messnum 9504749 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 5 Apr 2017 16:38:15 -0000
Received: from avas03.vendorsvc.cra.dublin.eircom.net (HELO avas03) (213.94.190.15) by mta04.svc.cra.dublin.eircom.net (qp 13939) with SMTP; 5 Apr 2017 16:38:15 -0000
Received: from [192.168.1.1] ([95.45.172.194]) by Cloudmark Gateway with SMTP id vnwlc8mhv5iSXvnwlcJmk5; Wed, 05 Apr 2017 17:38:15 +0100
X-CNFS-Analysis: v=2.2 cv=M/09E24s c=1 sm=1 tr=0 a=cd70hayXDeqSR0gwKT3DeQ==:117 a=cd70hayXDeqSR0gwKT3DeQ==:17 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=21QdtpxUhZGeRNjXSlUA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ross Chandler 
In-Reply-To: <20170405.164601.74682422.sthaug@nethelp.no>
Date: Wed, 5 Apr 2017 17:36:01 +0100
Cc: Tim.Chown@jisc.ac.uk, v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405.164601.74682422.sthaug@nethelp.no>
To: sthaug@nethelp.no
X-Mailer: Apple Mail (2.3273)
X-CMAE-Envelope: MS4wfDpk9MOjOem9LCNhQTRhpSUD1UNx/DA1b9u5tTDYoqC7tw9M8nQI7i/ofCNnhAMlnoZlG06w6t5OfwVRndS+3v2DXG5wEh+ZhsBpD9x77nEgfPZozGZP hQT2Oil6Zmbl5Kb/Bn62wGRh8h+jK80rSLbqLh99a+cRyCZ8nvlzEnNiavOKmx9Dqg9+iq4g2YbJ1ibndJM02oQ1l43nxqJ2Jo2OX1d2zTaDaHr6hSvoMY5e
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:38:21 -0000

> On 5 Apr 2017, at 15:46, sthaug@nethelp.no wrote:
>=20
>> Is a way forward to say
>>=20
>> a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and =
routers; it's not a significant implementation or running cost to any =
device, and an operator may still choose whether to use it or not
>>=20
>> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in =
routers, noting implementation on IoT and constrained devices may not be =
realistic (noting Owen's posted figures), but that managed enterprise =
environments will expect other configuration information beyond RDNSS =
and DNSSL to be available, so that local services can be used (rather =
than, say, Google DNS or time servers).  Again, it=E2=80=99s up to the =
operator to enable it

+1
>=20
> I'd actually like to explore a slightly different scenario for hosts:
> RFC3736 stateless DHCP *and* RFC3633 Prefix Delegation both being MUST
> for hosts (but not RFC3315 IA_NA/IA_TA).

+1
>=20
> I'm suggesting this because my impression is that at least some of the
> resistance against DHCPv6 for hosts is the fact that IA_NA only gives
> you *one* address. Prefix delegation can hand out a /56 or a /48 if
> needed. Yes, prefix delegation is supposed to be for routers - but in
> my book an Android with several other devices tethered behind it is
> definitely a router.

It seems their objections to DHCPv6 IA_NA/IA_TA has broadened since last =
year to include PD.

Does Google ever want Android devices getting more than a /64?

Ross

>=20
> It's of course entirely possible that prefix delegation doesn't make
> DHCPv6 any more interesting for those who are opposed today. Having
> some idea of the status here would be interesting.
>=20
> Steinar Haug, AS2116
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Wed Apr  5 09:44: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 8356B128CFF for ; Wed,  5 Apr 2017 09:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.303
X-Spam-Level: 
X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 lHfRsuKsz60q for ; Wed,  5 Apr 2017 09:44:40 -0700 (PDT)
Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2069B129498 for ; Wed,  5 Apr 2017 09:44:34 -0700 (PDT)
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 v35GiYr7009361 for ; Wed, 5 Apr 2017 12:44:34 -0400
DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v35GiYr7009361
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1491410674; bh=kgW2JAwqccixdohHLUMofSppJKD1WwO5JeKHzd3CADk=; h=Date:From:To:Subject:References:In-Reply-To; b=dXMKAcpP/mTDbkzl1SM+gTCYuJQ8ZXrarnAOCiGbaCtbtcB5KielP301mKoKvAQDZ JsVKbMSB1VNaJMqKn7x69/zlAR2JmXwROQYegTsQ8fbOmKBi9zlu2ksS8QX3ZsELj2 270Z777d/QDsrc0+fcF9uwvMp9JKSy524SEcC6/c=
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 v35GiYV5009358 for ; Wed, 5 Apr 2017 12:44:34 -0400
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 v35GiXAh014041 for ; Wed, 5 Apr 2017 12:44:33 -0400 (envelope-from cra@WPI.EDU)
Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 21053E0FEA; Wed,  5 Apr 2017 12:44:33 -0400 (EDT)
Date: Wed, 5 Apr 2017 12:44:33 -0400
From: Chuck Anderson 
To: v6ops@ietf.org
Message-ID: <20170405164432.GF28135@angus.ind.wpi.edu>
References: <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu> <20170405160746.GI25069@Space.Net> <20170405.182715.41700611.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=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_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_700_799 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 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_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 16:44:42 -0000

On Thu, Apr 06, 2017 at 01:34:54AM +0900, Lorenzo Colitti wrote:
> On Thu, Apr 6, 2017 at 1:27 AM,  wrote:
> 
> > "One of our anycast DNS servers has died. While we work to get that
> > server up and running again, clients will happily continue using the
> > same anycast server address - but may experience slightly increased
> > latency."
> >
> 
> Well, but that's not a useful argument. Just because certain networks don't
> take advantage of RDNSS being better doesn't mean it's not better.

The current operational reality is that irrespective of HOW DNS
configuration is distributed (and how many DNS servers are available),
Anycast DNS is the only way to provide highly-available DNS resolving
service to a diverse set of unmanaged local clients.


From nobody Wed Apr  5 10:02: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 441791287A7 for ; Wed,  5 Apr 2017 10:02:09 -0700 (PDT)
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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 g4UP3a6wFvTO for ; Wed,  5 Apr 2017 10:02:06 -0700 (PDT)
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 B41F11293DB for ; Wed,  5 Apr 2017 10:02:03 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 91CF762AA8 for ; Wed,  5 Apr 2017 19:02:01 +0200 (CEST)
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 4FD9D61399; Wed,  5 Apr 2017 19:02:01 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 425543630; Wed,  5 Apr 2017 19:02:01 +0200 (CEST)
Date: Wed, 5 Apr 2017 19:02:01 +0200
From: Gert Doering 
To: sthaug@nethelp.no
Cc: gert@space.net, cra@WPI.EDU, v6ops@ietf.org
Message-ID: <20170405170201.GJ25069@Space.Net>
References: <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu> <20170405160746.GI25069@Space.Net> <20170405.182715.41700611.sthaug@nethelp.no>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0HX8KfI760FczsQW"
Content-Disposition: inline
In-Reply-To: <20170405.182715.41700611.sthaug@nethelp.no>
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 17:02:09 -0000

--0HX8KfI760FczsQW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Apr 05, 2017 at 06:27:15PM +0200, sthaug@nethelp.no wrote:
> > "Our DNS server has died, let's put that address on the secondary box,=
=20
> > so clients can just happily continue using the address they have learned
> > by whatever means"
>=20
> "One of our anycast DNS servers has died. While we work to get that
> server up and running again, clients will happily continue using the
> same anycast server address - but may experience slightly increased
> latency."

Assuming old-style setups, where "one of our machines has died" actually
needs manual intervention to keep client happiness...

Our DNS recursors run anycast, and have used the very same IPv6 addresses
for 15+ years.  Replacing hardware and upgrading OS a number of times,
and no, we didn't announce new addresses to the clients every time we
broke something - neither RDNSS nor DHCPv6 (nor IPv4 DHCP, for that matter).

Gert Doering
        -- NetMaster
--=20
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

--0HX8KfI760FczsQW
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljlIwYACgkQ31bAZeTO
f8VTjg/8DG0plJSJBO+c9eIoDlBtJGHlvWCcvyBhQbIRjp7M0ktYM54FM7GKmpxm
Bk5yZ+i/4du5Z8HbmyAhyCJtHX3vYgD2bPh4R2AjY0J+yoK+VOEXINrHuo9NJtw2
egbrSCUJIFDELNJKrxv5dP8riyfil5rXKadgQs6ONO9VKtP6pGk6V4CGls99mH2G
AjjJwBKTLWqq+cTO0C7g5XDVgWc0a0CFGVzNYGQ2Z5SC3HkJtF+GWW1gzBAxPFnD
lOxyyMJIlzeUo5q5EcSBSX3p/mjQ5BZfFlN05deahatrTA0HTkwV77adDZsrytcn
SwQXqo5aW8OV3Vgsj6AKDwNuYO8I4Ox6Q07B9PVSlxvDRZRcglIYf3bLcLrZFYm9
8g7+FEb0ojuJ29ppHLXhQqFujJ0HMM9wWuTtIv3hn/sEuCrE9bepiQLjaaEoFH8H
2kE4+tvGImTwMb4Xq5Rr5Balzg35AT8BTWdcD7inMjNABqDUsWuccQcuAsmWTgxR
wlC6sgiE5WDprUVKXLVaIVQ/9ZY8ll7xH882WUCVSg0If2sfgYp+MKSf/hdvHLi3
M3uW5wDsrwqMZILUZypYWbt9QSXlNLDbddGG9WMqkAKqxwgjEND9M2YJkxYCVUYH
/+IxnenlttYDOnlVlgvkJ3P0M2HFE4thkA0HG9zoxLEU7cqUeHg=
=9Zeg
-----END PGP SIGNATURE-----

--0HX8KfI760FczsQW--


From nobody Wed Apr  5 10:03: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 41AD41293DB for ; Wed,  5 Apr 2017 10:03:10 -0700 (PDT)
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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 GExcY8L8Na5k for ; Wed,  5 Apr 2017 10:03:06 -0700 (PDT)
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 DD2061270A0 for ; Wed,  5 Apr 2017 10:03:04 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 76C5362AA8 for ; Wed,  5 Apr 2017 19:03:03 +0200 (CEST)
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 3BAE961399; Wed,  5 Apr 2017 19:03:03 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 38853363F; Wed,  5 Apr 2017 19:03:03 +0200 (CEST)
Date: Wed, 5 Apr 2017 19:03:03 +0200
From: Gert Doering 
To: Lorenzo Colitti 
Cc: sthaug@nethelp.no, Gert Doering , "v6ops@ietf.org WG" 
Message-ID: <20170405170303.GK25069@Space.Net>
References: <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu> <20170405160746.GI25069@Space.Net> <20170405.182715.41700611.sthaug@nethelp.no> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FCaxfLZdDTBfImim"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 17:03:10 -0000

--FCaxfLZdDTBfImim
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Apr 06, 2017 at 01:34:54AM +0900, Lorenzo Colitti wrote:
> On Thu, Apr 6, 2017 at 1:27 AM,  wrote:
>=20
> > "One of our anycast DNS servers has died. While we work to get that
> > server up and running again, clients will happily continue using the
> > same anycast server address - but may experience slightly increased
> > latency."
>=20
> Well, but that's not a useful argument. Just because certain networks don=
't
> take advantage of RDNSS being better doesn't mean it's not better.

Using whatever mechanism to distribute new information instead of just
making sure that the existing information *works* is silliness.

Doesn't matter if it's silliness wrapped in RDNSS, DHCPv6 or puppet.

Gert Doering
        -- NetMaster
--=20
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

--FCaxfLZdDTBfImim
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljlI0YACgkQ31bAZeTO
f8WuDA//WxRrftY9S+icuXI3YJ0briBzLHVRtaHy0Ra8w4D2rXBuBhybUULfjBIH
Q/lYfCECHMjrMRv4YQr6DYungu3vLOIgOKgV4uhlguAzumRI9Pccdi6u6GdFy3TC
7jUHBSuyrjVXP+jdqkonE0ZQ3Ii16W80YIiow9v2sg+eOslieGoHSRN6M4RclMzt
ofANByp2TN12S23UNL7gkXj3kNQ6JYSYKcHE82HSrhtf4OOUX5ab7zwVnMwM9OVy
975dFnKeBw2DXzvfPRAWghJgDss4UAv+ukPhCKp449zJ91l9zPUX+dZuugrr0c0J
nDl2NB7JvSDKNhxv4+3rxVKqqvzHiOmw2NspyEOflx3QggdozFvVx7vuN6oK9gVd
ri3yhKrMTaZF6FLdWb3CvmmQavequMn3sHjTsgODKgy270Dy3qh/DgcGpr/JQYyk
58S29guJ/W/xYqsMV4l0OKa026kNMwuxewIl2LoTQnTJep6VL80hGGRJeOfHmH92
nc6tqzMY6GlAhvk3VW+LS6iGqCY4sJBWEqh4520aM0Als8jua3JhKcwEmbYasPMi
d50pMhrJyOvL8PdtTLRWFGSRWNThTW03brZ+3gn0OjMe9j+aW4iM0J3eTBn2Q7ex
jwsT+66PzsB/Vzgc6gFHONP7UTQTnY5HamY4egFB/4t9J+ZWCvQ=
=eZw5
-----END PGP SIGNATURE-----

--FCaxfLZdDTBfImim--


From nobody Wed Apr  5 13: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 4FF1F127A90 for ; Wed,  5 Apr 2017 13:03:14 -0700 (PDT)
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 NC4c_GBipNiC for ; Wed,  5 Apr 2017 13:03:12 -0700 (PDT)
Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001: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 5657112948A for ; Wed,  5 Apr 2017 13:03:11 -0700 (PDT)
Received: by mail-io0-x243.google.com with SMTP id 68so2392109ioh.3 for ; Wed, 05 Apr 2017 13:03:11 -0700 (PDT)
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=gRRQVd08wLrjwqImfVkUDSZI1FGtoUhX0Xsmfqh+fx8=; b=tv/k01dM3IRGzozNv/gd5GhPZfcBwSJ9umJCy+PyrSWKSrRXSm/INApxcEdPthUygA wIyXbu/xBKzibBXEaq7CbQ/IV7cec3uy72C2N4pyyDdu/18mNNJVGasCfw43O/6W7wEP uTiYlCZFUe7N9fHv/eaOiB1C29zRmoMwEErYUMzpIvY4nrfoxc+tbvhxamSx3oqQIJ/s /wcekr7k7tGm9+k5do062V9kTo8k49Si3mZTaDKSNAsK3Jwg+bDfFbhk4M0HQkUIm772 tckMZcCm5h3gx9CF95M4m4afbDNBCNJ1LuR7BmZv7pfZY4o/7BNGNDbQDdkv+QpR4f9V GTig==
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=gRRQVd08wLrjwqImfVkUDSZI1FGtoUhX0Xsmfqh+fx8=; b=ZTZYYZv+mY8STjQjWZnZaGhRxjhEGwg3TwMVhRGXaOdrKJJ6coFMjzJ/Z1RqqG84Ym MSPLzglqWCIau1qjCAWMDA6eIG5AtKM0IW/0N1uuhg5FJXKkRbl6cO/x2bePcnz6X6MV BlnnofA6M5rlGbNWlSFrLt4tpYHsc+yfHsJvhkweSsXtPQgQeAg4QTcCFNbtj1gZUxqj 8X2Q9/7n7pNl6gdUZkuB1s45cKIdf/t5emKw5KgobvEKEK7CWNs1kH+AywIMEjbj2Y8G aTvdbxu94e3N1ZqoZpWI2kx/8rcxcIqtIbEwK0ikyMl536fLcW0t5rafr44BEgRDhD+j 5rpw==
X-Gm-Message-State: AFeK/H0UVQ9WcQ0Jcn9xvCi0uiMTR6cXUCMaauFxw39/AKDyCWANdN8cBVjxwJ2DI+bOOQ==
X-Received: by 10.107.195.66 with SMTP id t63mr33415404iof.155.1491422590587;  Wed, 05 Apr 2017 13:03:10 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id p70sm9561299itg.0.2017.04.05.13.03.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 13:03:09 -0700 (PDT)
To: Lorenzo Colitti , Tim Chown 
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> 
Cc: "v6ops@ietf.org" 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 6 Apr 2017 08:03:12 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 20:03:14 -0000

On 06/04/2017 03:39, Lorenzo Colitti wrote:
> On Wed, Apr 5, 2017 at 10:13 PM, Tim Chown  wrote:
> 
>> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in
>> routers
> 
> 
> I don't think we should recommend stateless DHCP support in hosts because
> it is technically inferior to RDNSS. (For a list of reasons why, see
> https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html , and
> also see what James just wrote) Taking a host that is capable of doing
> RDNSS and forcing it to also implement a less-capable protocol is a bad
> tradeoff for that host's users.

implement != enable-by-default

Your argument might be valid against enable-by-default but it certainly isn't
valid against (implement & disable-by-default).

In fact one algorithm for travelling hosts might be that when attaching to
a new network, if no RDNSS has been received after N seconds, then try
stateless DHCPv6. That seems like a decent tradeoff for the host's users.

    Brian

> 
> That is why host OS developers are opposed to DHCPv6, and I'm afraid that
> opposition is not going to go away. "My network, my choice" (as Job
> succinctly described a similar position in IEPG), is certainly not
> sufficient justification to change it. "This is what we do in IPv4" is also
> not - mass deployment of IPv4 will eventually go away, but the choices we
> make now are going to shape IPv6 for several decades after that.
> 
> We should all be providing what's best for our users.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Wed Apr  5 13:13: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 6DD061294AB for ; Wed,  5 Apr 2017 13:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.303
X-Spam-Level: 
X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 mM5KxNVm15iQ for ; Wed,  5 Apr 2017 13:13:15 -0700 (PDT)
Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 020341294A5 for ; Wed,  5 Apr 2017 13:13:03 -0700 (PDT)
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 v35KD3Pa014760 for ; Wed, 5 Apr 2017 16:13:03 -0400
DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v35KD3Pa014760
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1491423183; bh=I4dHDVZsNTh2J+o4SM1DX75t8UeFpwnrqyfy6SVIMaU=; h=Date:From:To:Subject:References:In-Reply-To; b=mlALRAtJbhaum4c0QJ0pGx4JmKhdOvGnIizBh2cY8kzU/ML4mUlgTxjwxR4iK/GC6 WBCoOfwNarxmOO9tWECmG3HqDaExOGhDD/nAfHhPW4+Sc4IAloT/V+t/TuizH39rYt VbF0DqfU/wWHPlS85NFSiP7jmh0i6ro4DHY5HuQM=
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 v35KD2Y2014757 for ; Wed, 5 Apr 2017 16:13:02 -0400
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 v35KD16H023090 for ; Wed, 5 Apr 2017 16:13:02 -0400 (envelope-from cra@WPI.EDU)
Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id D80F0E0FEA; Wed,  5 Apr 2017 16:13:01 -0400 (EDT)
Date: Wed, 5 Apr 2017 16:13:01 -0400
From: Chuck Anderson 
To: v6ops@ietf.org
Message-ID: <20170405201301.GP28135@angus.ind.wpi.edu>
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>  
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=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_1100_1199 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, REFERENCES 0, SINGLE_URI_IN_BODY 0, URI_ENDS_IN_HTML 0, URI_WITH_PATH_ONLY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 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, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0'
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 20:13:19 -0000

On Thu, Apr 06, 2017 at 08:03:12AM +1200, Brian E Carpenter wrote:
> On 06/04/2017 03:39, Lorenzo Colitti wrote:
> > On Wed, Apr 5, 2017 at 10:13 PM, Tim Chown  wrote:
> > 
> >> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in
> >> routers
> > 
> > 
> > I don't think we should recommend stateless DHCP support in hosts because
> > it is technically inferior to RDNSS. (For a list of reasons why, see
> > https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html , and
> > also see what James just wrote) Taking a host that is capable of doing
> > RDNSS and forcing it to also implement a less-capable protocol is a bad
> > tradeoff for that host's users.
> 
> implement != enable-by-default
> 
> Your argument might be valid against enable-by-default but it certainly isn't
> valid against (implement & disable-by-default).
> 
> In fact one algorithm for travelling hosts might be that when attaching to
> a new network, if no RDNSS has been received after N seconds, then try
> stateless DHCPv6. That seems like a decent tradeoff for the host's users.

Even better than that is just use the M & O bits to signal DHCPv6.


From nobody Wed Apr  5 13:31: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 4206412948A for ; Wed,  5 Apr 2017 13:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 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=-0.001, 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 mJLnCD5k2GCo for ; Wed,  5 Apr 2017 13:31:29 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C421293F2 for ; Wed,  5 Apr 2017 13:31:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1647; q=dns/txt; s=iport; t=1491424288; x=1492633888; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PRasMaHrTeSt5lqMUsAKlC5KEfp273LDs/UuILdNSlQ=; b=FvPTWjqtfpeaWeMEwlbJv/GzK/1kQvxIsw/JghVUJJArlHezXsOXir9r PkSjD27/vC5oCZ0rklAKwX/18ze/oOB44lPUYmErxEq805hUVtC6LiVmY Ah53omlhj8qqp2+f6new0j7tM6Yny3zEaLj5eorBEAt6lfHpDYddXYJR2 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDVU+VY/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjW6RPJVVgg4fC4V4AoNSPxgBAgEBAQEBAQFrHQuFFQE?= =?us-ascii?q?BAQEDAQE4NBcEAgEIEQQBAQEeCQcnCxQJCAIEEwiKBg6tN4prAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWLPoQ5AQEiK4UzBZxwAZJIkUWTdQEfOIEFWxVBhll1AYZ?= =?us-ascii?q?igSGBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.37,280,1488844800"; d="scan'208";a="232929053"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2017 20:31:27 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v35KVRum025222 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Apr 2017 20:31:27 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Apr 2017 15:31:27 -0500
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; Wed, 5 Apr 2017 15:31:27 -0500
From: "Bernie Volz (volz)" 
To: "v6ops@ietf.org" 
Thread-Topic: [v6ops] Making RDNSS a MUST?
Thread-Index: AQHSqOFtcCIh4JqwF0K0H7rCJjQ0haGunLAAgABDSACAA/sWgIAAKaaAgAANfQCAAAjfgIAABE8AgAA2LICAAHAg2YAADplOgABgLwCAAAlBgIACS1yrgAA4z+WAAFVpgIAAA6mAgAAD5ICAACjRAIAASbcAgAACvoD//7DqEA==
Date: Wed, 5 Apr 2017 20:31:27 +0000
Message-ID: 
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>   <20170405201301.GP28135@angus.ind.wpi.edu>
In-Reply-To: <20170405201301.GP28135@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.131.32.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 20:31:31 -0000

+1 (for both Brian's comment and use of M&O).

- Bernie

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Chuck Anderson
Sent: Wednesday, April 05, 2017 4:13 PM
To: v6ops@ietf.org
Subject: Re: [v6ops] Making RDNSS a MUST?

On Thu, Apr 06, 2017 at 08:03:12AM +1200, Brian E Carpenter wrote:
> On 06/04/2017 03:39, Lorenzo Colitti wrote:
> > On Wed, Apr 5, 2017 at 10:13 PM, Tim Chown  wrote=
:
> >=20
> >> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST=20
> >> in routers
> >=20
> >=20
> > I don't think we should recommend stateless DHCP support in hosts=20
> > because it is technically inferior to RDNSS. (For a list of reasons=20
> > why, see=20
> > https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html ,=20
> > and also see what James just wrote) Taking a host that is capable of=20
> > doing RDNSS and forcing it to also implement a less-capable protocol is=
 a bad tradeoff for that host's users.
>=20
> implement !=3D enable-by-default
>=20
> Your argument might be valid against enable-by-default but it=20
> certainly isn't valid against (implement & disable-by-default).
>=20
> In fact one algorithm for travelling hosts might be that when=20
> attaching to a new network, if no RDNSS has been received after N=20
> seconds, then try stateless DHCPv6. That seems like a decent tradeoff for=
 the host's users.

Even better than that is just use the M & O bits to signal DHCPv6.

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


From nobody Wed Apr  5 14:08: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 70DEE129490 for ; Wed,  5 Apr 2017 14:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 pfT2z9IJkeHR for ; Wed,  5 Apr 2017 14:08:35 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 830D2128B88 for ; Wed,  5 Apr 2017 14:08:35 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id d191so12019154ywe.2 for ; Wed, 05 Apr 2017 14:08:35 -0700 (PDT)
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=yMteouERV/HY7DtD1rm7kNJD7X+sUMYrj/MrZ1Wy/kI=; b=Aim7mVhcsPPktcpB+F8hAAgXRrUMTmlzQRDlI+kTz/wfKvpbNLwO6BhZCF8P73UwtG REjxKVG5Xs6Y+WN6HqLzwUx3xhXePLvAzj1dbEwPHKd7KVpPiM1mP5pYuIV0P7tLl3r9 E9w/B68lgzc2UZ3UV1CpnNWMNb29J20sc+rpn2bvyu7SeYdMfTQ8ctARnVeFjsT94d9L +6ijPXIUVJ74AOUm9w30R7ANJnHRYUepg6Canwg2heemX6GWnNpHt2e556hrlyAthFvh zqDLzAf5vY7jT/1pylYP6ctexxEyB+aK9UHMG8CFMRyqAj9hSXdDucc5X0lfr3SfW6JZ JO3g==
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=yMteouERV/HY7DtD1rm7kNJD7X+sUMYrj/MrZ1Wy/kI=; b=naW3HagURH3BxZ+PdSdGycV8j6YbWRWpLn6Ny01Bm9XN6PhaqVi9p4TZVWrq+BpaFq FT6yyZx7pJXbABCMu8TfsCxqNTBRhteFn7R2GX46NMypvO84XNBNzGhEyQ7QlVmNPGVX rBtK0vWV8z5EXcsQ2jQ676iLErNDuYcnj+HaCtlWzOj3Q9COg5OJmpq7W6w2dDJpoBEG z7kwE8XLkrsU9ktocyo131ATTCTbDLXb6cOHcEy7bQWHKqwDzf9cNP6FJmt66Zw8ZGFS /+LYwHHhMBdZ8kuMBBnOnSprWd/4nElNpLBugJ22D7fbOosVFutpSRAiyZGS/o8HZetq s2KQ==
X-Gm-Message-State: AFeK/H1cjHHyAGNntvjWf5i7KuSJkC+fidTG3BJo+NQ+tXzh+r8jvj3p5SHRIjbQTuKyeGxs3RiwE3dh8cLcuzCr
X-Received: by 10.13.242.198 with SMTP id b189mr19694288ywf.243.1491426514424;  Wed, 05 Apr 2017 14:08:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.220.12 with HTTP; Wed, 5 Apr 2017 14:08:13 -0700 (PDT)
In-Reply-To: <58DD21A0.2060604@foobar.org>
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org>
From: Erik Kline 
Date: Thu, 6 Apr 2017 06:08:13 +0900
Message-ID: 
To: Nick Hilliard 
Cc: Ted Lemon , "v6ops@ietf.org" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0356eca25ae5054c71cb42"
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 21:08:39 -0000

--94eb2c0356eca25ae5054c71cb42
Content-Type: multipart/alternative; boundary=94eb2c0356ec9a4903054c71cb35

--94eb2c0356ec9a4903054c71cb35
Content-Type: text/plain; charset=UTF-8

On 31 March 2017 at 00:17, Nick Hilliard  wrote:

> Ted Lemon wrote:
> > I would prefer that the default ietf ssid were IPv6-only with NAT64 for
> > legacy service.   If people want IPv4, they should switch to
> > ietf-legacy.   And if we really want this data to be meaningful, we
> > should change the name of ietf-legacy every IETF so that people have to
> > choose it to get it.
>
> I'd be pleased if this were done at meetings that I regularly attend.


Likewise.

FWIW, I believe that switching the default was proposed at a plenary in the
no too distant past.  The suggestion was for "ietf" to be operated as
"ietf-nat64" and replace "ietf-nat64" with "ietf-dualstack" or
"ietf-legacy".

--94eb2c0356ec9a4903054c71cb35
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 3=
1 March 2017 at 00:17, Nick Hilliard <nick@foobar.org> wrote:<=
br>
Ted Lemon wrote:

> I would prefer that the default ietf ssid were IPv6-only with NAT64 fo=
r

> legacy service.=C2=A0 =C2=A0If people want IPv4, they should switch to=


> ietf-legacy.=C2=A0 =C2=A0And if we really want this data to be meaning=
ful, we

> should change the name of ietf-legacy every IETF so that people have t=
o

> choose it to get it.



I'd be pleased if this were done at meetings that I regularly at=
tend.

Likewise.

FW=
IW, I believe that switching the default was proposed at a plenary in the n=
o too distant past.=C2=A0 The suggestion was for "ietf" to be ope=
rated as "ietf-nat64" and replace "ietf-nat64" with &qu=
ot;ietf-dualstack" or "ietf-legacy".


--94eb2c0356ec9a4903054c71cb35--

--94eb2c0356eca25ae5054c71cb42
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgmeMHfBGKZq3APRnet0GXQOSJc2kB+KKq
fBygVGwXVkIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA1
MjEwODM0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBADUgUTSIBOOOiNsMhl4EtGWDcI8+mRRGsAvkPvnBsBvCc+sErN0J
uC50KxED/sDsjdTcGo+rlazI0xl3LvhijcIeZi0T26SkIOc872E8ZeXcTjIRWhJJCTId5Y4RjQ2g
kdd8eujKSKDozTHVZpW5Lx9R+prFrCUIAIoIEveuVk7XNBlF+44Qngajw8/KOEdEJh8fatFEQIGI
jCwS6aKJwaZK2OAzBjZ+8EQuuQeDp0/X8/rls9IRtIc75o/EMr1GexbiSYlq8gkIDw9RpnrX+ToR
jp1Maikl1z198wbYhiylFw2auDmU25/gdpRaoBGn8I7LCjIRhH0/YhdqH03jOf8=
--94eb2c0356eca25ae5054c71cb42--


From nobody Wed Apr  5 14:24: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 09537129490 for ; Wed,  5 Apr 2017 14:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 3Lgd2r6kPpCn for ; Wed,  5 Apr 2017 14:24:53 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7B0126BF6 for ; Wed,  5 Apr 2017 14:24:51 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: ; Wed,  5 Apr 2017 21:25:08 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Simon Hobson 
In-Reply-To: 
Date: Wed, 5 Apr 2017 22:24:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us>    <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>        <914B3454-58A 4-4130-8B90-6371100D619D@fugue.com>  
To: v6ops@ietf.org
X-Mailer: Apple Mail (2.1510)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 21:24:56 -0000

Ted Lemon  wrote:

> ... and, by the way, you are _insane_ if you trust the DHCP server to =
tell you what NTP server to talk to, but that's a side issue

Vs trusting some random device broadcasting a claim that it's a =
legitimate router on the network ?



Erik Kline  wrote:

> Specifically, consider the case where 2 RAs are sent on the network =
each with different PIOs, RIOs, and RDNSS sets.  End nodes can associate =
all this information with each next hop, and make better, logically =
consistent use of essentially two different networks a la RFCs 7556 and =
8028.

One thing that slightly concerns me is all this determination to put =
decisions into the device, rather than the network. In effect, =
fundamental decisions are made by  which may well be a =
device which the network admin has zero control over.



Chuck Anderson  wrote:

> Why are DNS resolvers a link-specific parameter that needs to be
> distributed to clients at all?  Can't they just use some other
> discovery mechanism to find a resolver or do full-recursion w/DNSSEC
> validation?

That's a good question. Not even private DNS zones answers that one - a =
host wouldn't know which interface it needed to use until it knows the =
IP address of the destination and look it up in the routing table. And =
it won't know the IP address until it's done the DNS query.


From nobody Wed Apr  5 14:34: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 15A5B1294B1 for ; Wed,  5 Apr 2017 14:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D3cLwWMnGwJa for ; Wed,  5 Apr 2017 14:34:31 -0700 (PDT)
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 E19FF12948C for ; Wed,  5 Apr 2017 14:34:30 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id 21so16197979pgg.1 for ; Wed, 05 Apr 2017 14:34:30 -0700 (PDT)
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=iG4EOTmOzMA6RFkESAqr/T0JANfQMGlhTSWwoxx1WJE=; b=BzuSmllg1UpdWdQnWSffXcrg3ypLID6FHi70Fm+Qqe6aGv9kDw8trl3h4G7QZOjH57 K+CxYZHqAwq87Jn2hiAJ/1mUDU+pGL3eLdfzPUHKtjm6xLHbBPNedEBX4aPjBLs17O1+ zrvrG4KW3+Q4W+uVUZ9rGBN3jfhcLuiTdmhR6k1dPUT/S74B5MzLEo3NrKcz13TIS7vX CodhnmYdNpco4WzZs1LpWMMw97K1d2bwndwykBvvaq20NNVdkhfbWjsfVSMG0EHXC4yQ 901KB7ylVQuQ14wiobBja6/0PxdxSDl44j41e7RYZPGnK1COdFEZr/Eb4x6BxBfVJ2M0 HWrA==
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=iG4EOTmOzMA6RFkESAqr/T0JANfQMGlhTSWwoxx1WJE=; b=C9OOhFWVgCiWXDv2A9iPkL2Cv6BE0SgtEIyQ+ISXIcWw+rIC0SygQkYD03jCIKfU2g CtdEsu6NoER4AWv3qK1RTA828SiPs7fzvOmqK1HEvLk8heN8lNagzhAgNSCF1Vf2mVi3 NIO159WS7saGjwIFgOtwT1UWVMoOMT/w3zpH5PVJ0S8p4HRVAzxoIn0mzKJcDgsA+DCk dVSS9oU+1Zf36Z1o7Ibd/DvSx4EuuQJ2VN2OkC75wtu1+xG/yjLxVMp1vUMZiS1COvbf Pyw7LSZY2Xw3nlMRDfE+VJRt3r2nOglmGFnKyimWClkLrlq4Wqfek9cEOVn3Y6Ns4hqi bo+w==
X-Gm-Message-State: AFeK/H0JTcfXNSo9M6IvBK5offNnPMSRGaG6kESpHMDl+XMWvnIUZgFUzdLsZQSrlja56w==
X-Received: by 10.99.98.135 with SMTP id w129mr32789300pgb.134.1491428070543;  Wed, 05 Apr 2017 14:34:30 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:4822:af74:a02a:54d? ([2620:0:b60:17:4822:af74:a02a:54d]) by smtp.gmail.com with ESMTPSA id t66sm39222504pfk.53.2017.04.05.14.34.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 14:34:29 -0700 (PDT)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_ACFF30CD-6E5F-4DFA-ACFB-265EAC3B94F1"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 14:34:24 -0700
In-Reply-To: 
Cc: v6ops@ietf.org
To: Simon Hobson 
References:  <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us>    <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>        <914B3454-58A 4-4130-8B90-6371100D619D@fugue.com>   
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 21:34:33 -0000

--Apple-Mail=_ACFF30CD-6E5F-4DFA-ACFB-265EAC3B94F1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 2:24 PM, Simon Hobson  wrote:
> Vs trusting some random device broadcasting a claim that it's a =
legitimate router on the network ?

The difference is that an evil NTP server can expose you to attack.   A =
random device broadcasting on the network exposes you to denial of =
service or snooping/in-path attacks which, one hopes, your device is =
hardened against.   If it's not, working on that should be your =
priority.

> One thing that slightly concerns me is all this determination to put =
decisions into the device, rather than the network. In effect, =
fundamental decisions are made by  which may well be a =
device which the network admin has zero control over.

The service on a particular link does not know the set of all links to =
which a device may be connected, and has no basis for telling that =
device how to behave.   While decisions made by  may not =
be ideal, they are much more likely to be correct than decisions made by =
the network, which is often attacking  in some way =
(e.g., captive portals).


--Apple-Mail=_ACFF30CD-6E5F-4DFA-ACFB-265EAC3B94F1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 2:24 PM, Simon Hobson <linux@thehobsons.co.uk> wrote:
Vs trusting some random device =
broadcasting a claim that it's a legitimate router on the network =
?

The difference is that an evil NTP server can expose =
you to attack.   A random device broadcasting on the network =
exposes you to denial of service or snooping/in-path attacks which, one =
hopes, your device is hardened against.   If it's not, working on =
that should be your priority.

One thing that slightly concerns me is =
all this determination to put decisions into the device, rather than the =
network. In effect, fundamental decisions are made by <any old =
device> which may well be a device which the network admin has zero =
control over.

The service on a particular link does not know the set of all =
links to which a device may be connected, and has no basis for telling =
that device how to behave.   While decisions made by <any old =
device> may not be ideal, they are much more likely to be correct =
than decisions made by the network, which is often attacking <any old =
device> in some way (e.g., captive portals).

=

--Apple-Mail=_ACFF30CD-6E5F-4DFA-ACFB-265EAC3B94F1--


From nobody Wed Apr  5 14:50: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 EEBE21294CD for ; Wed,  5 Apr 2017 14:50:33 -0700 (PDT)
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, HK_RANDOM_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 1DNVJxmeSEVF for ; Wed,  5 Apr 2017 14:50:32 -0700 (PDT)
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 874D41294B9 for ; Wed,  5 Apr 2017 14:50:23 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id z204so21330087vkd.1 for ; Wed, 05 Apr 2017 14:50:23 -0700 (PDT)
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=aAvsegPiczwf/h64ZHKR95OVhbZlIhgYs9/STUG4gDU=; b=lV1H4WH2kbZjETWUlWZNpcEs6l1oqN0/GXU21lppFcm7FxvKKPoukepdunKHlTxSBj uwm7L1HrCrTcQvRa7Zv4aeV1vFeDlrscNY/BjX7f5lGX/yaKowiulCzX82v0hKMXCfc/ 42IFztHU9c3bsKTj3CxUQ1I4/CJhE2uUTYFnIGuj9o0DjeBA/vS3DhVz3ZSUORUsbRtP kBZqRhRh4/Abvj6JEYkV1kukxSBiFsJN2T6G3JAU3cMfmFKOFiz5RCnaA7NSAqmSBx4t T87c7VFIvKDEsuGCtty1R056284NGXxqquAKdsJDEb1iJh5asvjsrWvjwkyP6Je8SjdE pmbw==
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=aAvsegPiczwf/h64ZHKR95OVhbZlIhgYs9/STUG4gDU=; b=qojiLJuyknaJcfxXrX/550TpRCUMP9qC9Z62SyFiqNEFLtV2XIIWdFXhKfevVyk+Zu mJF5T3a3FR44O4/+Aj7xGZYKuCOlzoPYgQa5QzNW4fiamDytHTANQRR5gpsxAq1cOp6b dkZpaTd3eG8IHapPTfFGwbehSw4EwSq1+5dObKy8fb6jDyCB8B+iot9Ju/sWj/GMmmd8 jdALS1X07EwX1423kZzjp8Cx+8mXWiAuy9VwHAtjSzzDo9MHc7dAlFvVRHXmRtpL/JoJ 3nCO3/O46T4CY65aM0QxXxkMsxQdScUsaH0eigLZX2u8BG1AZpVVAt78NHgZoD3GWJsW 1Rzg==
X-Gm-Message-State: AN3rC/6fCCKXVxn+Jf/WFN0HzzTJnl9e4mCqLYdbVTN7awgqUCo+eDx7M2Xu7h85Uw00j8QLTX+LOncOrd7OlQ==
X-Received: by 10.159.40.33 with SMTP id c30mr1626797uac.98.1491429022597; Wed, 05 Apr 2017 14:50:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.55.177 with HTTP; Wed, 5 Apr 2017 14:49:52 -0700 (PDT)
In-Reply-To: 
References:  <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us>    <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>        
From: Mark Smith 
Date: Thu, 6 Apr 2017 07:49:52 +1000
Message-ID: 
To: Brian E Carpenter 
Cc: Owen DeLong , IPv6 Ops WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 21:50:34 -0000

On 5 April 2017 at 23:35, Brian E Carpenter  wrote:
> On 05/04/2017 12:44, Mark Smith wrote:
> ...
>> I don't understand this view that DNS information is the only
>> additional information a host needs over its addresses and default
>> gateways.
>
> That isn't the assertion. It's that DNS information is the only
> additional information a host needs *in order to get basic
> connectivity to the Internet*.
>

So then I'd say I don't understand how a host with basic connectivity
to the Internet with an unset real time clock is that all that useful.

Devices like this Chromebook are getting their time by having
hardcoded, Internet located NTP server addresses in their firmware.
There are potential trust, privacy and reliability issues with that
sort of model.

I think this would be a model that is encouraged by only requiring
RDNSS support.


Regards,
Mark.


From nobody Wed Apr  5 14:52: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 F0351129463 for ; Wed,  5 Apr 2017 14:52:29 -0700 (PDT)
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 1byG4D4C3ZxP for ; Wed,  5 Apr 2017 14:52:28 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 1181012949D for ; Wed,  5 Apr 2017 14:52:28 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id b140so18851951iof.1 for ; Wed, 05 Apr 2017 14:52:28 -0700 (PDT)
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=MDx/fxbl2znW7++fhahA2Pn7nfgGLCiZmPFQMxzK99o=; b=fOcYoNxOR3Go50mtOoBTrqas39V1K1/C9aq4FueFtehICS3Ho0YGt/tlFx8h9uTrB+ F5WUUjVYAqPuZfo8N/S2glnV2B74uck5r+lXSAyh6vjNDevj15Wi2Fx/uXW/7KjRsabN 2mnom3AXAPEXJta8bXwE4+l1PtV41U8wYdQ0fFKpp9TSs0P9qQYRCZni73J6NVRp6S1M q5uFz1ovponrvVX9XF7x3W8vO0KoY/cvIOOzCweaBcJptRol9iJo7fGxrCyWJN4YM/eN Rmq8nyCsoUNUuGSB+/ApswjUKO037fYLeTbTdAWxjIyn3mE2mMG705D0ihxqyIqnxHii qIDA==
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=MDx/fxbl2znW7++fhahA2Pn7nfgGLCiZmPFQMxzK99o=; b=DYo12dT1mhNy8vLgJu5fzTKsLVE78yjjJImACQIsDTcku2ravM+Is0P1H1peLzVrQQ 5+Bali4532BDlrqMm/a3/iXg/2Fh4xogU55IS1dfnSfcj3YwyDMjshowHkkHVCP/HxCY JAf9Dh2SOPYkZzQ+CtzDuUx7ncNrPTvXPQT/z4pRC4OPmvdxbMEM0oEKiYVbXHKQSeaW uaaG/oVWXlcd/bnqRp+fVOJs056iTfkJU58thp2uClxRw4nZECzH9/JVlgXlKN5dURfo Lgn+/5SN6rhEguCbbIrnk7EQee7z3wEDQmerCYdYg0SNNMBm+BepD6O5V2nB+ZTxALBJ 6U1w==
X-Gm-Message-State: AFeK/H3J2vCHBN7TCI1BkzIywdnT5bnaf4H2kswDLq3AM6hJobPRkq9FbC996HAlu0++lQ==
X-Received: by 10.107.154.202 with SMTP id c193mr28985179ioe.109.1491429147430;  Wed, 05 Apr 2017 14:52:27 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id h71sm11167145ioe.9.2017.04.05.14.52.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 14:52:27 -0700 (PDT)
To: Erik Kline , Nick Hilliard 
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org> 
Cc: "v6ops@ietf.org" 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>
Date: Thu, 6 Apr 2017 09:52:30 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 21:52:30 -0000

On 06/04/2017 09:08, Erik Kline wrote:
> On 31 March 2017 at 00:17, Nick Hilliard  wrote:
> 
>> Ted Lemon wrote:
>>> I would prefer that the default ietf ssid were IPv6-only with NAT64 for
>>> legacy service.   If people want IPv4, they should switch to
>>> ietf-legacy.   And if we really want this data to be meaningful, we
>>> should change the name of ietf-legacy every IETF so that people have to
>>> choose it to get it.
>>
>> I'd be pleased if this were done at meetings that I regularly attend.
> 
> 
> Likewise.
> 
> FWIW, I believe that switching the default was proposed at a plenary in the
> no too distant past.  The suggestion was for "ietf" to be operated as
> "ietf-nat64" and replace "ietf-nat64" with "ietf-dualstack" or
> "ietf-legacy".

Isn't the -legacy SSID the one with no authentication?

That said, no, I don't agree. The default should be (a) authenticated
and (b) dual stack. I don't buy (and never have, and never will) that
presenting NAT64 as preferable to genuine IPv4 is in the interests of
users. It's second-class dog food. Iff the IETF IPv4 service was
actually CGN it would be a different story; a bakeoff between NAT64
and CGN would be instructive.

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


From nobody Wed Apr  5 14:58: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 D10A0129463 for ; Wed,  5 Apr 2017 14:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 eYcBF85TOGFN for ; Wed,  5 Apr 2017 14:58:53 -0700 (PDT)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 65D1C126E3A for ; Wed,  5 Apr 2017 14:58:53 -0700 (PDT)
Received: by mail-pg0-x230.google.com with SMTP id x125so16636312pgb.0 for ; Wed, 05 Apr 2017 14:58:53 -0700 (PDT)
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=fgqiPFnrRTFODetbDccdIzWhX4wGLfCXwZT7Zbb//uc=; b=Zt34KS+TkPplrqanZfveqOegLp+sWTIxytNiEn51JdFinhe3dL3zb4zsL+05geLQO3 wcepMCfXnX5iogopg3B6a/KwaZk38efJKNs2mDfG1+HQl86sUz7TW/Nrkr39BlTAsgIe sNGu5drSdDN5Jz+q9G08zg2/zBNHwuDEAyOs+yu1x/jP01MW6fj4QUm9Z93+iT9MSmRq JC5x8/KVOdYsA65uFNRtBF13uoinP8SMxt/d/ViQd2Q3kY5QMhFg/91czyvFkm7Gjnw/ rq0K1zAZ+7tchR2hNFRZJx0dw/kJ94x0mEFmAmqKz5VwyC2E3fbWRk3SjAWCRheMfmIG Yh9A==
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=fgqiPFnrRTFODetbDccdIzWhX4wGLfCXwZT7Zbb//uc=; b=qvlEbnUPC86VVF5zAbbvgv7kTr2rue5pznmo3cs2BdzizYm0UibU1Y/PnM35MyoWH6 hOnfScuxtHGvKeWfmcQR+oFhuaMj6L64Ok+NWBP0trCBUpsX07+0qwWS1dQOPR97UkLQ lls0eJ8vpiYCJPAjXNOFDvkIsuYT7qWw8cdnyhFQTeg1HdT4EjynUU9jXdExADQtYkHo SDMGhkgzrOjJSC7W16/5NIKJC70wu50E8K8pT3ByRO6cFxpemEvTlMVPsWiSNZsJJQHk H7aQZdR7N8GcnGlma1YA7hKONDUuTE7F5oxR1vYae5+0qcVQMDkaWMD9A1oH1qB7mFVa VTUw==
X-Gm-Message-State: AFeK/H00BUa2gY1N2echJht+Rmra5qhhi0eT2RGpI81H2ut6Iey88wIsWGorP25Ct3vRDw==
X-Received: by 10.98.10.23 with SMTP id s23mr31160631pfi.78.1491429533040; Wed, 05 Apr 2017 14:58:53 -0700 (PDT)
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 c75sm39422332pga.22.2017.04.05.14.58.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 14:58:52 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Fred Baker 
In-Reply-To: <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>
Date: Wed, 5 Apr 2017 14:58:50 -0700
Cc: Erik Kline , Nick Hilliard , "v6ops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <20FF8CCB-973E-49D8-8BDD-2F9E7DE54EF0@gmail.com>
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org>  <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 21:58:55 -0000

> On Apr 5, 2017, at 2:52 PM, Brian E Carpenter =
 wrote:
>=20
> NAT64 and CGN would be instructive.

NAT64 *is* CGN (or at least NAT); it just happens to be between IPv4 and =
IPv6.=


From nobody Wed Apr  5 15:02: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 ED2101294B8 for ; Wed,  5 Apr 2017 15:02:43 -0700 (PDT)
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 xq15ZA9q0wyC for ; Wed,  5 Apr 2017 15:02:42 -0700 (PDT)
Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 F1F98128990 for ; Wed,  5 Apr 2017 15:02:41 -0700 (PDT)
Received: by mail-it0-x244.google.com with SMTP id w11so2697191itb.0 for ; Wed, 05 Apr 2017 15:02:41 -0700 (PDT)
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=+sqw67pVtZdM1Uu0Gew8de2ySs+7xua3r7nBbzOBiWI=; b=nDUoaesAQp8Iltke1fwUlGn2ygAH0H9GnBiig5Msdu+c1JJO03ShYR8XGYDGWkMc5h dUSmrT9xgA/vJN0HmW49xclx8eBfZsmIaNcsqC+pcFMau7M81EOnJih0BI2n/xyMqRLr p/DVmozW9r/K92dj0iRmo2GT048hNmROykeh/rnkyPIZA73leWi48lRJj6DfmS45aJqb hcsyirvMIMDS1LDECwvO/0oC+Jsy51mlseSa0BA+X1Sbah3JUGQDc3RkVvgpr0ZECIEb a1TmUbp3vSxBYP8e/hOA+e9WhPJjxkXico288zmtjCH6BJb0DJefpmybKbPG17JDy7HI ryqg==
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=+sqw67pVtZdM1Uu0Gew8de2ySs+7xua3r7nBbzOBiWI=; b=U0aaaw2uig2p1yD1RES7Vbzsqg3Fttp7XRqa/ukqoFUDRX80nagifoE+CRjDyDCnQW Lg68RiZXtLG7qyL9L0976Xk62HWVZjbNnT/Z3UlZq+1te/DoLMwHmK1+HXgUH2xExKmU A48rYyJ1VuV6BAU1gTVcJmNh3Lb/iFX0RjjHPaAUHobjLt6KSmo1xCN27U2FK8Y24D32 wFjhI5LTdi3OFblRr7i1SlBDTkrcdRrdoi/uoDaMjh642fbKv/zURdVIP8WYYL+//Uwy 8adtNYw3kCW1l0LL8PWwOuBcQBepJ8+ejVb8d7/0hA0xMVPUm3cZfN+fUp1TLoGICJ6T ujrg==
X-Gm-Message-State: AFeK/H1BHeEfyUhN+76ZI7RPpuuwsfYDCh5TixTX952DjAfcXp3ijMb9+zQf8l2c4UCnxQ==
X-Received: by 10.36.122.212 with SMTP id a203mr16377053itc.113.1491429761128;  Wed, 05 Apr 2017 15:02:41 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id m38sm11158584ioi.60.2017.04.05.15.02.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 15:02:40 -0700 (PDT)
To: Chuck Anderson , v6ops@ietf.org
References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk>   <20170405201301.GP28135@angus.ind.wpi.edu>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <6ca41854-74e4-4eda-92eb-dc4346f1d9c6@gmail.com>
Date: Thu, 6 Apr 2017 10:02:43 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170405201301.GP28135@angus.ind.wpi.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:02:44 -0000

On 06/04/2017 08:13, Chuck Anderson wrote:
> On Thu, Apr 06, 2017 at 08:03:12AM +1200, Brian E Carpenter wrote:
>> On 06/04/2017 03:39, Lorenzo Colitti wrote:
>>> On Wed, Apr 5, 2017 at 10:13 PM, Tim Chown  wrote:
>>>
>>>> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in
>>>> routers
>>>
>>>
>>> I don't think we should recommend stateless DHCP support in hosts because
>>> it is technically inferior to RDNSS. (For a list of reasons why, see
>>> https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html , and
>>> also see what James just wrote) Taking a host that is capable of doing
>>> RDNSS and forcing it to also implement a less-capable protocol is a bad
>>> tradeoff for that host's users.
>>
>> implement != enable-by-default
>>
>> Your argument might be valid against enable-by-default but it certainly isn't
>> valid against (implement & disable-by-default).
>>
>> In fact one algorithm for travelling hosts might be that when attaching to
>> a new network, if no RDNSS has been received after N seconds, then try
>> stateless DHCPv6. That seems like a decent tradeoff for the host's users.
> 
> Even better than that is just use the M & O bits to signal DHCPv6.

To make that watertight, the formal meaning of O would need to change:

OLD:
      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

NEW:
      O              1-bit "Other configuration" flag.  When set, it
                     indicates that DNS server information is available
                     via DHCPv6. Configuration information on other
                     servers within the network MAY be included. 

   Brian



From nobody Wed Apr  5 15:04: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 5CD0E126DFB for ; Wed,  5 Apr 2017 15:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v2ROYjwVN1bH for ; Wed,  5 Apr 2017 15:04:50 -0700 (PDT)
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 9B0451294B7 for ; Wed,  5 Apr 2017 15:04:44 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id 21so16791743pgg.1 for ; Wed, 05 Apr 2017 15:04:44 -0700 (PDT)
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=NtXF+WCYgZZTBWnyflpqAVWpT477z4/2WDtXeHjAdgY=; b=rSSBmAUHixIAh/SydOfurBBdjE/yt+TqB/gahHR2LxDJXg2AIUew86CKitQjkwlHnf C9MMMQvTMlVqSHFqXmH7IEKVMhnCmQVmqQ7+6eb7LvnBUL4NFkRw3ZBD0zCxvoNtb3Wb XPbew3GF82egjD+oDtPYxnGNOnZ/+7N/gLmh9T9nXBL50WnmJZryXA2zsRkHgrQ3PEYB PtEzndf5rSEMzRGae8WoiudcXKnuEMFUs24AL+nPGv3p5clA7kbIUuM1Pidn8VDpKw9J hkLa6EPv5hM6HgcELnypdAP+yAYj6ATI2Asw2nAHyvHBK+CDUQtL1kiBnWLdg+W9b8xT eccg==
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=NtXF+WCYgZZTBWnyflpqAVWpT477z4/2WDtXeHjAdgY=; b=AOgaL+9vfVjtTOmkQ2PVOIEvYRxTJBw39VxDE4S4a6bGJjDvMXEeqOZnV4E0+6aD3m fZ7T49vssCUsyWItozhSluzQGstYY530b0mbgNU4QeJPqU/nOSvFyhVApfih1z/X1tu0 wBl4fFe22Yofl44wBT2GoJE5UE5W0h3I/sS5+OWz1NqgLYijhi/Q4v9WSCi4ZBDgulZf lATZC1BDL6KjLIxqJWMmv3CSv5W1CWrYCIBtfMFWti6Vtp7VRfXkyNRXmjAURBhHGOat +aHiLwu6vO4z7dOVYkZaBQJiZk+GKW0VCfdKO2H3m7Kf+hgUv/CSvC8NLsr7mMWVrsJ8 76PA==
X-Gm-Message-State: AFeK/H2N4xx4Rj8nwcaXf8u75seOijNGlWrcccnSZcwgYQjJdrfm4hvkF2fAnTQ6NwSjlQ==
X-Received: by 10.84.171.195 with SMTP id l61mr21994299plb.75.1491429884217; Wed, 05 Apr 2017 15:04:44 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:4822:af74:a02a:54d? ([2620:0:b60:17:4822:af74:a02a:54d]) by smtp.gmail.com with ESMTPSA id i15sm39246730pfj.51.2017.04.05.15.04.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 15:04:43 -0700 (PDT)
From: Ted Lemon 
Message-Id: <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0C8CE6AB-F545-4B47-88A8-D8A9F4DFB958"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 15:04:40 -0700
In-Reply-To: 
Cc: Brian E Carpenter , IPv6 Ops WG 
To: Mark Smith 
References:  <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us>    <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>         
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:04:53 -0000

--Apple-Mail=_0C8CE6AB-F545-4B47-88A8-D8A9F4DFB958
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 2:49 PM, Mark Smith  wrote:\
> Devices like this Chromebook are getting their time by having
> hardcoded, Internet located NTP server addresses in their firmware.
> There are potential trust, privacy and reliability issues with that
> sort of model.

It's probably got a domain name, not an IP address, encoded.   And it =
might even have a pre-shared key, although that's not ideal.   And it =
probably has an RTC with a battery, so that it can reject really weird =
values, closing the window of opportunity for replay of compromised keys =
quite substantially.

So in practice, all it needs in order to use the network is a working =
default route and a pair of working DNS resolvers.


--Apple-Mail=_0C8CE6AB-F545-4B47-88A8-D8A9F4DFB958
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 2:49 PM, Mark Smith <markzzzsmith@gmail.com> wrote:\
Devices like this Chromebook are getting =
their time by having
hardcoded, Internet =
located NTP server addresses in their firmware.
There are potential trust, privacy and =
reliability issues with that
sort of =
model.

It's =
probably got a domain name, not an IP address, encoded.   And it =
might even have a pre-shared key, although that's not ideal.   And =
it probably has an RTC with a battery, so that it can reject really =
weird values, closing the window of opportunity for replay of =
compromised keys quite substantially.

So in practice, all it needs in order =
to use the network is a working default route and a pair of working DNS =
resolvers.

=

--Apple-Mail=_0C8CE6AB-F545-4B47-88A8-D8A9F4DFB958--


From nobody Wed Apr  5 15:11: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 330B41294C2 for ; Wed,  5 Apr 2017 15:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yDlNQcUlzMUq for ; Wed,  5 Apr 2017 15:11:06 -0700 (PDT)
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 A72031294CC for ; Wed,  5 Apr 2017 15:10:23 -0700 (PDT)
Received: by mail-pg0-x234.google.com with SMTP id g2so16696402pge.3 for ; Wed, 05 Apr 2017 15:10:23 -0700 (PDT)
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=DxwaJg9lEguBaomOEjqkmKlzgCruhEpItelxR1zwmN0=; b=zVI0LIHBVPVumdphPMGmp55anXGOhluJmegGu9QOmHy8BYPfjHb4ZkOw3IXHfoQzef ALiHHLjXYzeqwoPC6zLxnoNseDHpWhFijtLdh9akxRELwVFAsdCilU6ZpABWkqGJ9RFk iWGggkkYixj+KVUSEgAEtT7wCGELCkK7WfXlK0hObDvrAoOBIZR/jhWtahXSErvkH0SO 2ylugFqH4wnk+7WjPQiI9SMxyVuXA2MZqgkBgkNpLSq3YDMaTb7EleIhkf3hPBHbXXFP W+w+VM9/D/RSqSfQPVrMXyI/FmiV+KjkvqXRRGRkhEQJSbWZR+tXuz0PteDaOsbwI8Q1 QvAQ==
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=DxwaJg9lEguBaomOEjqkmKlzgCruhEpItelxR1zwmN0=; b=LOC4cbj7tBk5u5xGLx2bdIS6vW/f/SRnIudlCabaIBMWGGGhA+ImD0th3mm0NP68YK 8qfbIeIILw+nmRLd6VtCfE7ixSh1hwU1kCjsthqkhyflHFevB5r9mqZMa6MolqkuKrGv B8fMqNyYHIOsyOth4c+fX19DWREFY8wAB96AfOba9A6Ex5foAVZF+aWFI9U37xZ8fRS4 3jJ3uxUiLQDXSVUvSLzIDNBEjM0urbCxNSJoi8+OScY8HrD0hcVBGu3HhRt01+1t2k0j /rwIncmIarhNl/wMxgTJ8wDB966qG+tqQjZkU0/u3syNcELPG0UarKOAQQCJn2SV5pg2 hi7g==
X-Gm-Message-State: AFeK/H3Vznit+nWJmAXX9qR1ElyAcO6LSwVrfCy3cCsgOI3t9nMlCBtNLXwpEkh5EkFaug==
X-Received: by 10.84.211.130 with SMTP id c2mr39542745pli.82.1491430223222; Wed, 05 Apr 2017 15:10:23 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:4822:af74:a02a:54d? ([2620:0:b60:17:4822:af74:a02a:54d]) by smtp.gmail.com with ESMTPSA id y6sm27938749pgc.40.2017.04.05.15.10.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 15:10:22 -0700 (PDT)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_32AB5E5F-6F2E-408C-96B9-740CCE56E947"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 15:10:19 -0700
In-Reply-To: <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>
Cc: Erik Kline , Nick Hilliard , "v6ops@ietf.org" 
To: Brian E Carpenter 
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org>  <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:11:08 -0000

--Apple-Mail=_32AB5E5F-6F2E-408C-96B9-740CCE56E947
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 2:52 PM, Brian E Carpenter =
 wrote:
> Iff the IETF IPv4 service was
> actually CGN it would be a different story; a bakeoff between NAT64
> and CGN would be instructive.

It's almost certainly worth asking why IETF continues to carry around =
its old, obsolete IPv4 address block to every IETF.   This horribly =
confounds various geolocation services, so that for example when I tried =
to share a map to a meeting in Chicago with a bunch of other IETFers, I =
had to use tethering to get a US IP address so that I could reference =
maps.google.com  instead of maps.google.kr =
 (which for some reason was really slow).

There was a time when making sure that every IETF participant had a =
globally routed IPv4 address was a sensible thing to be doing, but I =
think that time is solidly in the past at this point.   Nowadays it's =
like having free morning shoeshine service (leave your shoes outside the =
door before bed, they'll be shined and returned, in case youngsters are =
wondering WTH I'm talking about).

I'm not saying we don't need IPv4, but there's no reason to run it as =
anything other than a legacy (CGN) service at this point: that's how =
it's run everywhere else, and if we think that running our network =
differently than the rest of the world is eating our own dogfood, I'm =
not sure why.


--Apple-Mail=_32AB5E5F-6F2E-408C-96B9-740CCE56E947
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 2:52 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Iff the IETF IPv4 service was
actually CGN it would be a different story; a =
bakeoff between NAT64
and CGN would be =
instructive.

It's almost certainly worth asking why IETF =
continues to carry around its old, obsolete IPv4 address block to every =
IETF.   This horribly confounds various geolocation services, so =
that for example when I tried to share a map to a meeting in Chicago =
with a bunch of other IETFers, I had to use tethering to get a US IP =
address so that I could reference maps.google.com instead of maps.google.kr (which =
for some reason was really slow).

There was a time when making sure that =
every IETF participant had a globally routed IPv4 address was a sensible =
thing to be doing, but I think that time is solidly in the past at this =
point.   Nowadays it's like having free morning shoeshine service =
(leave your shoes outside the door before bed, they'll be shined and =
returned, in case youngsters are wondering WTH I'm talking =
about).

I'm =
not saying we don't need IPv4, but there's no reason to run it as =
anything other than a legacy (CGN) service at this point: that's how =
it's run everywhere else, and if we think that running our network =
differently than the rest of the world is eating our own dogfood, I'm =
not sure why.

=

--Apple-Mail=_32AB5E5F-6F2E-408C-96B9-740CCE56E947--


From nobody Wed Apr  5 15:11: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 370C2126E3A for ; Wed,  5 Apr 2017 15:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 rxelKMRG4d7F for ; Wed,  5 Apr 2017 15:11:36 -0700 (PDT)
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 7F9EF1294E6 for ; Wed,  5 Apr 2017 15:10:38 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id p77so12583182ywg.1 for ; Wed, 05 Apr 2017 15:10:38 -0700 (PDT)
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=y3Y4I2WCmXk4Fyxd8t9BGIu6/0VRhnJVXEHXhY9PiZw=; b=FysyLWdBV44jip1Zkrf6Dzq0MsW58IRRNe/BYFlNR4YeU9to5F9nmWiXuSyHJhKksN V89qShekPwBaGDDNGsThLv9XgF9kA0s6qeQx/qKJL5+iOL4+gkInIBV9TO6WRzSdSe0C C0gIOd5fJ9wUcFOVSCaOycTgkVxjohL2Ep2rxtozR/map0S1gNGCxC9mSgwflWEN52lq yjx7v7Ow/oUq0VtNV21RapyrNwuhNB17qx3SNxahWaVn8ALWZrHMIbUygDZfTN+TU0p6 UIVqT4LVvZIynNf+O/o5cEnWL4nsTSvieqEAlGgYMPlONFg0oGq0K+3iKRMZ7HmEzRUp AoqA==
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=y3Y4I2WCmXk4Fyxd8t9BGIu6/0VRhnJVXEHXhY9PiZw=; b=YOvalDhqsUOVMKwPKvfzfTym5aadryINlMW1XqwT7By5MZm1ZtFfuGbqkZvqQhUCYM JiJKqbDsLjUg3Z8jgmvl5yJnCLW/8CujIZEK5PETuxbSNlvfCzB1dgpeHRfAaQ1/jEKC Z1gyiN40lOjRA0rZh0sN2+0itfB/KK8g8aKYESGoXPDUYwM4Ubf38C3eB7xO4EnyZ3M4 H0EacsYE6kM2e63d6KcI4v+6LrnKBDiQuRWhfBGd9XU4yGJR8QGz1ajYqfouSUcDmCCU WZeXOAsCHUNXAWBXeBHL/d2iXRpYqrmPhYlTGOB5dN5lbpO4jKH8m+8+NeRNxBWVzvyu MNzA==
X-Gm-Message-State: AFeK/H1oP2Io2/FBL+g1/trXGLcZ0Zu86dGtngssq3qDMVIIjuz0Q88oGIqN2cYCEJal1ZWC/D0MNYl8oI68f3Yg
X-Received: by 10.13.242.198 with SMTP id b189mr19882039ywf.243.1491430237401;  Wed, 05 Apr 2017 15:10:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.220.12 with HTTP; Wed, 5 Apr 2017 15:10:16 -0700 (PDT)
In-Reply-To: <20FF8CCB-973E-49D8-8BDD-2F9E7DE54EF0@gmail.com>
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org>  <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20FF8CCB-973E-49D8-8BDD-2F9E7DE54EF0@gmail.com>
From: Erik Kline 
Date: Thu, 6 Apr 2017 07:10:16 +0900
Message-ID: 
To: Fred Baker 
Cc: Brian E Carpenter , Nick Hilliard , "v6ops@ietf.org" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0356ec8ab9ff054c72a9b1"
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:11:38 -0000

--94eb2c0356ec8ab9ff054c72a9b1
Content-Type: multipart/alternative; boundary=94eb2c0356ec825ebc054c72a985

--94eb2c0356ec825ebc054c72a985
Content-Type: text/plain; charset=UTF-8

On 6 April 2017 at 06:58, Fred Baker  wrote:

>
> > On Apr 5, 2017, at 2:52 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> >
> > NAT64 and CGN would be instructive.
>
> NAT64 *is* CGN (or at least NAT); it just happens to be between IPv4 and
> IPv6.


Yeah, the IETF networks are extremely rare in handing out public IPv4 space.

For all intents and purposes these days, every device might as well have
the same IPv4 address and default router configured and only the default
router's MAC address needs to be found (with VRRP even that's in the
guessable realm).

--94eb2c0356ec825ebc054c72a985
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 6 April 2017 at 06:58, Fred Baker <fredbaker.ietf@gmail.com<=
/a>> wrote:

> On Apr 5, 2017, at 2:52 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

>

> NAT64 and CGN would be instructive.



NAT64 *is* CGN (or at least NAT); it just happens to be between IPv4=
 and IPv6.

Yeah, the IETF networks are extr=
emely rare in handing out public IPv4 space.

For a=
ll intents and purposes these days, every device might as well have the sam=
e IPv4 address and default router configured and only the default router=
9;s MAC address needs to be found (with VRRP even that's in the guessab=
le realm).



--94eb2c0356ec825ebc054c72a985--

--94eb2c0356ec8ab9ff054c72a9b1
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgxmzzb5fqH75kKZiZ68Aw/icLxmvoOnTG
Jz1QJJMuzFAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA1
MjIxMDM3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAJulR8tU9XXke0rXSK0jqJOlU6EjFPFpzVHd97KU9BZJLnRknFjr
COzbJtK4m7lXYDGHI/zP5GZxLtsj4/B2uPSFU6v1vuZ6ajcW1unvNN935gyrmGcFWJNuMuZG4O3n
T6Mvd0J0SCRfTrZToSckWSpttIVRsKRzMFJLB846YZz7Sf7PmSR5yhFSe0U0QFqq4+4eqCn9+8tm
bMe3MYRm5csQoSgEt4zxhBFEXCvMx2qm6ue73Xn5kib1owoK9TUD1GbyOAP6pqk5gnvp+p2Lgt5Z
M7qWZd/SASmpmYy9n+ax4/AEVBUjtiyUSCC2sthJW+aZuFdKz7uKK+B6cByv6Pc=
--94eb2c0356ec8ab9ff054c72a9b1--


From nobody Wed Apr  5 15:14: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 7B3C6126557 for ; Wed,  5 Apr 2017 15:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 xzYBga6c39yx for ; Wed,  5 Apr 2017 15:14:55 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 33EC91294CA for ; Wed,  5 Apr 2017 15:14:44 -0700 (PDT)
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 C65C63493AC; Wed,  5 Apr 2017 22:14:41 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 910D5160075; Wed,  5 Apr 2017 22:14:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7F49D160076; Wed,  5 Apr 2017 22:14:41 +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 xFD74GSsMMFx; Wed,  5 Apr 2017 22:14:41 +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 21399160075; Wed,  5 Apr 2017 22:14:41 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A99BB6A925A5; Thu,  6 Apr 2017 08:14:37 +1000 (AEST)
To: Brian E Carpenter 
Cc: Erik Kline , Nick Hilliard , "v6ops@ietf.org" 
From: Mark Andrews 
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org>  <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>
In-reply-to: Your message of "Thu, 06 Apr 2017 09:52:30 +1200." <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>
Date: Thu, 06 Apr 2017 08:14:37 +1000
Message-Id: <20170405221437.A99BB6A925A5@rock.dv.isc.org>
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:14:58 -0000

In message <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>, Brian E Carpenter writes:
> On 06/04/2017 09:08, Erik Kline wrote:
> > On 31 March 2017 at 00:17, Nick Hilliard  wrote:
> > 
> >> Ted Lemon wrote:
> >>> I would prefer that the default ietf ssid were IPv6-only with NAT64 for
> >>> legacy service.   If people want IPv4, they should switch to
> >>> ietf-legacy.   And if we really want this data to be meaningful, we
> >>> should change the name of ietf-legacy every IETF so that people have to
> >>> choose it to get it.
> >>
> >> I'd be pleased if this were done at meetings that I regularly attend.
> > 
> > 
> > Likewise.
> > 
> > FWIW, I believe that switching the default was proposed at a plenary in the
> > no too distant past.  The suggestion was for "ietf" to be operated as
> > "ietf-nat64" and replace "ietf-nat64" with "ietf-dualstack" or
> > "ietf-legacy".
> 
> Isn't the -legacy SSID the one with no authentication?
> 
> That said, no, I don't agree. The default should be (a) authenticated
> and (b) dual stack. I don't buy (and never have, and never will) that
> presenting NAT64 as preferable to genuine IPv4 is in the interests of
> users. It's second-class dog food. Iff the IETF IPv4 service was
> actually CGN it would be a different story; a bakeoff between NAT64
> and CGN would be instructive.
> 
>     Brian 

The point of eating one's own dog food is to expose one to all the
issues of using that dog food.  At the moment we have lots of people
that think NAT64 is something that should be recommended when you
start down the ipv6-only path.  Having them consume this dog food
may make them rethink that opinion.

This is just opt-out rather than opt-in.

Mark

> > _______________________________________________
> > 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Apr  5 15:17: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 CBA06126E3A for ; Wed,  5 Apr 2017 15:17:08 -0700 (PDT)
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 0miWvqMX-s8Z for ; Wed,  5 Apr 2017 15:17:07 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 6D47D127978 for ; Wed,  5 Apr 2017 15:16:59 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id z13so19149576iof.2 for ; Wed, 05 Apr 2017 15:16:59 -0700 (PDT)
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=LH7PMcB4fZ7NaNd7TREyoV/7urR147wxcvOA20KOhRM=; b=jTa8ZBwzP/C9BHI2zeG38HTuOCm8Uw8LQNLSYV/g17aCMD2cj7Kd8F6WlFTAJjm9vs WPhf2L7uRPP3XQ3voE1XhuTT78+QVyuLO2dWogXTpo0Rph2al5HchcxlXj3TevfVT2ie Ri3FttePlHuF+glnpEW7WlVhXBd7ShMvrf62ojvSACZXEQUD08fDJzA9wa8fFG7094nm 5anMs2frWWV3fEuX4ZcV7YgBxoiVBO1+8BTMM+qEC+v86hV0tzItmDCTAO5LaftNqF3P HqcWc5jR04P2O4lGk1c/HH/GHHIBL9XTRtuPY2tJmjWHoXBaosVzLfjA4G0uGzA49z1G TWNg==
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=LH7PMcB4fZ7NaNd7TREyoV/7urR147wxcvOA20KOhRM=; b=KLSWm+rpDuBstBk5Cao5trf40AFuPCtpE2nH37OkQUS/izg8xIf+Z37tUyoIFPVmY9 JHDvKub0iiMWbuuVH+8XVYxCK98t0lRwaCSxG0qD0NO2MpwIp0fz+gJCd+oZJnBX95u1 7H+uuaiSAUyp4mxs64ZAZN5G/ipNyRTaGW2IrE7tfAu23Io0lXoB/rMOagMnnKCnsJU3 /gEMoUpzixEAYHOE/n7WfMzEe3JVB81ZzZcwWlOs2GLrHrFQbGpa5wDWgT6ZzauoARDO gzXUMhxS7e6mNPaiNK4OSuqBGOGu/KU8bOkflZwrjJ3G5s2AgaBx6IkWO+wvpeV1AZ3Q USrw==
X-Gm-Message-State: AFeK/H0gwk+X4WzGg551i2bTtKuwUNSBupbtbpqp+sNzMPhHjxQwzuwdzNbUr4TGR1ti7g==
X-Received: by 10.107.147.134 with SMTP id v128mr30062078iod.128.1491430618833;  Wed, 05 Apr 2017 15:16:58 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id a184sm11187994ioe.62.2017.04.05.15.16.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 15:16:58 -0700 (PDT)
To: Mark Smith 
References:     <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>         
Cc: Owen DeLong , IPv6 Ops WG 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <69b21290-cea2-950b-1901-8447c0a39ed8@gmail.com>
Date: Thu, 6 Apr 2017 10:17:01 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:17:09 -0000

On 06/04/2017 09:49, Mark Smith wrote:
> On 5 April 2017 at 23:35, Brian E Carpenter  wrote:
>> On 05/04/2017 12:44, Mark Smith wrote:
>> ...
>>> I don't understand this view that DNS information is the only
>>> additional information a host needs over its addresses and default
>>> gateways.
>>
>> That isn't the assertion. It's that DNS information is the only
>> additional information a host needs *in order to get basic
>> connectivity to the Internet*.
>>
> 
> So then I'd say I don't understand how a host with basic connectivity
> to the Internet with an unset real time clock is that all that useful.

It depends what its job is. I don't care to generalise.

> Devices like this Chromebook are getting their time by having
> hardcoded, Internet located NTP server addresses in their firmware.
> There are potential trust, privacy and reliability issues with that
> sort of model.

That is indeed a terrible model. Another well-known O/S has used an
FQDN with a sensible choice of servers for many years now.

> I think this would be a model that is encouraged by only requiring
> RDNSS support.

I take the view that things like this, although fundamental, are
applications and should start with name resolution.

    Brian


From nobody Wed Apr  5 15:24:29 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 E51E91294B8 for ; Wed,  5 Apr 2017 15:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 wpgWAjTI82s4 for ; Wed,  5 Apr 2017 15:24:25 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 53DB11294AC for ; Wed,  5 Apr 2017 15:24:21 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id a140so17116020ita.0 for ; Wed, 05 Apr 2017 15:24:21 -0700 (PDT)
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=5I+CN1Z9B6+OYqPQ0aheLMjUPLnUdJwKZhE49Qti3jM=; b=lFBIT1EB04S4Avip/Fg9Pj6ZmFyAir2O/cLayMfUgpcQsYx5v6VkU9nmumO7TtrlbP aPoRMrJAC4FVjk5h8BsD9/xQ9qZ4rylBit7y8/pQ/aPdQ15HpehQPX2JaItFTt1abEMi +JOxTk5luoYbQbipCQ5KwM4AktWSdMY3Dwd+AW81o3vr7leydEiAvz45KXXEBwXTYGAY dD5wPFaODDyEaHk7zot1LvUPSyoSASr0j+tx2wF5PlJ40/zOfD77POkTNRMA33ENGLRx PidbVBPGhrwwNd8xMcqpj08nDybkcQzBoly9kjzj8Ey9D2pLWHajQPxB6VIx250bghqL VVfQ==
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=5I+CN1Z9B6+OYqPQ0aheLMjUPLnUdJwKZhE49Qti3jM=; b=uCRe+z2AfNCvtU3wIRRq28WY+wR0B901KXWtBnoqcfVjc/12IM/O8mcA5RhYW+7gaG qWedVxKY1bcJg/zS2o1pMPfMjR5eeaMPvMFsstBENH/4qFcce6ua4Y8pJApsmAWMXudW zCTsSW/LJbPhHpwE7pfNrvfSqY32fIAW82seeisZ3zC6ZiImAW2UTlDjBklma/C2RwkP HUTyK/qJWCUJ+IWSwL0aMKlqVvhn1KRcG0PUULTy0hqASYmPiaFOdPsRm7H0lo5tBTWW HHRQNGch6eoiKFfy4TsqgT2UfxJbCTgTuoEXSCqF1M+jDNXa6tf2tYNksalCp0XNp4CI QteA==
X-Gm-Message-State: AFeK/H287D7yO2tcKdYMN+nhZ3V6PtKTt216QjZ8UTuNhNXQapiogFoX lPNfW3s4mR8y+Q==
X-Received: by 10.36.47.142 with SMTP id j136mr9290599itj.29.1491431060745; Wed, 05 Apr 2017 15:24:20 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 33sm11199174ios.54.2017.04.05.15.24.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 15:24:20 -0700 (PDT)
To: Fred Baker 
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org>  <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20FF8CCB-973E-49D8-8BDD-2F9E7DE54EF0@gmail.com>
Cc: Erik Kline , Nick Hilliard , "v6ops@ietf.org" 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 6 Apr 2017 10:24:23 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20FF8CCB-973E-49D8-8BDD-2F9E7DE54EF0@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:24:29 -0000

On 06/04/2017 09:58, Fred Baker wrote:
> 
>> On Apr 5, 2017, at 2:52 PM, Brian E Carpenter  wrote:
>>
>> NAT64 and CGN would be instructive.
> 
> NAT64 *is* CGN (or at least NAT); it just happens to be between IPv4 and IPv6.

Yes. But it's still a different beast with potentially different failure
modes and performance impacts. It's not an apples/oranges comparison;
more like comparing two types of orange.

    Brian


From nobody Wed Apr  5 15:31: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 29AF6127978 for ; Wed,  5 Apr 2017 15:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 6CxI9J5HS0PH for ; Wed,  5 Apr 2017 15:31:55 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 0EA521286CA for ; Wed,  5 Apr 2017 15:31:55 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id y18so91741787itc.0 for ; Wed, 05 Apr 2017 15:31:55 -0700 (PDT)
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=ItwZ3bdxjmebaAcdFI/Vp9TSPAxZI29Ry2TYIvAh7Qo=; b=ux7WYlxDe/XP7NLIp7hN2KtrQrMS7d6c5u3B3GJwW3doyAQ+k54HVCrR4zkElW564F IZrYbtOJriBR/SgBnX3ab8x05ZUHUcitRFVtHqiT+7xjTW/E0K7kebk1JboTQoKEj6uj 1g3f2Lk/UGlQqlf+JcYWcCkRpndtGTLREtz6NdHWI3/Dw6LirfDaro3fQv83LmdFL1UA z5CLX151FyMpXxRyqvuRQXdOuL4HKOUePd5Bx2X7/U4kwnly/LiozhmS/LB4oACKzL6G FHwqKBpl1b7L5ykUYkr6lJJ9BCvLkLN0Zj0ye859HN2naSVJOhn2ww14ExpyduCE3WxA 1UqA==
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=ItwZ3bdxjmebaAcdFI/Vp9TSPAxZI29Ry2TYIvAh7Qo=; b=uhwCWoUEBF5kdEpJnJQy1oy8AbYfombFhP4ZHJqt500efcQWQ665Riy6vXraEED5Be uWEk24JDrhFjmHpJN9NWmoSfWRW9S6J1dFVtUkFhmWRezEuMuFa6QzBETALGGgtb/Tqk YlBg/2wBML8pJqpxF3137/EOrohFb1Igr2W5JfAv3nQiDSy+ZlkEtx8TLoUAv/vAvror AFsUI1KTO/FjBHVIRpHaGyP3bm1sFis/TbwU9evaYcXCB82UoUPTTP/w7nav/lnNJxhQ NyP53K5ZKUgSLpiEzKPvjS0plsUak4h77yNXjBMndK5q/0kiOessIWZ1AdqpHoctdZkS QW2A==
X-Gm-Message-State: AFeK/H2KzR919KnGfvoIsfAPhhOVSPUpetk58JDj4LzCdarXEjrDm42S2Bn/HIVPtoEitg==
X-Received: by 10.36.185.87 with SMTP id k23mr23016946iti.12.1491431514431; Wed, 05 Apr 2017 15:31:54 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id y125sm11171itb.4.2017.04.05.15.31.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 15:31:53 -0700 (PDT)
To: Mark Andrews 
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org>  <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20170405221437.A99BB6A925A5@rock.dv.isc.org>
Cc: Erik Kline , Nick Hilliard , "v6ops@ietf.org" 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <1a120640-a464-8938-07fe-8e3e0629825f@gmail.com>
Date: Thu, 6 Apr 2017 10:31:57 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170405221437.A99BB6A925A5@rock.dv.isc.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:31:57 -0000

On 06/04/2017 10:14, Mark Andrews wrote:
> In message <49286e89-43df-ac6d-8c9b-981661663684@gmail.com>, Brian E Carpenter writes:
>> On 06/04/2017 09:08, Erik Kline wrote:
>>> On 31 March 2017 at 00:17, Nick Hilliard  wrote:
>>>
>>>> Ted Lemon wrote:
>>>>> I would prefer that the default ietf ssid were IPv6-only with NAT64 for
>>>>> legacy service.   If people want IPv4, they should switch to
>>>>> ietf-legacy.   And if we really want this data to be meaningful, we
>>>>> should change the name of ietf-legacy every IETF so that people have to
>>>>> choose it to get it.
>>>>
>>>> I'd be pleased if this were done at meetings that I regularly attend.
>>>
>>>
>>> Likewise.
>>>
>>> FWIW, I believe that switching the default was proposed at a plenary in the
>>> no too distant past.  The suggestion was for "ietf" to be operated as
>>> "ietf-nat64" and replace "ietf-nat64" with "ietf-dualstack" or
>>> "ietf-legacy".
>>
>> Isn't the -legacy SSID the one with no authentication?
>>
>> That said, no, I don't agree. The default should be (a) authenticated
>> and (b) dual stack. I don't buy (and never have, and never will) that
>> presenting NAT64 as preferable to genuine IPv4 is in the interests of
>> users. It's second-class dog food. Iff the IETF IPv4 service was
>> actually CGN it would be a different story; a bakeoff between NAT64
>> and CGN would be instructive.
>>
>>     Brian 
> 
> The point of eating one's own dog food is to expose one to all the
> issues of using that dog food.  At the moment we have lots of people
> that think NAT64 is something that should be recommended when you
> start down the ipv6-only path.  Having them consume this dog food
> may make them rethink that opinion.

If that's the argument, then we should definitely have a 464XLAT
solution in the choice of dog food too.

But I will always opt for pure dual stack, like I have in my
university office. I have enough experience of dual stack + NAT44
at home, thanks.

   Brian

> This is just opt-out rather than opt-in.
> 
> Mark
> 
>>> _______________________________________________
>>> 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 Apr  5 15:40: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 940B3126FB3 for ; Wed,  5 Apr 2017 15:40:54 -0700 (PDT)
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=algebras-org.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 Rcpa9fRRvnKF for ; Wed,  5 Apr 2017 15:40:51 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 B615D1286CA for ; Wed,  5 Apr 2017 15:40:51 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id r69so22374139vke.2 for ; Wed, 05 Apr 2017 15:40:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PWCZjlyyZwKDvjTbZH0GMOfFGkD8J2HerdGfRSzByk4=; b=hkrNwO9f/z0WpAgX4HP3AhmB2ncZg7Q5BvirH4iyIV3n9XRvVDjLcSO38MawRhGxLB BwuOXzBmw6SrUJbxJgDjswG3bcq0jJCK0+3rNQt75o5TnKm3SX6p8Zev6i3zoTgEkceW 7yTsyrIFTshDcDV4bx4887B2zo3s7H8zf+96y2ibf1oZMgn4VaV0/noGiDYlqA3db111 0/H5X3CCJI2I6l82UdT+bkGOCqjvENgrx+dVMSquQKV1GukMXvlPQMrU2dvknDTbKLKV XNk5tJQ+nZ3NmDzakZfn4GuyO2olav8axeiVBk7zmFq+G+9fjCZ7srXnbC5Z+K0zVNVg Ccjg==
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; bh=PWCZjlyyZwKDvjTbZH0GMOfFGkD8J2HerdGfRSzByk4=; b=IVcPWcqCZzq25tICrLj+NMg4J+fj9ieUtHldSGcqbgW7hgu1BI1mJsFXn1yRReBBOd UIEIGhtRGEC1S+AUJsPWHCLCT3ErOT5x91Cs+Ml5LBI5y1KZTr6XMdC9v/8BsAGTqmP3 sN1o47RBZwDKf6JRyzxD0Dk/qKcz+dVQa9KzZQSiNt5l6iRNFsBOeoO93TqsuyIm15Uj MXJ6w9qgPVZ471PSNTdCVFLrTzsZlYgTc24C2r8Ip4FWTcfRijzm2yzWO/wmvMu7vqdk ggD+8B4bzxXXu76JVQ4IdaNYu3NitrUHy2fMzJpiHvsJbhGzp3s5xzPu2g4czBs/bRW2 T2iw==
X-Gm-Message-State: AFeK/H1LFcQkRJh6HFBnkaSP97EuG9bSxYnsDzDL5VqouEJNVHQEQLIqkxEN6d+R6ThAdAg9SUbma95/KwI+Ww==
X-Received: by 10.176.5.199 with SMTP id e65mr10283295uae.23.1491432050405; Wed, 05 Apr 2017 15:40:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.84.20 with HTTP; Wed, 5 Apr 2017 15:40:49 -0700 (PDT)
X-Originating-IP: [2001:dc0:a000:4:d9d1:217a:5ec2:b6cf]
In-Reply-To: 
References:  <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us>    <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>        
From: George Michaelson 
Date: Thu, 6 Apr 2017 08:40:49 +1000
Message-ID: 
To: "v6ops@ietf.org WG" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:40:54 -0000

I take a consumerist view, and I only contribute in that sense: I use
devices which move between underlying substrates and I want them to
work. Thats a common expectation. It reflects badly on BOTH client and
server implementor when I'm wedged because of decisions to not
implement in an A/B choice world. I understand that HAVING an A/B
choice was a 'wrong move' but post deployment, if you have one, you
have to live in one.

So I tend to a view that clients should be able to use the expected
configuration techniques, which is tending to 'implement the minimum
necessary sat of ALL of them" but I acknowledge that goes to 'which
applies, what ranking, if both are seen'. And, it goes to a lack of
control I have as a consumer: my purchase decision is made long, long
after the decision is baked in. In effect, I cannot enforce what I
require here.

In that context, I am the consumer of other peoples configuration. I
have been on networks with no automatic configuration, of any kind,
where use demands you configure by hand. Thats painful, but its a fact
of life. it also doesn't scale well. I have been on networks where you
are recruited to a VLAN/Switch model which is open access, to complete
migration through a portal and then wind up with a higher view which
then exposes new things, and I can imagine this applying in V6
autoconfig too: initial config in (a) and then subsequent config in
(b)

The idea that operations staff are going to 'obey' a directive as a
fiat statement isn't credible btw: I've met these people, and given an
ability to take a different path to the one you perceived, they hold
the genes which do this. Yes, thats unfortunate, but its simple
reality as I see it: there is no ACL they will not at some time have
considered on its merits, even ones which make IP (of any version)
untenably bad. And in that sense, venders implement the "tools" they
use to do this. This is not going to change. So, while I tend to
preferring SLAAC/RDNSS/RA worlds, because they appeal to my sense of
the future, I have no doubt there are operators out there who WILL
configure networks which demand DHCPv6 for reasons I cannot constrain.

This to me is the crux: I am going to wind up needing (for some value
of maslow) to get online, behind networks which don't do the "one true
way" and so I would prefer that my client support the worser kind as
well as the better kind, because in this particular prisoners dilemma,
I simply get nothing if I am let by a moral crusader to have only
version (a) code.

ie. much though I hate it, i think client MUST support (a) OR (b) and
server MUST support (a) AND (b) is probably where I head.

Here is why.

Some people here say "I am never going to do both (a) and (b)" which
is a strong statement. It goes to their power of decision, and their
market force.

What it says to me is: "I dare you to make my manager overrule me"
which of course, I cannot do. But I have a strong suspicion market
forces can (and do) override these decisions. Nobody I know wanted DRM
in the W3C standards stream. Here we are. Nobody I know wanted (as a
thing in itself) /64 but.. here we are. Nobody I know wanted v4-v6
transition to take this long, but here we are.

Arguing for purity in these times is a luxury I don't actually think
can be sustained. I suspect its more likely we'll get to deprecation,
which is exactly what happened to a bunch of things in the v4 world.
We don't do TOS bits any more. I expect future standards to deprecate
things, and then we get to a cleaner world.

I listened to the debate about constrained boxes with interest. Most
of the conversations I've had about these boxes tend to say they will
be on an Internet Protocol network, but not actually the public net,
for other reasons. I think the role of protocol standardization in
these cases is very narrow because its about implementation
consequence for private use at volume.  Statements about cellular
handsets don't apply to boxes which are planning for a bill of
materials where memory footprint is a cost constraint. Statements
about cellular network substrates do apply. So I find myself asking if
the HEAD END of these IoT networks actually will have a problem
implementing A and B, and I struggle with that. Which means I can
easily say, an IoT target context can drive to EITHER A or B, because
it can rely on a head end to do either too.  I know that argues
against my prior sense of things, but thats the fundamental
contradiction here: not all devices are alike.

Will all IoT devices wind up running Android? I suspect not. I suspect
that even in that market share, we will have a mix of A and B
configuration choices presented. So I begin to suspect, that the real
requirement is not on the clients, but on the servers. Clients will be
deployed which make a rigorous, memory constrained choice to do only
one form of configuration.

We need servers to do either, if we cannot constrain clients to only do one.

-G

On Wed, Apr 5, 2017 at 7:37 PM, Lorenzo Colitti  wrote:
> On Wed, Apr 5, 2017 at 6:23 PM, Philip Homburg 
> wrote:
>>
>> If the question is "Do you support making RDNSS a MUST, saying nothing
>> about DHCP DNS" then my answer is that I oppose that.
>
>
> Ok, so you're saying that of the two options, you choose option #1: do
> nothing and keep the current situation where there no method is required to
> be supported.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Wed Apr  5 15:45: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 3D2BA1286CA for ; Wed,  5 Apr 2017 15:45:12 -0700 (PDT)
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 MTfpgYhL9xUw for ; Wed,  5 Apr 2017 15:45:10 -0700 (PDT)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 61B5A126FB3 for ; Wed,  5 Apr 2017 15:45:10 -0700 (PDT)
Received: by mail-io0-x230.google.com with SMTP id f84so19413499ioj.0 for ; Wed, 05 Apr 2017 15:45:10 -0700 (PDT)
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=S0BFL3iV1Tyh6MMYH2+G4M2Vk0L586/f/hu7IM5yoFE=; b=ZChIRoMzEgwzEoWibKksTs8UUb73Vx9pfV829DsTlwt6tiLwZ3njK2ihRs/Ql7hGOO ojaAzqtd0jymKjfdkCQpy6k9tn9sLwsNybDOBJPHAG6BbvZwGKg3poxxt6LQDQP+0Ya+ muwBvv1mToVCqEvW8C0iKJXAB8IPgH1WPSI8Ecj4CH3+YBInlJ9o0U6Y+C//3unlWhm3 jsUMsO4unx2hTgoSPSq7aEpExxOSxrXAvpiT+6iiaqpmEbj2R7Ux3YY/89ubIvX7UERh rYA2O42+zs1OOVZ1ugPxqEcFgKn/V0wY5jmDE/1KuToOY7WpoI/UFuYhy1qv6pnsXdSY IEIA==
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=S0BFL3iV1Tyh6MMYH2+G4M2Vk0L586/f/hu7IM5yoFE=; b=Y/l2YilwSa/Xa/fcBS9sXMcXrF1R83kZUYHij1M46lJ/pNb+/ZtjulQk5fadYNNcTm J5+xFTG6o/LGMshOtZbo8mzqV2N0adPIJPp9kEp54fqBDEXn1btiL7mYielPfp0AU9o3 7Mpl8dplAE+Sj/29/OPHbDYqEIqxNwTyKP8zbCBF9RSUMP7Lq4QKKoPpdvn6QiHpyxr0 fq4/RkvfgfTUZ7INs02AiQ0YBRzNMAGnz+h6oY0tkdLTZ1jCwgcJgQcb3MbuxB80Ga14 mgnRvmSSQSTRhwMwRJjhaQUbAobIq8RYS1tJNMsCqLJxxy/Ea9esXQYaYkHHeUKGmixo +CMA==
X-Gm-Message-State: AFeK/H1VE96awGYs2Kkmtjmx72PKxPvwk4O5ZtyDRkWz0tYkF10OsNQsSMSeFg+M3Q47Eg==
X-Received: by 10.107.47.137 with SMTP id v9mr30354691iov.112.1491432309758; Wed, 05 Apr 2017 15:45:09 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 86sm11732iom.58.2017.04.05.15.45.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 15:45:09 -0700 (PDT)
To: Ted Lemon 
References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de>   <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org>  <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> 
Cc: Erik Kline , Nick Hilliard , "v6ops@ietf.org" 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 6 Apr 2017 10:45:12 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Eating one's own dog food
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:45:12 -0000

On 06/04/2017 10:10, Ted Lemon wrote:
...
> I'm not saying we don't need IPv4, but there's no reason to run it as anything other than a legacy (CGN) service at this point: that's how it's run everywhere else, 

Absolutely not true. Many campuses still run a proper IPv4 service, and many ISPs still
don't need to run CGN (of course their subscribers mainly run small-scale NAT44).

There are a lot of CGNs, nobody is denying that. It's been researched:
www.icir.org/christian/publications/2016-imc-cgnat.pdf

   Brian


From nobody Wed Apr  5 15:46: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 63A521286CA for ; Wed,  5 Apr 2017 15:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Level: 
X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.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 abuB_v3Z6tMj for ; Wed,  5 Apr 2017 15:46:04 -0700 (PDT)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 1486C126FB3 for ; Wed,  5 Apr 2017 15:46:04 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 9CBA2254 for ; Wed,  5 Apr 2017 22:46:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T8JKNQOH-Bp for ; Wed,  5 Apr 2017 17:46:03 -0500 (CDT)
Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 67ABF8E for ; Wed,  5 Apr 2017 17:46:03 -0500 (CDT)
Received: by mail-vk0-f69.google.com with SMTP id r69so6819028vke.4 for ; Wed, 05 Apr 2017 15:46:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZKOZcx4x5Py5Zjjc16uU+kXYahjd3LmPldwAqat3V6c=; b=VbAHgfXGmBVbo/c6QDhpfewccpcqjiF1gQ5XTRzJWw83r/EW283Pfb/8stSwOBE5Za 4a/jOGp3DV+zzutky+UDRJk9EXYzxA1wFAHK/2S7B3pA5hZb0DBb50lwSjKejdibNags iza7ZQkPs8RumDUJZdbZhSWLKQfJWnZ4P9QzDKIEr7Kb+S0UORc7DqqitxAJxq9SQ6ZI 3SeHvvTk6sAYw9yAxDUkI+DoU+9mTM0K56ctq5Q9HzV8i6dQysXzln+CB6bIGrCX1sfI S8IUcUyr+IaZvPRD7uEidQiQlziCTDKO3heQ/9EJVlCjWITxsq/HKhwftFv+iKIA3Ox5 SxWg==
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=ZKOZcx4x5Py5Zjjc16uU+kXYahjd3LmPldwAqat3V6c=; b=Mx+KLDGH0d2V1vLPM1fb13f2EItG0br57iwZGcobEAGIG+xguk5U++SqR1N7EB8VY4 l7ndYiXjnPDZFQEpUBYTyh42XOaOZ83pkdkPhogrG5LkcwN25HxzzqZDvyrSgyJ3XQ4l oOCehJV1r0lm8HbB9fMXvaAiKJHaFWgrxhere7NHKJs8yTjzppmStNasMG8LsRCuVkl0 PUZym5Zgz3RvBsylJzFVi902yaWAtbYfTlPao3PP4Rrg35SygEnDXe2uNLKDrVzxK5IC Eqh7cz/+CmuceHcGu5FmejhZngfSeGa4FClta6BEOUvyG352UksLFnuno7vh1J+gh4Ui jmjQ==
X-Gm-Message-State: AFeK/H1hudFqdWVzSOLJs4M/smorq8+jAKprjts8qa21NMsbBpK4hccANJkvS3h/3fc2cncdlJyQM5klEIFD7PUTQngoYq3+PHEanVb84zXL8+o4dQixoLZZxNeJhSK/XiSPvGz0MtyCwbX6Nb6r
X-Received: by 10.159.34.8 with SMTP id 8mr15895669uad.108.1491432362773; Wed, 05 Apr 2017 15:46:02 -0700 (PDT)
X-Received: by 10.159.34.8 with SMTP id 8mr15895656uad.108.1491432362464; Wed, 05 Apr 2017 15:46:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.144.27 with HTTP; Wed, 5 Apr 2017 15:46:01 -0700 (PDT)
In-Reply-To: 
References:  <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us>    <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>        <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>  
From: David Farmer 
Date: Wed, 5 Apr 2017 17:46:01 -0500
Message-ID: 
To: Ted Lemon 
Cc: Philip Homburg , IPv6 Operations ,  =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Content-Type: multipart/alternative; boundary=001a113d00802bf289054c7328a3
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 22:46:06 -0000

--001a113d00802bf289054c7328a3
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 5, 2017 at 10:15 AM, Ted Lemon  wrote:

> On Apr 5, 2017, at 6:21 AM, David Farmer  wrote:
>
> However, If we require both RDNSS and DHCPv6 for both routers and host, we
> reach maximal effectiveness sooner.
>
>
> Right, but if we do neither, we reach maximal effectiveness later.   That
> is the status quo.
>

I'm sorry but here is the issue, there is a fear that a statement only
requiring RDNSS is just intended as an additional political statement
against DHCPv6, which is not really helpful.

In this discussion DHCPv6 proponents started with MUST support DHCPv6 for
both hosts and routers, this was rebuffed by RDNSS proponents. When a
compromise of SHOULD for hosts was just proposed, this too was rebuffed.
This just reinforces the feeling that the real objective here is to create
an additional argument against DHCPv6.

It sounds to me like there is a consensus to require routers to support for
RDNSS, stateless DHCPv6, and DHCPv6 relay. Furthermore, at least to me, it
sounds like there isn't consensus what to say anything about hosts on this
matter.  So, maybe we just don't say anything at all about hosts, and only
say something about routers. It should be noted that requiring all routers
to support the three items above does still move us forward, not as fast as
I think anyone wants, but it moves us forward.

Hosts are allowed to do as they please, support RDNSS, or not, support
DHCPv6, or not, which is what it seems host implementers want. This is not
optimal from an network operator perspective, but it seems like all we have
consensus for.  Furthermore, if DHCPv6 was only a SHOULD for hosts,
operationally we are in the same place anyway. For a network to guarantee
support for all hosts a network operator will have to support both RDNSS
and DHCPv6 on all links, but at least we will eventually have routers that
will support both host configuration protocols.

So, if host implementers want to be obstinate, lets have the router
implementers and network operators move things forward, by adding a
requirement to support RDNSS, stateless DHCPv6, and DHCPv6 relay in all
routers.  Then suggest a configuration option for the router to get the
RDNSS info from a DHCPv6 server on the link or via DHCPv6 Relay, either
with from a DHCPv6-PD request or an additional info request.  At least this
would operationally allow the DHCPv6 server to be the primary source of all
configuration info for a network, even for hosts that only support RDNSS,
if that were operationally desired.

Thanks.

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

--001a113d00802bf289054c7328a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Wed, Apr 5, 2017 at 10:15 AM, Ted Lemon <mellon@fugue.com>=
 wrote:
On Apr 5, 2017, at 6:21 AM, David Farmer <farmer@umn.edu> wrote:<=
div>
However, If w=
e require both RDNSS and DHCPv6 for both routers and host, we reach maximal=
 effectiveness sooner.

Right, but i=
f we do neither, we reach maximal effectiveness later. =C2=A0 That is the s=
tatus quo.

I'm sorry but he=
re is the issue, there is a fear that a statement only requiring RDNSS is j=
ust intended as an additional political statement against DHCPv6, which is =
not really helpful.

In this discussion DHCPv6 prop=
onents started with MUST support DHCPv6 for both hosts and routers, this wa=
s rebuffed by RDNSS proponents. When a compromise of SHOULD for hosts was j=
ust proposed, this too was rebuffed.=C2=A0 This just reinforces the feeling=
 that the real objective here is to create an additional argument against D=
HCPv6.

It sounds to me like there is a consens=
us to require routers to support for RDNSS, stateless DHCPv6, and DHCPv6 re=
lay. Furthermore, at least to me, it sounds like there isn't consensus =
what to say anything about hosts on this matter.=C2=A0 So, maybe we just do=
n't say anything at all about hosts, and only say something about route=
rs. It should be noted that requiring all routers to support the three item=
s above does still move us forward, not as fast as I think anyone wants, bu=
t it moves us forward.

Hosts are allowed to do as =
they please, support RDNSS, or not, support DHCPv6, or not, which is what i=
t seems host implementers want. This is not optimal from an network operato=
r perspective, but it seems like all we have consensus for.=C2=A0 Furthermo=
re, if DHCPv6 was only a SHOULD for hosts, operationally we are in the same=
 place anyway. For a network to guarantee support for all hosts a network o=
perator will have to support both RDNSS and DHCPv6 on all links, but at lea=
st we will eventually have routers that will support both host configuratio=
n protocols.

So, if host implementers want to be o=
bstinate, lets have the router implementers and network operators move thin=
gs forward, by adding a requirement to support RDNSS, stateless DHCPv6, and=
 DHCPv6 relay in all routers.=C2=A0 Then suggest a configuration option for=
 the router to get the RDNSS info from a DHCPv6 server on the link or via D=
HCPv6 Relay, either with from a DHCPv6-PD request or an additional info req=
uest.=C2=A0 At least this would operationally allow the DHCPv6 server to be=
 the primary source of all configuration info for a network, even for hosts=
 that only support RDNSS, if that were operationally desired.
Thanks.

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.ed=
u
Networking & Telecommunication Services
Office of Informati=
on Technology
University of Minnesota=C2=A0=C2=A0 
2218 University Av=
e SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 5541=
4-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 




--001a113d00802bf289054c7328a3--


From nobody Wed Apr  5 16:00: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 1FB931294B5 for ; Wed,  5 Apr 2017 16:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DtOQPFzL7hu3 for ; Wed,  5 Apr 2017 16:00:13 -0700 (PDT)
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 02C58126FB3 for ; Wed,  5 Apr 2017 16:00:13 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id x125so17774279pgb.0 for ; Wed, 05 Apr 2017 16:00:12 -0700 (PDT)
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=CXbl5gT4dgSHmRnIWW1d1bHc3QGkrRIq3wVnvIRty8Q=; b=d1TH1D+gecpzH/mAX+o3rP3WAMWmjqZnLqJ67nuYQB3jcnRsyL9L/EApu74AKIiByj EgPTrn3r/7TfqEdv3REukg0rw1HhDkLJzvjQkpiMWGUvYq+Y80BNQuVQKD/+I6bYVTfA BDqVKVlKlqpSUVuOOVsPdp8gTt7OxV4tbqu4dwao2zqCRMZLks4vFpBogXRpzInB/zt1 2AtZMsd6FdQlYBs4Ym9Nj8oaaCfw3RxKPR3CsGsWWvkMs8Runz5p26tijMLWUiJ7DrEM WMGo6tHB+vLj6NuHAplb+bheq3IU+Y4SFYfJi5tJ08sNFxOt9hjHTkNR/C5gBKCxWTXN 7D3g==
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=CXbl5gT4dgSHmRnIWW1d1bHc3QGkrRIq3wVnvIRty8Q=; b=LVf64ZSYkyUkUiNJYNTkNdQFYgI558w1psG/UyBjVq5sUbnCjD2LP80WxtvRBpefRn /fN5QULwAAl3rwfFQM090kUI/pWUCHUmwh08+WW24fHBJldUGXSfgWKtzCvNGWfFLCmy H7VvJKl3wXKliaMIQllL/7NT6DVUTGb6zHWfHAWNGDude92YGB3K1CuaJPH01n5X9KIw h4KM+YoQzVuBQtzaMiUKBYrGMN5z9FlvVOT7d3Uv9F1KWmXPOg/oZFJSYggLtb8vmGFj 8zRmxw/d2SDijsW4vjH76j2PBesE740eU/hojzdHUxj1lnpapeyXalTXlrHcZ1NI6zxe 7ZKg==
X-Gm-Message-State: AFeK/H0YBBGqF2T5tNsFM3wufccAJRc0hpp9RKpQwd0T0mQ5aCTk44v+z24SXpb8rVfMQQ==
X-Received: by 10.98.96.65 with SMTP id u62mr31759699pfb.219.1491433212513; Wed, 05 Apr 2017 16:00:12 -0700 (PDT)
Received: from ?IPv6:2620::b60:17:4822:af74:a02a:54d? ([2620:0:b60:17:4822:af74:a02a:54d]) by smtp.gmail.com with ESMTPSA id t83sm330688pfe.24.2017.04.05.16.00.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 16:00:11 -0700 (PDT)
From: Ted Lemon 
Message-Id: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E90BB911-FDC1-48BB-B96C-C5FE6FFAAD47"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 16:00:07 -0700
In-Reply-To: 
Cc: Philip Homburg , IPv6 Operations , =?utf-8?B?56We5piO6YGU5ZOJ?= 
To: David Farmer 
References:  <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us>    <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us>   <58E253B4.9010501@foobar.org>        <914B3454-58A4-4130-8B90-6371100D619D@fugue.com>   
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Making RDNSS a MUST?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Apr 2017 23:00:15 -0000

--Apple-Mail=_E90BB911-FDC1-48BB-B96C-C5FE6FFAAD47
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 5, 2017, at 3:46 PM, David Farmer  wrote:
> In this discussion DHCPv6 proponents started with MUST support DHCPv6 =
for both hosts and routers, this was rebuffed by RDNSS proponents. When =
a compromise of SHOULD for hosts was just proposed, this too was =
rebuffed.  This just reinforces the feeling that the real objective here =
is to create an additional argument against DHCPv6.

Who cares?   I just want something to be MTI.   Getting DHCPv6 to be MTI =
requires more work than getting RDNSS to be MTI.   Insisting on "both or =
neither" means that it has to be done in a single document, and that =
document probably won't be this document.

I don't get why this is a fear-based argument.   It's simply a fact of =
how processes work.   If you want to require DHCPv6, you have to say =
what that means, and that's a new document.   This document is not that =
document.   So we can certainly say that RDNSS can't be added to _this_ =
document because DHCPv6 isn't done yet, but that is a _nonsensical_ =
thing to say.

The only reason to say it is to hold one requirement hostage in hopes =
that that will force the other.


--Apple-Mail=_E90BB911-FDC1-48BB-B96C-C5FE6FFAAD47
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Apr 5, 2017, at 3:46 PM, David Farmer <farmer@umn.edu> =
wrote:
In this discussion DHCPv6 =
proponents started with MUST support DHCPv6 for both hosts and routers, =
this was rebuffed by RDNSS proponents. When a compromise of SHOULD for =
hosts was just proposed, this too was rebuffed.  This just =
reinforces the feeling that the real objective here is to create an =
additional argument against DHCPv6.

Who cares?   I just want something to be =
MTI.   Getting DHCPv6 to be MTI requires more work than getting =
RDNSS to be MTI.   Insisting on "both or neither" means that it has =
to be done in a single document, and that document probably won't be =
this document.

I=
 don't get why this is a fear-based argument.   It's simply a fact =
of how processes work.   If you want to require DHCPv6, you have to =
say what that means, and that's a new document.   This document is =
not that document.   So we can certainly say that RDNSS can't be =
added to _this_ document because DHCPv6 isn't done yet, but that is a =
_nonsensical_ thing to say.

The only reason to say it is to hold one requirement hostage =
in hopes that that will force the other.

= --Apple-Mail=_E90BB911-FDC1-48BB-B96C-C5FE6FFAAD47-- From nobody Wed Apr 5 16:03: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 C688012948C for ; Wed, 5 Apr 2017 16:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVICPNHomckE for ; Wed, 5 Apr 2017 16:03:03 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4D7129463 for ; Wed, 5 Apr 2017 16:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491433381; x=1492038181; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=agPFqzDuqR6YzZ4mUgMmD4Hmm QYridrd4bpB5dELTww=; b=ck3VU2/uAaTHE4/kyxZ60yFFNrpufOynmYwzNZIOh ADg/ff8Zp9DEqRnPJyCqVA0pFreRlgXGtEqradqxZ0IYAcia9NX+CcbfON2LnukH 0QFZ8YnmAK0j9W22X5UGjqp3FWAUhRoLbpNf7+xAMpVPJhRa90Sq8hXgESE7QEu6 No= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=USuXpWsXcYM5H+Z+LrHfQBEzFu518HThsunpS3bFeIhrVhu1FR3KetBU7eQn 18qk3yU2gcl8KfdTgX0w36+iO3KqxKf3+RVZCzPPO0MqGyUMODTPRg26W k+dC6HNWeaGLw4RA2kjtWfvtGY0zBhQqoJ7CfXFqCHrl66b/WkI6A8=; X-MDAV-Processed: mail.consulintel.es, Thu, 06 Apr 2017 01:03:01 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 06 Apr 2017 01:03:00 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005403456.msg for ; Thu, 06 Apr 2017 01:03:00 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170405:md50005403456::Ph8k9hFRZzlvoJPL:00003ma2 X-Return-Path: prvs=1268eec01c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 06 Apr 2017 01:02:57 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <64FE2FEA-4469-4ECF-A02A-2FBD00DB2989@consulintel.es> Thread-Topic: [v6ops] Eating one's own dog food References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de> <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org> <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20FF8CCB-973E-49D8-8BDD-2F9E7DE54EF0@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Eating one's own dog food X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 23:03:06 -0000 That=E2=80=99s why long time ago I insisted in not having in the default ne= twork public IPv4 addresses, and instead running a CLAT. This means that we are using GUA+private IPv4 addresses. In the last IETF at Chicago, I got configured a /64 in my laptop and was ru= nning a VM with the CLAT client. This VM can be actually in the =E2=80=9Cdefault=E2=80=9D IETF SSID. If anyone needs IPv4 public address, move over the legacy SSID. In most of our daily usages networks we get the same configuration, and thi= s is what we will get for some years in homes and offices. That=E2=80=99s t= he only real =E2=80=9Cown dog food=E2=80=9D. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Erik Kline Responder a: Fecha: jueves, 6 de abril de 2017, 0:10 Para: Fred Baker CC: "v6ops@ietf.org" Asunto: Re: [v6ops] Eating one's own dog food =20 =20 On 6 April 2017 at 06:58, Fred Baker wrote: =20 =20 > On Apr 5, 2017, at 2:52 PM, Brian E Carpenter wrote: > > NAT64 and CGN would be instructive. =20 NAT64 *is* CGN (or at least NAT); it just happens to be between IPv4 an= d IPv6. =20 =20 Yeah, the IETF networks are extremely rare in handing out public IPv4 s= pace. =20 For all intents and purposes these days, every device might as well hav= e the same IPv4 address and default router configured and only the default = router's MAC address needs to be found (with VRRP even that's in the guessa= ble realm). =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 5 16:07: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 9BC5E1293F5 for ; Wed, 5 Apr 2017 16:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 SwGgkq6YMjp5 for ; Wed, 5 Apr 2017 16:06:57 -0700 (PDT) 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 2BBD11286CA for ; Wed, 5 Apr 2017 16:06:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cvu0t-0000FWC; Thu, 6 Apr 2017 01:06:55 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405201301.GP28135@angus.ind.wpi.edu> <6ca41854-74e4-4eda-92eb-dc4346f1d9c6@gmail.com> In-reply-to: Your message of "Thu, 6 Apr 2017 10:02:43 +1200 ." <6ca41854-74e4-4eda-92eb-dc4346f1d9c6@gmail.com> Date: Thu, 06 Apr 2017 01:06:54 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 23:06:59 -0000 >To make that watertight, the formal meaning of O would need to change: > >OLD: > O 1-bit "Other configuration" flag. When set, it > indicates that other configuration information is > available via DHCPv6. Examples of such information > are DNS-related information or information on other > servers within the network. > >NEW: > O 1-bit "Other configuration" flag. When set, it > indicates that DNS server information is available > via DHCPv6. Configuration information on other > servers within the network MAY be included. I think the old meaning is correct. When the O bit is set, a host should try to get the DHCP options it supports. In the ideal case, a host receives DNS information from either DHCP or from RDNSS. Note that if an important group of devices refuse to support DHCP, you have to support RDNSS, but the operator may want to provide NTP servers through DHCP. In that case it doesn't make sense if DHCP also has to provide DNS. In the case a host receives DNS from both we need a merging algorithm. I don't have a preference for that. Though to allow DHCP to override global settings, it may make sense to have a preference for DHCP. From nobody Wed Apr 5 16:16:24 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 F21F8126B71 for ; Wed, 5 Apr 2017 16:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.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 afh_Bg1zrsVk for ; Wed, 5 Apr 2017 16:16:20 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 5F64A129417 for ; Wed, 5 Apr 2017 16:16:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 7DDF29AA for ; Wed, 5 Apr 2017 23:16:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyOCFYa46FQl for ; Wed, 5 Apr 2017 18:16:13 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 48B2F7A9 for ; Wed, 5 Apr 2017 18:16:13 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id 71so6957643vkc.8 for ; Wed, 05 Apr 2017 16:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cWBOg+noEEq5y39HkZA9mOxN3E6I8w5/1lWts6iQsOE=; b=XM0suIo/NpuJuxB9+rc7luXfiQn+BMcYF+ZyCyVfsrlFMy1bQPFtR5keN7dqFcJrcF xJu2kAYAC13+AuUeoO2ybqpFkuQlRPmO7s1Erj5rZCirclK2PUDR7Iya2ru2znSHGG04 amX0yhiZFbqzhXm2N8lvyaAOH9a8YycQnTdTp7gPuxxFU1/BWplQkjXfLjNEerK3StaT g9qa7FOOFx9cEdd8sxxyNnFyysq9MJ46J+roG285skggg+Y7BT0koWLMA9R+rmCJq9Aq lTWJT0D+6hoCZsy41BX1ayetOsth9WIEzPOZIpfy7JETLcx1lw9Ang8/c+d55ogr5bbH Z3ow== 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=cWBOg+noEEq5y39HkZA9mOxN3E6I8w5/1lWts6iQsOE=; b=HlkbHPAVEhdc3hGDbJdEliqoBYNCHcZxmvwatZFmh4pf4je59gpykpZl26qYcHxxEo +MU6R8XZt4c8ftd+vkh4Hm5JIJf3hkSm0pEOrWKsCuh1z6E5rvpDUMgTOhfu9cNrV0tO Gd5uNsEgAL5wHsWiHWUbVmTBdCYqmJ21i1Tx6J/Hn+VVDwyO3ZyQ1WVdsk6CLUB+q9/b AbOMQFB9KhopDajMG+mayx5KWJe7V8t0iWZ9k0hMhOVftKSgsee8jFr2ed7lpVks+m7Z 5ClziVnW2A3rNgwy+X0G1HP5zLDhzmLHNaRuLzwuM9PiTDOnDySCkGrZdeJF2oEIrEdW 7QGw== X-Gm-Message-State: AFeK/H0lpVoetvvP7NVJWRV9x7HgbiF/mrPwyHQWcWG76EnhLtzpNe4/LsHp2F0J+8mqQHogPUqgdU0Y6eAi5KjaK+m4VmXo5QFeZ9b/sJap5A+FvGpFQb3p0oeZaMnSm/WKc4GQsoo4HHIu7o3G X-Received: by 10.176.4.102 with SMTP id 93mr3520106uav.151.1491434172551; Wed, 05 Apr 2017 16:16:12 -0700 (PDT) X-Received: by 10.176.4.102 with SMTP id 93mr3520093uav.151.1491434172282; Wed, 05 Apr 2017 16:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.144.27 with HTTP; Wed, 5 Apr 2017 16:16:11 -0700 (PDT) In-Reply-To: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: David Farmer Date: Wed, 5 Apr 2017 18:16:11 -0500 Message-ID: To: Ted Lemon Cc: Philip Homburg , IPv6 Operations , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c000bec0b8ea1054c739442 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 23:16:23 -0000 --94eb2c000bec0b8ea1054c739442 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 6:00 PM, Ted Lemon wrote: > On Apr 5, 2017, at 3:46 PM, David Farmer wrote: > > In this discussion DHCPv6 proponents started with MUST support DHCPv6 for > both hosts and routers, this was rebuffed by RDNSS proponents. When a > compromise of SHOULD for hosts was just proposed, this too was rebuffed. > This just reinforces the feeling that the real objective here is to create > an additional argument against DHCPv6. > > > Who cares? I just want something to be MTI. Getting DHCPv6 to be MTI > requires more work than getting RDNSS to be MTI. Insisting on "both or > neither" means that it has to be done in a single document, and that > document probably won't be this document. > I'm just saying what George Michaelson said, in a different way; hosts do (a) or (b), and routers do (a) and (b). > I don't get why this is a fear-based argument. It's simply a fact of how > processes work. If you want to require DHCPv6, you have to say what that > means, and that's a new document. This document is not that document. > So we can certainly say that RDNSS can't be added to _this_ document > because DHCPv6 isn't done yet, but that is a _nonsensical_ thing to say. > > The only reason to say it is to hold one requirement hostage in hopes that > that will force the other. > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c000bec0b8ea1054c739442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 6:00 PM, Ted Lemon <mellon@fugue.com> wrote:
On Apr 5, 2017, at 3:46 PM, David Farmer <farmer@umn.edu> wrot= e:
In this di= scussion DHCPv6 proponents started with MUST support DHCPv6 for both hosts = and routers, this was rebuffed by RDNSS proponents. When a compromise of SH= OULD for hosts was just proposed, this too was rebuffed.=C2=A0 This just re= inforces the feeling that the real objective here is to create an additiona= l argument against DHCPv6.

Who care= s? =C2=A0 I just want something to be MTI. =C2=A0 Getting DHCPv6 to be MTI = requires more work than getting RDNSS to be MTI. =C2=A0 Insisting on "= both or neither" means that it has to be done in a single document, an= d that document probably won't be this document.

I'm just saying what=C2=A0George Michaelson said,= in a different way; hosts do (a) or (b), and routers do (a) and (b).
=
=C2=A0
I don't get why this is a fear-based a= rgument. =C2=A0 It's simply a fact of how processes work. =C2=A0 If you= want to require DHCPv6, you have to say what that means, and that's a = new document. =C2=A0 This document is not that document. =C2=A0 So we can c= ertainly say that RDNSS can't be added to _this_ document because DHCPv= 6 isn't done yet, but that is a _nonsensical_ thing to say.
<= br>
The only reason to say it is to hold one requirement hostage = in hopes that that will force the other.




--
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking= & Telecommunication Services
Office of Information Technology
Un= iversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2= =A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c000bec0b8ea1054c739442-- From nobody Wed Apr 5 16: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 D5F14126E01 for ; Wed, 5 Apr 2017 16:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G6dtuCGdwgQR for ; Wed, 5 Apr 2017 16:20:09 -0700 (PDT) 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 157DA1201FA for ; Wed, 5 Apr 2017 16:20:09 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id 81so18168282pgh.2 for ; Wed, 05 Apr 2017 16:20:09 -0700 (PDT) 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=MhSvMOI5xSn6Hv3luShOtB5gF8tsChAS5+lGb79X6Do=; b=sLvYQZhlPfiFiRZ7uV+671M0o5YR0l3uVihqzSw03QxzYsinvvxpysWaboCDQcMm+B 9EHk8T70O1hv7nYJAQEKz+S0J2/+m6CeQ14xgooVVoXyBjUNG+4ILYwBlcRHZ7wPR3x2 ZeO5a/H/Lh2PRBHxWmKYkYcCMx04isorUKF856WHtn/Zr+kaTOkyeBkLzQcWOwdZqgEV Ex6rcI+7XRvS/D/wpuEinZoNf7jMXj6pSNThsrUzyZcszF+nntRdHo1rH2X9U01UErw2 9Cl+Giqpn+DVxLGk7yIt0r2aB+OdbE0GZvwPAviyuGjGCmIcypcdI3x36xG37mE0fs9a q6lw== 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=MhSvMOI5xSn6Hv3luShOtB5gF8tsChAS5+lGb79X6Do=; b=nS2EL6GiMeZL5X2cH1nwdsYfGnfvGYs00mXBLG3paEUuCQ285OpRIaz6mtPsgZNOh8 ZXucIIz3EXp6Xl8ohRipxTcPQPHb6MU2ow7T1iV2OsbrPbDfA+BZReXi8qlzpBxZhiyP 0t4pyg3A+UCMrFI5K2L95mh6mpnwWPU6nf3Dad1j/WUFcFUKCWSzQHIT+Xq235iAZmeq +j5hzutnroMSeFjYzOceiDuVRd4zgSqPY+P40qyZX0H3TYJE6WW7smLAzHL3bvRDZIA6 B8zhfjYSxb55ndlYJWNq8sXwdwSnMOSCgSwGHLh6ELKK0vh4qteHjs0DIcTcgGSOcvFC iuiA== X-Gm-Message-State: AFeK/H1s/cu9S0oypOmMbDuTuXq79U3wtYek+0TH/+lUSmiiMIE5QtA+2BKd2V9NDGKVXA== X-Received: by 10.99.110.6 with SMTP id j6mr33418173pgc.64.1491434408691; Wed, 05 Apr 2017 16:20:08 -0700 (PDT) Received: from ?IPv6:2620::b60:17:4822:af74:a02a:54d? ([2620:0:b60:17:4822:af74:a02a:54d]) by smtp.gmail.com with ESMTPSA id e89sm39387846pfd.122.2017.04.05.16.20.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 16:20:07 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_19184F61-BD72-4C52-AACF-163340DB6CD3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Apr 2017 16:20:04 -0700 In-Reply-To: Cc: Philip Homburg , IPv6 Operations , =?utf-8?B?56We5piO6YGU5ZOJ?= To: David Farmer References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 23:20:11 -0000 --Apple-Mail=_19184F61-BD72-4C52-AACF-163340DB6CD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2017, at 4:16 PM, David Farmer wrote: > I'm just saying what George Michaelson said, in a different way; hosts = do (a) or (b), and routers do (a) and (b). Okay. I'm not objecting to that. I am asking why it has to all = happen at once. I.e., if we have an opportunity to make (a) MTI right = now, should we take it, or should we not? --Apple-Mail=_19184F61-BD72-4C52-AACF-163340DB6CD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 5, 2017, at 4:16 PM, David Farmer <farmer@umn.edu> = wrote:
I'm= just saying what George Michaelson said, in a different way; hosts = do (a) or (b), and routers do (a) and (b).

Okay.   I'm not objecting to that.   I = am asking why it has to all happen at once.   I.e., if we have an = opportunity to make (a) MTI right now, should we take it, or should we = not?


= --Apple-Mail=_19184F61-BD72-4C52-AACF-163340DB6CD3-- From nobody Wed Apr 5 16:57: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 394C7128C83 for ; Wed, 5 Apr 2017 16:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.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 lWNSt2i2G1Gr for ; Wed, 5 Apr 2017 16:57:46 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 5B7E81293F5 for ; Wed, 5 Apr 2017 16:57:46 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id E3998A90 for ; Wed, 5 Apr 2017 23:57:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaG9SbWZ6je2 for ; Wed, 5 Apr 2017 18:57:45 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id B4DCB863 for ; Wed, 5 Apr 2017 18:57:45 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id l65so7203013vkd.11 for ; Wed, 05 Apr 2017 16:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u4ExFQsrjdc+nWMNmZvYRu04YmD/RbEoCCGRn1MtfyA=; b=DrPocNjB1feJqSY4+iVquHxJJCxQXLjc/3yVX2Ptx/r/TzrdNRs6Q4LqKiE+GiuMrd QI/i2JBG4aVbGRW0+6lUvfar8YWu0nM6Y1lOki9Z9qHOPxaKZQWEuaGcsVo4+IeMbzRh kpiYIUE76ENr50AUfS3NHfcoJ/rYu5t/KL5W4FEDnkYPflDwYzT5dYeAQsTwSvkk9oPo CNgYEDJBcHT1l0RFu6QGS3eWooSt9/BOKhU1XQDR/GXjZ2/3acEMgC2Q0C4NUpaEnuCq qglzul4I5o1hv80Q0pZcDmxlenJz6sBqAhBCwg5m9L09f44++EYoL/5ESjydIi2KSv2a g6tQ== 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=u4ExFQsrjdc+nWMNmZvYRu04YmD/RbEoCCGRn1MtfyA=; b=hC/IaLZeQNFJPKb2u935f4GrN85tfQvsAycKMeJp8rpKAjWh7J+R0cgA/ycd+gHPF1 DWFS37dA68ZftYM0wTthPA7UOixHPmpAjY45Q27NaKV51lAiYlix4+EcooaxadDSg/BT Jk/4RFmlqbmqYlQELeB78feT7sjpmv6SrSNQ8EpCwbrQqE4OfneWx9DcegUDnWrjGAK2 9LIZhTcF5zrMv2rO2aY5XiCwPTHEv4Yrs9xodp2nQJcFctSzkaqI/c7sZRommkjpkT2J C0AyEmj8xRieLCVeUa/uQ7LE3fO9mpCJ7wGHWZkA5FAr956SD85q7jsRLX3IIzaLf/lV YYCw== X-Gm-Message-State: AFeK/H0sOtADHbsbBVRvzIQ7DajZ1p0Da+b4dV+BloIOoMYpvjIQp7MNLDQBGQPr6y94R7+HGW4PwHu42kfIPt4YembRkqfN+o1D2lwIgtNkw9EoDooP/wuaRblojVZq7Nx9rPyOJuuD3IBZb1jU X-Received: by 10.31.108.151 with SMTP id j23mr14986778vki.96.1491436665012; Wed, 05 Apr 2017 16:57:45 -0700 (PDT) X-Received: by 10.31.108.151 with SMTP id j23mr14986766vki.96.1491436664723; Wed, 05 Apr 2017 16:57:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.144.27 with HTTP; Wed, 5 Apr 2017 16:57:43 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: David Farmer Date: Wed, 5 Apr 2017 18:57:43 -0500 Message-ID: To: Ted Lemon Cc: Philip Homburg , IPv6 Operations , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a1147922c9b3091054c742840 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 23:57:48 -0000 --001a1147922c9b3091054c742840 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 6:20 PM, Ted Lemon wrote: > On Apr 5, 2017, at 4:16 PM, David Farmer wrote: > > I'm just saying what George Michaelson said, in a different way; hosts do > (a) or (b), and routers do (a) and (b). > > > Okay. I'm not objecting to that. I am asking why it has to all happen > at once. I.e., if we have an opportunity to make (a) MTI right now, > should we take it, or should we not? > We are working on the document, "Requirements for IPv6 Routers" draft-ali-ipv6rtr-reqs-02, and it I think it would be good to get this right the first time that why. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a1147922c9b3091054c742840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 6:20 PM, Ted Lemon <mellon@fugue.com> wrote:
On Apr 5, 2017, at 4:16 PM, David Farmer <farmer@umn.edu> wrot= e:
I'm just saying what=C2=A0George = Michaelson said, in a different way; hosts do (a) or (b), and routers do (a= ) and (b).

Okay. =C2=A0 I'm not = objecting to that. =C2=A0 I am asking why it has to all happen at once. =C2= =A0 I.e., if we have an opportunity to make (a) MTI right now, should we ta= ke it, or should we not?

We are= working on the document, "Requirements for IPv6 Routers"=C2=A0dr= aft-ali-ipv6rtr-reqs-02, and it I think it would be good to get this right = the first time that why.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Tele= communication Services
Office of Information Technology
University of= Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell= : 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
--001a1147922c9b3091054c742840-- From nobody Wed Apr 5 17:06: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 4331C126DFB for ; Wed, 5 Apr 2017 17:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sbWrJVagFQ0K for ; Wed, 5 Apr 2017 17:06:02 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 CCD251293F5 for ; Wed, 5 Apr 2017 17:06:00 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id x125so18977251pgb.0 for ; Wed, 05 Apr 2017 17:06:00 -0700 (PDT) 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=m08b6IYu6SATB/p4YSswAelAgAndrnWgEv5ov9dhzZk=; b=quKn7wHV1ahhmlijQvvIy1O2lf8TprsLDs9n177ueiTxm2D7jGZRSEXUS4ssEWLO9S eUMU4hdkrsPH478rhFoK+pw42lfoZoXQL7uEj92ph1EoLemLn122LC7U14DrRHIDxbgW XWGLiBjrCMshN0K6c70dJh/t/iIBks7bWST3v9mz5lR5Ut5mWUWDld1w/vPBT6kHZl/T QuJaBFVhnNG4fpAQMgfuPoKEOsQhYCL5FcW0KFSWSDBlVCz21ifutIjMk3s8/tRA8vuc eRFDUefTL+EdBtHfbbBBef7KTO+lRx7f3p7wFNtNeaXfdd4KIwSocMOe96huPYVBBWLn lHYQ== 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=m08b6IYu6SATB/p4YSswAelAgAndrnWgEv5ov9dhzZk=; b=f3PFxFC09AdEFvE48msW8WFABf6LcXZPAmCLcsOmnwvyC7bqNf0NHHQkSFnA6So/zB Rhky+itvUUuFO/yFkDchzzE/hN9Z893tN7kWL7eKd5b5khn/3VmafWAel4I8pKGCADb/ FgQxC0J60xMqfB3Bvlf3yYFvjs6pXbxQaJ2/fEsmujucKqL6GmIe/27tVw2ZdaA/X3U9 7SHbkOZbmfbxAeOKQv97HZEvtuTZsV4jf+vNLaBD8L9ysBxYwvVAKDhE1f09tCHinUti 79PqUCwOPHONFToaEgRuj/5u3gIXFAkiGzYFY/DtNBfthxLS9f554/Z9nPnp2e8BwvUw Y3WA== X-Gm-Message-State: AFeK/H0zlYrJ1auAuXahTqQDaTw0XrSPozqMmj/xH0ZEI1EZ1gRmmDc/XxwrUsdtKx6+Dg== X-Received: by 10.98.159.149 with SMTP id v21mr31472197pfk.57.1491437160363; Wed, 05 Apr 2017 17:06:00 -0700 (PDT) Received: from ?IPv6:2620::b60:17:4822:af74:a02a:54d? ([2620:0:b60:17:4822:af74:a02a:54d]) by smtp.gmail.com with ESMTPSA id r12sm39560989pgn.26.2017.04.05.17.05.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 17:05:59 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9BC86CCA-D138-4A18-B4D6-29DC89FD4502" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Apr 2017 17:05:56 -0700 In-Reply-To: Cc: Philip Homburg , IPv6 Operations , =?utf-8?B?56We5piO6YGU5ZOJ?= To: David Farmer References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 00:06:04 -0000 --Apple-Mail=_9BC86CCA-D138-4A18-B4D6-29DC89FD4502 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2017, at 4:57 PM, David Farmer wrote: > We are working on the document, "Requirements for IPv6 Routers" = draft-ali-ipv6rtr-reqs-02, and it I think it would be good to get this = right the first time that why. Right, understood. So do you know what text to write to require DHCPv6? --Apple-Mail=_9BC86CCA-D138-4A18-B4D6-29DC89FD4502 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 5, 2017, at 4:57 PM, David Farmer <farmer@umn.edu> = wrote:
We are working on the document, = "Requirements for IPv6 Routers" draft-ali-ipv6rtr-reqs-02, and it I = think it would be good to get this right the first time that = why.

Right, = understood.  So do you know what text to write to require = DHCPv6?

= --Apple-Mail=_9BC86CCA-D138-4A18-B4D6-29DC89FD4502-- From nobody Wed Apr 5 17:09: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 3521E1293DA for ; Wed, 5 Apr 2017 17:09:51 -0700 (PDT) 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=algebras-org.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 1Nte5Xv1YL0i for ; Wed, 5 Apr 2017 17:09:49 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 03BEB128C83 for ; Wed, 5 Apr 2017 17:09:49 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id d188so23767565vka.0 for ; Wed, 05 Apr 2017 17:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0yIu1v6/1aJHc7J8bZW6KM5AA4Edxj65q3rMo0n9T7w=; b=CbuV8KYQkXPcWE9+uLBEC7CNyI5XaXxnLU5ZcPrF0sPf6TfP4OCa/ZfSOln3lmpjU0 JfLv60k1N3BxapStAtE0xkTKPGwMWbQt1ql3vRozi1goZdINAWNHfnCiia+f/HBkHWXl lyTvEiwJRwS2vj5nvXzTOcvVdWymWyLUgrJ2+3bq9epotaHiupASPBrr4GsSYq+KuTXS JWoc/t2Yh0L8hqHfcSFBDVV+dfrzeya4rq24OMX6GA5YQWPXHB9dm1nS7j0qr2+08YNk pz8XCknfe4wwd/1lnLmKsQkev8tk909rPV/GMc0yeju3mttysEAbkeUTKrGAu+T4eJyp VQXw== 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=0yIu1v6/1aJHc7J8bZW6KM5AA4Edxj65q3rMo0n9T7w=; b=En8cctmepb4N1QU+v9bmnTE7f9xMwxRCbRGnZUIIVZTArRiRYIEc4EubZpJ90NwRsf t6Ew/Nw4jFWlbhTD57IWOVz7GI4j1I8r+nFAumSO2woPOcuKlwdbk2DXYmsjIyqtoUVp zWQARB2pRQ7nKfLj/Vwvy/x9y8Z+Swk14TKwzleSfJg807UFhc5qCEINsk4b+nlYP1Hg oMy0uhUZ2Yig1yPH8mFTf10tchaYZVmSfgzEcHdSayJr1+/nSbm9IND9EFZjAGLx5S3Y LkeHcluEZ6GkvTXJtGeWBqgZkx7kjDzFXBVMGfqGvwojQivx2yftQUCQKtIDY0I51LBp CNRg== X-Gm-Message-State: AFeK/H0jSNzFyxY+QvLIN8EjunglK68FVtpoX1GJup/LblOCewspKH/JkybmxnmWbAa2v4PQHGqFiVKrS7kSqA== X-Received: by 10.31.67.209 with SMTP id q200mr14603291vka.43.1491437388029; Wed, 05 Apr 2017 17:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Wed, 5 Apr 2017 17:09:47 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:d9d1:217a:5ec2:b6cf] In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: George Michaelson Date: Thu, 6 Apr 2017 10:09:47 +1000 Message-ID: To: Ted Lemon Cc: David Farmer , IPv6 Operations , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 00:09:51 -0000 I'd be heading to 'MUST implement, SHOULD be configurable MAY be turned off by default' type choices. * it has to be there as a choice, to be able to meet the client single-implement logic * it has to be controllable but we don't constrain how that works. maybe people make burned in decisions * it doesn't have to be the one which is on at boot. On Thu, Apr 6, 2017 at 10:05 AM, Ted Lemon wrote: > On Apr 5, 2017, at 4:57 PM, David Farmer wrote: > > We are working on the document, "Requirements for IPv6 Routers" > draft-ali-ipv6rtr-reqs-02, and it I think it would be good to get this right > the first time that why. > > > Right, understood. So do you know what text to write to require DHCPv6? > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Apr 5 17:12: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 DFC541293DA for ; Wed, 5 Apr 2017 17:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 X5Rp5Gn1Jymv for ; Wed, 5 Apr 2017 17:12:48 -0700 (PDT) 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 26015128C83 for ; Wed, 5 Apr 2017 17:12:47 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id x125so19103568pgb.0 for ; Wed, 05 Apr 2017 17:12:47 -0700 (PDT) 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=noc234MrPGVFNTlLyDoIcShdajqnXiFI/fy/u8J5MlM=; b=IzQzy5tak2wP+/si9vb4IoCcnxfY9KjsLZvD3nPnGpgthZfvCMXVLsnLCUZB0UaZRz ZCMxJymckAYinsVqArkEjLvXjDsxhG9WxWAyfjG6+3uLN/ljK6ADqhG+VVPxUD8FWEqw kpNarqF639tFfkdfj1Nhb9GREEsZ8coHI6FecmdwGDsX/fLk64Uy7pLuQwytvYkk6aEL eCzuigzLuJ+dVYklO/SVg7zyr0UinnBF1q91x140D6XzqUsfv0fJkjoF5p1K6Y8zjI3f 8oHZ44a9Txuib06ZxcFXiogwXhkjKpoUx3FoSCgJMtnGBYLUr9DBh0usbDC1/078EVUM JpcQ== 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=noc234MrPGVFNTlLyDoIcShdajqnXiFI/fy/u8J5MlM=; b=KW2HNJ1me+UZh0LTllRG2RGiBn+fUL66hQwIgXC7uJcmBa8CVsoZLYVsNPvrnFJbSQ b0R0GF6rpMaraTouqWkon9PpqTEnbwULHf0xxj9oeGmakZdxFuRy9Ya++Y4LTCjGQXLx t19MpkyVN0KncRXY2No112O1ocTEapStoueMshsn9im9ar19obOD0tDLyZ3m4iBUclFa mvF005b2z8COU+dbanANu7/Ujp6mb+YEWYbzGyg5JVLmOVTehVIXt3oLwzA1JbDOYvAX ukpenNamTMrXS6sThTrGNYopW6+nD2jfl163EaiCF7iNxIqeIM6yfNRR3KGmhXW6FQsm PIDw== X-Gm-Message-State: AFeK/H2jZiXZ2optRQB8oWvZarXUAaMRO+487zIvfB6Z7XByzH10Ux4hsGhmT5+2ijT3kg== X-Received: by 10.84.138.193 with SMTP id 59mr39975944plp.167.1491437566782; Wed, 05 Apr 2017 17:12:46 -0700 (PDT) Received: from ?IPv6:2620::b60:17:4822:af74:a02a:54d? ([2620:0:b60:17:4822:af74:a02a:54d]) by smtp.gmail.com with ESMTPSA id n65sm13577386pga.8.2017.04.05.17.12.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 17:12:46 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A50079E0-E358-4BD8-B261-BA675157D1FC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Apr 2017 17:12:41 -0700 In-Reply-To: Cc: David Farmer , IPv6 Operations To: George Michaelson References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 00:12:50 -0000 --Apple-Mail=_A50079E0-E358-4BD8-B261-BA675157D1FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2017, at 5:09 PM, George Michaelson wrote: > I'd be heading to 'MUST implement, SHOULD be configurable MAY be > turned off by default' type choices. This is a specification. Can you tell me what specific text you would = write? I'm asking because I don't know, so handwaving about MUST and = SHOULD is kind of off-topic. I apologize for continuing to hammer on = this, but I think that there may be some misconception that this is just = a line of text. It's not. --Apple-Mail=_A50079E0-E358-4BD8-B261-BA675157D1FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 5, 2017, at 5:09 PM, George Michaelson <ggm@algebras.org> = wrote:
I'd be heading to = 'MUST implement, SHOULD be configurable MAY be
turned off by default' type = choices.

This is a specification.   Can you tell me what specific = text you would write?   I'm asking because I don't know, so = handwaving about MUST and SHOULD is kind of off-topic.   I = apologize for continuing to hammer on this, but I think that there may = be some misconception that this is just a line of text.   It's = not.

= --Apple-Mail=_A50079E0-E358-4BD8-B261-BA675157D1FC-- From nobody Wed Apr 5 17:42: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 68742128C84 for ; Wed, 5 Apr 2017 17:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.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 wcW_1a4j7oMT for ; Wed, 5 Apr 2017 17:42:12 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 54CC4127B31 for ; Wed, 5 Apr 2017 17:42:12 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id s68so24549743vke.3 for ; Wed, 05 Apr 2017 17:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2qNpSIuZWxKrVBxDZGaf2H+8BWQePFjHFTm6reO+Dt8=; b=sFdzhnddM3TYPcdpjNoEBjk65qyzXZ0yLIfp9N30SitpX2860+2TqRAG0w7bLoCJ3n Cg9pxayOFphF76AEzlk4AQF8odO0cXdQMLCLfflJBDIyiDS8W0UMPw+urb5jnWyTEG9k qdObvzW/yF11yCf5hBlrFWTr3blQy7n6JX/KR2SIMvIFA0E2Vbpv2ixSCxBN4Ow9k+Qq Ln3LXQER6FFWJdQqCZfyloHdbEpTGBpFgB+cJEGtS2ZCNXonJP0DILT2l8g8hsgKV+E2 uxYj9Mdh/Zonb+5eI1CN/UELvnExIFunKXRKxehk0c+yMNIq7POw7MPqsAZYOpGQTM6Q 6VlA== 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=2qNpSIuZWxKrVBxDZGaf2H+8BWQePFjHFTm6reO+Dt8=; b=YVNfl/RscErBASL7ku36Fan1kp9H6Ur3FMCepoz1WNEBDikGNPG1Ra/eh7g5G5bnRG Otlcg4QD9a/6iOaafUo/3OpyKJpPcXPpM3k68YY4gCtCNQDxxqRFoNaAUncPydfBMme4 67SxD632+nTTcdsfWOhdNVCYOt5EcCWrA7scBh6D7uEPulM0WHN8Oy4ocX+v8urx1r66 jyOMkc7mWhrA01usuSKU/Z1D5R0dyMqli1xGHpqmEFdq6v3TO88hcmVesiCoRWlAXxHZ reBXsY4iyBwmUdWiLs3JeT5iZt2zx08VAaDFufsr9fO2Ft0lC8VbQyPeGo1GJqai28ik Ub2g== X-Gm-Message-State: AFeK/H1qdjFx5PvKIl3yCKNqt3fWG8pz9cdU4aZNalkhHuhdOAaZtdsUpBJ/Vt5cOEfZ2fSauzd4w8XNwG+MOA== X-Received: by 10.31.85.5 with SMTP id j5mr14113206vkb.167.1491439331293; Wed, 05 Apr 2017 17:42:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Wed, 5 Apr 2017 17:42:10 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:d9d1:217a:5ec2:b6cf] In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: George Michaelson Date: Thu, 6 Apr 2017 10:42:10 +1000 Message-ID: To: Ted Lemon Cc: David Farmer , IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 00:42:14 -0000 You're right. Do you go further to say that my failure to be able to write specific test is a strong test its a bad idea? I guess I was heading to support what Tim Chown said 11 hours ago: > a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and rout= ers; it=E2=80=99s not a significant implementation or running cost to any d= evice, and an operator may still choose whether to use it or not > b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in rout= ers, noting implementation on IoT and constrained devices may not be realis= tic [...] but that managed enterprise environments will expect other config= uration information beyond RDNSS and DNSSL to be available, so that local s= ervices can be used [...] it=E2=80=99s up to the operator to enable it Tim owns that language not me, but thats what I think I'm heading to suppor= t. Are there words in that, which can meet normative requirements for a standards document? -G On Thu, Apr 6, 2017 at 10:12 AM, Ted Lemon wrote: > On Apr 5, 2017, at 5:09 PM, George Michaelson wrote: > > I'd be heading to 'MUST implement, SHOULD be configurable MAY be > turned off by default' type choices. > > > This is a specification. Can you tell me what specific text you would > write? I'm asking because I don't know, so handwaving about MUST and > SHOULD is kind of off-topic. I apologize for continuing to hammer on th= is, > but I think that there may be some misconception that this is just a line= of > text. It's not. > From nobody Wed Apr 5 18:28: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 D6ABC127058 for ; Wed, 5 Apr 2017 18:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 tLtKtPYwVR7v for ; Wed, 5 Apr 2017 18:28:53 -0700 (PDT) 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 BD2C4124BE8 for ; Wed, 5 Apr 2017 18:28:53 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id x125so20530715pgb.0 for ; Wed, 05 Apr 2017 18:28:53 -0700 (PDT) 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=Som1+PlHvTM+8Pk/9dOBaeyvyxOz6KeBTtAvel1x+gQ=; b=SyygdUFjlSRc1Ji9hdEmMuEKjyYLOqmHQAeFH1tRWCWnkh5/dtpPhxZdcd/GgrvpYl 3ZwpbD6SfjJpXChwlF9cexqag6n0zHKo9bnkgIgyRigsPgvjWXPEshZIy4ItJxS/eZQO NSKFwPaGHZVn8iROdkGKzTRp/fPXCeDvqU8y55/T6vk+gHShjyL9IRzRrKXQvS/BNDeO alnWI2lOcLwZyZ+bO/2xrNF0In9ovj+4HoH37zcmk1kFHh6ouV1/miQcnpfGDyIpStY3 k8tWFvMdot+YdiXj747GT6o+jEXPfLCgNpM7uVQ8vDJJAETnPh7cNzF5ejEikzmmWIxg fKmA== 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=Som1+PlHvTM+8Pk/9dOBaeyvyxOz6KeBTtAvel1x+gQ=; b=tmqXy1T06Zfk5MuzVsw9wbFMbhI+Kz6KYLW75de1/to/G9KJ3Slnsiou0QkSm+GUl2 BvjmEr5NpqZpcdsi9Dp/BJFICSZOPFUQ4y52BEL6BL4ZzIN78EIGhIsME23paeNLcKgV Qq4qQYfqWmV4kRqMNtNUtiJmj8jz3yDdjklcCeAWkprqfx3zk6DL4hvRzoL8EpIxW4jt yPRmtcvc0w8mId2jWnxqQh2DRcZ1objgiUhNF7LZ7OOahUGPWxXz5MJ9LC9N+VrOSwfb Di3Jf4F/YAeN06pOr5WBntHlqQjwFz0vAnTNR/E80V2cNhqZ//4jCr536R4ClGfbGkmg Cecw== X-Gm-Message-State: AFeK/H3S9Oj/ViRv5sz5RNc7iF47xhAIiwODKjyzdkZZKcOGYOR+uvEvielzPPPrkO5M8g== X-Received: by 10.84.253.15 with SMTP id z15mr39920313pll.142.1491442133331; Wed, 05 Apr 2017 18:28:53 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-223-134.public.wayport.net. [64.134.223.134]) by smtp.gmail.com with ESMTPSA id t15sm84104pfl.25.2017.04.05.18.28.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 18:28:51 -0700 (PDT) From: Ted Lemon Message-Id: <86E7BEF7-A807-4C3C-A41F-F6E8C9B3C51F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5BA7650F-83C3-4F5B-9512-2DBD103ADB48" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Apr 2017 18:28:46 -0700 In-Reply-To: Cc: David Farmer , IPv6 Operations To: George Michaelson References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 01:28:56 -0000 --Apple-Mail=_5BA7650F-83C3-4F5B-9512-2DBD103ADB48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2017, at 5:42 PM, George Michaelson wrote: > Are there words in that, which can meet normative requirements for a > standards document? No. In order for it to be a normative requirement, I should in theory = be able to know what tests to write to ensure that I am in compliance. = So: Are routers required to implement a stateless DHCP server? How is that server configured? Is it required that the stateless DHCP server be configurable with a = different set of RDNSS values than the RA server? Is it required that the two servers' configurations be the same? Is it required that the RDNSS server setting be configurable for both = DHCP and RA with a single configuration parameter? What M&O bits should be in the RA? Should the O bit be set if DHCP service is enabled, or are the two = settings independent? If DHCP relay is supported, and stateless DHCP is supported, does the = router relay for stateful requests and answer information requests = directly? Does it do both? Must the stateless DHCP server support parameters other than RDNSS? These are just the questions that pop off the top of my head. The = answer for RDNSS/RA is "must support, must be configurable." That's a = lot simpler. I think that Tim's text is a great statement of intent, but if that were = all that were in the document, I don't think we would have made the = situation better. --Apple-Mail=_5BA7650F-83C3-4F5B-9512-2DBD103ADB48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 5, 2017, at 5:42 PM, George Michaelson <ggm@algebras.org> = wrote:
Are there words in = that, which can meet normative requirements for a
standards document?

No. =   In order for it to be a normative requirement, I should in theory = be able to know what tests to write to ensure that I am in compliance. =   So:

Are = routers required to implement a stateless DHCP server?
How is that server configured?
Is it = required that the stateless DHCP server be configurable with a different = set of RDNSS values than the RA server?
Is it = required that the two servers' configurations be the same?
Is it required that the RDNSS server setting be configurable = for both DHCP and RA with a single configuration parameter?
What M&O bits should be in the RA?
Should the O bit be set if DHCP service is enabled, or are = the two settings independent?
If DHCP relay is = supported, and stateless DHCP is supported, does the router relay for = stateful requests and answer information requests directly?
Does it do both?
Must the stateless DHCP = server support parameters other than RDNSS?

These are just the questions that pop = off the top of my head.   The answer for RDNSS/RA is "must support, = must be configurable."   That's a lot = simpler.

I = think that Tim's text is a great statement of intent, but if that were = all that were in the document, I don't think we would have made the = situation better.

= --Apple-Mail=_5BA7650F-83C3-4F5B-9512-2DBD103ADB48-- From nobody Wed Apr 5 19:55: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 DE710128C83 for ; Wed, 5 Apr 2017 19:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, HK_RANDOM_FROM=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=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 E7eA5MhM7wxv for ; Wed, 5 Apr 2017 19:55:19 -0700 (PDT) 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 5D3141270FC for ; Wed, 5 Apr 2017 19:55:18 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id r69so26706992vke.2 for ; Wed, 05 Apr 2017 19:55:18 -0700 (PDT) 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=jFtzQC9/7SfyWkaUMkDNMgnXFV77Y6r4BYVgbRgm1uQ=; b=WnpSBfK8rwk4/Da4qdw/oz+gBCB/CpcGL3XjhTHF5dmFHI40Mloe3agLhnc4idyXr+ hIE/8k5MpWWofon3w41Tc/bfsIgJtQJJ2Uqc0xelsgS7JhZGkGdKv44/QhKgVVUblQMV 6cUbiJ8yLqZsMiWMYQL0XqrQLYkGYPE9vncY26/78kDMFOmvcrFubmTG25MQw44y7Gxh 0PDTPl/wAHGgXKcVEEk9nfe3rP+y3WRVij5GxU7nfg76yNPScfvHzG7TeTS1oZpN3GJh IQVpWZH02huMHVS8mRjjjI2ZqfI3UF4Ymxs09JzatSe66GX3HGuYus5dEd8vJ+sk9rkG DELw== 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=jFtzQC9/7SfyWkaUMkDNMgnXFV77Y6r4BYVgbRgm1uQ=; b=dLpkqMG5yQGoA+xobdd2wCrzBHmHpzSKgfoWYjIsQQXdtQX6xrzoK+62Es+eLDD/Td Ca7UBCm9OXX5RjbTByMe4H9tJT6BisRxPxQUmm4LD4A+/uci13NLYsQ6trznyj72C2ac A5Ppu/eJrdsVFW9DE93ld0MahS2eGLmtGJHUjzVVDFxnPisaXaVIVVNdwSYDyprCrH37 2v+9OL0dtd/yYHA74INTFsqTHUoPR0+TkgGhkPevDKhnROhlX5fxMbK1p96Q7UcIIjqt nBroaAhFJaW9RjVDmreC5eXuuaP0zmehywQYbQNYQvVuEFdPyVfuIt/kDn+eVPxJgOnw tW1Q== X-Gm-Message-State: AFeK/H1+WfWrjgE9OCPQux5f99Y84Rq+oR6je1v/ueT26hGuV015F0em5tOjoGSS1K+397xxXvlxyAq1/cREQg== X-Received: by 10.176.83.124 with SMTP id y57mr14222587uay.141.1491447317365; Wed, 05 Apr 2017 19:55:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Wed, 5 Apr 2017 19:54:46 -0700 (PDT) In-Reply-To: <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> From: Mark Smith Date: Thu, 6 Apr 2017 12:54:46 +1000 Message-ID: To: Ted Lemon Cc: Brian E Carpenter , IPv6 Ops WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 02:55:22 -0000 On 6 April 2017 at 08:04, Ted Lemon wrote: > On Apr 5, 2017, at 2:49 PM, Mark Smith wrote:\ > > Devices like this Chromebook are getting their time by having > hardcoded, Internet located NTP server addresses in their firmware. > There are potential trust, privacy and reliability issues with that > sort of model. > > > It's probably got a domain name, not an IP address, encoded. And it might > even have a pre-shared key, although that's not ideal. And it probably has > an RTC with a battery, so that it can reject really weird values, closing > the window of opportunity for replay of compromised keys quite > substantially. > > So in practice, all it needs in order to use the network is a working > default route and a pair of working DNS resolvers. > If this is a reasonable or ideal end host approach or model, then I think RDNSS starts to become unnecessary too. Firmware vendors may as well embed DNS addresses. Google already do that with devices like their Chromecast, embedding 8.8.8.8 as the preferred DNS resolver (if that address is unreachable the Chromecast switches to using the DHCPv4 supplied DNS resolver). The approach makes sense. If you were a vendor of these sorts of devices, you want to minimise the possibility of 3rd party's service impacting the perceived performance of your product - Google wouldn't want their Chromecast product to look bad because the local CPE or an upstream ISP has a badly performing DNS resolver. It seems the following is a recent example of an application using NTP directly (Snapchat), rather than trusting the local host's clock. This seems quite odd to go to the effort do, unless there had been enough cases where the local host's clock wasn't accurate or accurate enough for the application. "Recent NTP pool traffic increase" https://community.ntppool.org/t/recent-ntp-pool-traffic-increase/18 I'm pretty sure Microsoft and Apple too default to their own NTP servers on their respective desktop OSes. Perhaps this indicates a trend where host and application implementations aren't going to trust the local network's services because if they perform badly or incorrectly they'd make the host or application look bad in the eyes of the device's non-technical end-user. Regards, Mark. From nobody Wed Apr 5 20:30: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 0F1521272E1 for ; Wed, 5 Apr 2017 20:30:39 -0700 (PDT) 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=algebras-org.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 ZuoNwskQr_Q3 for ; Wed, 5 Apr 2017 20:30:37 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 E7517127735 for ; Wed, 5 Apr 2017 20:30:36 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id z204so27303010vkd.1 for ; Wed, 05 Apr 2017 20:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5S+RG/vLQHOwRaxiyFP6bovz7mChizkDUklUpik9uCs=; b=lzx2oMHzS4rFiijL7DEcNGBdwE+e5L13/46lHi9vcpaaSdu7P2sBlLIdkSb2TWzWhQ Sw/Wy21A+6NegqYNDtmtdw5x167JPem/RPgiWWGe0Ye9qrHGixSv4Ywj2z191A18EL6u vlTcUzpoVB7fRIuXUvLJkyyNY9rqeksf5RCchNCN1hqilZfM59OFOVb8UG2TMUBgJIRn 8aXB8H2RAxXiQnc19EFZ1NWWe8SlJYPxA6s5BP9zt9osFppVmCLKdr56ACKPEmlSSZDi Jt1PsyyJly6QnG4YDHWKA9IOG9CNYyBCWH2Qk412G/K8XJmSXLEnJ5oswX/Ijn2DfJTB ZCMw== 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=5S+RG/vLQHOwRaxiyFP6bovz7mChizkDUklUpik9uCs=; b=QBeZFxeT7LK9zZnfxk4LkFFPpaADVQA0xAG93bq3dm4LcLCc3UTQ9ygHxmpSkAzQ3w t9hTC3luRV+aVaAnbb9Buxpiit63keIW1R8H7y4JnVTQNc63yEelUUKzHuGQkuN8H3HI O6noQdIuuKyzVUrb0FXOqpQkhmipmiGZOXESOEmujqpLJNRZ8WcU0mIAZuoHxlkdT0/T 5y5JGmvM2tWn3kdP3Mx0uHjT0ZJHlfd3s2pPL87ZjKAKmfASnobmJ2meN6OF2mwotNag Dlisg4NR82GGJL9YOwxN15vycc+5iCKIkQhOqLGAze/MPIYo2rQNwYWoKVHYOGxgrE7e s6EA== X-Gm-Message-State: AFeK/H3LmZzPs3hv7D8gi32aC0c6g/6QbhWL2kG+Hxl2LSAcAZKJKb03tLCaplYxk8e30irxlixbSjlTY3YS5g== X-Received: by 10.176.84.147 with SMTP id p19mr14041417uaa.35.1491449435979; Wed, 05 Apr 2017 20:30:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Wed, 5 Apr 2017 20:30:35 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:d9d1:217a:5ec2:b6cf] In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> From: George Michaelson Date: Thu, 6 Apr 2017 13:30:35 +1000 Message-ID: To: Mark Smith Cc: IPv6 Ops WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 03:30:39 -0000 Sorry Mark, but that feels orthogonal to the matter at hand. It is true that vendors do this, it is true that large vendors of closed ecologies do this, it doesn't alter the normative standards drive to specify what should or should not be done, when systems want to ask for locally supplied configuration. So I don't see your comment saying anything material to what a standards document would say, because the decision not to honour RDNSS or related definition of local DNS service binding is not going to appear in a document. Unless you are seriously proposing text for a third option which goes to 'or.. if you chose not to do this then ignore all of the above' -G From nobody Wed Apr 5 20:32:24 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 4E01B129329 for ; Wed, 5 Apr 2017 20:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8NZ44QaYWVAx for ; Wed, 5 Apr 2017 20:32:19 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 749A4128C83 for ; Wed, 5 Apr 2017 20:32:16 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id w43so39627368wrb.0 for ; Wed, 05 Apr 2017 20:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:reply-to:message-id:references:to; bh=6QaNxVE8839qbDnob4IT7pLBq6BWPFMeFxZnVpyZop8=; b=OouviM0oqUw8M0q7xV57/x76BDrc18C0xqBe0D3o05Kw3i2gLvUm3bfte74x4IwfhX MG9Ozbu9sgJIA5VtQZY1ZONZs5vgb64Rw/wh2Y0okR5tvSlE3AbGW2aYAgBycc4Se5eZ gE5Ajqq3sjQXbGHvIojrog6LUcZyjtg4E+bCCKSfpEbz/9g46Y0nzIzb57+LfF/PFLtp OyZv3ll9ONp4KVd8wXBVEnVZKqut2qPqCVeQkefZIVdYbCRBKPE9EWF1E9hkjocTPjKN RCq0UIZkkVkjsox0Y9f0LU3D0hLeTz3oDwaQz82JQNF4SYQeWKdhMtbu+V8RzoOh2nJG ZLMA== 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 :content-transfer-encoding:reply-to:message-id:references:to; bh=6QaNxVE8839qbDnob4IT7pLBq6BWPFMeFxZnVpyZop8=; b=ovHUtqb2tky86u36xEXqUkoIuEwzLf880P0aAgyzk+nhR5Q5G7FArwOpjPAXR9riMW hLORRyY8O6+eAwf9nCZA3FGwnJdaAzIrOMcwzol3vtmWtXEPswtEO4ih7MUzLw2HJ2n9 KqH2IVBQNPrfX+vDwIz67BrmtR0iFG5eB9BRiM1OgECzXcG5Pyb8EwgkJWaDVUPoF/Vv D4PaZswrJnCldfqHFeajApPrZ1JCaoWVbYb9u/aXQfNEeY9RA02tYuFRhUF05D0oTlRq Vj5bXlTvWCOgjaymvCt65LMSLWjrezdxCvOkYq0vw9JTBlAi3B67ZQZTmsFL+IJAHN9R 9gzQ== X-Gm-Message-State: AFeK/H0/1YXASJXdr2kS6+EgUVfIY/hp7kCeQ+Ze4KQZL48pXxGDSzRl217YNK4xwtRGow== X-Received: by 10.223.162.147 with SMTP id s19mr29515724wra.1.1491449534866; Wed, 05 Apr 2017 20:32:14 -0700 (PDT) Received: from 233.66.20.149.in-addr.arpa (233.66.20.149.in-addr.arpa. [149.20.66.233]) by smtp.gmail.com with ESMTPSA id m14sm352005wrb.13.2017.04.05.20.32.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 20:32:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> Date: Wed, 5 Apr 2017 20:32:11 -0700 Content-Transfer-Encoding: quoted-printable Reply-To: V6ops Chairs Message-Id: <82DC3B74-BA76-4B8B-934D-A98236EF3479@gmail.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 03:32:23 -0000 > On Apr 5, 2017, at 4:00 PM, Ted Lemon wrote: >=20 > Who cares? I just want something to be MTI. Getting DHCPv6 to be = MTI requires more work than getting RDNSS to be MTI. Insisting on = "both or neither" means that it has to be done in a single document, and = that document probably won't be this document. OK, let me take a virtual hum. The reply-to on this message is = v6ops-chairs@ietf.org, in order to not deluge people (and the archive) = with "+1" responses. I'll summarize next week; the time to respond is = now. Do we agree to, in some document, make RDNSS and Stateless DHCP = "Mandatory to Implement" in the router, with a view to supporting both = classes of networks? Note that in posing the question, I paused a bit. RDNSS has to be in the = RA, and therefore in the router that advertises it. Stateless DHCP can = be in any system as long as folks can figure out who to ask. Stateless = DHCP is a profile of DHCP, sez the RFC, so I presume that follows the = same logic as DHCPv6 itself. I'm asking very specifically whether the = *router* has to implement both, or whether if one wants to have = stateless DHCP, one could install some other system for that. Very = specifically, *what* is mandatory for *whom* to implement? Four possible answers:=20 (1) RDNSS and Stateless DHCP are both required (SHOULD or MUST) in the = router (2) RDNSS is required (MUST) in the router, and if the network wants = stateless DHCP, it could implement a router that implements it, or it = could install something else; the router MAY implement a DHCP server, = and that server MAY/SHOULD/MUST implement whatever the DHCP documents = say it MAY/SHOULD/MUST. (3) Stateless DHCP (SHOULD or MUST) is required in the router, and if = the network wants RDNSS (MAY), it could buy a router that implements it. (4) The market decides. RDNSS and Stateless DHCP *MAY* be implemented in = a router, or stateless DHCP could be implemented in some other system = (present state). Note also that, to me, the question answers itself. But I want the WG's = viewpoint. The next question is "in what document". https://tools.ietf.org/html/rfc3736 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. (Format: TXT=3D18510 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3736) From nobody Wed Apr 5 20:45: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 8181C120727 for ; Wed, 5 Apr 2017 20:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jdUnOKP3AD20 for ; Wed, 5 Apr 2017 20:45:32 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 DDD3A127735 for ; Wed, 5 Apr 2017 20:45:31 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w11so39097325wrc.3 for ; Wed, 05 Apr 2017 20:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:reply-to:message-id:references:to; bh=A40g9EloWTAJn2OeZ/9wvqyo2le5ji1cbwkfIwUegr4=; b=sAsaY+YH9sPNCHr5zokf0/Ey2ayFimaU2Qjad6u5vNf/erLz8lTHxq76WbGwr5TCBH yyKh/DAJgGPpJKlAkQ2pguLD462MM+gboKV29lWynUIWYPxRJ22aVDDJMtu5RKEVcP0b OGyVilmd1vDLkpin1RdCq2tWR7wEU40fDYKBCkh6xInP1cixQeXfnzNjhieRhBzi9dlq mcyEYpUbkSxFFoSf/C174Wv7Up4ggRkiYuXi5cUPaw6VLdvHQ5xgWhwCNQG6ecpRobog v53mPg4Ub2JfATa/Qchz2zuwOJhoSKA/h+1/gH9p440msQBoV8ey5rscS4NvgNLe18PQ 0n3A== 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 :content-transfer-encoding:reply-to:message-id:references:to; bh=A40g9EloWTAJn2OeZ/9wvqyo2le5ji1cbwkfIwUegr4=; b=bcmnFYJSrh1eV2e/2pz3WUxGvGG6ErwsN6I6paKqiKpdgl/8tJpIFacEPqfsu2a7/5 RlfqdzSGqodWyJ0Gv9jaLpmZPUh5+j7tV57WpEDAISlFVnqZ34sSqjLKu9UPm4eJSdNk MtNkbJFmA8aWjcAtUmsnvfFB1fmm93VgU45z4nBpDOK6VX1elyG4oPKr8lIEqjUSNY+D VVMS7/f6N3MAnYvaTlohB8ohNAv7QFUrWyDuMiHxQEFqiNGwTveRJX3kHf44jRK3f7V2 8cfQ61uaSLwXV5Z5biEIxoS5VVZZGtCdEDaQdvIv/I4a+NGs35x0QgFn52kR7x7sHrST mz2A== X-Gm-Message-State: AFeK/H3QSmyvu2ngaOZFqdjXGikZmLdsAhFysbZzkDpowtbGFvDenin1nDrTtMP1Vu6YJg== X-Received: by 10.28.27.14 with SMTP id b14mr21850577wmb.50.1491450330271; Wed, 05 Apr 2017 20:45:30 -0700 (PDT) Received: from 233.66.20.149.in-addr.arpa (233.66.20.149.in-addr.arpa. [149.20.66.233]) by smtp.gmail.com with ESMTPSA id 32sm387497wrr.2.2017.04.05.20.45.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 20:45:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> Date: Wed, 5 Apr 2017 20:45:27 -0700 Content-Transfer-Encoding: quoted-printable Reply-To: V6ops Chairs Message-Id: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 03:45:35 -0000 > On Apr 5, 2017, at 4:00 PM, Ted Lemon wrote: >=20 > Who cares? I just want something to be MTI. Getting DHCPv6 to be = MTI requires more work than getting RDNSS to be MTI. Insisting on = "both or neither" means that it has to be done in a single document, and = that document probably won't be this document. Let me restate this "virtual hum". Someone replied with a better = question, and now I'm asking it, v2. Again, the reply-to on this message = is v6ops-chairs@ietf.org, in order to not deluge people (and the = archive) with "+1" responses. I'll summarize next week; the time to = respond is now. Do we agree to, in some document, make RDNSS and DHCP Relay "Mandatory = to Implement" in the router, with a view to supporting both classes of = networks? Four possible answers:=20 (1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD or = MUST) in the router (2) A router MUST implement RDNSS, and MAY implement DHCP Relay or a = DHCP server. (3) A router MUST implement DHCP Relay, and MAY implement RDNSS (4) The market decides. RDNSS and DHCP (Relay or server) *MAY* be = implemented in a router. This is the present state. Note also that, to me, the question answers itself. But I want the WG's = viewpoint. The next question is "in what document". https://tools.ietf.org/html/rfc3736 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. (Format: TXT=3D18510 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3736) From nobody Wed Apr 5 20:55: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 437D6127B60 for ; Wed, 5 Apr 2017 20:55:30 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 Q2-l1uHhyOAI for ; Wed, 5 Apr 2017 20:55:28 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 586871270AC for ; Wed, 5 Apr 2017 20:55:28 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r69so27585133vke.2 for ; Wed, 05 Apr 2017 20:55:28 -0700 (PDT) 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=fxl1YEnkHXy5ZElaEOPgRWZp7Fo5cSljTKtrUxWgiRA=; b=oO3J2Y5ADoE0yF4NARn+tXS2me79BwRQYbqm8dGGVc3qmNVCFPaVyThpsO0EJeJaT7 iDS1aUB/47MNN+BKwW/gyC2KduWdD3nFkKdA3LStAp10xEhTA88oyVZAGx/VkLCY69ES ww/Wpjs3quv5xWIo6NpkRZPH83UJH64Y27NMV28ZZCS18aDXmxXM3pMAfY/TCQL+H6Xe 74ZlnLYDW5I3wD4Ry0KQV47+OaHUb8KJAdUEBxk+ICRKu+H9LdLw7iaVgXcb8ac1fc92 39C7SmDpXBG93rFOi6QqoQpQ6n6+YL+evBWlZ3AlwKkeBgMJ5i6Fz1CBts+j6aA5KRcR 2fOg== 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=fxl1YEnkHXy5ZElaEOPgRWZp7Fo5cSljTKtrUxWgiRA=; b=bHUX3w9BZzshtt60HSMS6YK1RVfXx5KV3iM+e7iDCzJVYbibidzYSFsam21/fyvfYR 1t3SuIvFMXyGdbsD4//bcnc8xUtQh3xIROA5hEdHmbUCxDyWpL3KE4mYc8WDY3tKAbV1 obYbhiQ4o3augwbUuvgiFq3lD8Q+vY72I9ImjdUDOQiRjz87cSfDiWT0NIGNcRKnFJWZ pbHsZKxpvHPKGmeHLrYVUzLgjMKk7+PRT5/PAtf2F753k6WaFW9bEBBdxXWOY8enVoli hc8uQiV5NdQQsU49gO2nRP53B+CcHYs8SR+G4+ubQTUmoirrtycPNKYMU7QKgiZ+1sgs KAfg== X-Gm-Message-State: AFeK/H05029J7j3tLzDCUoUcllhIel/lFbTt1dYP5sqDz3jVXpiHMOzIfYrCS3TTgk0N7wIpTUg14akteU8mD3x8 X-Received: by 10.31.60.17 with SMTP id j17mr9895454vka.45.1491450927271; Wed, 05 Apr 2017 20:55:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 20:55:06 -0700 (PDT) In-Reply-To: <82DC3B74-BA76-4B8B-934D-A98236EF3479@gmail.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <82DC3B74-BA76-4B8B-934D-A98236EF3479@gmail.com> From: Lorenzo Colitti Date: Thu, 6 Apr 2017 12:55:06 +0900 Message-ID: To: V6ops Chairs Cc: IPv6 Operations Content-Type: multipart/alternative; boundary=001a11436e50b8ce43054c777a53 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 03:55:30 -0000 --001a11436e50b8ce43054c777a53 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 6, 2017 at 12:32 PM, Fred Baker wrote: > OK, let me take a virtual hum. The reply-to on this message is > v6ops-chairs@ietf.org, in order to not deluge people (and the archive) > with "+1" responses. I'll summarize next week; the time to respond is now. > Is calling a poll - particularly one with four options - going to help us reach rough consensus? What happened to the original question of "do we have consensus to say that RDNSS is MTI"? Have the chairs already decided there is no rough consensus on that? --001a11436e50b8ce43054c777a53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 6, 2017 at 12:32 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
OK, let me take a vi= rtual hum. The reply-to on this message is v6ops-chairs@ietf.org, in order to not deluge people (and the = archive) with "+1" responses. I'll summarize next week; the t= ime to respond is now.

Is calling a pol= l - particularly one with four options - going to help us reach rough conse= nsus?

What happened to the original question of &q= uot;do we have consensus to say that RDNSS is MTI"? Have the chairs al= ready decided there is no rough consensus on that?
--001a11436e50b8ce43054c777a53-- From nobody Wed Apr 5 21:01: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 78C72127ABE for ; Wed, 5 Apr 2017 21:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 caHpg-DRWP6a for ; Wed, 5 Apr 2017 21:01:51 -0700 (PDT) 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 3B414126DD9 for ; Wed, 5 Apr 2017 21:01:51 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id d188so27440057vka.0 for ; Wed, 05 Apr 2017 21:01:51 -0700 (PDT) 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=KtYIZV6Q2J68gfWRjkCQbZqDARgIpLLo8aG5CB8RWL8=; b=tKzKdOdg0PAFsjdbb+nEmYJ0Cum/VGmRWlW9RlGUtSolXsn936nzgeII17Sk3KY4FE 5Rbs40521Aj9Dwap1gvZCB9UStN30kE0qUIdxcZaVwEjPLKJgm2HDv3w77M4dWEEdll7 ZS3ST2cVuCmflwChFq7ioEhUFost0R5gGmEK3zvrta3pbINXP68lA55+KNnF3cSrQGeN eM4SrFdJ9kNTwxDilFfPDhcwjpAsshstXtmXnzDF1oircSZMrMkqXrfu41whM5S97iRY +MJDxgzGLP9/Y7C8DTC1nJYz+KKX+unbPbDiiD6942UdNytZIux9jwpXkUQIEWCmWakQ /YQw== 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=KtYIZV6Q2J68gfWRjkCQbZqDARgIpLLo8aG5CB8RWL8=; b=h6vn5YPm0v5tSdGfPxw/n1HbQvf2dHInQuCRMwXohwyM6Vzvz3tYmV/NKGdVGed/jc XDkLH9DfUsVVJmTr7J7xpeny/uPvqe40XZ4xTQ4UDLCGX954zfRZ6pUnhc7yOZZYyF+7 0TLNdo3tcx7NHj00/8ER5WBYNxDnsQLOWKqV7YLh83w0RCkp4HrdjqoKsEAomaAjfFIv SoG57xui7UBij0fm6LVQxnIdoAynybxHby0fT9eyal+85lckfI+Al7xQ3wQDgkXpeWTA BqEWQdoX65AY6X6aQt27W1np3NOhOtjzI7I6fSLScfbMlRzvQI7lrSG0jpYcQt4JwFaR haQg== X-Gm-Message-State: AFeK/H23HVzJzPlBwSEu1zjtX8hWHNpvxBhOLUq+snKU16Ir5r0WMVilVNn1OGcn6WrbJyZI5mLLhf8Cti8KkdzF X-Received: by 10.176.2.9 with SMTP id 9mr1281442uas.30.1491451310056; Wed, 05 Apr 2017 21:01:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 21:01:29 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: Lorenzo Colitti Date: Thu, 6 Apr 2017 13:01:29 +0900 Message-ID: To: V6ops Chairs Cc: IPv6 Operations Content-Type: multipart/alternative; boundary=001a113e4bb489a149054c77915d Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 04:01:54 -0000 --001a113e4bb489a149054c77915d Content-Type: text/plain; charset=UTF-8 On Thu, Apr 6, 2017 at 12:45 PM, Fred Baker wrote: > Do we agree to, in some document, make RDNSS and DHCP Relay "Mandatory to > Implement" in the router, with a view to supporting both classes of > networks? > I'm not sure it makes sense to ask this question in isolation. Suppose we were to declare rough consensus on #3. We haven't improved things, because it seems pretty clear to me that we won't get rough consensus on making DHCPv6 a MUST for hosts, as there is substantial opposition to that from the host software developers who are directly affected by it. --001a113e4bb489a149054c77915d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113e4bb489a149054c77915d-- From nobody Wed Apr 5 21:08: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 ACD61127735 for ; Wed, 5 Apr 2017 21:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 4MzQuxyFa2pQ for ; Wed, 5 Apr 2017 21:08:12 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 7691E124D37 for ; Wed, 5 Apr 2017 21:08:12 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id t20so41889817wra.1 for ; Wed, 05 Apr 2017 21:08:12 -0700 (PDT) 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=EtnxTUuWLnjPTn7ciSJpc6fDj/x4p8ioqMLr+YUfdL8=; b=nf22lQyg5ItbvT73fJ65G2metMaakRDnipF8sbfV7Vd7pcgua691pUzRhqXSHWTm32 OePa5Hw88PwDatDnh9g6i0V6Ir5YFHCvmiFTQzevUisln1nkdM/mD+te9fBILB40PdYi mVAQX5c5Mr9ItalK7Cac9gVH0UiDPaX+VJ+oeng1u+1ZXJJyUsM2+qK8gbCCStZ9aLpE IJYK9msavkJme9P5eISEhfN0D27XqgX5VEi9N1EBDW0Z+1aD+ubjYS/GSgfSvZp0ahIs eyxLq/dyZh8D4mSfNd70up4rlIhv9Bnk03Qa93Iv5bcg+gKnZ5Z6hCQEIvC5uacDECGm aYng== 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=EtnxTUuWLnjPTn7ciSJpc6fDj/x4p8ioqMLr+YUfdL8=; b=FnC5kF0awX8VNcq1jwjICJ4QcvRJNsvL3xWVzi5X6BnLTiK/yFNJs72JUnvDmMbj46 m5oNDrjQ+bq8jMYx1sCiUSMZse2wj89jxzzzhdn1a777ETkvtJCazbmJdzG4ML74YZ4K bXU8vgCAh3MzvFqBFnXkG8ExDnYeWuPzKohGZxq+1D9KKPBbHaL4fwcw5g82QCgBEeSd 3OGpiVjroxyVCHEzo+jRD13Kf38vK3XpKeaIZLUNVM0X/LANaXJE7njeGj7b1IuqoT1n IIuONP5yC02z8GgIoBwSq7V827vFajO5LJjlgzEKoS/hQBfKSvRkqvtcI+dMqo3kxPS9 RG3Q== X-Gm-Message-State: AFeK/H1LemO/Ki+JoF0Y2liyH828g5Va9P6gi3Hm17RViTvgG3dCoEAX/zXStmkc1X7nTA== X-Received: by 10.223.172.55 with SMTP id v52mr3253763wrc.112.1491451691016; Wed, 05 Apr 2017 21:08:11 -0700 (PDT) Received: from 233.66.20.149.in-addr.arpa (233.66.20.149.in-addr.arpa. [149.20.66.233]) by smtp.gmail.com with ESMTPSA id j2sm429358wrd.26.2017.04.05.21.08.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 21:08:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Wed, 5 Apr 2017 21:08:07 -0700 Cc: V6ops Chairs , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <8B32D2FC-3624-4787-B347-880D7A147841@gmail.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 04:08:15 -0000 On Apr 5, 2017, at 9:01 PM, Lorenzo Colitti wrote: >=20 > On Thu, Apr 6, 2017 at 12:45 PM, Fred Baker = wrote: >> Do we agree to, in some document, make RDNSS and DHCP Relay = "Mandatory to Implement" in the router, with a view to supporting both = classes of networks? >=20 > I'm not sure it makes sense to ask this question in isolation. Suppose = we were to declare rough consensus on #3. We haven't improved things, = because it seems pretty clear to me that we won't get rough consensus on = making DHCPv6 a MUST for hosts, as there is substantial opposition to = that from the host software developers who are directly affected by it. I'm not particularly in a position to measure that. I might be in a = position to measure the operational viewpoint.= From nobody Wed Apr 5 21:13: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 252591270AC for ; Wed, 5 Apr 2017 21:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 iL4BIR-RluEg for ; Wed, 5 Apr 2017 21:13:17 -0700 (PDT) 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 84C94126DD9 for ; Wed, 5 Apr 2017 21:13:15 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id z204so27914289vkd.1 for ; Wed, 05 Apr 2017 21:13:15 -0700 (PDT) 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=KJdqoOM0XVa7iuY33Khdu5o7yJjI89vmpisy94R5TJs=; b=Mjmqtqrx8EOXWKZYsMv4/Mej8cR2DeLboCG+2ufTEtkBRMqa3Ot4xwIOQ8yFXINjii uvE1FRJebjRAO5zyGMKgYJLNylNdoZSyehTL2DqlN4xRp8ESfS4dy2axGHJj2DlRDmiJ 5sC0Tyi3WseJr+O08+C8imm6RIxzD2Z2E5ZfxW4pUtYUY2Y8CwRKmB05fdgYqHrOwyqx d+3i6vMJhOyPh72hFVVZhHS30PQmo6v3OuGrGJFSHDvFdszj32hP3231H8t9WAknbIHo RC6OEXkU2HzE4XIKBkD5/HYYcL13trdYh9Uti067kNAv2nMoCcUr6g5nP9OD12V7/qEO QvAA== 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=KJdqoOM0XVa7iuY33Khdu5o7yJjI89vmpisy94R5TJs=; b=WVqypaCYMQsOPhWOeD9N5GG7ccDSi4HiKuzRoOp1NAig6X1NslgOEtiyv+yl3O1f5y sEaCHACE9N+pZuY3SNNnGF5s++73w41dnnrIZy0joHMVvmOlCw1Hz8drjQZVGKpfYRR8 95bw2jtrlQfpX+Nv3A6nxRxUBdWBAyI3q7wTM5RXVA7ru17A8Cj5Z3giBsToplCwYGSv 16krfLvnbGaa472yzb0eZVtVT97KhGHeDIhqHDwoQ0iNvu2BjvBg3bYJtYgivgSDBGB0 lJWyL7GfzO9VRqmDe8ddyGe7d/jrUEspMqdgZrWEj9IlEEuS8U23ZPpntb3JHJDAkKo+ PkEA== X-Gm-Message-State: AFeK/H07ThzgkznGVUsIsvbUCJ08vOe4so3ob777CwqcHJxAe/VPfwJIEDURN3OgzQ5gkUHq0mKImpvrEZQmk5ZN X-Received: by 10.159.36.77 with SMTP id 71mr17396123uaq.124.1491451994295; Wed, 05 Apr 2017 21:13:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 21:12:53 -0700 (PDT) In-Reply-To: <8B32D2FC-3624-4787-B347-880D7A147841@gmail.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <8B32D2FC-3624-4787-B347-880D7A147841@gmail.com> From: Lorenzo Colitti Date: Thu, 6 Apr 2017 13:12:53 +0900 Message-ID: To: Fred Baker Cc: V6ops Chairs , IPv6 Operations Content-Type: multipart/alternative; boundary=001a113dc80e526b1c054c77ba83 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 04:13:19 -0000 --001a113dc80e526b1c054c77ba83 Content-Type: text/plain; charset=UTF-8 Would it help if I dug up the objections from host OS developers and collected them in one place to help you evaluate? If we end up saying that routers MUST support DHCPv6 and we know that hosts OS developers don't want that, then will have made things even worse than they actually are. On Thu, Apr 6, 2017 at 1:08 PM, Fred Baker wrote: > > On Apr 5, 2017, at 9:01 PM, Lorenzo Colitti wrote: > > > > On Thu, Apr 6, 2017 at 12:45 PM, Fred Baker > wrote: > >> Do we agree to, in some document, make RDNSS and DHCP Relay "Mandatory > to Implement" in the router, with a view to supporting both classes of > networks? > > > > I'm not sure it makes sense to ask this question in isolation. Suppose > we were to declare rough consensus on #3. We haven't improved things, > because it seems pretty clear to me that we won't get rough consensus on > making DHCPv6 a MUST for hosts, as there is substantial opposition to that > from the host software developers who are directly affected by it. > > I'm not particularly in a position to measure that. I might be in a > position to measure the operational viewpoint. --001a113dc80e526b1c054c77ba83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would it help if I dug up the objections from host OS deve= lopers and collected them in one place to help you evaluate? If we end up s= aying that routers MUST support DHCPv6 and we know that hosts OS developers= don't want that, then will have made things even worse than they actua= lly are.

On = Thu, Apr 6, 2017 at 1:08 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:

On Apr 5, 2017, at 9:01 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On Thu, Apr 6, 2017 at 12:45 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
>> Do we agree to, in some document, make RDNSS and DHCP Relay "= Mandatory to Implement" in the router, with a view to supporting both = classes of networks?
>
> I'm not sure it makes sense to ask this question in isolation. Sup= pose we were to declare rough consensus on #3. We haven't improved thin= gs, because it seems pretty clear to me that we won't get rough consens= us on making DHCPv6 a MUST for hosts, as there is substantial opposition to= that from the host software developers who are directly affected by it.
I'm not particularly in a position to measure that. I might= be in a position to measure the operational viewpoint.
<= br>
--001a113dc80e526b1c054c77ba83-- From nobody Wed Apr 5 21:18: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 9DBEF127419 for ; Wed, 5 Apr 2017 21:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, HK_RANDOM_FROM=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=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 RxAOhfi80PUH for ; Wed, 5 Apr 2017 21:18:01 -0700 (PDT) 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 D9157126DD9 for ; Wed, 5 Apr 2017 21:18:00 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id z204so27981177vkd.1 for ; Wed, 05 Apr 2017 21:18:00 -0700 (PDT) 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=miAsQa0nE5WX5Bu7tfS7+h5r9egcrgfRP6xVeZ2zIsg=; b=nlFgReRLnXwvRQ82kfTTw5OuxWDqxkW/ZQ0QMz8mY7vg3g3RbaGcpY0CpB2aPksQNT M2BcH87Kwtlho69WA4Nqhp9NS753sGX9uWw+VeKAJvE1qO15HxjwjwrQqdGfQ/iFLyjn Ym8+xij/6NSFDYNswVN0XEigj0/duUuHEWouFw74QYYdREsCuX5FTzLfaqNbrn87fA6S HBrr+EoNBaApb/VK4KaYQGmjdDJu9SaSk1gy2AbGlOm3+CJlaKDMjKMuunKMBfOmfRdc KB+KQhDKCJ1N4c9Ow+WAmGw1tpSJILNxIx848qD4GLpcFaQ28pJg6z989lFR4dBz8llc HxRQ== 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=miAsQa0nE5WX5Bu7tfS7+h5r9egcrgfRP6xVeZ2zIsg=; b=Vw5tmZABPUtmpDEdzw9cwXk0GcZXoQ1hNp3cvlsPbtrCvBik5L3MXE1toPTjBk2WBC 9csrX/fpNpx3TvrQHMf59m1XS7UhYKNhvr+2FkZLDVhjL3zue/d/iQMSOaMudMlrD/qW IuoNcRZK+lf80dTNbwJQdPrbSXfKs7d9vItlMpeyjG0AXlGbyxB0trHRHV8GtUJqnd4Y 4rZm/ZVEA3KN5voCw09ql+zQWx2U6uZTNS3bqOjks2BPm4Pp8sbRnyw1RdrKMdq/esWy +9fsa3mS/W55MY0STZaZm4tCyN+bqDKqwvJYwBoPxiHLiXrwR15whZxQ+gCEKEnBJTJH UlOA== X-Gm-Message-State: AFeK/H0wG26ZCA2PV3fRFizWD7isReknut4HZKP5jJbDoNpAfkbJxuQLdd+gjL3SoDtPlPtYAv0GW9pwg7shuQ== X-Received: by 10.159.49.87 with SMTP id n23mr16237760uab.157.1491452279895; Wed, 05 Apr 2017 21:17:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Wed, 5 Apr 2017 21:17:29 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> From: Mark Smith Date: Thu, 6 Apr 2017 14:17:29 +1000 Message-ID: To: George Michaelson Cc: IPv6 Ops WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 04:18:03 -0000 On 6 April 2017 at 13:30, George Michaelson wrote: > Sorry Mark, but that feels orthogonal to the matter at hand. > Maybe it is to an extent. Perhaps what it is is showing is that "host" is too general a term to define even a required minimum of something such as RDNSS. As the Chromecast example shows, it wouldn't get much value from being required to implement RDNSS. Google have 2 x IPv4 and 2 x IPv6 public DNS resolvers, if the CC can't reach any of them, it is probably useless, and the network needs to be fixed to be able to reach them. So Google could probably quite reasonably say, we're not going to implement RDNSS, we're just going to embed our 4 public DNS servers' addresses in our firmware. When people in this thread are thinking of a typical "host", what are they visualising in the mind? - Traditional desktop PC running MS Windows or MAC OS? - Smartphone or Tablet? - A halfway between those two device types like a Chromebook? - VOD type devices such as Chromecast or Apple TV? - IOT devices such as AMI smart meter modules? While there will be some commonality between what services they require to function, how do they acquire that information might be different based on both what the device's function is and the environment where it is most likely used (e.g., BYO smartphone to a public and private networks (residential or enterprise), or AMI smart meter only ever connected to a single, fully managed private network.) I think it would be ideal to define a single minimum, however you don't really want to be foisting an minimum on a device for which it won't ever be used. > It is true that vendors do this, it is true that large vendors of > closed ecologies do this, it doesn't alter the normative standards > drive to specify what should or should not be done, when systems want > to ask for locally supplied configuration. > > So I don't see your comment saying anything material to what a > standards document would say, because the decision not to honour RDNSS > or related definition of local DNS service binding is not going to > appear in a document. > > Unless you are seriously proposing text for a third option which goes > to 'or.. if you chose not to do this then ignore all of the above' > > -G Regards, Mark. From nobody Wed Apr 5 21:28: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 C5DA4126DD9 for ; Wed, 5 Apr 2017 21:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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=apple.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 JSKVA7UTCmSW for ; Wed, 5 Apr 2017 21:28:42 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 D79291293E9 for ; Wed, 5 Apr 2017 21:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491452922; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ESUk7YoJJRIaLIKsIDFD87HOz57nky1mJv5Ihz5T85c=; b=SwFvQ4OKx4HoB7gyjZLBGNUQPL/M+5aQRLjhIrb4Nu2V3gCHTJQ2yd+QvjPJGjXk 964nkV+EQDQDz7dpUoqRmj0mZ3Ohyz/8m6R+exjEruFW6E9mztVo/r58QNvOEG7m MGOwEbqjg72iWTwiiuXcCa0EefNuUzPTE5RuobjfgEaG31EUmAJOqaDnDLLU6FXO fEeBzcGrxFvZu54B3VIV1Fjgf/ZmWaZqk5uI1lYOOKP0DBQAiflR+3lJfSZbDUv1 bMKm9dmWmmy0fpMKFBVddygY/a3Pvk1hcou8TQ8e/cg+GC5+IdPUCSXSVLauINMF uESvowdyL3qvWULAzHerVw==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id BA.6C.25383.AF3C5E85; Wed, 5 Apr 2017 21:28:42 -0700 (PDT) X-AuditID: 11973e12-003389a000006327-62-58e5c3fa58f8 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay7.apple.com (Apple SCV relay) with SMTP id 33.9D.19944.9F3C5E85; Wed, 5 Apr 2017 21:28:42 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ih627UrqBFtTYPnFw3pCaw)" Received: from [17.153.39.228] (unknown [17.153.39.228]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONZ00J950FTXN70@jimbu.apple.com>; Wed, 05 Apr 2017 21:28:41 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <594CF081-8DBC-4408-BA9E-BEBBBF75C01A@apple.com> Date: Wed, 05 Apr 2017 21:28:40 -0700 In-reply-to: <82783B38-E60C-4815-B783-6E7F245BC0E3@consulintel.es> Cc: IPv6 Ops WG To: jordi.palet@consulintel.es References: <004EF04D-AA6F-4301-A003-83E900826F4B@apple.com> <82783B38-E60C-4815-B783-6E7F245BC0E3@consulintel.es> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FCYqvvr8NMIgx3HVCz+Hv/MbHH62F5m ByaPdfsDPJYs+ckUwBTFZZOSmpNZllqkb5fAlXHzbzdzwamCit5jk5kbGCfHdzFyckgImEjs /nKdtYuRi0NIYB+jxI8dZ1hgEo2TjzNCJJYxSrx+cogRJMErICjxY/I9sCJmgTCJOZN3QHX/ Z5SYuHIBK0hCWEBaouvCXSCbg4NNQEviwBojiF4bif+tC6FK7CV2zdsNNpNFQFVi/8weNhCb U8BJYuuNVnaI+QoSbe/awWpEBOQk7q5ohTpoL6PEhEk/GCEulZX49PwnO0hCQuAAm8TbU6dY JzAKzUJy7Cwkx84CuolZQF1iypRciLC2xJN3F1ghbDWJhb8XMSGLL2BkW8UolJuYmaObmWei l1hQkJOql5yfu4kRFAvT7YR2MJ5aZXWIUYCDUYmH1+Pxkwgh1sSy4srcQ4zSHCxK4rxq2U8j hATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOMN6YJ/vbv/LW9odnN87/Iq1sKv/5bTKD9tQz H/539cuuvKKkc/pac8lpHwVlgx0X24vvLzw7ofGw5ZK5we/fXn1ifuv+5htF3y5MKtp2dLFG cc83mc9dszbt3vVV9fuz68vSoxsPJx07sC6KZd2Ba13yf6Xuzr6Ss0LtX6jrzn06ClZS1V8/ GSmxFGckGmoxFxUnAgCzV1XcZgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUiON1OVffX4acRBnOms1v8Pf6Z2eL0sb3M Dkwe6/YHeCxZ8pMpgCmKyyYlNSezLLVI3y6BK+Pm327mglMFFb3HJjM3ME6O72Lk5JAQMJFo nHycsYuRi0NIYBmjxOsnhxhBErwCghI/Jt9jAbGZBcIk5kzewQpR9J9RYuLKBawgCWEBaYmu C3eBbA4ONgEtiQNrjCB6bST+ty6EKrGX2DVvN9hMFgFVif0ze9hAbE4BJ4mtN1rZIeYrSLS9 awerERGQk7i7ohXqoL2MEhMm/WCEuFRW4tPzn+wTGPlnIblvFpL7ZgGdwSygLjFlSi5EWFvi ybsLrBC2msTC34uYkMUXMLKtYhQoSs1JrDTXSywoyEnVS87P3cQICt2GwtQdjI3LrQ4xCnAw KvHwejx+EiHEmlhWXJl7iFGCg1lJhDd99tMIId6UxMqq1KL8+KLSnNTiQ4wTGYG+nMgsJZqc D4ysvJJ4QxMTAxNjYzNjY3MTc1oKK4nzbrz3OEJIID2xJDU7NbUgtQjmKCYOTqkGxrxtHa1J wpuYhRcnz7/x5tiG99kv7skeNbZ/bSY79dqs+f9Y7FNe6dnNe7+480P+z+nc2/74cF+tnrx2 UeG7xQ+cTiX/evJrzwNz7glfAg8u8Am+ysh05xuTnMsjGYP15SLHROxTua/ZH9iwt1tbW1c4 /ZOTdxDf4bYngtP/Cxzs2Zx4oiJ1+hElluKMREMt5qLiRACTdeez0AIAAA== Archived-At: Subject: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 04:28:46 -0000 --Boundary_(ID_ih627UrqBFtTYPnFw3pCaw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Jordi, I think error reporting is an interesting idea. We're proposing PvD as a way for the network to give the device = information, so that could be a good tool here: https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains = We'd have to flesh out what the device sends and ensure that it doesn't = negatively impact users' privacy. I think it might be worth writing a draft and discussing it with the = community in Prague. Thanks, David > On Apr 3, 2017, at 15:22, JORDI PALET MARTINEZ = wrote: >=20 > Hi David, >=20 > I understand that a gradual phase out may be not feasible, or even = difficult to standardize as I=E2=80=99m not even sure the IETF process = provides that path. So, maybe the only option is to come back in 1-2 = years and declare HE historic, maybe as part of the sunset4 WG work. >=20 > On Friday, speaking about this with a colleague, we had an idea, which = could be part of the HE update. >=20 > What if we can, not just improve HE, but also ensure that the = operators get reported those failures? May be by means of a well known = IPv4+IPv6 anycast address in operator networks with a collector to get = the data about those failures, or alternatively to the anycast, some DNS = PTR, etc. >=20 > Maybe I=E2=80=99m targeting too high, but we could take also the = opportunity to signal to the same collector those failures that HE = doesn=E2=80=99t sort out, such as PMTUD. >=20 > Operators will decide if they implement it or not, but we can provide = the tool at least, and seems to me that if we update HE, it may be the = perfect place to do so. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de David Schinazi = > Responder a: > Fecha: lunes, 3 de abril de 2017, 23:45 > Para: Ca By > CC: IPv6 Ops WG > Asunto: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01 >=20 > Hi Cameron, > Jordi was asking us to phase out Happy Eyeballs because it masks = breakage in the network, > and what plan we could build to gradually phase it out. My response = was that if you, as a > network operator, prefer to avoid Happy Eyeballs, you can deploy = IPv6-only, as that will > in effect disable HE. >=20 > The scenario you describe is the opposite: you have a broken server = and want HE to > hide that breakage from users. The tradeoff here is slightly = different since that breakage > is much less widespread. It is something that a NAT64-aware HE = stack could provide though. >=20 > David >=20 >=20 >=20 > On Mar 29, 2017, at 13:22, Ca By wrote: >=20 > Just a comment following up on Jordi's Mic comment > Jordi said there was an issue with HE hiding IPv6 issues. >=20 > David's response was something along the lines of "deploy = ipv6-only". I did not really understand this. >=20 > When folks deploy ipv6-only, they find they are all alone with a = broken ipv6 scenarios that work on all their competitors IPv4-only = networks and HE dual-stack networks. >=20 > Also, friendly reminder that Dan Wing catalogs a subset of the = websites that fail on ipv6-only = http://www.employees.org/~dwing/aaaa-stats/ >=20 > And, my customers still complain about www.fra.dot.gov = ... this works for everyone but me... because = of HE...and I am already on IPv6-only ... and nobody will fix it. This = issues has been known by the USG DOT for over 3 months, noted to NANOG, = nobody cares to fix it. >=20 > So, perhaps there is room in the I-D for including NAT64 = synthesized address candidate set. Meaning the HE algo on an IPv6-only = host would include the set of available native IPv6 answers as well as a = 500ms timer for attempting an A query with using whatever mechanism is = available to the host for relaying IPv4 packets across an IPv6 only = network (RFC6877, Bump in API, ...)=20 >=20 > Without this, IPv6-only networks are at a painful disadvantage = since IPv6 must be perfect while every other scenario has HE to mask = brokenness.=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_ih627UrqBFtTYPnFw3pCaw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Jordi,

I= think error reporting is an interesting idea.

We're proposing PvD as a = way for the network to give the device information, so that could be a = good tool here:
https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-= domains

We'd= have to flesh out what the device sends and ensure that it doesn't = negatively impact users' privacy.

I think it might be worth writing a = draft and discussing it with the community in Prague.

Thanks,
David


On Apr 3, 2017, at 15:22, JORDI PALET = MARTINEZ <jordi.palet@consulintel.es> wrote:

Hi = David,

I understand that a gradual phase = out may be not feasible, or even difficult to standardize as I=E2=80=99m = not even sure the IETF process provides that path. So, maybe the only = option is to come back in 1-2 years and declare HE historic, maybe as = part of the sunset4 WG work.

On Friday, = speaking about this with a colleague, we had an idea, which could be = part of the HE update.

What if we can, not = just improve HE, but also ensure that the operators get reported those = failures? May be by means of a well known IPv4+IPv6 anycast address in = operator networks with a collector to get the data about those failures, = or alternatively to the anycast, some DNS PTR, etc.

Maybe I=E2=80=99m targeting too high, but we could take also = the opportunity to signal to the same collector those failures that HE = doesn=E2=80=99t sort out, such as PMTUD.

Operators will decide if they implement it or not, but we can = provide the tool at least, and seems to me that if we update HE, it may = be the perfect place to do so.

Regards,
Jordi


-----Mensaje = original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de David Schinazi = <dschinazi@apple.com>
Responder a: <dschinazi@apple.com>
Fecha: lunes, 3 de = abril de 2017, 23:45
Para: Ca By <cb.list6@gmail.com>
CC: IPv6 Ops WG = <v6ops@ietf.org>Asunto: Re: [v6ops] = draft-pauly-v6ops-happy-eyeballs-update-01

=    Hi Cameron,
   Jordi was = asking us to phase out Happy Eyeballs because it masks breakage in the = network,
   and what plan we could build = to gradually phase it out. My response was that if you, as a
   network operator, prefer to avoid Happy = Eyeballs, you can deploy IPv6-only, as that will
=    in effect disable HE.

=    The scenario you describe is the opposite: you have a = broken server and want HE to
   hide that = breakage from users. The tradeoff here is slightly different since that = breakage
   is much less widespread. It is = something that a NAT64-aware HE stack could provide though.

   David



   On Mar 29, = 2017, at 13:22, Ca By <cb.list6@gmail.com> wrote:

=    Just a comment following up on Jordi's Mic comment
   Jordi said there was an issue with HE = hiding IPv6 issues.

=    David's response was something along the lines of = "deploy ipv6-only".  I did not really understand this.

   When folks deploy = ipv6-only, they find they are all alone with a broken ipv6 scenarios = that work on all their competitors IPv4-only networks and HE dual-stack = networks.

   Also, friendly = reminder that Dan Wing catalogs a subset of the websites that fail on = ipv6-only http://www.employees.org/~dwing/aaaa-stats/

   And, my customers still = complain about www.fra.dot.gov <http://www.fra.dot.gov/> ... this works for everyone = but me... because of HE...and I am already on IPv6-only ... and nobody = will fix it.  This issues has been known by the USG DOT for over 3 = months, noted to NANOG, nobody cares to fix it.

   So, perhaps there is room in the I-D for = including NAT64 synthesized address candidate set.  Meaning the HE = algo on an IPv6-only host would include the set of available native IPv6 = answers as well as a 500ms timer for attempting an A query with using = whatever mechanism is available to the host for relaying IPv4 packets = across an IPv6 only network (RFC6877, Bump in API, ...)
   Without this, IPv6-only networks are at a = painful disadvantage since IPv6 must be perfect while every other = scenario has HE to mask brokenness.


=    _______________________________________________
   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




**********************************************
IPv4 is over
Are you ready for the new Internet = ?
http://www.consulintel.es
The IPv6 = Company

This electronic message contains = information which may be privileged or confidential. The information is = intended to be for the use of the individual(s) named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information, including = attached files, is prohibited.



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

= --Boundary_(ID_ih627UrqBFtTYPnFw3pCaw)-- From nobody Wed Apr 5 23: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 A28F01293DF for ; Wed, 5 Apr 2017 23:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 l1ymWtNF1JgV for ; Wed, 5 Apr 2017 23:53:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23496129416 for ; Wed, 5 Apr 2017 23:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14276; q=dns/txt; s=iport; t=1491461579; x=1492671179; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N4ntB0TaMKgqjfN4Y31a/Lajd+VeXr776IV4SftJf4c=; b=ESIYXY90lDaSJsqR9LZrs6jbsOV0LR9qSI9pl0OGkQN/VzjX2Xn0LCNh raV2QCXkk3457Wi6qgFtthLgM3a8xRgi9C3ixpVfF05FsfGKo/G5hXHeY p3CxamlRmH5xtYCjSVnvCCwL4STn3iQqZxVp/PvrvwiaffsdLkCj1Q+x9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQAy5eVY/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYELB4NcihKRPIgaiAeFNIIPgmyDNgIagzo/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAyMKTBACAQgRBAEBAScDAgICHxEUCQgCBAENBQgTiVsDFaocg?= =?us-ascii?q?iaHMA2DLgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToRwglGCO4JQgl8FnDU7AY4?= =?us-ascii?q?ZhDCRRYp5iHwBHzhLOlsVhxx1iASBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,283,1488844800"; d="scan'208,217";a="406490014" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2017 06:52:58 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v366qw9T000896 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2017 06:52:58 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 01:52:57 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 01:52:57 -0500 From: "Pascal Thubert (pthubert)" To: Lorenzo Colitti , Fred Baker CC: IPv6 Operations , V6ops Chairs Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohLNvCUSH/sBkqJ5Usv80fbDqG4C7GAgAAB2oCAAAFVgP//1Oww Date: Thu, 6 Apr 2017 06:52:41 +0000 Deferred-Delivery: Thu, 6 Apr 2017 06:52:31 +0000 Message-ID: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <8B32D2FC-3624-4787-B347-880D7A147841@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_cc3bfd0e9d224ca5ba6a6b3930d8070cXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 06:53:06 -0000 --_000_cc3bfd0e9d224ca5ba6a6b3930d8070cXCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTG9yZW56byA6DQoNClRoaXMgc2hvdWxkIGNlcnRhaW5seSBiZSBvbiB0aGUgdGFibGUg aW4gb25lIHBsYWNlLCBhbmQgSSB3b3VsZCB3ZWxjb21lIGEgZHJhZnQgdGhhdCB3b3VsZCBsaXZl IHNvbWUgdGltZSBpbiB0aGUgV0csIGFzIG9wcG9zZWQgdG8gc2NhdHRlcmVkIGluZm9ybWF0aW9u IGluIHNvIG1hbnkgZW1haWxzLiBJdCB3b3VsZCBhbHNvIGJlIGdyYW5kIHRvIGRvY3VtZW50IHdo YXQgY2FuIGJlIGRvbmUgKGFuZCB3aGF04oCZcyBtaXNzaW5nKSB3aXRoIE5ELW9ubHkgc29sdXRp b25zLg0KDQpJ4oCZZCBhbHNvIHdlbGNvbWUgYSBkcmFmdCB0aGF0IGRvY3VtZW50cyB0aGUgYXV0 aG9yc+KAmSB2aWV3IG9mIHdoeSBhbmQgaW4gd2hpY2ggZW52aXJvbm1lbnQgREhDUHY2IHNob3Vs ZCBzdGF5LiBNYXliZSBhIG1vcmUgaW5kdXN0cnktc3BlY2lmaWMgY3VycmVudCBwcmFjdGljZSwg c2luY2UgYXQgdGhlIGVuZCBvZiB0aGUgZGF5LCB3ZSBhcmUgaGVyZSB0byBkZXZlbG9wIHRlY2hu b2xvZ3kgdGhhdCBwZW9wbGUgd2FudCB0byB1c2UuDQoNCkkgY2FuIHNlZSBzdHVmZiB0byB3cml0 ZSBpbiB0aGUgSU9UIHNwYWNlLiwgd2hlcmUgc29tZSBwZW9wbGUgdXNlIERIQ1AgdG8gZW5zdXJl IHRoYXQgaG9zdHMgZ2V0IHNob3J0IGFkZHJlc3NlcyB0aGF0IGNhbiBiZSBjb21wcmVzc2VkIHN0 YXRlbGVzc2x5LCAgYSB0ZWNobmlxdWUgdGhhdCBoYXMgcHJvcyBhbmQgY29ucywgYW5kIG1heWJl IGFsdGVybmF0ZXMsIGFsbCBvZiB3aGljaCBzaG91bGQgYWxzbyBiZSBvbiB0aGUgdGFibGUuDQoN ClRoZW4gbm9kZSBtYWtlcnMgY291bGQgZGVjaWRlIHdoYXQgdG8gcGxhY2UgaW4gdGhlaXIgZGV2 aWNlcyBkZXBlbmRpbmcgb24gdGhlIG1hcmtldCB0aGV5IGFkZHJlc3MgYW5kIHRoZWlyIHJvbGUg aW4gdGhlIG5ldHdvcmsuDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNCg0KDQpGcm9tOiB2Nm9w cyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENv bGl0dGkNClNlbnQ6IGpldWRpIDYgYXZyaWwgMjAxNyAwNjoxMw0KVG86IEZyZWQgQmFrZXIgPGZy ZWRiYWtlci5pZXRmQGdtYWlsLmNvbT4NCkNjOiBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYu b3JnPjsgVjZvcHMgQ2hhaXJzIDx2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3Y2b3BzXSBNYWtpbmcgUkROU1MgYSBNVVNUPywgaHVtIHYyDQoNCldvdWxkIGl0IGhl bHAgaWYgSSBkdWcgdXAgdGhlIG9iamVjdGlvbnMgZnJvbSBob3N0IE9TIGRldmVsb3BlcnMgYW5k IGNvbGxlY3RlZCB0aGVtIGluIG9uZSBwbGFjZSB0byBoZWxwIHlvdSBldmFsdWF0ZT8gSWYgd2Ug ZW5kIHVwIHNheWluZyB0aGF0IHJvdXRlcnMgTVVTVCBzdXBwb3J0IERIQ1B2NiBhbmQgd2Uga25v dyB0aGF0IGhvc3RzIE9TIGRldmVsb3BlcnMgZG9uJ3Qgd2FudCB0aGF0LCB0aGVuIHdpbGwgaGF2 ZSBtYWRlIHRoaW5ncyBldmVuIHdvcnNlIHRoYW4gdGhleSBhY3R1YWxseSBhcmUuDQoNCk9uIFRo dSwgQXByIDYsIDIwMTcgYXQgMTowOCBQTSwgRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21h aWwuY29tPG1haWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KT24gQXBy IDUsIDIwMTcsIGF0IDk6MDEgUE0sIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29t PG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+PiB3cm90ZToNCj4NCj4gT24gVGh1LCBBcHIgNiwg MjAxNyBhdCAxMjo0NSBQTSwgRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPG1h aWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCj4+IERvIHdlIGFncmVlIHRv LCBpbiBzb21lIGRvY3VtZW50LCBtYWtlIFJETlNTIGFuZCBESENQIFJlbGF5ICJNYW5kYXRvcnkg dG8gSW1wbGVtZW50IiBpbiB0aGUgcm91dGVyLCB3aXRoIGEgdmlldyB0byBzdXBwb3J0aW5nIGJv dGggY2xhc3NlcyBvZiBuZXR3b3Jrcz8NCj4NCj4gSSdtIG5vdCBzdXJlIGl0IG1ha2VzIHNlbnNl IHRvIGFzayB0aGlzIHF1ZXN0aW9uIGluIGlzb2xhdGlvbi4gU3VwcG9zZSB3ZSB3ZXJlIHRvIGRl Y2xhcmUgcm91Z2ggY29uc2Vuc3VzIG9uICMzLiBXZSBoYXZlbid0IGltcHJvdmVkIHRoaW5ncywg YmVjYXVzZSBpdCBzZWVtcyBwcmV0dHkgY2xlYXIgdG8gbWUgdGhhdCB3ZSB3b24ndCBnZXQgcm91 Z2ggY29uc2Vuc3VzIG9uIG1ha2luZyBESENQdjYgYSBNVVNUIGZvciBob3N0cywgYXMgdGhlcmUg aXMgc3Vic3RhbnRpYWwgb3Bwb3NpdGlvbiB0byB0aGF0IGZyb20gdGhlIGhvc3Qgc29mdHdhcmUg ZGV2ZWxvcGVycyB3aG8gYXJlIGRpcmVjdGx5IGFmZmVjdGVkIGJ5IGl0Lg0KSSdtIG5vdCBwYXJ0 aWN1bGFybHkgaW4gYSBwb3NpdGlvbiB0byBtZWFzdXJlIHRoYXQuIEkgbWlnaHQgYmUgaW4gYSBw b3NpdGlvbiB0byBtZWFzdXJlIHRoZSBvcGVyYXRpb25hbCB2aWV3cG9pbnQuDQoNCg== --_000_cc3bfd0e9d224ca5ba6a6b3930d8070cXCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IZWxsbyBMb3Jlbnpv Jm5ic3A7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBz aG91bGQgY2VydGFpbmx5IGJlIG9uIHRoZSB0YWJsZSBpbiBvbmUgcGxhY2UsIGFuZCBJIHdvdWxk IHdlbGNvbWUgYSBkcmFmdCB0aGF0IHdvdWxkIGxpdmUgc29tZSB0aW1lIGluIHRoZSBXRywgYXMg b3Bwb3NlZCB0byBzY2F0dGVyZWQgaW5mb3JtYXRpb24gaW4gc28NCiBtYW55IGVtYWlscy4gSXQg d291bGQgYWxzbyBiZSBncmFuZCB0byBkb2N1bWVudCB3aGF0IGNhbiBiZSBkb25lIChhbmQgd2hh dOKAmXMgbWlzc2luZykgd2l0aCBORC1vbmx5IHNvbHV0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPknigJlkIGFsc28gd2VsY29tZSBhIGRyYWZ0IHRoYXQg ZG9jdW1lbnRzIHRoZSBhdXRob3Jz4oCZIHZpZXcgb2Ygd2h5IGFuZCBpbiB3aGljaCBlbnZpcm9u bWVudCBESENQdjYgc2hvdWxkIHN0YXkuIE1heWJlIGEgbW9yZSBpbmR1c3RyeS1zcGVjaWZpYyBj dXJyZW50IHByYWN0aWNlLA0KIHNpbmNlIGF0IHRoZSBlbmQgb2YgdGhlIGRheSwgd2UgYXJlIGhl cmUgdG8gZGV2ZWxvcCB0ZWNobm9sb2d5IHRoYXQgcGVvcGxlIHdhbnQgdG8gdXNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBjYW4gc2VlIHN0dWZmIHRvIHdy aXRlIGluIHRoZSBJT1Qgc3BhY2UuLCB3aGVyZSBzb21lIHBlb3BsZSB1c2UgREhDUCB0byBlbnN1 cmUgdGhhdCBob3N0cyBnZXQgc2hvcnQgYWRkcmVzc2VzIHRoYXQgY2FuIGJlIGNvbXByZXNzZWQg c3RhdGVsZXNzbHksICZuYnNwO2EgdGVjaG5pcXVlDQogdGhhdCBoYXMgcHJvcyBhbmQgY29ucywg YW5kIG1heWJlIGFsdGVybmF0ZXMsIGFsbCBvZiB3aGljaCBzaG91bGQgYWxzbyBiZSBvbiB0aGUg dGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGVuIG5v ZGUgbWFrZXJzIGNvdWxkIGRlY2lkZSB3aGF0IHRvIHBsYWNlIGluIHRoZWlyIGRldmljZXMgZGVw ZW5kaW5nIG9uIHRoZSBtYXJrZXQgdGhleSBhZGRyZXNzIGFuZCB0aGVpciByb2xlIGluIHRoZSBu ZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGFrZSBj YXJlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGFzY2FsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50 OjwvYj4gamV1ZGkgNiBhdnJpbCAyMDE3IDA2OjEzPGJyPg0KPGI+VG86PC9iPiBGcmVkIEJha2Vy ICZsdDtmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJUHY2IE9w ZXJhdGlvbnMgJmx0O3Y2b3BzQGlldGYub3JnJmd0OzsgVjZvcHMgQ2hhaXJzICZsdDt2Nm9wcy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNd IE1ha2luZyBSRE5TUyBhIE1VU1Q/LCBodW0gdjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5Xb3VsZCBpdCBoZWxwIGlmIEkgZHVnIHVwIHRoZSBvYmplY3Rpb25zIGZyb20gaG9z dCBPUyBkZXZlbG9wZXJzIGFuZCBjb2xsZWN0ZWQgdGhlbSBpbiBvbmUgcGxhY2UgdG8gaGVscCB5 b3UgZXZhbHVhdGU/IElmIHdlIGVuZCB1cCBzYXlpbmcgdGhhdCByb3V0ZXJzIE1VU1Qgc3VwcG9y dCBESENQdjYgYW5kIHdlIGtub3cgdGhhdCBob3N0cyBPUyBkZXZlbG9wZXJzDQogZG9uJ3Qgd2Fu dCB0aGF0LCB0aGVuIHdpbGwgaGF2ZSBtYWRlIHRoaW5ncyBldmVuIHdvcnNlIHRoYW4gdGhleSBh Y3R1YWxseSBhcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5P biBUaHUsIEFwciA2LCAyMDE3IGF0IDE6MDggUE0sIEZyZWQgQmFrZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5mcmVkYmFrZXIu aWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCjxicj4NCk9uIEFwciA1LCAyMDE3LCBhdCA5OjAxIFBNLCBMb3JlbnpvIENv bGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPmxvcmVuem9AZ29v Z2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgQXByIDYs IDIwMTcgYXQgMTI6NDUgUE0sIEZyZWQgQmFrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVkYmFr ZXIuaWV0ZkBnbWFpbC5jb20iPmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZndDsmZ3Q7IERvIHdlIGFncmVlIHRvLCBpbiBzb21lIGRvY3VtZW50LCBtYWtlIFJE TlNTIGFuZCBESENQIFJlbGF5ICZxdW90O01hbmRhdG9yeSB0byBJbXBsZW1lbnQmcXVvdDsgaW4g dGhlIHJvdXRlciwgd2l0aCBhIHZpZXcgdG8gc3VwcG9ydGluZyBib3RoIGNsYXNzZXMgb2YgbmV0 d29ya3M/PGJyPg0KJmd0Ozxicj4NCiZndDsgSSdtIG5vdCBzdXJlIGl0IG1ha2VzIHNlbnNlIHRv IGFzayB0aGlzIHF1ZXN0aW9uIGluIGlzb2xhdGlvbi4gU3VwcG9zZSB3ZSB3ZXJlIHRvIGRlY2xh cmUgcm91Z2ggY29uc2Vuc3VzIG9uICMzLiBXZSBoYXZlbid0IGltcHJvdmVkIHRoaW5ncywgYmVj YXVzZSBpdCBzZWVtcyBwcmV0dHkgY2xlYXIgdG8gbWUgdGhhdCB3ZSB3b24ndCBnZXQgcm91Z2gg Y29uc2Vuc3VzIG9uIG1ha2luZyBESENQdjYgYSBNVVNUIGZvciBob3N0cywgYXMgdGhlcmUNCiBp cyBzdWJzdGFudGlhbCBvcHBvc2l0aW9uIHRvIHRoYXQgZnJvbSB0aGUgaG9zdCBzb2Z0d2FyZSBk ZXZlbG9wZXJzIHdobyBhcmUgZGlyZWN0bHkgYWZmZWN0ZWQgYnkgaXQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+SSdtIG5vdCBwYXJ0aWN1bGFybHkgaW4gYSBwb3NpdGlvbiB0byBtZWFzdXJlIHRo YXQuIEkgbWlnaHQgYmUgaW4gYSBwb3NpdGlvbiB0byBtZWFzdXJlIHRoZSBvcGVyYXRpb25hbCB2 aWV3cG9pbnQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_cc3bfd0e9d224ca5ba6a6b3930d8070cXCHRCD001ciscocom_-- From nobody Thu Apr 6 01: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 B7C0212940B for ; Thu, 6 Apr 2017 01:13:07 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aQ90UQiGQ0jO for ; Thu, 6 Apr 2017 01:13:05 -0700 (PDT) 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 6BC66129416 for ; Thu, 6 Apr 2017 01:13:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D122AA2; Thu, 6 Apr 2017 10:13:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491466381; bh=YKCSi6FBcdRa5uW+zVh5Wmx+81wqL9c4sv4e7GDtDo4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BKw5k7SvRw7R1QYy9mYTVQ8/2lL+S5Tyl9huoZfYs4+/iaV69zjUFbLnsxug/HhSc WTcB+nlKfZRJyyndaC81lSYov1WI5yyWc9QHdtue9/2BQrfjro4rnkUq0NZYuGbbQQ FnUbhtx/QokgcFgrCRQNt3fp7y83BdDy2LglVzZs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B7FD388; Thu, 6 Apr 2017 10:13:01 +0200 (CEST) Date: Thu, 6 Apr 2017 10:13:01 +0200 (CEST) From: Mikael Abrahamsson To: Gert Doering cc: Chuck Anderson , v6ops@ietf.org In-Reply-To: <20170405160746.GI25069@Space.Net> Message-ID: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405154854.GA28135@angus.ind.wpi.edu> <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu> <20170405160746.GI25069@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 08:13:08 -0000 On Wed, 5 Apr 2017, Gert Doering wrote: > "Our DNS server has died, so let's quickly provide new recursor addresses > to EVERYTHING" > > instead of > > "Our DNS server has died, let's put that address on the secondary box, > so clients can just happily continue using the address they have learned > by whatever means" Flash renumbering of an entire LAN to for instance a different ISP and different resolvers. Think "fixed line went down, no running on mobile backup connectivity". Yes, you can have your own caching resolver on ULAs to fix that problem, but being able to provide new information quickly might be better for some scenarios. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Apr 6 02:03: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 25C2112940C for ; Thu, 6 Apr 2017 02:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, 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 FT_UMC5KREND for ; Thu, 6 Apr 2017 02:03:36 -0700 (PDT) Received: from smtp12.doorway.no (smtp12.doorway.no [212.125.205.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D53126C23 for ; Thu, 6 Apr 2017 02:03:35 -0700 (PDT) Received: from dware1044.doorway.loc (10.0.20.54) by smtp12.doorway.no (10.0.21.42) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 6 Apr 2017 11:03:24 +0200 Received: from olen.dhcp.nlogic.no (84.208.27.142) by dware1044.doorway.loc (10.0.20.54) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 6 Apr 2017 11:03:29 +0200 To: References: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> From: Ola Thoresen Message-ID: <8dd64dbb-3d6b-6aa6-1936-557cd13673de@nlogic.no> Date: Thu, 6 Apr 2017 11:03:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [84.208.27.142] X-ClientProxiedBy: DWARE1041.doorway.loc (10.0.20.51) To dware1044.doorway.loc (10.0.20.54) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:03:38 -0000 On 06. april 2017 04:54, Mark Smith wrote: > On 6 April 2017 at 08:04, Ted Lemon wrote: >> On Apr 5, 2017, at 2:49 PM, Mark Smith wrote:\ >> (...) >> So in practice, all it needs in order to use the network is a working >> default route and a pair of working DNS resolvers. >> > If this is a reasonable or ideal end host approach or model, then I > think RDNSS starts to become unnecessary too. Firmware vendors may as > well embed DNS addresses. > In that case, it would be better if the devices actually implemented their own resolvers, and did NOT relay on external resolvers at all. Of course this would break a lot of cases where the admin is doing something "evil" with dns, like split horizons and stuff. And it would mean that a lot of firewalls will need to be adjusted. OTOH, the host could detect that it is on an IPv6-only network, and use DNS64 for itself when it needs to connect to v4-only servers. /Ola (T) From nobody Thu Apr 6 02:31: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 61CF41243FE for ; Thu, 6 Apr 2017 02:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAdKaDPH82iX for ; Thu, 6 Apr 2017 02:31:33 -0700 (PDT) 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 53F07126C23 for ; Thu, 6 Apr 2017 02:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491471091; bh=0/y8DafB8wNQYj18pcowyJuAu2bEqgDBbhX3v6C60RU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q5aHw2Dr53tx2+LvKWRpxgahz0S7e5AQJ6/mpVTySB8ln0Egt+Mt0RN4PK7s11Q0c+KoVnZfuQpyR0wF8+8IbkG//FBQAp8ROqcmrZDMGrXz63wAAFaAe7Nz/ZwQDzpPIiNxALk9ZabVz4JkKiOhZnN4kOPLia3FYBHUaJ9Cg94= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0118.outbound.protection.outlook.com [213.199.154.118]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-40-LJc6-oadN7ufL6xE3-K4WA-1; Thu, 06 Apr 2017 10:31:23 +0100 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_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 09:31:22 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.021; Thu, 6 Apr 2017 09:31:22 +0000 From: Tim Chown To: Brian E Carpenter CC: Mark Andrews , "v6ops@ietf.org" Thread-Topic: [v6ops] Eating one's own dog food Thread-Index: AQHSrlC8qUnubSMEFEu3KPekoWUR9qG3UTYAgAAGXZuAAASpgIAAuDyA Date: Thu, 6 Apr 2017 09:31:22 +0000 Message-ID: References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de> <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org> <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20170405221437.A99BB6A925A5@rock.dv.isc.org> <1a120640-a464-8938-07fe-8e3e0629825f@gmail.com> In-Reply-To: <1a120640-a464-8938-07fe-8e3e0629825f@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: [212.188.254.49] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:gXlxPFYiWUeJQx00J7eZYHGatzjKuApn+NgjKhLb0hTqm2Qv2VySU7VpLV/j3scK+t8+NyeoezyvkR3Hj1aDlPtAZimRI65VypSS9pVvxWAmmcqlTUtioBPyRBJOUWJCiXkyyC9RDGmev2qRYQ6xfOr1skn89Bb9qz2V+G7DBoS78g9zgXkbvyFSHmFuKBV2D5ANZ0fohfgTOGg229nuJg1JS2Goy9afSyGF8yORScVxHgxg3KAMqX/bD8bu2oi9CyGfKT51B3pNLWdG5kCo1tA4y2ac/zmuhPkxZcj9gd+rUELwJodCaQJTY4ZNXhjc8lHvCwE/bx8xyRSv20EvgA==; 20:/0GHZ2SvdUNzyFwuidFejtX6HyPfCbJvym1GPSRlkiwHn6IbWk6OAncpfi3U8kZTDFZawZzwaFQFSif3+TB18c1YxTuTj5/yd23JsC2upKH/1pdI4aT+Ao+115du2PoOllMjWuA3WO5XvywiA05oSqo3h3Gkm/b8uZp4pjxG9Tc= x-ms-office365-filtering-correlation-id: f560dbdc-4728-4741-568a-08d47ccfb036 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(39850400002)(24454002)(8936002)(50986999)(50226002)(3280700002)(3660700001)(4326008)(53546009)(25786009)(76176999)(110136004)(38730400002)(81166006)(8676002)(33656002)(3846002)(102836003)(6116002)(39060400002)(74482002)(66066001)(57306001)(36756003)(189998001)(2900100001)(42882006)(6512007)(6246003)(99286003)(54906002)(83716003)(6436002)(6486002)(5250100002)(6506006)(86362001)(82746002)(5660300001)(2906002)(2950100002)(93886004)(6916009)(305945005)(229853002)(53936002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <76D7179F1C52C245945B9117FD4EC8D4@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 09:31:22.1146 (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: LJc6-oadN7ufL6xE3-K4WA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Eating one's own dog food X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:31:35 -0000 PiBPbiA1IEFwciAyMDE3LCBhdCAyMzozMSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwNi8wNC8yMDE3IDEwOjE0LCBNYXJr IEFuZHJld3Mgd3JvdGU6DQo+PiBJbiBtZXNzYWdlIDw0OTI4NmU4OS00M2RmLWFjNmQtOGM5Yi05 ODE2NjE2NjM2ODRAZ21haWwuY29tPiwgQnJpYW4gRSBDYXJwZW50ZXIgd3JpdGVzOg0KPj4+IE9u IDA2LzA0LzIwMTcgMDk6MDgsIEVyaWsgS2xpbmUgd3JvdGU6DQo+Pj4+IE9uIDMxIE1hcmNoIDIw MTcgYXQgMDA6MTcsIE5pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9yZz4gd3JvdGU6DQo+Pj4+ IA0KPj4+Pj4gVGVkIExlbW9uIHdyb3RlOg0KPj4+Pj4+IEkgd291bGQgcHJlZmVyIHRoYXQgdGhl IGRlZmF1bHQgaWV0ZiBzc2lkIHdlcmUgSVB2Ni1vbmx5IHdpdGggTkFUNjQgZm9yDQo+Pj4+Pj4g bGVnYWN5IHNlcnZpY2UuICAgSWYgcGVvcGxlIHdhbnQgSVB2NCwgdGhleSBzaG91bGQgc3dpdGNo IHRvDQo+Pj4+Pj4gaWV0Zi1sZWdhY3kuICAgQW5kIGlmIHdlIHJlYWxseSB3YW50IHRoaXMgZGF0 YSB0byBiZSBtZWFuaW5nZnVsLCB3ZQ0KPj4+Pj4+IHNob3VsZCBjaGFuZ2UgdGhlIG5hbWUgb2Yg aWV0Zi1sZWdhY3kgZXZlcnkgSUVURiBzbyB0aGF0IHBlb3BsZSBoYXZlIHRvDQo+Pj4+Pj4gY2hv b3NlIGl0IHRvIGdldCBpdC4NCj4+Pj4+IA0KPj4+Pj4gSSdkIGJlIHBsZWFzZWQgaWYgdGhpcyB3 ZXJlIGRvbmUgYXQgbWVldGluZ3MgdGhhdCBJIHJlZ3VsYXJseSBhdHRlbmQuDQo+Pj4+IA0KPj4+ PiBMaWtld2lzZS4NCj4+Pj4gDQo+Pj4+IEZXSVcsIEkgYmVsaWV2ZSB0aGF0IHN3aXRjaGluZyB0 aGUgZGVmYXVsdCB3YXMgcHJvcG9zZWQgYXQgYSBwbGVuYXJ5IGluIHRoZQ0KPj4+PiBubyB0b28g ZGlzdGFudCBwYXN0LiAgVGhlIHN1Z2dlc3Rpb24gd2FzIGZvciAiaWV0ZiIgdG8gYmUgb3BlcmF0 ZWQgYXMNCj4+Pj4gImlldGYtbmF0NjQiIGFuZCByZXBsYWNlICJpZXRmLW5hdDY0IiB3aXRoICJp ZXRmLWR1YWxzdGFjayIgb3INCj4+Pj4gImlldGYtbGVnYWN5Ii4NCj4+PiANCj4+PiBJc24ndCB0 aGUgLWxlZ2FjeSBTU0lEIHRoZSBvbmUgd2l0aCBubyBhdXRoZW50aWNhdGlvbj8NCj4+PiANCj4+ PiBUaGF0IHNhaWQsIG5vLCBJIGRvbid0IGFncmVlLiBUaGUgZGVmYXVsdCBzaG91bGQgYmUgKGEp IGF1dGhlbnRpY2F0ZWQNCj4+PiBhbmQgKGIpIGR1YWwgc3RhY2suIEkgZG9uJ3QgYnV5IChhbmQg bmV2ZXIgaGF2ZSwgYW5kIG5ldmVyIHdpbGwpIHRoYXQNCj4+PiBwcmVzZW50aW5nIE5BVDY0IGFz IHByZWZlcmFibGUgdG8gZ2VudWluZSBJUHY0IGlzIGluIHRoZSBpbnRlcmVzdHMgb2YNCj4+PiB1 c2Vycy4gSXQncyBzZWNvbmQtY2xhc3MgZG9nIGZvb2QuIElmZiB0aGUgSUVURiBJUHY0IHNlcnZp Y2Ugd2FzDQo+Pj4gYWN0dWFsbHkgQ0dOIGl0IHdvdWxkIGJlIGEgZGlmZmVyZW50IHN0b3J5OyBh IGJha2VvZmYgYmV0d2VlbiBOQVQ2NA0KPj4+IGFuZCBDR04gd291bGQgYmUgaW5zdHJ1Y3RpdmUu DQo+Pj4gDQo+Pj4gICAgQnJpYW4gDQo+PiANCj4+IFRoZSBwb2ludCBvZiBlYXRpbmcgb25lJ3Mg b3duIGRvZyBmb29kIGlzIHRvIGV4cG9zZSBvbmUgdG8gYWxsIHRoZQ0KPj4gaXNzdWVzIG9mIHVz aW5nIHRoYXQgZG9nIGZvb2QuICBBdCB0aGUgbW9tZW50IHdlIGhhdmUgbG90cyBvZiBwZW9wbGUN Cj4+IHRoYXQgdGhpbmsgTkFUNjQgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIHJlY29tbWVu ZGVkIHdoZW4geW91DQo+PiBzdGFydCBkb3duIHRoZSBpcHY2LW9ubHkgcGF0aC4gIEhhdmluZyB0 aGVtIGNvbnN1bWUgdGhpcyBkb2cgZm9vZA0KPj4gbWF5IG1ha2UgdGhlbSByZXRoaW5rIHRoYXQg b3Bpbmlvbi4NCj4gDQo+IElmIHRoYXQncyB0aGUgYXJndW1lbnQsIHRoZW4gd2Ugc2hvdWxkIGRl ZmluaXRlbHkgaGF2ZSBhIDQ2NFhMQVQNCj4gc29sdXRpb24gaW4gdGhlIGNob2ljZSBvZiBkb2cg Zm9vZCB0b28uDQo+IA0KPiBCdXQgSSB3aWxsIGFsd2F5cyBvcHQgZm9yIHB1cmUgZHVhbCBzdGFj aywgbGlrZSBJIGhhdmUgaW4gbXkNCj4gdW5pdmVyc2l0eSBvZmZpY2UuIEkgaGF2ZSBlbm91Z2gg ZXhwZXJpZW5jZSBvZiBkdWFsIHN0YWNrICsgTkFUNDQNCj4gYXQgaG9tZSwgdGhhbmtzLg0KDQpZ b3UgbWlnaHQg4oCYb3B04oCZIGZvciBpdCwgYnV0IGFuIGFyZ3VtZW50IGZvciBOQVQ2NCs0NjRY TEFUIGlzIHRvIGF2b2lkIG5lZWRpbmcgdG8gc3VwcG9ydCBJUHY0IGluIHRoZSBhY2Nlc3MgbmV0 d29yaywgYXQgbGVhc3QgaWYgdGhlIENMQVQgaXMgZW1iZWRkZWQgaW4gdGhlIGhvc3RzLg0KDQpD b21wbGV4aXR5IGluIHRoZSBob3N0L2VkZ2UgKENMQVQvTkFUNjQvRE5TNjQpIHZzIGNvbXBsZXhp dHkgaW4gdGhlIG5ldHdvcmsgKHJ1bm5pbmcgdHdvIHByb3RvY29scykuDQoNCkkgbGlrZSB0aGF0 IHRoZSBJRVRGIG9mZmVycyBOQVQ2NCwgYW5kIHB1cmUgSVB2Ni1vbmx5LCBhbmQgb2YgY291cnNl IGR1YWwtc3RhY2suIA0KDQpXZeKAmXJlIGp1c3QgYmlrZS1zaGVkZGluZyBvbiB0aGUgZGVmYXVs dC4NCg0KVGltDQoNCg== From nobody Thu Apr 6 02:38: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 A03A112871F for ; Thu, 6 Apr 2017 02:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 4aDVJ_jD-kUf for ; Thu, 6 Apr 2017 02:38:20 -0700 (PDT) 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 C3970127B31 for ; Thu, 6 Apr 2017 02:38:19 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id r45so31349246qte.3 for ; Thu, 06 Apr 2017 02:38:19 -0700 (PDT) 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; bh=J3TjLhAytckbMRikcbtfSx8O8hbLXhiKKphmqW9NcrU=; b=toyIPf7RsnbtJB7SngPW4G/aZYBk23IJoShklwluaYfCLuG8wbzffAqDHQmF3fxvzR Irg/0psnvO53WUUztP4Kb1s/ru8ZJ0kqNeG0LgD80NeDe5huQGdgI4U03rbUYFTsFtCl 16e45QyV3f+ZI9+vzCbzZQYJPfue6J4waoQqoMbU0Bh+o+hnD/ykC6Qy8o5yyu6ik9o4 LIKYQHhAJFaIu4D/CaeLiTVYlVlTP/8dwYg2k2m0QbJBo5YuCIccu6YRFZAub2DKxkzL e1OdWBfyGzceKxXFSdtBlqbS5FbdPuoHmT41oEtxfYA3BbFq/hqSkGiNJf24XCdSe8wZ GMXA== 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; bh=J3TjLhAytckbMRikcbtfSx8O8hbLXhiKKphmqW9NcrU=; b=e8qlJrIpUeQ+U47Ro/xTVdFednpQkwA+YpTgYe1r+NsdxOGVmBmrGU67reT55B7hmn eAovfeWpct0nAAHHU59s9GY8nlsQOTR+WELDLgtWMWATOPlfWKdyGoPZpGZfkhuk/TOs UtmCXwkX9ZsU2Nft3h+RAHK7cSFzY60QFnd4RJXhSZrpVY7wN7Jq/cGAbnSdJeOh9CN9 BabFc337xW9n1tWUPDJlmEtZepF5cCestIJscUfyRXYkh/Wc/W++eTXPadeGo3neDWUh Xew9gJPKm3mhRbGJmKp1jQQkHixeSBJEdGGG9PchagKw0hTKDHbRO9Q0D0s3oXrwot57 NuKA== X-Gm-Message-State: AFeK/H1x11BVOww1mC6+4FCJhm0UY0fTYUApEggFlQxqMNzQD1pIaR2TkWtUnnbcAe5+EdnpujA+znRfxgl/QA== X-Received: by 10.237.35.218 with SMTP id k26mr36341088qtc.60.1491471498945; Thu, 06 Apr 2017 02:38:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.32.226 with HTTP; Thu, 6 Apr 2017 02:37:58 -0700 (PDT) In-Reply-To: <82DC3B74-BA76-4B8B-934D-A98236EF3479@gmail.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <82DC3B74-BA76-4B8B-934D-A98236EF3479@gmail.com> From: Richard Hartmann Date: Thu, 6 Apr 2017 11:37:58 +0200 Message-ID: To: V6ops Chairs , IPv6 Operations Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:38:22 -0000 Hi chairs, disregarding forced realities created by some host platforms, from the engineering PoV, I see the hum as incomplete. Are you willing to add a hum for: (5) Hosts MUST implement both RDNSS and Stateless DHCP; routers MUST implement one or the other and SHOULD implement both. Hosts are moving from network to network, not the other way round. They should be able to interoperate with the widest possible set of network realities they encounter. Richard From nobody Thu Apr 6 03:16: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 DD7001292FD for ; Thu, 6 Apr 2017 03:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1JtW1JqBqd0H for ; Thu, 6 Apr 2017 03:16:00 -0700 (PDT) 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 62DB7127241 for ; Thu, 6 Apr 2017 03:15:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cw4SJ-0000GfC; Thu, 6 Apr 2017 12:15:55 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A 4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <8B32D2FC-3624-4787-B347-880D7A147841@gmail.com> In-reply-to: Your message of "Thu, 6 Apr 2017 13:12:53 +0900 ." Date: Thu, 06 Apr 2017 12:15:54 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 10:16:02 -0000 >Would it help if I dug up the objections from host OS developers and >collected them in one place to help you evaluate? If we end up saying that >routers MUST support DHCPv6 and we know that hosts OS developers don't want >that, then will have made things even worse than they actually are. I think that would be helpful. Because it is my impression that of the objections against DHCP very little has to do with code actually running on a host os and a lot is telling operators how they should run their networks. From nobody Thu Apr 6 03:46: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 BC70312943E for ; Thu, 6 Apr 2017 03:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 0l_FtKNxl1AO for ; Thu, 6 Apr 2017 03:46:39 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 3939C12778D for ; Thu, 6 Apr 2017 03:46:39 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=50032 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cw4vz-0008BC-Tx; Thu, 06 Apr 2017 10:46:35 +0000 Date: Thu, 6 Apr 2017 12:46:35 +0200 From: Tore Anderson To: v6ops@ietf.org Cc: V6ops Chairs Message-ID: <20170406124635.0fb20504@echo.ms.redpill-linpro.com> In-Reply-To: References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 10:46:41 -0000 * Fred Baker > (1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD > or MUST) in the router *hum* Tore From nobody Thu Apr 6 04:09: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 DA88512945B for ; Thu, 6 Apr 2017 04:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 UOIUpSiDpeVg for ; Thu, 6 Apr 2017 04:09:06 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 B8C6D129450 for ; Thu, 6 Apr 2017 04:08:59 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=50822 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cw5Hd-00008s-5h; Thu, 06 Apr 2017 11:08:57 +0000 Date: Thu, 6 Apr 2017 13:08:56 +0200 From: Tore Anderson To: Lorenzo Colitti Cc: Fred Baker , IPv6 Operations Message-ID: <20170406130856.4b8659c9@echo.ms.redpill-linpro.com> In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <8B32D2FC-3624-4787-B347-880D7A147841@gmail.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 11:09:08 -0000 * Lorenzo Colitti > Would it help if I dug up the objections from host OS developers and > collected them in one place to help you evaluate? If we end up saying that > routers MUST support DHCPv6 and we know that hosts OS developers don't wa= nt > that, then will have made things even worse than they actually are. Keep in mind that there more to a host than the operating system, the firmware is another important piece of the puzzle. UEFI, in particular, is all about DHCPv6. It was added to the UEFI spec all the way back in 2010 (in revision 2.3D), yet there is no shortage of devices that are shipping today with firmware that implements older revisions without any IPv6 support. The manufacturers move very slowly. Furthermore, to the best of my knowledge, there's no functionality equivalent to RFC5970 found in ICMPv6 ND today. So if you want to build a network today without any DHCPv6, you won't be able to provision devices until someone writes and publishes RFC5970-for-ND, UEFI spins a new revision with that spec added, and the device manufacturers starts shipping updated firmware that impements that new UEFI revision. We're talking at least a decade here. So from a completely practical standpoint, DHCPv6 is for me a MUST. Not because I have any particular fondness for it, find myself in the =C2=ABDHCPv6 camp=C2=BB (or the =C2=ABRDNSS camp=C2=BB for that matter)= , but it is the only protocol that provides an absolutely essential tool. So even if I considered myself a die-hard RDNSS fanboy and DHCPv6 hater, I still need DHCPv6 to get my job done. Apart from IPv4, there exists no alternative. Thus, DHCPv6 is mandatory. C'est la vie. Tore From nobody Thu Apr 6 04:17: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 B61AC129462 for ; Thu, 6 Apr 2017 04:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-bit key) header.d=iol.unh.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 VNJe2YSQHpL3 for ; Thu, 6 Apr 2017 04:17:38 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 BBC19127342 for ; Thu, 6 Apr 2017 04:17:38 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id n21so32924556qta.1 for ; Thu, 06 Apr 2017 04:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8+sU9e55YJg3N/hW3GppGKaxrRRf/MjUQPz8ToNSDnE=; b=PmrWVMK0+wmOMAUFMqHcygfSg/3mJjqYfDes9e/dfT6l5OcKNq14/4HogbdKvhh+DJ H/AmM4arsYUqJS1gg1+dNvR6aUxANypg4RvGZxyrFf+m6Y8vj2QaH7iPV/EOnXfYyyCk 4OMfbrk+YP9EXQ3XWJsdLOi05RzVzcY2/T0Is= 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=8+sU9e55YJg3N/hW3GppGKaxrRRf/MjUQPz8ToNSDnE=; b=Z5lU8Sd3RqH24Pzbb+Mm9/b3l30eCVbbT/DgX/8hqY7MiLP8yQ7k6a5HpsH9SR8ria Y2SgBqel0yadgYm9m/YsxQCVM6/U7axUhSORwVUgDckw5Kfya6/Mq+qhyL9g2KfrHS1g I5bRlssUAFZVrU8LWra+8ud7d5yEmWFZLO2OYHTrMdleyXUg/BhlEAkFW9kOIeZcxK+m LooLamMLzzGBKkytz/rCxKsZsHk7H4N2RBXxl7XJwlsGkW8kv8y9Y2EyRh8uvKyF1R4b aFnWWotYyjOOZ8x64P4I/jEmCGMN1qUVqsqPpk1ss49sauAIjUXHRkTUGnzfOIMyBACA n4BQ== X-Gm-Message-State: AFeK/H3u0zWTD6qu9kP0emtxAj5m2nnFo7lQtuh4OQpC/DlylAu3qrpyUyPygiNO1wLh439LjZP/tzVuoEfiCBx4 X-Received: by 10.200.41.33 with SMTP id y30mr33245719qty.47.1491477457819; Thu, 06 Apr 2017 04:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Thu, 6 Apr 2017 04:17:37 -0700 (PDT) In-Reply-To: <20170406124635.0fb20504@echo.ms.redpill-linpro.com> References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> From: Timothy Winters Date: Thu, 6 Apr 2017 07:17:37 -0400 Message-ID: To: Tore Anderson Cc: IPv6 Operations , V6ops Chairs Content-Type: multipart/alternative; boundary=001a11406a1e1076d5054c7da837 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 11:17:42 -0000 --001a11406a1e1076d5054c7da837 Content-Type: text/plain; charset=UTF-8 I also prefer option 1 as it leads to the most Interoperable solutions for going forward but also legacy devices. ~Tim On Thu, Apr 6, 2017 at 6:46 AM, Tore Anderson wrote: > * Fred Baker > > > (1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD > > or MUST) in the router > > *hum* > > Tore > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a11406a1e1076d5054c7da837 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also prefer option 1 as it leads to the most Interoperab= le solutions for going forward but also legacy devices.

= ~Tim

O= n Thu, Apr 6, 2017 at 6:46 AM, Tore Anderson <tore@fud.no> wrote:=
* Fred Baker <fredbaker.ietf@gmail.com>

> (1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD<= br> > or MUST) in the router

*hum*

Tore

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



--
=

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--001a11406a1e1076d5054c7da837-- From nobody Thu Apr 6 05:26: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 25CAE12947D for ; Thu, 6 Apr 2017 05:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 BIORQrkXBPfl for ; Thu, 6 Apr 2017 05:26:10 -0700 (PDT) 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 ADD691294BF for ; Thu, 6 Apr 2017 05:26:07 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id v76so19183742ywg.0 for ; Thu, 06 Apr 2017 05:26:07 -0700 (PDT) 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=fiB3xLbq3UadOXalRHuIm0kd74YkQcN/cWpHEq4tWq0=; b=XBaBVvHBoL6sbkrZcRzV5axZca/2Zkvm0cX9AVhyaaruPXrijh3U6jPOHeqYfDyMcM IwBglIFhaiduBmy2lW0sQISw+y0ahcZzEAXWSu0FzkclWs8IZmxyFUyhcTbOGHYMguRs lYeR/0w1ic7BoBudNftT9u9qqsywlmclSFHO1YArUXJ+SA/DojxUGzfmcbm7GRe9UOk8 xSOPp6rXk7+OwKwjJj9nkTKCEyVVoakRFpgMoNNRyTSwVQscUgeETm5TSGjeDK+JFQmo Yu0I6UiaxgeS1aKIC8U3Yg2/R5U0Bxn/3HBuu4tk0Q2cKjPYdNtmqoKo/D0uvDFq4hVL PPvA== 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=fiB3xLbq3UadOXalRHuIm0kd74YkQcN/cWpHEq4tWq0=; b=shVhL7YoHXRscjuCgBCyFu2ryX+uXXzHI/MlmNzsM1W8CRaEIBun1t7uuWoFFRbazw O0kYayKmS6qnGfB5p/Cm/WFD7QIA5MA/dGyBrwJsn6zSHGaUy405YDZHE4sCpXEOC0zJ vbxSi1fh+9tq2aXmKsZipsrzePOjoN2fJwiQG4Basi4Hhcr8W8sSRQqm9ZFyuVNxzR04 QMuKYmunrxVNqiNM+2PMfGqgyDNRoWJZlfn0wS9WBEJYXNxAWTG3Zl46toaHDddMV5DR rnoRaRlPvCCxsBC3VdGzjngnfU2PR1TDUnEoSN7ijQAU8TgTI0JsS4WJp/duUf4pLW5n DJTw== X-Gm-Message-State: AFeK/H0aBJjeVQxj/7atiU9/Zg4+X2IGNecf09EzHfqJfbZTOkd6IpCIlbeTlDt7lKpnyILtyXt5aGpQ2b/4Ilm5 X-Received: by 10.129.137.66 with SMTP id z63mr25012098ywf.211.1491481566456; Thu, 06 Apr 2017 05:26:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.220.12 with HTTP; Thu, 6 Apr 2017 05:25:45 -0700 (PDT) In-Reply-To: References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> From: Erik Kline Date: Thu, 6 Apr 2017 21:25:45 +0900 Message-ID: To: Timothy Winters Cc: Tore Anderson , IPv6 Operations , V6ops Chairs Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c064e08feae4c054c7e9ce2" Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:26:12 -0000 --94eb2c064e08feae4c054c7e9ce2 Content-Type: multipart/alternative; boundary=94eb2c064e08f5a68b054c7e9c16 --94eb2c064e08f5a68b054c7e9c16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a vendor of a device that is sometimes a router I am opposed to, and have precisely zero interesting in, implementing a DHCPv6 relay or server function. It adds nothing, and can actually break clients that prefer DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.=E2=80=8B --94eb2c064e08f5a68b054c7e9c16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a vendor of a device that is sometimes a router I am op= posed to, and have precisely zero interesting in, implementing a DHCPv6 rel= ay or server function.=C2=A0 It adds nothing, and can actually break client= s that prefer DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.= =E2=80=8B
--94eb2c064e08f5a68b054c7e9c16-- --94eb2c064e08feae4c054c7e9ce2 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgW7gOaLb25Tc2dIk9RtoV5bzNK4JKZaT+ c3TWPTFZsQ4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA2 MTIyNjA3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAKBWb89joBOY4euYOQUAbgh3onbuA4Zln93fS3xMNlIfwCr1ubXO oT1edxWh8DQ5cMzETq1dlLN8w/96h7dD9Tcv4Hn/4x7Jp+GiIy+kOEpg325AXB18zu1t1pju4n8w 73R5+L3rhzm/7Q+mQRP8xfucvoQLtCIVLYFry9AtNhVd5RwBVLEbcJZjeLgzM5BXlrEzUbt4Q9/l f+pjZ1qyuI/hGATrACi4MPACiqTM5Kc+rxVp0OBQgyKbX7tahlEHgsAun4GFUMpI3xGSyvBF0Iti 1F3XGqDVh72+WCLf1lV3JbG7HOhcSxa6pT4ZwDcNrgijhwppXrEO9OUZ2LZseIE= --94eb2c064e08feae4c054c7e9ce2-- From nobody Thu Apr 6 05:26: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 751621294C9 for ; Thu, 6 Apr 2017 05:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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=unibague-edu-co.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 3GfcTNz5XTEj for ; Thu, 6 Apr 2017 05:26:48 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 E7B4A1294BD for ; Thu, 6 Apr 2017 05:26:45 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id l7so28183447ioe.3 for ; Thu, 06 Apr 2017 05:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unibague-edu-co.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=6rY3HE+9UNa2SPrZBfa1hYLW2PUP6V7yS8lsUYKTvbE=; b=KooM940pYciIbIrXFwNxUWEF3nBGN3e+sbonYK5XCwlp5YDNdz//tXmNsHqIihlrz/ 6XzfT8dTsyqlonh2w0ixWPhkWsOK1s52+zFfs2y76Z+pNeSeqrCnK8Pjh0Xj5VTRJl7y t+Xu52wn2SQo7WhhSTPvCJeI2hxcpk5DJ1GK+kS/VegJC19CHsEyoHUQWWmBDyablOuG 0Trla/cTU3cmNRy8NNU5wBpyzt37sNoF/6Tlhd41hsu4i4M7JE+DYFSC5oJN/PyBvWWA /Zjdz4W33os0rOUT7IkvqixongovxgsWQbnCxMhnOJ4fwkSxTg8/IC15SEAPy8qHXay8 UI+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:from:date:message-id:subject:to:cc; bh=6rY3HE+9UNa2SPrZBfa1hYLW2PUP6V7yS8lsUYKTvbE=; b=COJDwsatEYOnQy4X3Z1+gV4VLJ4gf3GSyjA6T8weWkVLnOoVSAYiWAj1Vq9gEuXoyw McE3EyHKGH9NQiXgojgnHWD9aHzRfMIczAFtQ5Y6QkbOB5uXLfaYFdx3t0AAsQaM4nst 4o3XYGr+oICdU/KyMds+muE+fZf07lD67Zi1NJXEwYZ4t09sWNO1TSb9dF9sFnLH4wpf 4WkAhixR5oREY4StVAYk/cu+HmB4GdaSFZnHcGjui7q4EiJWc/7UKBs7GaJlXco6LA9w rHr/nMCNakjoJp0ofDYC6o0Qa9C920gAuHFmbPjw9+fpS83QdBdMcRWcAzTFmJl6/Y2p E4Dw== X-Gm-Message-State: AFeK/H3K6FmDWP9eC8kEm1NK24JARF8mmArFr0Kdk1QjB2Z4tZcgxmmJ3ztULEOhcOLmUFacUZJJS+/xi0pURQmF X-Received: by 10.107.3.14 with SMTP id 14mr31034774iod.231.1491481605267; Thu, 06 Apr 2017 05:26:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.15.30 with HTTP; Thu, 6 Apr 2017 05:26:24 -0700 (PDT) From: =?UTF-8?Q?Ricardo_Pel=C3=A1ez_Negro?= Date: Thu, 6 Apr 2017 07:26:24 -0500 Message-ID: To: brian.e.carpenter@gmail.com Cc: bs7652@att.com, v6ops@ietf.org Content-Type: multipart/alternative; boundary=001a113f0a7a4581cc054c7e9fde Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:26:55 -0000 --001a113f0a7a4581cc054c7e9fde Content-Type: text/plain; charset=UTF-8 >> Stuff "designed for homes" gets put on corprate nets all the time. It should >> just work there. There is very little, if anything, that doesn't get connected >> to both types of nets. > > I guess my employer's corporate network must be very different from that of others. >Yes. There are lots of enterprise networks, for example probably every university >that supports IPv6, where BYOD is the norm. There are also lots of enterprise >networks that are strict. One size definitely does not fit all. "MUST implement" implement." >Brian This is the case in the university I work for, We have a lot of students/staff with BYOD. +1 to making RDNSS a MUST implement. (Much better with stateless DHCPv6 a MUST/SHOULD, to give a complete set of options to network operators) *Ricardo * --001a113f0a7a4581cc054c7e9fde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>> Stuff "designed for homes&= quot; gets put on corprate nets all the time.=C2=A0 It should
>> just work there.=C2=A0 There is very little, if anything, tha= t doesn't get connected
>> to both types of net= s.
>
> I guess my employer's = corporate network must be very different from that of others.
>Yes. There are lots of enterprise networks, for example proba= bly every university
>that supports IPv6, where BYOD i= s the norm. There are also lots of enterprise
>network= s that are strict. One size definitely does not fit all. "MUST impleme= nt"
<is very different from "MUST enable&quo= t;. I believe we're talking about "MUST >implement."=C2=A0
>Brian

This is the = case in the university I work for, We have a lot of students/staff with BYO= D. +1 to making RDNSS a MUST implement. (Much better with stateless DHCPv6 = a MUST/SHOULD, to give a complete set of options to network operators)
=

Ricardo=C2=A0
--001a113f0a7a4581cc054c7e9fde-- From nobody Thu Apr 6 05: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 3710B1294E5 for ; Thu, 6 Apr 2017 05:52:56 -0700 (PDT) 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 cbGSdlH43uTL for ; Thu, 6 Apr 2017 05:52:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA091294E4 for ; Thu, 6 Apr 2017 05:52:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cw6uB-0000FMC; Thu, 6 Apr 2017 14:52:51 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpr o.com> In-reply-to: Your message of "Thu, 6 Apr 2017 21:25:45 +0900 ." Date: Thu, 06 Apr 2017 14:52:50 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:52:56 -0000 >As a vendor of a device that is sometimes a router I am opposed to, and >have precisely zero interesting in, implementing a DHCPv6 relay or server >function. It adds nothing, and can actually break clients that prefer >DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes. Wow, I seldomly see such a user hostile attitude. Suppose that I as a user of such a device want to pass a NTP, or a PXE boot option to a downstream device that supports those options. Great that you are telling me that you see no value in that. From nobody Thu Apr 6 05:57: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 A3ECD1294F6 for ; Thu, 6 Apr 2017 05:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=umn.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 m1JC7mbLrQHX for ; Thu, 6 Apr 2017 05:57:47 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 87E13124BFA for ; Thu, 6 Apr 2017 05:57:47 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 1AB7257D for ; Thu, 6 Apr 2017 12:57:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9-QgHWKB3Nm for ; Thu, 6 Apr 2017 07:57:46 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id DCBC8B63 for ; Thu, 6 Apr 2017 07:57:46 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id o76so12380142vkc.20 for ; Thu, 06 Apr 2017 05:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AWycyJlu6MIT4s2zaoHMZnyUThr9vQAnbeCBOFU7jp0=; b=kDu+5PChN3qfEyCzhLhungb+yD/e0X5GaVGtDqA1//Hfdg4srjALMBhh9tLhgt+4qp Nm+7Y2cxR5sVUK8FLU+LIP0GUwSDXMY9RNdIJOID9kJHyMKQiGUL9TMkls4KFWLeSLD+ AmtW1dPYnFLSPWPXS2yyY1Hvcubhp1vwGWhQkXbBILcSqzEzluErzy7h1Qdcg1URZYwN ksnknc3zujanTLt+ZfmXHTxNHR9NLMVX1Em1Iy71kxigqAOAd6Fe1fjkMAdszhkdrYDS abcZJOSDbRPTB7gQGnw8Fc2eJf2fvmqmAJS7mcnohEIz1zT2V9jZQhgmD023wwHPYUKi ZSZg== 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=AWycyJlu6MIT4s2zaoHMZnyUThr9vQAnbeCBOFU7jp0=; b=VC/h1GIxd7OpigGyzXFOwGpaEo6RIBzipa3hWvJJYoSuJlW6P85Ppoe74jtcLLY+zK I78GAxsrSp3S/+djtkFwaN5xF/irmVYgIe5ZLG2vlSaS4gTzwfR/qbbPfgCjGufcIKLb xuI6Md2ZE0YkuW/Tsxfi6d/xma8ug3rBePFFLjqyKBafS5F9zgBtaBErZIWVM7+gSYZe SWMLdrfiFpNgAq+BzCsuArXhLMOjHtcm5Fzky5VUI/i/1d+Qhr5A7hX1IOKh+q+45gUT s/WbR3g4kMqeDTcSGk+125vZKophvKCXzAp95QswLlXUqPJh8lv6TQ+NMuFBGbA0wxea bnfQ== X-Gm-Message-State: AFeK/H0EO89FO5OIAmQPB/pCTzd0NnaGRa8w+StmBWyy3DRFd4bhugShG0spnVoydhtEg3IDT57LHqsuk2MHf+1gRHWG1wXC1Y1Db1Bx0bDoiW5iuhYg7xdaOM0YZcqz5MzYYBPzcuSP621fY6qO X-Received: by 10.159.34.129 with SMTP id 1mr17674292uan.25.1491483466274; Thu, 06 Apr 2017 05:57:46 -0700 (PDT) X-Received: by 10.159.34.129 with SMTP id 1mr17674283uan.25.1491483465963; Thu, 06 Apr 2017 05:57:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.65.24 with HTTP; Thu, 6 Apr 2017 05:57:45 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: David Farmer Date: Thu, 6 Apr 2017 07:57:45 -0500 Message-ID: To: Lorenzo Colitti Cc: V6ops Chairs , IPv6 Operations Content-Type: multipart/alternative; boundary=94eb2c0402502d68cf054c7f0e52 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:57:50 -0000 --94eb2c0402502d68cf054c7f0e52 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 11:01 PM, Lorenzo Colitti wrote: > On Thu, Apr 6, 2017 at 12:45 PM, Fred Baker > wrote: > >> Do we agree to, in some document, make RDNSS and DHCP Relay "Mandatory to >> Implement" in the router, with a view to supporting both classes of >> networks? >> > > I'm not sure it makes sense to ask this question in isolation. Suppose we > were to declare rough consensus on #3. We haven't improved things, because > it seems pretty clear to me that we won't get rough consensus on making > DHCPv6 a MUST for hosts, as there is substantial opposition to that from > the host software developers who are directly affected by it. > Lorenzo, Unfortunately, I don't think there is any consensus to be had about hosts. You have made it perfectly clear that you and others can not accept any requirement for hosts to do DHCPv6 in any way (SHOULD or MUST). And, others are equally adamant that hosts have to be required (SHOULD or MUST) to do DHCPv6 to move a RDNSS requirement for hosts forward. I believe we have an impasse on the subject, and having the two sides yell at each other on the mailing list gets us no where. As for routers; It's clear we need routers that support RDNSS to support the hosts you and others are making. Then, until you have convinced all host OS vendors to remove DHCPv6 support, and the old hosts are all gone, we need routers that also support DHCPv6. There seems to be a consensus that routers need support for RDNSS, at least DHCPv6 Relay (probably a MUST), and Stateless DHCPv6 (probably a SHOULD). It's just that simple from an operational perspective that draft-ali-ipv6rtr-reqs-02 has. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c0402502d68cf054c7f0e52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 11:01 PM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
=

= Unfortunately, I don't think there is any consensus to be had about hos= ts.=C2=A0 You have made it perfectly clear that you and others can not acce= pt any requirement for hosts to do DHCPv6 in any way (SHOULD or MUST).=C2= =A0 And, others are equally adamant that hosts have to be required (SHOULD = or MUST) to do DHCPv6 to move a RDNSS requirement for hosts forward.=C2=A0 = I believe we have an impasse on the subject, and having the two sides yell = at each other on the mailing list gets us no where. =C2=A0 =C2=A0 =C2=A0

As for routers; It's clear we need routers that = support RDNSS to support the hosts you and others are making.=C2=A0 Then, u= ntil you have convinced all host OS vendors to remove DHCPv6 support, and t= he old hosts are all gone, we need routers that also support DHCPv6.=C2=A0 = There seems to be a consensus that routers need support for RDNSS, at least= DHCPv6 Relay (probably a MUST), and Stateless DHCPv6 (probably a SHOULD).= =C2=A0 It's just that simple from an operational perspective that=C2=A0= draft-ali-ipv6rtr-reqs-02 has.=C2=A0

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0 Email:farme= r@umn.edu
Networking & Telecommunication Services
Office of I= nformation Technology
University of Minnesota=C2=A0=C2=A0
2218 Unive= rsity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis,= MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c0402502d68cf054c7f0e52-- From nobody Thu Apr 6 05:59: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 663D012441E for ; Thu, 6 Apr 2017 05:59:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 RSmrYKpjyg5B for ; Thu, 6 Apr 2017 05:59:36 -0700 (PDT) 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 95065124BFA for ; Thu, 6 Apr 2017 05:59:36 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id d191so19597847ywe.2 for ; Thu, 06 Apr 2017 05:59:36 -0700 (PDT) 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=5KZVptnS47JkPd3yy5UBc6S9lFtniUdoCy5mHnbiW14=; b=j1IiWPWNRXgEYmsvOQ5XxozYCBeZksHznRxlTHERVVdgpiso4G2/39bwdPGIYsCj57 GB8mX4vfqdY8EUhC6YUw4I6hVQXxKYQLXT11FR+AIKqKnlGy5YhHLr7BfUY2ViBntg2f /3amVLbX7hA5k09TunWEqWIHFWkiJXe2mqJ09G0Rt2b8zeIYpdmXczCn8MU1TlsqcQEW TNMD7WSjgm7wM4X0ZCoHp0irgVCLZbEZOl9YO+hy3bqO+DEDjmLNuNI6WLLSyaAd+MPE +OnqCBc6H5+Cn/s0i7OQhe3BPcRqSqa5LKIzwQTB6UDBDHpF/JKOWTxgZqu/FyXB/kiw bKog== 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=5KZVptnS47JkPd3yy5UBc6S9lFtniUdoCy5mHnbiW14=; b=l0tyM1HEaNpS+SDpWzB7KXNbhkfubbFPytBmJG0/hCKG1uNJ20mj7zdZvWiY+TaP0H KmkRbGI7eiwbOmdDKkiiwk66rPQHT+Yp5eFpITfp1Y+dKnrgRASswCPBExOHCdjUDqmv ANrO5BZRu/TEXJGOuQhe7WtCKU0V8WgbZwi68eAJQB9xn/1X8yFcraDkE5YU1L9AC30t b4itD50X/l5Ue8RQTn49o9gD7Ohzcf0ke9rowLLxTbc9Ef07ahTjh4BC/kw6Hix4WpAY 2OyfQYudhsKYzoTngtxegshYinQjO006J8epNuezUtZ8qh9YWAXN2v2gi4XcVFptsHn8 E73g== X-Gm-Message-State: AFeK/H1CFQ5hNlDebU5YKu31BdU6TV60r7MgnqZx6YpIwEqL0zo29tKadAIarx6EbqDe4DJXQDBbAQUv6DUnkeAy X-Received: by 10.13.242.198 with SMTP id b189mr21992158ywf.243.1491483575187; Thu, 06 Apr 2017 05:59:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.220.12 with HTTP; Thu, 6 Apr 2017 05:59:14 -0700 (PDT) In-Reply-To: References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> From: Erik Kline Date: Thu, 6 Apr 2017 21:59:14 +0900 Message-ID: To: Philip Homburg Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0356ecbb65c4054c7f14e9" Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:59:38 -0000 --94eb2c0356ecbb65c4054c7f14e9 Content-Type: multipart/alternative; boundary=94eb2c0356ecb0c9a2054c7f14e9 --94eb2c0356ecb0c9a2054c7f14e9 Content-Type: text/plain; charset=UTF-8 On 6 April 2017 at 21:52, Philip Homburg wrote: > >As a vendor of a device that is sometimes a router I am opposed to, and > >have precisely zero interesting in, implementing a DHCPv6 relay or server > >function. It adds nothing, and can actually break clients that prefer > >DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes. > > Wow, I seldomly see such a user hostile attitude. > > Suppose that I as a user of such a device want to pass a NTP, or a PXE boot > option to a downstream device that supports those options. > > Great that you are telling me that you see no value in that. > > > That is correct: I see no value in supporting PXE booting from behind an Android device in tethering mode. --94eb2c0356ecb0c9a2054c7f14e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 April 2017 at 21:52, Philip Homburg <pch-v6ops-7@u-1.ph= icoh.com> wrote:
>As a vendor of a device that is sometim= es a router I am opposed to, and
>have precisely zero interesting in, implementing a DHCPv6 relay or serv= er
>function.=C2=A0 It adds nothing, and can actually break clients that pr= efer
>DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.

Wow, I seldomly see such a user hostile attitude.

Suppose that I as a user of such a device want to pass a NTP, or a PXE boot=
option to a downstream device that supports those options.

Great that you are telling me that you see no value in that.



That is correct: I = see no value in supporting PXE booting from behind an Android device in tet= hering mode.
--94eb2c0356ecb0c9a2054c7f14e9-- --94eb2c0356ecbb65c4054c7f14e9 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgiV6rkxyH40lMDDq1lOMNNPU4Cdd01w4r QQwj0aUJ9OQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA2 MTI1OTM1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAJuWhgGTnDnWEWJHh8BEC0zzQv5HGvytXPkfyoviOAXTXD7P8nn5 cQqTT+Z38FELit/EfJOoZu2IOjsX31lcZe3vMff85irYUf1IepkIuq9kIHwyLdUg05nYCozdcu9Y EoSBJK4hq2Sh79UuXEPIaGzLdhYm0aPTjvqGuMPmzWLRTLm0I7j80GOPMVquEhe8xyvy7t6dwpI2 ThN5hx3+nve8T72SjEJudoECnOhgzd6CpuRcX45lNEMoDrwMxNXhGHXKoKh6I7GzC5WpBX37iC9k z6CmH37/kOQRWK/aoKIOQCqNgW3mpFzjfqdrg8nmAbUBMtVGlVWcozV9uhilGYc= --94eb2c0356ecbb65c4054c7f14e9-- From nobody Thu Apr 6 06:12: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 29A0E1294EE for ; Thu, 6 Apr 2017 06:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0i-XovQkQFev for ; Thu, 6 Apr 2017 06:12:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7A4128D69 for ; Thu, 6 Apr 2017 06:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13862; q=dns/txt; s=iport; t=1491484361; x=1492693961; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=doYGKHSG3U6meygjt5eF74YmJeHUXTDQslgvsranNlo=; b=C5mI9Gh+HCmeY41arWLVJTBj4e5xrBh8Csyoj7mJjvJutL7BdUUKNpTu bhxa9l3Tbtl7uUiCDP6qdtDBN48ahF9+C3pMtkuUbThq1C7mpA7v/F21v GNcA+yJcPYRv0liOF2e3H9PyOrT2vLuqdkHD8JsPOaJ47iQm0si4bXoOe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQCKPeZY/5JdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYELB41ukT2IGogHhTSCDx8BCoV4AhqDKj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDAQEhCkEbAgEIEQQBASgDAgICHwYLFAkIAgQTCBOJWwMVCQWpA?= =?us-ascii?q?oImKYcFDYMuAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYs+glGBYQ5MglCCXwWcODs?= =?us-ascii?q?Bhn2HHIQwkUaKewIliFUBHziBBVsVQYIihDl1DAGHFYEwgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,159,1488844800"; d="scan'208,217";a="408453746" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2017 13:12:40 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v36DCexV010588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Apr 2017 13:12:40 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 08:12:39 -0500 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, 6 Apr 2017 08:12:39 -0500 From: "Bernie Volz (volz)" To: IPv6 Operations Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohLAlJXdnN5j0uTKcn23s0z76G4fOCAgAAIq4D//8r3sA== Date: Thu, 6 Apr 2017 13:12:39 +0000 Message-ID: References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.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.197] Content-Type: multipart/alternative; boundary="_000_eb478a60fef74e3dadb4d49744d3442aXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 13:12:46 -0000 --_000_eb478a60fef74e3dadb4d49744d3442aXCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gMS4NCg0KSSB0aGluayBmb3Igcm91dGVycyBpdCBpcyBNVVNUIGZvciBib3RoLiBGb3Ig REhDUCwgSeKAmW0gdGFsa2luZyBhYm91dCBnZW5lcmFsIHB1cnBvc2Ugcm91dGVycyBhbmQgbm90 IGxpbWl0ZWQgZnVuY3Rpb25hbGl0eSByb3V0ZXJzIChpLmUuLCB0aG9zZSB0aGF0IG1pZ2h0IGJl IHVzZWQgZm9yIHRldGhlcmluZyDigJMgdGhvc2UgY291bGQgZ2V0IGJ5IHdpdGggUkROU1MpLg0K DQpJIHRoaW5rIGZvciBob3N0cyBpdCBzaG91bGQgYmUgTVVTVCBzdXBwb3J0IFJETlNTIGFuZCBT SE9VTEQgc3VwcG9ydCAoYXQgbGVhc3Qgc3RhdGVsZXNzKSBESENQdjYuDQoNCg0KLSAgICAgICAg ICBCZXJuaWUNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgVGltb3RoeSBXaW50ZXJzDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDYsIDIw MTcgNzoxOCBBTQ0KVG86IFRvcmUgQW5kZXJzb24gPHRvcmVAZnVkLm5vPg0KQ2M6IElQdjYgT3Bl cmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+OyBWNm9wcyBDaGFpcnMgPHY2b3BzLWNoYWlyc0B0b29s cy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIE1ha2luZyBSRE5TUyBhIE1VU1Q/LCBo dW0gdjINCg0KSSBhbHNvIHByZWZlciBvcHRpb24gMSBhcyBpdCBsZWFkcyB0byB0aGUgbW9zdCBJ bnRlcm9wZXJhYmxlIHNvbHV0aW9ucyBmb3IgZ29pbmcgZm9yd2FyZCBidXQgYWxzbyBsZWdhY3kg ZGV2aWNlcy4NCg0KflRpbQ0KDQpPbiBUaHUsIEFwciA2LCAyMDE3IGF0IDY6NDYgQU0sIFRvcmUg QW5kZXJzb24gPHRvcmVAZnVkLm5vPG1haWx0bzp0b3JlQGZ1ZC5ubz4+IHdyb3RlOg0KKiBGcmVk IEJha2VyIDxmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmZyZWRiYWtlci5pZXRmQGdt YWlsLmNvbT4+DQoNCj4gKDEpIFJETlNTIGFuZCBESENQIFJlbGF5IChvciBhIERIQ1Agc2VydmVy KSBhcmUgYm90aCByZXF1aXJlZCAoU0hPVUxEDQo+IG9yIE1VU1QpIGluIHRoZSByb3V0ZXINCg0K Kmh1bSoNCg0KVG9yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoN Cg0KDQotLQ0KDQpOb3cgb2ZmZXJpbmcgdGVzdGluZyBmb3IgU0ROIGFwcGxpY2F0aW9ucyBhbmQg Y29udHJvbGxlcnMgaW4gb3VyIFNETiBzd2l0Y2ggdGVzdCBiZWQuIExlYXJuIG1vcmUgdG9kYXkg aHR0cDovL2JpdC5seS9TRE5fSU9MUFINCg== --_000_eb478a60fef74e3dadb4d49744d3442aXCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okdlb3JnaWE7DQoJ cGFub3NlLTE6MiA0IDUgMiA1IDQgNSAyIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCglt YXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpi DQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTczMDU3NTIzOw0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzE0NDYwNDg4 IDEzNTMwODExODAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiYjNDM7MSBvbiAxLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBmb3Igcm91 dGVycyBpdCBpcyBNVVNUIGZvciBib3RoLiBGb3IgREhDUCwgSeKAmW0gdGFsa2luZyBhYm91dCBn ZW5lcmFsIHB1cnBvc2Ugcm91dGVycyBhbmQgbm90IGxpbWl0ZWQgZnVuY3Rpb25hbGl0eSByb3V0 ZXJzIChpLmUuLCB0aG9zZSB0aGF0IG1pZ2h0IGJlDQogdXNlZCBmb3IgdGV0aGVyaW5nIOKAkyB0 aG9zZSBjb3VsZCBnZXQgYnkgd2l0aCBSRE5TUykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIGZvciBob3N0cyBpdCBzaG91bGQgYmUgTVVTVCBzdXBw b3J0IFJETlNTIGFuZCBTSE9VTEQgc3VwcG9ydCAoYXQgbGVhc3Qgc3RhdGVsZXNzKSBESENQdjYu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB2 Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PlRpbW90aHkgV2ludGVyczxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMDYsIDIw MTcgNzoxOCBBTTxicj4NCjxiPlRvOjwvYj4gVG9yZSBBbmRlcnNvbiAmbHQ7dG9yZUBmdWQubm8m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBJUHY2IE9wZXJhdGlvbnMgJmx0O3Y2b3BzQGlldGYub3JnJmd0 OzsgVjZvcHMgQ2hhaXJzICZsdDt2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIE1ha2luZyBSRE5TUyBhIE1VU1Q/LCBodW0gdjI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gcHJlZmVyIG9wdGlv biAxIGFzIGl0IGxlYWRzIHRvIHRoZSBtb3N0IEludGVyb3BlcmFibGUgc29sdXRpb25zIGZvciBn b2luZyBmb3J3YXJkIGJ1dCBhbHNvIGxlZ2FjeSBkZXZpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+flRpbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciA2LCAyMDE3IGF0IDY6NDYg QU0sIFRvcmUgQW5kZXJzb24gJmx0OzxhIGhyZWY9Im1haWx0bzp0b3JlQGZ1ZC5ubyIgdGFyZ2V0 PSJfYmxhbmsiPnRvcmVAZnVkLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBGcmVkIEJha2VyICZsdDs8YSBocmVmPSJt YWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tIj5mcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxicj4NCiZndDsgKDEpIFJETlNTIGFuZCBESENQIFJlbGF5IChvciBhIERI Q1Agc2VydmVyKSBhcmUgYm90aCByZXF1aXJlZCAoU0hPVUxEPGJyPg0KJmd0OyBvciBNVVNUKSBp biB0aGUgcm91dGVyPGJyPg0KPGJyPg0KKmh1bSo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+VG9yZTwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxs Ij4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEm cXVvdDssc2VyaWYiPk5vdyBvZmZlcmluZyB0ZXN0aW5nIGZvciBTRE4gYXBwbGljYXRpb25zIGFu ZCBjb250cm9sbGVycyBpbiBvdXIgU0ROIHN3aXRjaCB0ZXN0IGJlZC4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90 OyxzZXJpZiI+TGVhcm4gbW9yZSB0b2RheQ0KPGEgaHJlZj0iaHR0cDovL2JpdC5seS9TRE5fSU9M UFIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vYml0Lmx5L1NETl9JT0xQUjwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_eb478a60fef74e3dadb4d49744d3442aXCHALN003ciscocom_-- From nobody Thu Apr 6 06:35: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 7A5B6126B72 for ; Thu, 6 Apr 2017 06:35:02 -0700 (PDT) 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 4eL3pPJJfDN5 for ; Thu, 6 Apr 2017 06:35:00 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 AFD0F124217 for ; Thu, 6 Apr 2017 06:35:00 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id b140so29579246iof.1 for ; Thu, 06 Apr 2017 06:35:00 -0700 (PDT) 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=Djx2FzqyAzTpSVmQrTaaDhBSfv0A9qmLt04fpO9CmOM=; b=eMXm7waGRQ3Ix/X6PKC/+59RY8i9Njv8OTU7m76peN8Zlc0+vF/Axr42MKbOq7MsPw P48ipk8NUgsBcE3lobQgQD0Q9XPImqi0RS8138vJd8SEXDG0XdIRhhsyWORgmG4O669F 6P+KLt7BJk9iv0aT7PTeVx+evwzQBbEKIUun4Flyuj1bGcM+zy7GtZp64mb2+OpgGPK7 zWrFp5PJVKbWX0n5sgIRFJK8oTCLWyAGps0sSjT1d/NlR4RELEj81aHZlm+0d7ScwGh1 qQKt3vYaH0ee7ay7KYrDwH/wN5uKHB5EBd2oUwvJ8HkUEXXv/Co8X5vSVmv7xRwwGus1 9+Tw== 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=Djx2FzqyAzTpSVmQrTaaDhBSfv0A9qmLt04fpO9CmOM=; b=i0WweTdQ2OOH1AtOFn8Tylvun1jHl6DffXciqMdU8GEN7w+cg/I+nxt8lp4DdcaVQC 4ZCGwXOLInQ7l9OINgWslvx0glvq7MqVSDz2WvxLmLrphFuG6Hgcxig72Cl9koGqcrHf BKgFWtdlCENZIIrYmdFp+DSbRKInwvZB5Qtkz4D8QxhLqe7DX7vjDagY7wGj4+72DEbo 5HwVI9xkf1upIAIaCcvtlUCTsAAZPJRI25Sepgcnllxi2TmMEMaWigfUb/A9ZQUEclXG DYJHAS3GslvqJD3QHybonjaw0Q5qOKdn6nt2NOMKIRM4rQX9GjVhCD3i/ZFxSz+am8mN AFUA== X-Gm-Message-State: AFeK/H19xuWBsoVquW/ouLoXrDt69KSVFPssXD9udfOndCVkxKN0rpQ6zv4TZA8QNd6hyw== X-Received: by 10.107.131.211 with SMTP id n80mr33782488ioi.210.1491485699807; Thu, 06 Apr 2017 06:34:59 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id n10sm10158095itg.8.2017.04.06.06.34.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 06:34:59 -0700 (PDT) To: Philip Homburg , v6ops@ietf.org References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405201301.GP28135@angus.ind.wpi.edu> <6ca41854-74e4-4eda-92eb-dc4346f1d9c6@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 7 Apr 2017 01:35:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] OI flag [was: Making RDNSS a MUST?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 13:35:02 -0000 On 06/04/2017 11:06, Philip Homburg wrote: >> To make that watertight, the formal meaning of O would need to change: >> >> OLD: >> O 1-bit "Other configuration" flag. When set, it >> indicates that other configuration information is >> available via DHCPv6. Examples of such information >> are DNS-related information or information on other >> servers within the network. >> >> NEW: >> O 1-bit "Other configuration" flag. When set, it >> indicates that DNS server information is available >> via DHCPv6. Configuration information on other >> servers within the network MAY be included. > > I think the old meaning is correct. When the O bit is set, a host should > try to get the DHCP options it supports. Why bother to look at that flag at all? It's so vaguely defined that it could mean anything. Just try DHCP anyway - the worst that can happen is nothing. Brian > In the ideal case, a host receives DNS information from either DHCP or > from RDNSS. > > Note that if an important group of devices refuse to support DHCP, you > have to support RDNSS, but the operator may want to provide NTP servers > through DHCP. In that case it doesn't make sense if DHCP also has to > provide DNS. > > In the case a host receives DNS from both we need a merging algorithm. > I don't have a preference for that. Though to allow DHCP to override > global settings, it may make sense to have a preference for DHCP. > . > From nobody Thu Apr 6 06:45: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 703111294F5 for ; Thu, 6 Apr 2017 06:45:17 -0700 (PDT) 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 wvffjwIfRUDZ for ; Thu, 6 Apr 2017 06:45:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id BA5FB129501 for ; Thu, 6 Apr 2017 06:45:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cw7ir-0000IoC; Thu, 6 Apr 2017 15:45:13 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405201301.GP28135@angus.ind.wpi.edu> <6ca41854-74e4-4eda-92eb-dc4346f1d9c6@gmail.com> In-reply-to: Your message of "Fri, 7 Apr 2017 01:35:04 +1200 ." Date: Thu, 06 Apr 2017 15:45:12 +0200 Archived-At: Subject: Re: [v6ops] OI flag [was: Making RDNSS a MUST?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 13:45:17 -0000 >Why bother to look at that flag at all? It's so vaguely defined that >it could mean anything. Just try DHCP anyway - the worst that can happen >is nothing. For one, there is a difference between stateful and stateless DHCP requests. In networks where multicast is expensive, it is not a good idea to have lots of hosts multicast DHCP requests all the time. For a host it is important to decide how long to wait for a DHCP response. If the O flag is clear, the host can continue booting right after receiving an RA. If the O flag is set, the host should probably wait a couple of retries. (Some hosts are more advanced than others. Some hosts may continues booting as soon as one DNS resolver is found. Others execute a number of steps and then move on) From nobody Thu Apr 6 06:58: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 64D171294FF for ; Thu, 6 Apr 2017 06:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 U5cIcRSKJzla for ; Thu, 6 Apr 2017 06:58:30 -0700 (PDT) Received: from smtp12.doorway.no (smtp12.doorway.no [212.125.205.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A20129508 for ; Thu, 6 Apr 2017 06:58:28 -0700 (PDT) Received: from dware1044.doorway.loc (10.0.20.54) by smtp12.doorway.no (10.0.21.42) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 6 Apr 2017 15:58:21 +0200 Received: from olen.dhcp.nlogic.no (84.208.27.142) by dware1044.doorway.loc (10.0.20.54) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 6 Apr 2017 15:58:25 +0200 To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405201301.GP28135@angus.ind.wpi.edu> <6ca41854-74e4-4eda-92eb-dc4346f1d9c6@gmail.com> From: Ola Thoresen Message-ID: Date: Thu, 6 Apr 2017 15:58:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [84.208.27.142] X-ClientProxiedBy: DWARE1041.doorway.loc (10.0.20.51) To dware1044.doorway.loc (10.0.20.54) Archived-At: Subject: Re: [v6ops] OI flag [was: Making RDNSS a MUST?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 13:58:32 -0000 On 06. april 2017 15:45, Philip Homburg wrote: >> Why bother to look at that flag at all? It's so vaguely defined that >> it could mean anything. Just try DHCP anyway - the worst that can happen >> is nothing. > For one, there is a difference between stateful and stateless DHCP requests. > > In networks where multicast is expensive, it is not a good idea to have > lots of hosts multicast DHCP requests all the time. > > For a host it is important to decide how long to wait for a DHCP response. > If the O flag is clear, the host can continue booting right after receiving > an RA. If the O flag is set, the host should probably wait a couple of retries. > > (Some hosts are more advanced than others. Some hosts may continues booting > as soon as one DNS resolver is found. Others execute a number of steps and > then move on) A related issue I just discovered while doing some tests is that NetworkManager - at least in Fedora 25 - will not start (nor stop) sending DHCP-requests if the flags changes after it has first received an RA. So if the first RA it receives have O=M=0, it will never start sending DHCP-Solicits, even if a later RA has O or M=1 And also, if it has received a RA with O/M=1 and have gotten an DHCP-lease, it will continue to renew this, even if you later remove the O/M-flags from the RA-packets. I am not sure the behaviour in this case (where the flags are changed) is defined in any RFCs? Also, I am not sure how a host would behave if there were multiple sources of RAs, and some had O/M=1 and others had O/M=0. Rgds. Ola Thoresen From nobody Thu Apr 6 07:13: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 AFFFC128D69 for ; Thu, 6 Apr 2017 07:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 5TOCJbIri9sF for ; Thu, 6 Apr 2017 07:13:34 -0700 (PDT) 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 F0B6A1275AB for ; Thu, 6 Apr 2017 07:13:33 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v36E60n6023730; Thu, 6 Apr 2017 10:13:19 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 29nq4krdtj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 10:13:18 -0400 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 v36EDH75005597; Thu, 6 Apr 2017 10:13:18 -0400 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 v36ED9Hv005470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 10:13:10 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 6 Apr 2017 14:12:58 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 10:12:58 -0400 From: "STARK, BARBARA H" To: Erik Kline , Timothy Winters CC: IPv6 Operations , Tore Anderson Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohJPytzlZ90JUCxvg9piYpj0aG4bByAgAAIrICAABMJgP//1ehg Date: Thu, 6 Apr 2017 14:12:58 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.235] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-06_12:, , 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-1702020001 definitions=main-1704060116 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 14:13:36 -0000 SGkgRXJpaywNCg0KPiBBcyBhIHZlbmRvciBvZiBhIGRldmljZSB0aGF0IGlzIHNvbWV0aW1lcyBh IHJvdXRlciBJIGFtIG9wcG9zZWQgdG8sIGFuZCBoYXZlIHByZWNpc2VseSB6ZXJvIGludGVyZXN0 aW5nIGluLCANCj4gaW1wbGVtZW50aW5nIGEgREhDUHY2IHJlbGF5IG9yIHNlcnZlciBmdW5jdGlv bi7CoCBJdCBhZGRzIG5vdGhpbmcsIGFuZCBjYW4gYWN0dWFsbHkgYnJlYWsgY2xpZW50cyB0aGF0 IHByZWZlciANCj4gREhDUHY2IEROUyBvdmVyIFJETlNTIHdoZW4gdGhlIHVwc3RyZWFtIElQdjYg cHJlZml4IGNoYW5nZXMu4oCLDQoNCkkgd2FzIGhhdmluZyBhIGxpdHRsZSB0cm91YmxlIHBhcnNp bmcgdGhpcywgYW5kIGp1c3Qgd2FudGVkIHRvIG1ha2Ugc3VyZSBJIHVuZGVyc3Rvb2QgeW91IGNv cnJlY3RseS4NCjEuIFlvdSBhcmUgb3Bwb3NlZCB0byBpbXBsZW1lbnRpbmcgYSBESENQdjYgcmVs YXkgb3Igc2VydmVyIGZ1bmN0aW9uIGluIHRoZXNlIGRldmljZXMnIHJvdXRlciBmdW5jdGlvbiwg YnV0IGl0IGlzIG5vdCAiYSByb3V0ZXIgSSBhbSBvcHBvc2VkIHRvIi4gSSBhZG1pdCB0byBtaXNy ZWFkaW5nIHRoaXMgdGhlIGZpcnN0IGZldyB0aW1lcyAodGhpbmtpbmcgeW91IHdlcmUgb3Bwb3Nl ZCB0byB0aGUgZGV2aWNlIHNvbWV0aW1lcyBiZWluZyBhIHJvdXRlciksIHNvIEkgdGhvdWdodCBJ J2QgYXNrIHRvIG1ha2Ugc3VyZS4gRnJvbSBleHBlcmllbmNlLCBJIGtub3cgdGhhdCB3aGVuZXZl ciBJIG1pc3JlYWQgc3VjaCBzdGF0ZW1lbnRzLCBJJ20gbmV2ZXIgYWxvbmUuIEknbSBqdXN0IG5v dCBhZnJhaWQgdG8gYXNrLg0KDQoyLiBZb3Ugc2F5IHlvdSBkb24ndCB3YW50IHRvIGJyZWFrIGNs aWVudHMgKGhvc3RzKSB0aGF0IHByZWZlciBESENQdjYgRE5TIG92ZXIgUkROU1MuIFNpbmNlIHlv dSBvcHBvc2UgREhDUHY2IHJlbGF5IG9yIHNlcnZlciAoaW4gdGhlIGFic2VuY2Ugb2YgYSBxdWFs aWZpZXIgSSB0YWtlIHNlcnZlciB0byBtZWFuIHN0YXRlZnVsIG9yIHN0YXRlbGVzcyAtLSBzbyB5 b3Ugb3Bwb3NlIGJvdGggdHlwZXMgb2Ygc2VydmVyPyksIGRvZXMgdGhpcyBtZWFuIHlvdSBiZWxp ZXZlIHRoZSB3YXkgdG8gcHJldmVudCBicmVha2FnZSBpcyB0byBvbmx5IG9mZmVyIFJETlNTIHRv IGNsaWVudHMgKHNvIHRoZWlyIHByZWZlcmVuY2UgaXMgaXJyZWxldmFudCwgYW5kIHRoZXkgaGFk IGJldHRlciBhbHNvIGltcGxlbWVudCBSRE5TUyBpbiBzcGl0ZSBvZiB0aGVpciBwcmVmZXJlbmNl KT8gT3IgaXMgaXQganVzdCBzdGF0ZWZ1bCBzZXJ2ZXIgdGhhdCB5b3Ugb3Bwb3NlPyBJZiBqdXN0 IG9wcG9zZWQgdG8ganVzdCBzdGF0ZWZ1bCBzZXJ2ZXIsIGFyZSB5b3UgaW4gZmF2b3Igb2Ygc3Rh dGVsZXNzIHN1cHBvcnQgaW4gcm91dGVycyB0aGF0IGRvbid0IGRvIHN0YXRlZnVsLCBpbiBvcmRl ciB0byBzdXBwb3J0IHBvc3NpYmxlIGNsaWVudHMgdGhhdCBvbmx5IHJlcXVlc3QgRE5TIGJ5IERI Q1B2NiBzdGF0ZWxlc3M/DQoNCk5vIGFnZW5kYTsganVzdCB0cnlpbmcgbm90IHRvIG1pc3VuZGVy c3RhbmQgLi4uDQpCYXJiYXJhDQoNCg0K From nobody Thu Apr 6 08:09: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 F1588128768 for ; Thu, 6 Apr 2017 08:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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=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 qiWVW1_fcdyM for ; Thu, 6 Apr 2017 08:09:39 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 CF398127599 for ; Thu, 6 Apr 2017 08:09:38 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id f133so22575022qke.2 for ; Thu, 06 Apr 2017 08:09:38 -0700 (PDT) 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:content-transfer-encoding; bh=i0ST1QdQjmG4p4E1eOpvzg8LFB1vARAzNS6MuKF/Cl0=; b=cRySwrAhglsfVQY3aA0WnGJiX03xkaqR/KnwtghmFf+3a2yxhNvc0wNRFTHos7pFeB 2DQHiDBlVgdrAEzerE2pOqNJgB30A9/8ubI9Kvj+fyKmu4KX09H7i3HtXByHRQyurJr1 GOoW2lr1Tm/jWoKdrlxH47psCowThsU8YqlzDUf90ks3zBNlg3wTGU8pFq1aguvh9fl+ aeXLMg9nIpkALYo9oRxYGVpuzgrZBpsOFBRZCDBrDQ3JkTtPHJ8W7DrKDGOmBxpWBZK3 8TKRWwieVuYyO0lDhlSpr8ZV8E4W48WcWYHRHHKm1UirO7kEYuRFiwVsiQ30sp1ratr1 6ZSQ== 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:content-transfer-encoding; bh=i0ST1QdQjmG4p4E1eOpvzg8LFB1vARAzNS6MuKF/Cl0=; b=E16mT4A+gyZGhy8jU62fb2JIcrwy2AnXgt97F/OiPigowRrqnT9hmpgNYLkxA9pj+j WWEKJPxojC3FpSL+bNT9dmAq4pEO9f5IRAxeJcn7QD0n1RQVBt60OxEiXqvmfo8vySAf sNX3OYnNNIGeHtTPNKs2FRL5IIw0/Cj6dna2HrCkuGZClhPsP+3TP5jNQpjfP2S9JeDP Pb8xjbmXt4M67S/vB4ZKxYGvqrrB+aHuSEHNR8uSL7j7rqwv+Ma5DCarvlvQrLTLX0ki 9Ca1BJR7GtnoYrjMuw0l2g71KNLPvSrFl77lBKFEaZNpQKBSxPUiUYH/0Q6Gqr7+P7Ln SsQg== X-Gm-Message-State: AN3rC/4L1WjP1JeRLf5CG4obY/p+h4Pjx+N9x0nQ62r0ubISNpULAK/urgp47Rsd/N16LPj3UpgqUq8ZeVb2MQ== X-Received: by 10.233.235.14 with SMTP id b14mr6411989qkg.86.1491491377869; Thu, 06 Apr 2017 08:09:37 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Thu, 6 Apr 2017 08:09:37 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 6 Apr 2017 08:09:37 -0700 X-Google-Sender-Auth: OdG_Uv20Id82_UmPNyUWHECvKvs Message-ID: To: V6ops Chairs Cc: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:09:41 -0000 At Wed, 5 Apr 2017 20:45:27 -0700, Fred Baker wrote: > > Who cares? I just want something to be MTI. Getting DHCPv6 to > > be MTI requires more work than getting RDNSS to be MTI. > > Insisting on "both or neither" means that it has to be done in a > > single document, and that document probably won't be this > > document. > Let me restate this "virtual hum". Someone replied with a better question= , and now I'm asking it, v2. Again, the reply-to on this message is v6ops-c= hairs@ietf.org, in order to not deluge people (and the archive) with "+1" r= esponses. I'll summarize next week; the time to respond is now. > > Do we agree to, in some document, make RDNSS and DHCP Relay > "Mandatory to Implement" in the router, with a view to supporting > both classes of networks? > > Four possible answers: > (1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD or = MUST) in the router > (2) A router MUST implement RDNSS, and MAY implement DHCP Relay or a DHCP= server. > (3) A router MUST implement DHCP Relay, and MAY implement RDNSS > (4) The market decides. RDNSS and DHCP (Relay or server) *MAY* be impleme= nted in a router. This is the present state. I don't see the point of answer #2 and #3 in this context. I thought the main purpose of this MTI discussion is to guarantee an implementation situation where any combination of hosts and routers (and DHCPv6 servers if DHCPv6 is used) can work as long as these nodes are configured as such, or just say nothing about this topic. In that sense #2 and #3 don't help since some host implementations don't support RDNSS and some other host implementations don't support DHCPv6. If we want to include these choices, don't these have to come with a requirement to host implementations? That is: (2') A router MUST implement RDNSS, and MAY implement DHCP Relay or a DHCP server. A host MUST implement RDNSS, and MAY implement stateless DHCPv6. (3') A router MUST implement DHCP Relay, and MAY implement RDNSS. A host MUST implement stateless DHCPv6, and MAY implement RDNSS. -- JINMEI, Tatuya From nobody Thu Apr 6 08:35: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 38FB4127599 for ; Thu, 6 Apr 2017 08:35:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 Hkrrqu3eViWw for ; Thu, 6 Apr 2017 08:35:50 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 418B812942F for ; Thu, 6 Apr 2017 08:35:50 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id d188so44524282vka.0 for ; Thu, 06 Apr 2017 08:35:50 -0700 (PDT) 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=9jEfCWn7RmdICj50fgr6B5TUWdSLcj3hW76efc3yEh8=; b=nRVXhOnPMkUQe2miu3l5tRPiSfiz71Vuj9yLxpg5peTITAmwMpt9m1mDs4gvHKtUh3 U+AUXZdiZ+jwLowxJnYp+N5WnAfH3gvZqdcUP+RZCLSvt2YNLSnF/SC0dhGgyjArUM0g BgFBUwLwYjBQKdEybXZpmasvpT7H/jseoOA/p9fLqqdM6ZlYT6Emv5wGTuF1OkpZi+KC nW2Uv5QhpnjC92K262EkzE3wOIhwrPB2E0dAx0xf/0mdP9QJsAxZ8u53zOEhByhLWjbH PxkhWJWIQEa/mzSiDflesOYDCFoL4yn+nbdzxEV3dHnO2STQn9tCk/tTdq0r4tIqfOr6 6CXw== 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=9jEfCWn7RmdICj50fgr6B5TUWdSLcj3hW76efc3yEh8=; b=M43LYG5oeESLY6K+u/Guw/K+w5LO69pKC/DMP7Mg5RD/uW6HWDvSuXs9ozbUBf0rDh +T5QyeDTverv9JkRsliHnsUihTsAPQdrdd832b6cwsqyqR3nlGy7s+h9Igckg2v955/m MB714wZfAfzflpf8qqA+7crI1mWs3zOMBmHBjmeourbrmIWtiRtwpvT0B4KOi1RNZObs 388TXt4hxHQGmmirLTv9AlwEc+73S7S1aZ92q3R72iLfJLVjy/5uAycaupZU00ICBUxI nbtCvnN8PrhzspTNC84qbGuPlrEH3dyFlj4G26Xb5+wmbf4QTh3Zln5ijXPhrp+OaAH+ ivqw== X-Gm-Message-State: AN3rC/5+wBpVV4d+1YUp/A0GYBrlWOCq91iWom4xXSigQrJlXEwfWraGXtwS1umPNbhD3B34Pw6C+eui9xP0VF2I X-Received: by 10.176.2.104 with SMTP id 95mr152779uas.30.1491492948876; Thu, 06 Apr 2017 08:35:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Thu, 6 Apr 2017 08:35:28 -0700 (PDT) In-Reply-To: References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 00:35:28 +0900 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: V6ops Chairs , IPv6 Operations Content-Type: multipart/alternative; boundary=001a1134ee3867aa20054c8143a6 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:35:52 -0000 --001a1134ee3867aa20054c8143a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 7, 2017 at 12:09 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > (1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD o= r > MUST) in the router > > (2) A router MUST implement RDNSS, and MAY implement DHCP Relay or a > DHCP server. > > (3) A router MUST implement DHCP Relay, and MAY implement RDNSS > > (4) The market decides. RDNSS and DHCP (Relay or server) *MAY* be > implemented in a router. This is the present state. > > I don't see the point of answer #2 and #3 in this context. I thought > the main purpose of this MTI discussion is to guarantee an > implementation situation where any combination of hosts and routers > (and DHCPv6 servers if DHCPv6 is used) can work as long as these nodes > are configured as such, or just say nothing about this topic. In that > sense #2 and #3 don't help since some host implementations don't > support RDNSS and some other host implementations don't support > DHCPv6. If we want to include these choices, don't these have to come > with a requirement to host implementations? That is: > > (2') A router MUST implement RDNSS, and MAY implement DHCP Relay or a > DHCP server. A host MUST implement RDNSS, and MAY implement > stateless DHCPv6. > (3') A router MUST implement DHCP Relay, and MAY implement RDNSS. A > host MUST implement stateless DHCPv6, and MAY implement RDNSS. > Right. Specifying only one side of the equation won't solve the interoperability problem. Which is why I said earlier that there's no point trying to answer the router question without considering the host question. --001a1134ee3867aa20054c8143a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 12:09 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
> (1) RDNSS and DHCP Relay (or a DHCP server) are both required= (SHOULD or MUST) in the router
> (2) A router MUST implement RDNSS, and MAY implement DHCP Relay or a D= HCP server.
> (3) A router MUST implement DHCP Relay, and MAY implement RDNSS
> (4) The market decides. RDNSS and DHCP (Relay or server) *MAY* be impl= emented in a router. This is the present state.

I don't see the point of answer #2 and #3 in this context.=C2=A0= I thought
the main purpose of this MTI discussion is to guarantee an
implementation situation where any combination of hosts and routers
(and DHCPv6 servers if DHCPv6 is used) can work as long as these nodes
are configured as such, or just say nothing about this topic.=C2=A0 In that=
sense #2 and #3 don't help since some host implementations don't support RDNSS and some other host implementations don't support
DHCPv6.=C2=A0 If we want to include these choices, don't these have to = come
with a requirement to host implementations?=C2=A0 That is:

(2') A router MUST implement RDNSS, and MAY implement DHCP Relay or a =C2=A0 =C2=A0 =C2=A0DHCP server.=C2=A0 A host MUST implement RDNSS, and MAY= implement
=C2=A0 =C2=A0 =C2=A0stateless DHCPv6.
(3') A router MUST implement DHCP Relay, and MAY implement RDNSS.=C2=A0= A
=C2=A0 =C2=A0 =C2=A0host MUST implement stateless DHCPv6, and MAY implement= RDNSS.

Right. Specifying only one side= of the equation won't solve the interoperability problem. Which is why= I said earlier that there's no point trying to answer the router quest= ion without considering the host question.=C2=A0
--001a1134ee3867aa20054c8143a6-- From nobody Thu Apr 6 08:47: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 DEED5129400 for ; Thu, 6 Apr 2017 08:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 ZrAqj0VzvlpJ for ; Thu, 6 Apr 2017 08:47:27 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 9317D126BF7 for ; Thu, 6 Apr 2017 08:47:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36FlN86166700 for ; Thu, 6 Apr 2017 17:47:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2927F206614 for ; Thu, 6 Apr 2017 17:47:23 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1FA422062F7 for ; Thu, 6 Apr 2017 17:47:23 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36FlMGg006060 for ; Thu, 6 Apr 2017 17:47:23 +0200 To: v6ops@ietf.org References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> From: Alexandre Petrescu Message-ID: Date: Thu, 6 Apr 2017 17:47:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:47:29 -0000 Le 05/04/2017 à 16:15, Erik Kline a écrit : > > On 5 April 2017 at 23:06, Tim Chown > wrote: > >> On 5 Apr 2017, at 14:28, Timothy Winters > > wrote: >> >> Hi Tim, >> >> I would add that supporting 3736 as Relay Agent. I'm guessing >> that many routers will just use the relay function to send the DHCP >> messages to a central server. > > Yes, indeed. > > It’s basically what Owen was proposing what feels like a few hundred > emails ago; a clear model for hosts and routers, but adding > qualifications for the SHOULD. I think my MUSTs and SHOULDs are the > same as he proposed. > > Tim > > > We shouldn't pretend, though, that DHCPv6 DNS and RA DNS are the > same and the choice is between two equal things. > > From my point of view, RA DNS is way more expressive and useful than > DHCPv6 DNS. > > Specifically, consider the case where 2 RAs are sent on the network > each with different PIOs, RIOs, and RDNSS sets. End nodes can > associate all this information with each next hop, I am not sure how precisely this works (associate DNS resolver with a next hop). Or maybe it is the rt table lookup that make it sound so. I will have to look. > and make better, logically consistent use of essentially two > different networks a la RFCs 7556 and 8028. > > I don't think DHCPv6 DNS can do that. Err- resolv.conf associates a domain name to a resolver IP address. A smartphone with WiFi and cellular gets a different domain name per interface. (true - some clients over-write resolv.conf, instead of appending to it, but that's another matter). Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Apr 6 08:50: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 0437E129531 for ; Thu, 6 Apr 2017 08:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 gAhNb2slv2-f for ; Thu, 6 Apr 2017 08:50:33 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 2B41E12953A for ; Thu, 6 Apr 2017 08:50:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36FoLiV027846 for ; Thu, 6 Apr 2017 17:50:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5342C209CB6 for ; Thu, 6 Apr 2017 17:50:21 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 49F47209CB0 for ; Thu, 6 Apr 2017 17:50:21 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36FoKKE007957 for ; Thu, 6 Apr 2017 17:50:21 +0200 To: v6ops@ietf.org References: <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405.164601.74682422.sthaug@nethelp.no> From: Alexandre Petrescu Message-ID: <28cdeef7-c768-1ba0-09d4-63d9efa25644@gmail.com> Date: Thu, 6 Apr 2017 17:49:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170405.164601.74682422.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:50:35 -0000 Le 05/04/2017 à 16:46, sthaug@nethelp.no a écrit : >> Is a way forward to say >> >> a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and routers; it's not a significant implementation or running cost to any device, and an operator may still choose whether to use it or not >> >> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in routers, noting implementation on IoT and constrained devices may not be realistic (noting Owen's posted figures), but that managed enterprise environments will expect other configuration information beyond RDNSS and DNSSL to be available, so that local services can be used (rather than, say, Google DNS or time servers). Again, it's up to the operator to enable it > > I'd actually like to explore a slightly different scenario for hosts: > RFC3736 stateless DHCP *and* RFC3633 Prefix Delegation both being MUST > for hosts (but not RFC3315 IA_NA/IA_TA). > > I'm suggesting this because my impression is that at least some of the > resistance against DHCPv6 for hosts is the fact that IA_NA only gives > you *one* address. Prefix delegation can hand out a /56 or a /48 if > needed. Yes, prefix delegation is supposed to be for routers - but in > my book an Android with several other devices tethered behind it is > definitely a router. > > It's of course entirely possible that prefix delegation doesn't make > DHCPv6 any more interesting for those who are opposed today. Having > some idea of the status here would be interesting. There is this PIO-X proposal over in 6MAN. PIO-X is almost Prefix Delegation in ND messaging. I disagree with it, but there it is. Alex > > Steinar Haug, AS2116 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Apr 6 09:03: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 3E91E126BF7 for ; Thu, 6 Apr 2017 09:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 oC1TvuGy4Ii6 for ; Thu, 6 Apr 2017 09:03:06 -0700 (PDT) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 64FFB1270B4 for ; Thu, 6 Apr 2017 09:03:05 -0700 (PDT) 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 v36G35ZD013312 for ; Thu, 6 Apr 2017 12:03:05 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v36G35ZD013312 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1491494585; bh=5Mg8ADAwE6pBc1J25BripLgRAYKcZmSqs3PlGdOTIJQ=; h=Date:From:To:Subject:References:In-Reply-To; b=BplT1jc7784IcWMiSdfsI9WFhTOESiTiSRjKnmE/hvSQ/Ve6ZtZJu5g+Bp5z67VOT XKQROs+8SljmVqXVD7nHWEVl528wOzHCRKSHgXlLOyiHeg/1WnB6Fdwic4eJyaVWWQ ZO5l2xiOvJoj9W4OS8TbA2Z6hjuggeliLht4LlAE= 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 v36G35BY013306 for ; Thu, 6 Apr 2017 12:03:05 -0400 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 v36G34rD018482 for ; Thu, 6 Apr 2017 12:03:05 -0400 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 520EDE0F5E; Thu, 6 Apr 2017 12:03:04 -0400 (EDT) Date: Thu, 6 Apr 2017 12:03:04 -0400 From: Chuck Anderson To: v6ops@ietf.org Message-ID: <20170406160303.GG4764@angus.ind.wpi.edu> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> 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=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_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_900_999 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_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:03:11 -0000 On Fri, Apr 07, 2017 at 12:35:28AM +0900, Lorenzo Colitti wrote: > > DHCPv6. If we want to include these choices, don't these have to come > > with a requirement to host implementations? That is: > > > > (2') A router MUST implement RDNSS, and MAY implement DHCP Relay or a > > DHCP server. A host MUST implement RDNSS, and MAY implement > > stateless DHCPv6. > > (3') A router MUST implement DHCP Relay, and MAY implement RDNSS. A > > host MUST implement stateless DHCPv6, and MAY implement RDNSS. > > > > Right. Specifying only one side of the equation won't solve the > interoperability problem. Which is why I said earlier that there's no point > trying to answer the router question without considering the host question. Given that you have said that gaining rough consensus on host behavior is unlikely, does this mean you are for option (4), do nothing? From nobody Thu Apr 6 09:05: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 203EA1270B4 for ; Thu, 6 Apr 2017 09:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oweJIMT0f7hM for ; Thu, 6 Apr 2017 09:04:57 -0700 (PDT) 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 EF31D128D2E for ; Thu, 6 Apr 2017 09:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2873; q=dns/txt; s=iport; t=1491494694; x=1492704294; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3UIXg1MCkemUAyOXKJ7Kin1S2T1gTTPJjiY69QMyfls=; b=Nz/+98WmYYpsu8v/F56sZ4ddF4npE99vxTD+N3CemLN6YR9SR1xnvBvb 52r7zphO7/beltvH8jZQFifzMmf/oL1nGKMg4N0Pni+F3ecXa1WWqcK0T J4qcphUsybkAOBSESSaTmi1xp+gqzX4Ly0qLooIGW8W5um/0M/Koxaabu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCzZuZY/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjW6RPZVVgg8fC4V4AoNFPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBAQFsEAcEAgEIEQQBASgHJwsUCQgCBAESCIl+CA6sU4pmAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWLPoRAPIU/BZAqjEkBkkmRRpN3AR84SzpbFUGGWgF1iFK?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,160,1488844800"; d="scan'208";a="227856396" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2017 16:04:54 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v36G4rkL005141 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2017 16:04:54 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 11:04:53 -0500 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, 6 Apr 2017 11:04:53 -0500 From: "Bernie Volz (volz)" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST? Thread-Index: AQHSru1xcCIh4JqwF0K0H7rCJjQ0haG4gFGQ Date: Thu, 6 Apr 2017 16:04:53 +0000 Message-ID: <7e68abca9b9042bc977b155e3a4d914f@XCH-ALN-003.cisco.com> References: <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405.164601.74682422.sthaug@nethelp.no> <28cdeef7-c768-1ba0-09d4-63d9efa25644@gmail.com> In-Reply-To: <28cdeef7-c768-1ba0-09d4-63d9efa25644@gmail.com> 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.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:05:04 -0000 > I'm suggesting this because my impression is that at least some of the=20 > resistance against DHCPv6 for hosts is the fact that IA_NA only gives=20 > you *one* address. Just for you information: If a host wanted 3 addresses, it can just include 3 IA_NAs in the Solicit/R= equest. DHCPv6 allows a host to get many addresses, not just 1. Note: A DHCPv6 server might actually return more than one address for a sin= gle IA_NA instance, but that depends on the server's policy (configuration)= . And, I think those not in favor of DHCPv6 would argue a few other points. - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Thursday, April 06, 2017 11:50 AM To: v6ops@ietf.org Subject: Re: [v6ops] Making RDNSS a MUST? Le 05/04/2017 =E0 16:46, sthaug@nethelp.no a =E9crit : >> Is a way forward to say >> >> a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and=20 >> routers; it's not a significant implementation or running cost to any=20 >> device, and an operator may still choose whether to use it or not >> >> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in=20 >> routers, noting implementation on IoT and constrained devices may not=20 >> be realistic (noting Owen's posted figures), but that managed=20 >> enterprise environments will expect other configuration information=20 >> beyond RDNSS and DNSSL to be available, so that local services can be=20 >> used (rather than, say, Google DNS or time servers). Again, it's up=20 >> to the operator to enable it > > I'd actually like to explore a slightly different scenario for hosts: > RFC3736 stateless DHCP *and* RFC3633 Prefix Delegation both being MUST=20 > for hosts (but not RFC3315 IA_NA/IA_TA). > > I'm suggesting this because my impression is that at least some of the=20 > resistance against DHCPv6 for hosts is the fact that IA_NA only gives=20 > you *one* address. Prefix delegation can hand out a /56 or a /48 if=20 > needed. Yes, prefix delegation is supposed to be for routers - but in=20 > my book an Android with several other devices tethered behind it is=20 > definitely a router. > > It's of course entirely possible that prefix delegation doesn't make > DHCPv6 any more interesting for those who are opposed today. Having=20 > some idea of the status here would be interesting. There is this PIO-X proposal over in 6MAN. PIO-X is almost Prefix Delegati= on in ND messaging. I disagree with it, but there it is. Alex > > Steinar Haug, AS2116 > > _______________________________________________ > 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 Apr 6 09:07: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 A1674128854 for ; Thu, 6 Apr 2017 09:07:13 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 aa9iQ_taQ-S2 for ; Thu, 6 Apr 2017 09:07:12 -0700 (PDT) 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 441DB126BF7 for ; Thu, 6 Apr 2017 09:07:06 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r69so46256986vke.2 for ; Thu, 06 Apr 2017 09:07:06 -0700 (PDT) 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=mN3byyBYUKhorvdtzP6MaobimZoAqwPf87oY8TTo7dM=; b=idP6DPFvQCyTuG4CgxgsyhcILsAfuwec+7lu/Updl1fAqLR3fJ1Dbn1WtAm2a3XI3h gbq3rehVm8iWlzmRwOm5Sy8DClu2qom61obUB8hFgiRMHvhbTKfXJdBjYkZSOw0mc4wp ZfpbxCbmG4pzwoQW0UNjG5sjlJBT3KcCvn1Mw0YufiKkJwCBpeaAo1tXt2W8C3WZFWaz diekKLK7/cuxKVW0u2usm687NGqJyNoCOOhKdHxcNhxxBa1svPrYLCsD5ZbxWQjlMslT OzmR0VTWmW8Om09kETWDUWqbZA80nh0DKqEB/CP5efefvWHF7ec1qd6hOyIQ1DC5XabS cS5g== 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=mN3byyBYUKhorvdtzP6MaobimZoAqwPf87oY8TTo7dM=; b=CaI9LkSnoYgvkQXK8UFSHHD5zLosymH9uQdJKkEpqECGNnpw6dB4t+kECQZXsbM09q vJK2Tbop6Oc3m5vejc3rwbyy2m9vaynWp0LXiYO7Fow8D45QK3oCAqEPzem+9Ihgq57k VJsNRC7MSWyKID8VoHNk6M73a6yAJYfUAVc12Osk46V/Szkb+Xuj6y8DhE6y3slddDDx fRiiBCRVXa165yQiharcEvL+4fgiLr9H9beLv+mI2f2bjQ8+GUlaHYgXx6w8GJLP++3U 7h3LOHSL4vSlZxA8slIO84JpHS76rGu09tsbBz+4S5BESfR2HoQgUyh24tEMPck7WIh5 TCJg== X-Gm-Message-State: AN3rC/7QcEfB8Gl3zzS8BY3GDyvpTH5y3oFULraPzdY0AwioangHyZHJ0PZN97uNj11iLpBlUxVPegSnRYLKDHt1 X-Received: by 10.176.2.104 with SMTP id 95mr227213uas.30.1491494824908; Thu, 06 Apr 2017 09:07:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Thu, 6 Apr 2017 09:06:44 -0700 (PDT) In-Reply-To: <20170406160303.GG4764@angus.ind.wpi.edu> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406160303.GG4764@angus.ind.wpi.edu> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 01:06:44 +0900 Message-ID: To: Chuck Anderson Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a1134ee3839fda9054c81b38e Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:07:14 -0000 --001a1134ee3839fda9054c81b38e Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 1:03 AM, Chuck Anderson wrote: > Given that you have said that gaining rough consensus on host behavior > is unlikely, does this mean you are for option (4), do nothing? > I didn't say that. I said that gaining rough consensus on saying that DHCPv6 is a MUST for hosts seems unlikely. I'm still not sure that we can't reach rough consensus to say RDNSS is a MUST for hosts. --001a1134ee3839fda9054c81b38e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 1:03 AM, Chuck Anderson <cra@wpi.edu> wrote:
Given that you have said that gaining rough= consensus on host behavior
is unlikely, does this mean you are for option (4), do nothing?

I didn't say that. I said that gaining rough c= onsensus on saying that DHCPv6 is a MUST for hosts seems unlikely. I'm = still not sure that we can't reach rough consensus to say RDNSS is a MU= ST for hosts.
--001a1134ee3839fda9054c81b38e-- From nobody Thu Apr 6 09:08: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 25AAE128854 for ; Thu, 6 Apr 2017 09:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 fxaSZHBiItEb for ; Thu, 6 Apr 2017 09:08:21 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 6E14A129545 for ; Thu, 6 Apr 2017 09:08:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36G8AkQ020992 for ; Thu, 6 Apr 2017 18:08:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 770D3209CB0 for ; Thu, 6 Apr 2017 18:08:10 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6CC96209CA1 for ; Thu, 6 Apr 2017 18:08:10 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36G8Aaq020282 for ; Thu, 6 Apr 2017 18:08:10 +0200 To: v6ops@ietf.org References: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> From: Alexandre Petrescu Message-ID: Date: Thu, 6 Apr 2017 18:07:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:08:23 -0000 Le 06/04/2017 à 00:04, Ted Lemon a écrit : > On Apr 5, 2017, at 2:49 PM, Mark Smith > wrote:\ >> Devices like this Chromebook are getting their time by having >> hardcoded, Internet located NTP server addresses in their firmware. >> There are potential trust, privacy and reliability issues with that >> sort of model. > > It's probably got a domain name, not an IP address, encoded. And it > might even have a pre-shared key, although that's not ideal. And it > probably has an RTC with a battery, so that it can reject really weird > values, closing the window of opportunity for replay of compromised keys > quite substantially. > > So in practice, all it needs in order to use the network is a working > default route and a pair of working DNS resolvers. No no, I disagree. NTP timeservers change: some disappear. (so until DNS gets updated with that there is a risk). Batteries get depleted. Cheap CR2032 on BIOS lasts shorter than high-quality. Car 12V battery in the cold, or even the powerful batteries of electrical cars are all risking depletion under certain conditions. Some times even a daylight savings time change can disrupt (think server in a country not consdiering DST like S Korea and client in a country considering DST, like, well, let's say, Argentina). Some IP protocols break when the ends have too disparate times. I went through a few emergencies because of each of these. Alex > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Apr 6 09:14: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 3CF061293E1 for ; Thu, 6 Apr 2017 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 z0xYDYjRyyGC for ; Thu, 6 Apr 2017 09:14:22 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 8E8F51270B4 for ; Thu, 6 Apr 2017 09:14:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36GEKRU022644 for ; Thu, 6 Apr 2017 18:14:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F039D209CCD for ; Thu, 6 Apr 2017 18:14:20 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E63F6209CB0 for ; Thu, 6 Apr 2017 18:14:20 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36GEKpD023732 for ; Thu, 6 Apr 2017 18:14:20 +0200 To: v6ops@ietf.org References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> From: Alexandre Petrescu Message-ID: <25242d6d-54ec-abe7-9129-a038f7c22e9f@gmail.com> Date: Thu, 6 Apr 2017 18:13:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:14:24 -0000 (1) Le 06/04/2017 à 05:45, Fred Baker a écrit : > >> On Apr 5, 2017, at 4:00 PM, Ted Lemon wrote: >> >> Who cares? I just want something to be MTI. Getting DHCPv6 to be MTI requires more work than getting RDNSS to be MTI. Insisting on "both or neither" means that it has to be done in a single document, and that document probably won't be this document. > > Let me restate this "virtual hum". Someone replied with a better question, and now I'm asking it, v2. Again, the reply-to on this message is v6ops-chairs@ietf.org, in order to not deluge people (and the archive) with "+1" responses. I'll summarize next week; the time to respond is now. > > Do we agree to, in some document, make RDNSS and DHCP Relay "Mandatory to Implement" in the router, with a view to supporting both classes of networks? > > Four possible answers: > (1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD or MUST) in the router > (2) A router MUST implement RDNSS, and MAY implement DHCP Relay or a DHCP server. > (3) A router MUST implement DHCP Relay, and MAY implement RDNSS > (4) The market decides. RDNSS and DHCP (Relay or server) *MAY* be implemented in a router. This is the present state. > > Note also that, to me, the question answers itself. But I want the WG's viewpoint. > > The next question is "in what document". > > https://tools.ietf.org/html/rfc3736 > 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for > IPv6. R. Droms. April 2004. (Format: TXT=18510 bytes) (Status: > PROPOSED STANDARD) (DOI: 10.17487/RFC3736) > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Apr 6 09:19: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 0AE051276AF for ; Thu, 6 Apr 2017 09:19:47 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 ws3Pm3QqZrWP for ; Thu, 6 Apr 2017 09:19:45 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 0ABB3129549 for ; Thu, 6 Apr 2017 09:19:36 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d188so46089903vka.0 for ; Thu, 06 Apr 2017 09:19:35 -0700 (PDT) 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=+6bI9KfnUVOGmgSLpZPAJ68+YrBqQq3RP0Fn1syXuns=; b=s5mkClcvvfc0+Fn2VCg9UB7i8UEyDuiJww5x7ud4lT3q8YJmXFS37IYh1GP9WeGkpy sH4tYwWO/NXc3L3lFoPJtX3iZO4mUFq/3KNB6Nke1rvuIoDy7Yb0shB0UTOn7F0bQZJY jTSk2PN208k9Nj1yZcDNYNSgLNfdecLBmRWukCIzCnVDwbmH8HQgc8Dgr4dW0XfqOIUa NnTST4HAPn/MdDQ+2DrnK+FZzFr3uz48JjkugCukzwQykP3kofFUH89d15iQnWFcZ7Qo m3m0f5/FZyf2C4ADzR75hUFMgQ/vIq5XUHC9877Y8v4B2VhIT0smDUJNmfOx7g1gE+bS NNGQ== 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=+6bI9KfnUVOGmgSLpZPAJ68+YrBqQq3RP0Fn1syXuns=; b=WxaT+ZRMjlNV1z/y6yaEQPVRjEG92lmxA4eY22tbAEljAFdMgYOnWgbaczThNbgAkS zEgvv5SRwrYEZcaH/O7fPKmpKISoT7G4A2s6goSAXvrB68A1RPg5/ODe3+D0Aktx76no VRbb11meV+Fws1Wwx9eh9ougneRodvE8SQV+V+WzNAk7FLc0e/wnjju2x2WHZ+SUZ2Xn uUl+gH1MQeRyKtyuaOIDNhtluij13suu1igoSEA70sdy+MBnYmjMSyxEr77W2rXtbRQj OyFUY9OGVPOzremsSsyjR49DFZQ0c0PrYOREQl67QVjVyqRlxWDIlN392HVDCw2Jbce6 +DKg== X-Gm-Message-State: AFeK/H2Top3K0hdzDfvzHNNylxQixqQdHK9OwWRo2anqGjmgn2Q94EOLZ6GQFbnN0/oYBey8sSvmea52aG5X1J7L X-Received: by 10.31.107.93 with SMTP id g90mr16138056vkc.155.1491495574868; Thu, 06 Apr 2017 09:19:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Thu, 6 Apr 2017 09:19:14 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 01:19:14 +0900 Message-ID: To: "STARK, BARBARA H" Cc: Erik Kline , Timothy Winters , IPv6 Operations , Tore Anderson Content-Type: multipart/alternative; boundary=001a11478dd0ece8a2054c81df8c Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:19:47 -0000 --001a11478dd0ece8a2054c81df8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 6, 2017 at 11:12 PM, STARK, BARBARA H wrote: > > As a vendor of a device that is sometimes a router I am opposed to, and > have precisely zero interesting in, > > implementing a DHCPv6 relay or server function. It adds nothing, and > can actually break clients that prefer > > DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.=E2=80=8B > > [...] > > 2. You say you don't want to break clients (hosts) that prefer DHCPv6 DNS > over RDNSS. Since you oppose DHCPv6 relay or server (in the absence of a > qualifier I take server to mean stateful or stateless -- so you oppose bo= th > types of server?), does this mean you believe the way to prevent breakage > is to only offer RDNSS to clients (so their preference is irrelevant, and > they had better also implement RDNSS in spite of their preference)? I think this is the sort of thing that Erik opposes. I thought I had sent it to the list, but actually it was an off-list reply. =3D=3D=3D=3D The Android phone in my pocket is a router when I go to the coffee shop every morning and turn on tethering. As the maintainer of that code, I absolutely do not want to spend software engineering time writing a DHCPv6 server that is not only less capable than the RDNSS implementation that we have now, but also degrades functionality. The reason it is degrades functionality is that with stateless DHCPv6 it is impossible to implement even such basic things as "tell the client that its DNS server is now gone because the cellular network went down and came back up with a different prefix when you temporarily lost cell coverage". This works today using RDNSS, but if we implement DHCPv6, this will stop working for clients that support DHCPv6, even if they also support RDNSS. 1. Client gets DNS addresses from both RDNSS and DHCPv6, and prefers DHCPv6 due to RFC 8106. 2. Upstream goes down. We deprecate the prefix (we can't make it invalid because of the 2-hour rule), and declare the DNS servers invalid. We can= 't do anything about DHCPv6. 3. The upstream comes back with a new prefix. We announce the new DNS servers using RDNSS. But the client still uses the out-of-date DHCPv6-provided DNS servers, because RFC 8106 says it should prefer DHCP= v6 over RDNSS. I cannot live with breaking user experience like this. =3D=3D=3D=3D --001a11478dd0ece8a2054c81df8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 6, 2017 at 11:12 PM, STARK, BARBARA H <bs7652@att.com> = wrote:
> As a vendor of a device that is sometimes a router I am oppose= d to, and have precisely zero interesting in,
> implementing a DHCPv6 relay or server function.=C2=A0 It adds nothing,= and can actually break clients that prefer
> DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.=E2=80=8B<= br>
[...]

2. You say you don't want to break clients (hosts) that prefer DHCPv6 D= NS over RDNSS. Since you oppose DHCPv6 relay or server (in the absence of a= qualifier I take server to mean stateful or stateless -- so you oppose bot= h types of server?), does this mean you believe the way to prevent breakage= is to only offer RDNSS to clients (so their preference is irrelevant, and = they had better also implement RDNSS in spite of their preference)?

I think this is the sort of thing that Erik oppose= s. I thought I had sent it to the list, but actually it was an off-list rep= ly.

=3D=3D=3D=3D
The Android phone = in my pocket is a router when I go to the coffee shop every morning and tur= n on tethering. As the maintainer of that code, I absolutely do not want to= spend software engineering time writing a DHCPv6 server that is not only l= ess capable than the RDNSS implementation that we have now, but also degrad= es functionality.

The reason it is degrades functi= onality is that with stateless DHCPv6 it is impossible to implement even su= ch basic things as "tell the client that its DNS server is now gone be= cause the cellular network went down and came back up with a different pref= ix when you temporarily lost cell coverage". This works today using RD= NSS, but if we implement DHCPv6, this will stop working for clients that su= pport DHCPv6, even if they also support RDNSS.
  1. Client gets DNS addresses f= rom both RDNSS and DHCPv6, and prefers DHCPv6 due to RFC 8106.
  2. Upstream goes down. We deprecate the prefix (we = can't make it invalid because of the 2-hour rule), and declare the DNS = servers invalid. We can't do anything about DHCPv6.
  3. The upstream comes back with a new prefix. We announce the = new DNS servers using RDNSS. But the client still uses the out-of-date DHCP= v6-provided DNS servers, because RFC 8106 says it should prefer DHCPv6 over= RDNSS.
I cannot live with bre= aking user experience like this.
=3D=3D=3D=3D
--001a11478dd0ece8a2054c81df8c-- From nobody Thu Apr 6 09:28: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 DAD4012894A for ; Thu, 6 Apr 2017 09:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 3hx-6D3Eo1Gg for ; Thu, 6 Apr 2017 09:28:49 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 2C621129550 for ; Thu, 6 Apr 2017 09:28:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36GSP1k039128 for ; Thu, 6 Apr 2017 18:28:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 63B46209DBD for ; Thu, 6 Apr 2017 18:28:25 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5A4DC209CCD for ; Thu, 6 Apr 2017 18:28:25 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36GSPer021156 for ; Thu, 6 Apr 2017 18:28:25 +0200 To: v6ops@ietf.org References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Alexandre Petrescu Message-ID: Date: Thu, 6 Apr 2017 18:28:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? - tethering, DHCPv6, RDNSS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:28:51 -0000 Le 06/04/2017 à 18:19, Lorenzo Colitti a écrit : [...] > The Android phone in my pocket is a router when I go to the coffee > shop every morning and turn on tethering. Tethering? Which standard is that? > As the maintainer of that code, I absolutely do not want to spend > software engineering time writing a DHCPv6 server that is not only > less capable than the RDNSS implementation that we have now, but also > degrades functionality. Please ask the maintainer of that code which standard is s/he using for tethering, before we can discuss DNS-in-RA or -in-DHCP. Alex > The reason it is degrades functionality is that with stateless DHCPv6 > it is impossible to implement even such basic things as "tell the > client that its DNS server is now gone because the cellular network > went down and came back up with a different prefix when you > temporarily lost cell coverage". This works today using RDNSS, but if > we implement DHCPv6, this will stop working for clients that support > DHCPv6, even if they also support RDNSS. > > 1. Client gets DNS addresses from both RDNSS and DHCPv6, and prefers > DHCPv6 due to RFC 8106. 2. Upstream goes down. We deprecate the > prefix (we can't make it invalid because of the 2-hour rule), and > declare the DNS servers invalid. We can't do anything about DHCPv6. > 3. The upstream comes back with a new prefix. We announce the new > DNS servers using RDNSS. But the client still uses the out-of-date > DHCPv6-provided DNS servers, because RFC 8106 says it should prefer > DHCPv6 over RDNSS. > > I cannot live with breaking user experience like this. ==== > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Apr 6 09:31: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 BA471129562 for ; Thu, 6 Apr 2017 09:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wBhE5HyMxVQR for ; Thu, 6 Apr 2017 09:31:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB98F12954A for ; Thu, 6 Apr 2017 09:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36240; q=dns/txt; s=iport; t=1491496259; x=1492705859; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b/HodOI1LEuGib0KXa4oHjpF/DK28gue7z/rfMnrGs8=; b=BRntDWmsZkKeHWXLd5Qr45EqcN2Uf9mh7SwhrPRFv+M2BsNOXlpzkR+6 NRwi+T57hZjfWQbXNfjFa6tkTtUKJb0uOOu59TyY7zu7O5Jr/8vA++4Xf nq4sRY2zlcqh6Tqo1QWMHhFKHT07DgZlUVbVaDCR3/3K4htpjiZgjyqjx 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQDYbOZY/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYELB4NcihKRPZVVgg8qgkKDNgIagys/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEjCkwFCwIBCBEEAQEBIAcDAgICMBQJCAIEDgUIEYltCA6qMYImi?= =?us-ascii?q?mYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYs+hEACKx+CUIJfBYoOjA+GVgGGfYt?= =?us-ascii?q?MggePP4heixkBHziBBVsVQYZbdQEBhyABJQSBBoENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,160,1488844800"; d="scan'208,217";a="227876175" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2017 16:30:58 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v36GUwQP000677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2017 16:30:58 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 11:30:57 -0500 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, 6 Apr 2017 11:30:57 -0500 From: "Bernie Volz (volz)" To: Lorenzo Colitti , "STARK, BARBARA H" CC: IPv6 Operations Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohLAlJXdnN5j0uTKcn23s0z76G4fOCAgAAIq4CAABMKgIAAHfQAgAAjSAD//6z/MA== Date: Thu, 6 Apr 2017 16:30:57 +0000 Message-ID: References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.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.197] Content-Type: multipart/alternative; boundary="_000_d521c13a59dc4e488d02515d673f671cXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:31:07 -0000 --_000_d521c13a59dc4e488d02515d673f671cXCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHJlYXNvbiBpdCBpcyBkZWdyYWRlcyBmdW5jdGlvbmFsaXR5IGlzIHRoYXQgd2l0aCBzdGF0 ZWxlc3MgREhDUHY2IGl0IGlzIGltcG9zc2libGUgdG8gaW1wbGVtZW50IGV2ZW4gc3VjaCBiYXNp YyB0aGluZ3MgYXMgInRlbGwgdGhlIGNsaWVudCB0aGF0IGl0cyBETlMgc2VydmVyIGlzIG5vdyBn b25lIGJlY2F1c2UgdGhlIGNlbGx1bGFyIG5ldHdvcmsgd2VudCBkb3duIGFuZCBjYW1lIGJhY2sg dXAgd2l0aCBhIGRpZmZlcmVudCBwcmVmaXggd2hlbiB5b3UgdGVtcG9yYXJpbHkgbG9zdCBjZWxs IGNvdmVyYWdlIi4gVGhpcyB3b3JrcyB0b2RheSB1c2luZyBSRE5TUywgYnV0IGlmIHdlIGltcGxl bWVudCBESENQdjYsIHRoaXMgd2lsbCBzdG9wIHdvcmtpbmcgZm9yIGNsaWVudHMgdGhhdCBzdXBw b3J0IERIQ1B2NiwgZXZlbiBpZiB0aGV5IGFsc28gc3VwcG9ydCBSRE5TUy4NCg0KVGhpcyBpcyBi b2d1cy4gSW4gdGhpcyBjYXNlIHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gaW5pdGlhdGUgREhD UHY2IHRvIGRpc2NvdmVyIG5ldyBpbmZvcm1hdGlvbi4gWWVzLCBSRkMgMzMxNS8zNzM2IHdhcyBu b3QgYXMgY2xlYXIgYXMgaXQgY291bGQgaGF2ZSBiZWVuIGFib3V0IHRoaXMgYnV0IHRoYXQgaXNu 4oCZdCBjb21wbGV0ZWx5IGZhaXIgY29tcGFyaXNvbiBiZWNhdXNlIHRoZXNlIHdlcmUgd3JpdHRl biBhIGxvbmcgdGltZSBhZ28gYW5kIHRoZSBuZXR3b3JraW5nIHdvcmxkIHdhcyBkaWZmZXJlbnQg YmFjayB0aGVuLg0KDQpSRkMgMzczNiBzdGF0ZXM6DQoNCiAgIFJGQyAzMzE1PGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmMzMzE1PiBhbHNvIGRvZXMgbm90IHByb3ZpZGUgYW55IGd1aWRh bmNlIGFib3V0IHdoZW4gYSBob3N0IG1pZ2h0DQogICB1c2UgYW4gSW5mb3JtYXRpb24tcmVxdWVz dCBtZXNzYWdlIHRvIG9idGFpbiB1cGRhdGVkIGNvbmZpZ3VyYXRpb24NCiAgIHBhcmFtZXRlcnMg d2hlbiB0aGUgaG9zdCBoYXMgbW92ZWQgdG8gYSBuZXcgbGluay4gIFRoZSBESEMgV0cgaXMNCiAg IHJldmlld2luZyBhIHJlbGF0ZWQgZG9jdW1lbnQsICJEZXRlY3Rpb24gb2YgTmV0d29yayBBdHRh Y2htZW50IChETkEpDQogICBpbiBJUHY0IiBbODxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMzczNiNyZWYtOD5dLCB3aGljaCBkZXNjcmliZXMgaG93IGEgaG9zdCB1c2luZyBJUHY0IGNh biBkZXRlcm1pbmUNCiAgIHdoZW4gdG8gdXNlIERIQ1B2NC4gIEVpdGhlciB0aGUgREhDIFdHIG9y IGEgV0cgZm9ybWVkIGZyb20gdGhlIEROQQ0KICAgQk9GIHdpbGwgdW5kZXJ0YWtlIGRldmVsb3Bt ZW50IG9mIGEgc2ltaWxhciBkb2N1bWVudCBmb3IgSVB2Ni4NCg0KQnV0IGlmIGEgaG9zdCBkZXRl Y3RzIHRoYXQgdGhpbmdzIG1heSBoYXZlIGNoYW5nZWQgKHN1Y2ggYXMgd2hlbiBhIGxpbmsgZ29l cyBkb3duKSwgaXQgd291bGQgYmUgcmF0aGVyIHNpbGx5IG9mIGl0IG5vdCB0byBwZXJmb3JtIGFu IHVwZGF0ZSBvZiBpdHMgREhDUCBpbmZvcm1hdGlvbi4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMtMDcgaGFzOg0KMTguMjxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmZjMzMxNWJpcy0wNyNzZWN0aW9uLTE4 LjI+LiAgQ2xpZW50IEJlaGF2aW9yDQogICBBIGNsaWVudCB1c2VzIHRoZSBTb2xpY2l0IG1lc3Nh Z2UgdG8gZGlzY292ZXIgREhDUCBzZXJ2ZXJzIGNvbmZpZ3VyZWQNCiAgIHRvIGFzc2lnbiBsZWFz ZXMgb3IgcmV0dXJuIG90aGVyIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBvbiB0aGUgbGluaw0K ICAgdG8gd2hpY2ggdGhlIGNsaWVudCBpcyBhdHRhY2hlZC4NCg0KICAgQSBjbGllbnQgdXNlcyBS ZXF1ZXN0LCBSZW5ldywgUmViaW5kLCBSZWxlYXNlIGFuZCBEZWNsaW5lIG1lc3NhZ2VzDQogICBk dXJpbmcgdGhlIG5vcm1hbCBsaWZlIGN5Y2xlIG9mIGFkZHJlc3NlcyBhbmQgZGVsZWdhdGVkIHBy ZWZpeGVzLg0KICAgV2hlbiBhIGNsaWVudCBkZXRlY3RzIGl0IG1heSBoYXZlIG1vdmVkIHRvIGEg bmV3IGxpbmssIGl0IHVzZXMNCiAgIENvbmZpcm0gaWYgaXQgb25seSBoYXMgYWRkcmVzc2VzIGFu ZCBSZWJpbmQgaWYgaXQgaGFzIGRlbGVnYXRlZA0KICAgcHJlZml4ZXMgKGFuZCBhZGRyZXNzZXMp LiAgSXQgdXNlcyBJbmZvcm1hdGlvbi1yZXF1ZXN0IG1lc3NhZ2VzIHdoZW4NCiAgIGl0IG5lZWRz IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gYnV0IG5vIGFkZHJlc3NlcyBhbmQgbm8gcHJlZml4 ZXMuDQoNClBlcmhhcHMgd2Ugc2hvdWxkIGJlIGEgYml0IG1vcmUgY2xlYXIgYWJvdXQgYWxsIG9m IHRoZSBjb25kaXRpb25zIGluIHRoaXMgdGV4dC4gVGhlIHRleHQgYWJvdXQgQ29uZmlybSBoYXMg YSBtb3JlIGV4dGVuc2l2ZSBsaXN0Og0KDQoxOC4yLjM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMtMDcjc2VjdGlvbi0xOC4yLjM+LiAgQ3JlYXRp b24gYW5kIFRyYW5zbWlzc2lvbiBvZiBDb25maXJtIE1lc3NhZ2VzDQoNCg0KDQogICBXaGVuZXZl ciBhIGNsaWVudCBtYXkgaGF2ZSBtb3ZlZCB0byBhIG5ldyBsaW5rLCB0aGUgcHJlZml4ZXMvDQoN CiAgIGFkZHJlc3NlcyBhc3NpZ25lZCB0byB0aGUgaW50ZXJmYWNlcyBvbiB0aGF0IGxpbmsgbWF5 IG5vIGxvbmdlciBiZQ0KDQogICBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpbmsgdG8gd2hpY2ggdGhl IGNsaWVudCBpcyBhdHRhY2hlZC4gIEV4YW1wbGVzDQoNCiAgIG9mIHRpbWVzIHdoZW4gYSBjbGll bnQgbWF5IGhhdmUgbW92ZWQgdG8gYSBuZXcgbGluayBpbmNsdWRlOg0KDQoNCg0KICAgbyAgVGhl IGNsaWVudCByZWJvb3RzIChhbmQgaGFzIHN0YWJsZSBzdG9yYWdlIGFuZCBwZXJzaXN0ZWQgREhD UA0KDQogICAgICBzdGF0ZSkuDQoNCg0KDQogICBvICBUaGUgY2xpZW50IGlzIHJlY29ubmVjdGVk IHRvIGEgbGluayBvbiB3aGljaCBpdCBoYXMgb2J0YWluZWQNCg0KICAgICAgbGVhc2VzLg0KDQoN Cg0KICAgbyAgVGhlIGNsaWVudCByZXR1cm5zIGZyb20gc2xlZXAgbW9kZS4NCg0KDQoNCiAgIG8g IFRoZSBjbGllbnQgY2hhbmdlcyBhY2Nlc3MgcG9pbnRzIChzdWNoIGFzIGlmIHVzaW5nIGEgd2ly ZWxlc3MNCg0KICAgICAgdGVjaG5vbG9neSkuDQoNCg0KLSAgICAgICAgICBCZXJuaWUNCg0KRnJv bTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG9y ZW56byBDb2xpdHRpDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDYsIDIwMTcgMTI6MTkgUE0NClRv OiBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbT4NCkNjOiBJUHY2IE9wZXJhdGlvbnMg PHY2b3BzQGlldGYub3JnPjsgVG9yZSBBbmRlcnNvbiA8dG9yZUBmdWQubm8+DQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBNYWtpbmcgUkROU1MgYSBNVVNUPywgaHVtIHYyDQoNCk9uIFRodSwgQXByIDYs IDIwMTcgYXQgMTE6MTIgUE0sIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0 bzpiczc2NTJAYXR0LmNvbT4+IHdyb3RlOg0KPiBBcyBhIHZlbmRvciBvZiBhIGRldmljZSB0aGF0 IGlzIHNvbWV0aW1lcyBhIHJvdXRlciBJIGFtIG9wcG9zZWQgdG8sIGFuZCBoYXZlIHByZWNpc2Vs eSB6ZXJvIGludGVyZXN0aW5nIGluLA0KPiBpbXBsZW1lbnRpbmcgYSBESENQdjYgcmVsYXkgb3Ig c2VydmVyIGZ1bmN0aW9uLiAgSXQgYWRkcyBub3RoaW5nLCBhbmQgY2FuIGFjdHVhbGx5IGJyZWFr IGNsaWVudHMgdGhhdCBwcmVmZXINCj4gREhDUHY2IEROUyBvdmVyIFJETlNTIHdoZW4gdGhlIHVw c3RyZWFtIElQdjYgcHJlZml4IGNoYW5nZXMu4oCLDQoNClsuLi5dDQoNCjIuIFlvdSBzYXkgeW91 IGRvbid0IHdhbnQgdG8gYnJlYWsgY2xpZW50cyAoaG9zdHMpIHRoYXQgcHJlZmVyIERIQ1B2NiBE TlMgb3ZlciBSRE5TUy4gU2luY2UgeW91IG9wcG9zZSBESENQdjYgcmVsYXkgb3Igc2VydmVyIChp biB0aGUgYWJzZW5jZSBvZiBhIHF1YWxpZmllciBJIHRha2Ugc2VydmVyIHRvIG1lYW4gc3RhdGVm dWwgb3Igc3RhdGVsZXNzIC0tIHNvIHlvdSBvcHBvc2UgYm90aCB0eXBlcyBvZiBzZXJ2ZXI/KSwg ZG9lcyB0aGlzIG1lYW4geW91IGJlbGlldmUgdGhlIHdheSB0byBwcmV2ZW50IGJyZWFrYWdlIGlz IHRvIG9ubHkgb2ZmZXIgUkROU1MgdG8gY2xpZW50cyAoc28gdGhlaXIgcHJlZmVyZW5jZSBpcyBp cnJlbGV2YW50LCBhbmQgdGhleSBoYWQgYmV0dGVyIGFsc28gaW1wbGVtZW50IFJETlNTIGluIHNw aXRlIG9mIHRoZWlyIHByZWZlcmVuY2UpPw0KDQpJIHRoaW5rIHRoaXMgaXMgdGhlIHNvcnQgb2Yg dGhpbmcgdGhhdCBFcmlrIG9wcG9zZXMuIEkgdGhvdWdodCBJIGhhZCBzZW50IGl0IHRvIHRoZSBs aXN0LCBidXQgYWN0dWFsbHkgaXQgd2FzIGFuIG9mZi1saXN0IHJlcGx5Lg0KDQo9PT09DQpUaGUg QW5kcm9pZCBwaG9uZSBpbiBteSBwb2NrZXQgaXMgYSByb3V0ZXIgd2hlbiBJIGdvIHRvIHRoZSBj b2ZmZWUgc2hvcCBldmVyeSBtb3JuaW5nIGFuZCB0dXJuIG9uIHRldGhlcmluZy4gQXMgdGhlIG1h aW50YWluZXIgb2YgdGhhdCBjb2RlLCBJIGFic29sdXRlbHkgZG8gbm90IHdhbnQgdG8gc3BlbmQg c29mdHdhcmUgZW5naW5lZXJpbmcgdGltZSB3cml0aW5nIGEgREhDUHY2IHNlcnZlciB0aGF0IGlz IG5vdCBvbmx5IGxlc3MgY2FwYWJsZSB0aGFuIHRoZSBSRE5TUyBpbXBsZW1lbnRhdGlvbiB0aGF0 IHdlIGhhdmUgbm93LCBidXQgYWxzbyBkZWdyYWRlcyBmdW5jdGlvbmFsaXR5Lg0KDQpUaGUgcmVh c29uIGl0IGlzIGRlZ3JhZGVzIGZ1bmN0aW9uYWxpdHkgaXMgdGhhdCB3aXRoIHN0YXRlbGVzcyBE SENQdjYgaXQgaXMgaW1wb3NzaWJsZSB0byBpbXBsZW1lbnQgZXZlbiBzdWNoIGJhc2ljIHRoaW5n cyBhcyAidGVsbCB0aGUgY2xpZW50IHRoYXQgaXRzIEROUyBzZXJ2ZXIgaXMgbm93IGdvbmUgYmVj YXVzZSB0aGUgY2VsbHVsYXIgbmV0d29yayB3ZW50IGRvd24gYW5kIGNhbWUgYmFjayB1cCB3aXRo IGEgZGlmZmVyZW50IHByZWZpeCB3aGVuIHlvdSB0ZW1wb3JhcmlseSBsb3N0IGNlbGwgY292ZXJh Z2UiLiBUaGlzIHdvcmtzIHRvZGF5IHVzaW5nIFJETlNTLCBidXQgaWYgd2UgaW1wbGVtZW50IERI Q1B2NiwgdGhpcyB3aWxsIHN0b3Agd29ya2luZyBmb3IgY2xpZW50cyB0aGF0IHN1cHBvcnQgREhD UHY2LCBldmVuIGlmIHRoZXkgYWxzbyBzdXBwb3J0IFJETlNTLg0KMS4gICAgICAgQ2xpZW50IGdl dHMgRE5TIGFkZHJlc3NlcyBmcm9tIGJvdGggUkROU1MgYW5kIERIQ1B2NiwgYW5kIHByZWZlcnMg REhDUHY2IGR1ZSB0byBSRkMgODEwNi4NCjIuICAgICAgIFVwc3RyZWFtIGdvZXMgZG93bi4gV2Ug ZGVwcmVjYXRlIHRoZSBwcmVmaXggKHdlIGNhbid0IG1ha2UgaXQgaW52YWxpZCBiZWNhdXNlIG9m IHRoZSAyLWhvdXIgcnVsZSksIGFuZCBkZWNsYXJlIHRoZSBETlMgc2VydmVycyBpbnZhbGlkLiBX ZSBjYW4ndCBkbyBhbnl0aGluZyBhYm91dCBESENQdjYuDQozLiAgICAgICBUaGUgdXBzdHJlYW0g Y29tZXMgYmFjayB3aXRoIGEgbmV3IHByZWZpeC4gV2UgYW5ub3VuY2UgdGhlIG5ldyBETlMgc2Vy dmVycyB1c2luZyBSRE5TUy4gQnV0IHRoZSBjbGllbnQgc3RpbGwgdXNlcyB0aGUgb3V0LW9mLWRh dGUgREhDUHY2LXByb3ZpZGVkIEROUyBzZXJ2ZXJzLCBiZWNhdXNlIFJGQyA4MTA2IHNheXMgaXQg c2hvdWxkIHByZWZlciBESENQdjYgb3ZlciBSRE5TUy4NCkkgY2Fubm90IGxpdmUgd2l0aCBicmVh a2luZyB1c2VyIGV4cGVyaWVuY2UgbGlrZSB0aGlzLg0KPT09PQ0K --_000_d521c13a59dc4e488d02515d673f671cXCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpoMw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVh ZGluZyAzIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMy41cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K aDQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCBD aGFyIjsNCgltYXJnaW4tdG9wOjIuMHB0Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglw YWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkgTGlnaHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzJFNzRCNTsNCglmb250LXdlaWdo dDpub3JtYWw7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmdtYWlsLQ0KCXttc28tc3R5bGUtbmFt ZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw YW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyI7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFu LkhlYWRpbmc0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIExpZ2h0IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMyRTc0QjU7DQoJZm9udC1z dHlsZTppdGFsaWM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU2MDQxMTcyODsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg0NjUzNTE4NCAxNDYzNjEw OTg0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6MTE5Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo5ODgzNjU1MzQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xMTE0OTU5NzA7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZWFzb24gaXQgaXMgZGVncmFkZXMgZnVuY3Rpb25h bGl0eSBpcyB0aGF0IHdpdGggc3RhdGVsZXNzIERIQ1B2NiBpdCBpcyBpbXBvc3NpYmxlIHRvIGlt cGxlbWVudCBldmVuIHN1Y2ggYmFzaWMgdGhpbmdzIGFzICZxdW90O3RlbGwgdGhlIGNsaWVudCB0 aGF0IGl0cyBETlMgc2VydmVyIGlzIG5vdyBnb25lIGJlY2F1c2UgdGhlIGNlbGx1bGFyIG5ldHdv cmsgd2VudCBkb3duIGFuZCBjYW1lIGJhY2sgdXAgd2l0aA0KIGEgZGlmZmVyZW50IHByZWZpeCB3 aGVuIHlvdSB0ZW1wb3JhcmlseSBsb3N0IGNlbGwgY292ZXJhZ2UmcXVvdDsuIFRoaXMgd29ya3Mg dG9kYXkgdXNpbmcgUkROU1MsIGJ1dCBpZiB3ZSBpbXBsZW1lbnQgREhDUHY2LCB0aGlzIHdpbGwg c3RvcCB3b3JraW5nIGZvciBjbGllbnRzIHRoYXQgc3VwcG9ydCBESENQdjYsIGV2ZW4gaWYgdGhl eSBhbHNvIHN1cHBvcnQgUkROU1MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoaXMgaXMgYm9ndXMuIEluIHRoaXMgY2FzZSB0aGUgY2xpZW50IGlzIHN1cHBvc2VkIHRvIGlu aXRpYXRlIERIQ1B2NiB0byBkaXNjb3ZlciBuZXcgaW5mb3JtYXRpb24uIFllcywgUkZDIDMzMTUv MzczNiB3YXMgbm90IGFzIGNsZWFyIGFzIGl0IGNvdWxkIGhhdmUgYmVlbiBhYm91dA0KIHRoaXMg YnV0IHRoYXQgaXNu4oCZdCBjb21wbGV0ZWx5IGZhaXIgY29tcGFyaXNvbiBiZWNhdXNlIHRoZXNl IHdlcmUgd3JpdHRlbiBhIGxvbmcgdGltZSBhZ28gYW5kIHRoZSBuZXR3b3JraW5nIHdvcmxkIHdh cyBkaWZmZXJlbnQgYmFjayB0aGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+UkZDIDM3MzYgc3RhdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MzMxNSI+UkZDIDMzMTU8L2E+IGFsc28gZG9lcyBub3QgcHJvdmlkZSBhbnkgZ3VpZGFuY2UgYWJv dXQgd2hlbiBhIGhvc3QgbWlnaHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO3VzZSBhbiBJbmZvcm1h dGlvbi1yZXF1ZXN0IG1lc3NhZ2UgdG8gb2J0YWluIHVwZGF0ZWQgY29uZmlndXJhdGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgcGFyYW1ldGVycyB3aGVuIHRoZSBob3N0IGhhcyBtb3ZlZCB0byBh IG5ldyBsaW5rLiZuYnNwOyBUaGUgREhDIFdHIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZXZp ZXdpbmcgYSByZWxhdGVkIGRvY3VtZW50LCAmcXVvdDtEZXRlY3Rpb24gb2YgTmV0d29yayBBdHRh Y2htZW50IChETkEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbiBJUHY0JnF1b3Q7IFs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzczNiNyZWYtOCIgdGl0bGU9IiZxdW90 O0RldGVjdGlvbiBvZiBOZXR3b3JrIEF0dGFjaG1lbnQgKEROQSkgaW4gSVB2NCZxdW90OyI+ODwv YT5dLCB3aGljaCBkZXNjcmliZXMgaG93IGEgaG9zdCB1c2luZyBJUHY0DQogY2FuIGRldGVybWlu ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgd2hlbiB0byB1c2UgREhDUHY0LiZuYnNwOyBFaXRoZXIg dGhlIERIQyBXRyBvciBhIFdHIGZvcm1lZCBmcm9tIHRoZSBETkE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IEJPRiB3aWxsIHVuZGVydGFrZSBkZXZlbG9wbWVudCBvZiBhIHNpbWlsYXIgZG9jdW1lbnQg Zm9yIElQdjYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQg aWYgYSBob3N0IGRldGVjdHMgdGhhdCB0aGluZ3MgbWF5IGhhdmUgY2hhbmdlZCAoc3VjaCBhcyB3 aGVuIGEgbGluayBnb2VzIGRvd24pLCBpdCB3b3VsZCBiZSByYXRoZXIgc2lsbHkgb2YgaXQgbm90 IHRvIHBlcmZvcm0gYW4gdXBkYXRlIG9mIGl0cyBESENQIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMtMDciPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzLTA3PC9hPiBoYXM6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saW5lLWhlaWdodC1h bHQ6MHB0Ij4NCjxhIG5hbWU9InNlY3Rpb24tMTguMiI+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzLTA3I3NlY3Rpb24tMTgu MiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjE4LjI8L3NwYW4+PC9iPjwvYT48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+LiZuYnNwOw0KIENsaWVudCBCZWhhdmlvcjxvOnA+PC9vOnA+PC9zcGFu PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IEEgY2xpZW50IHVzZXMgdGhlIFNvbGljaXQgbWVzc2FnZSB0byBkaXNjb3ZlciBE SENQIHNlcnZlcnMgY29uZmlndXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdG8gYXNzaWduIGxl YXNlcyBvciByZXR1cm4gb3RoZXIgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIG9uIHRoZSBsaW5r PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0byB3aGljaCB0aGUgY2xpZW50IGlzIGF0dGFjaGVkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgY2xpZW50IHVzZXMgUmVxdWVz dCwgUmVuZXcsIFJlYmluZCwgUmVsZWFzZSBhbmQgRGVjbGluZSBtZXNzYWdlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgZHVyaW5nIHRoZSBub3JtYWwgbGlmZSBjeWNsZSBvZiBhZGRyZXNzZXMgYW5k IGRlbGVnYXRlZCBwcmVmaXhlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6cmVkIj5XaGVuIGEgY2xpZW50IGRldGVjdHMgaXQgbWF5IGhhdmUgbW92ZWQgdG8g YSBuZXcgbGluazwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LCBpdCB1c2VzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBDb25maXJtIGlmIGl0IG9ubHkgaGFzIGFkZHJlc3NlcyBhbmQgUmViaW5k IGlmIGl0IGhhcyBkZWxlZ2F0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHByZWZpeGVzIChhbmQg YWRkcmVzc2VzKS4mbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPkl0IHVzZXMgSW5m b3JtYXRpb24tcmVxdWVzdCBtZXNzYWdlcyB3aGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgaXQgbmVl ZHMgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBidXQgbm8gYWRkcmVzc2VzIGFuZCBubyBwcmVm aXhlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBlcmhhcHMg d2Ugc2hvdWxkIGJlIGEgYml0IG1vcmUgY2xlYXIgYWJvdXQgYWxsIG9mIHRoZSBjb25kaXRpb25z IGluIHRoaXMgdGV4dC4gVGhlIHRleHQgYWJvdXQgQ29uZmlybSBoYXMgYSBtb3JlIGV4dGVuc2l2 ZSBsaXN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 aDQgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij48YSBuYW1lPSJzZWN0aW9uLTE4LjIu MyI+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRo Yy1yZmMzMzE1YmlzLTA3I3NlY3Rpb24tMTguMi4zIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjaztmb250 LXN0eWxlOm5vcm1hbCI+MTguMi4zPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjaztmb250 LXN0eWxlOm5vcm1hbCI+LiZuYnNwOw0KIENyZWF0aW9uIGFuZCBUcmFuc21pc3Npb24gb2YgQ29u ZmlybSBNZXNzYWdlczxvOnA+PC9vOnA+PC9zcGFuPjwvaDQ+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFdoZW5ldmVyIGEgY2xpZW50IG1heSBoYXZl IG1vdmVkIHRvIGEgbmV3IGxpbmssIHRoZSBwcmVmaXhlcy88bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWRkcmVzc2Vz IGFzc2lnbmVkIHRvIHRoZSBpbnRlcmZhY2VzIG9uIHRoYXQgbGluayBtYXkgbm8gbG9uZ2VyIGJl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGFwcHJvcHJpYXRlIGZvciB0aGUgbGluayB0byB3aGljaCB0aGUgY2xpZW50 IGlzIGF0dGFjaGVkLiZuYnNwOyBFeGFtcGxlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvZiB0aW1lcyB3aGVuIGEg Y2xpZW50IG1heSBoYXZlIG1vdmVkIHRvIGEgbmV3IGxpbmsgaW5jbHVkZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgbyZuYnNwOyBUaGUgY2xpZW50IHJlYm9vdHMgKGFuZCBoYXMgc3RhYmxlIHN0b3JhZ2Ug YW5kIHBlcnNpc3RlZCBESENQPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0YXRlKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgY2xpZW50IGlzIHJlY29ubmVjdGVkIHRvIGEg bGluayBvbiB3aGljaCBpdCBoYXMgb2J0YWluZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbGVhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBjbGllbnQgcmV0dXJucyBm cm9tIHNsZWVwIG1vZGUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIGNsaWVudCBjaGFu Z2VzIGFjY2VzcyBwb2ludHMgKHN1Y2ggYXMgaWYgdXNpbmcgYSB3aXJlbGVzczxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0ZWNobm9sb2d5KS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5CZXJuaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA2LCAyMDE3IDEyOjE5IFBNPGJyPg0KPGI+VG86 PC9iPiBTVEFSSywgQkFSQkFSQSBIICZsdDticzc2NTJAYXR0LmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IElQdjYgT3BlcmF0aW9ucyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7OyBUb3JlIEFuZGVyc29u ICZsdDt0b3JlQGZ1ZC5ubyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gTWFr aW5nIFJETlNTIGEgTVVTVD8sIGh1bSB2MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgNiwgMjAxNyBhdCAxMToxMiBQTSwgU1RB UkssIEJBUkJBUkEgSCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJzNzY1MkBhdHQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7 IEFzIGEgdmVuZG9yIG9mIGEgZGV2aWNlIHRoYXQgaXMgc29tZXRpbWVzIGEgcm91dGVyIEkgYW0g b3Bwb3NlZCB0bywgYW5kIGhhdmUgcHJlY2lzZWx5IHplcm8gaW50ZXJlc3RpbmcgaW4sPC9zcGFu Pjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgaW1wbGVtZW50aW5nIGEgREhDUHY2IHJl bGF5IG9yIHNlcnZlciBmdW5jdGlvbi4mbmJzcDsgSXQgYWRkcyBub3RoaW5nLCBhbmQgY2FuIGFj dHVhbGx5IGJyZWFrIGNsaWVudHMgdGhhdCBwcmVmZXI8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 ImdtYWlsLSI+Jmd0OyBESENQdjYgRE5TIG92ZXIgUkROU1Mgd2hlbiB0aGUgdXBzdHJlYW0gSVB2 NiBwcmVmaXggY2hhbmdlcy7igIs8L3NwYW4+PGJyPg0KPGJyPg0KWy4uLl08YnI+DQo8YnI+DQoy LiBZb3Ugc2F5IHlvdSBkb24ndCB3YW50IHRvIGJyZWFrIGNsaWVudHMgKGhvc3RzKSB0aGF0IHBy ZWZlciBESENQdjYgRE5TIG92ZXIgUkROU1MuIFNpbmNlIHlvdSBvcHBvc2UgREhDUHY2IHJlbGF5 IG9yIHNlcnZlciAoaW4gdGhlIGFic2VuY2Ugb2YgYSBxdWFsaWZpZXIgSSB0YWtlIHNlcnZlciB0 byBtZWFuIHN0YXRlZnVsIG9yIHN0YXRlbGVzcyAtLSBzbyB5b3Ugb3Bwb3NlIGJvdGggdHlwZXMg b2Ygc2VydmVyPyksIGRvZXMgdGhpcyBtZWFuDQogeW91IGJlbGlldmUgdGhlIHdheSB0byBwcmV2 ZW50IGJyZWFrYWdlIGlzIHRvIG9ubHkgb2ZmZXIgUkROU1MgdG8gY2xpZW50cyAoc28gdGhlaXIg cHJlZmVyZW5jZSBpcyBpcnJlbGV2YW50LCBhbmQgdGhleSBoYWQgYmV0dGVyIGFsc28gaW1wbGVt ZW50IFJETlNTIGluIHNwaXRlIG9mIHRoZWlyIHByZWZlcmVuY2UpPzxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGlz IGlzIHRoZSBzb3J0IG9mIHRoaW5nIHRoYXQgRXJpayBvcHBvc2VzLiBJIHRob3VnaHQgSSBoYWQg c2VudCBpdCB0byB0aGUgbGlzdCwgYnV0IGFjdHVhbGx5IGl0IHdhcyBhbiBvZmYtbGlzdCByZXBs eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PT09PTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBBbmRyb2lkIHBob25lIGluIG15IHBvY2tldCBpcyBhIHJvdXRlciB3aGVuIEkg Z28gdG8gdGhlIGNvZmZlZSBzaG9wIGV2ZXJ5IG1vcm5pbmcgYW5kIHR1cm4gb24gdGV0aGVyaW5n LiBBcyB0aGUgbWFpbnRhaW5lciBvZiB0aGF0IGNvZGUsIEkgYWJzb2x1dGVseSBkbyBub3Qgd2Fu dCB0byBzcGVuZCBzb2Z0d2FyZSBlbmdpbmVlcmluZyB0aW1lIHdyaXRpbmcgYSBESENQdjYgc2Vy dmVyIHRoYXQgaXMgbm90DQogb25seSBsZXNzIGNhcGFibGUgdGhhbiB0aGUgUkROU1MgaW1wbGVt ZW50YXRpb24gdGhhdCB3ZSBoYXZlIG5vdywgYnV0IGFsc28gZGVncmFkZXMgZnVuY3Rpb25hbGl0 eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHJlYXNvbiBpdCBpcyBkZWdyYWRlcyBmdW5jdGlvbmFsaXR5IGlzIHRoYXQgd2l0aCBzdGF0 ZWxlc3MgREhDUHY2IGl0IGlzIGltcG9zc2libGUgdG8gaW1wbGVtZW50IGV2ZW4gc3VjaCBiYXNp YyB0aGluZ3MgYXMgJnF1b3Q7dGVsbCB0aGUgY2xpZW50IHRoYXQgaXRzIEROUyBzZXJ2ZXIgaXMg bm93IGdvbmUgYmVjYXVzZSB0aGUgY2VsbHVsYXIgbmV0d29yayB3ZW50IGRvd24gYW5kIGNhbWUg YmFjayB1cCB3aXRoDQogYSBkaWZmZXJlbnQgcHJlZml4IHdoZW4geW91IHRlbXBvcmFyaWx5IGxv c3QgY2VsbCBjb3ZlcmFnZSZxdW90Oy4gVGhpcyB3b3JrcyB0b2RheSB1c2luZyBSRE5TUywgYnV0 IGlmIHdlIGltcGxlbWVudCBESENQdjYsIHRoaXMgd2lsbCBzdG9wIHdvcmtpbmcgZm9yIGNsaWVu dHMgdGhhdCBzdXBwb3J0IERIQ1B2NiwgZXZlbiBpZiB0aGV5IGFsc28gc3VwcG9ydCBSRE5TUy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDo0Ny4yNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZv MSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+Q2xpZW50IGdldHMgRE5TIGFkZHJlc3NlcyBmcm9tIGJvdGggUkROU1MgYW5k IERIQ1B2NiwgYW5kIHByZWZlcnMgREhDUHY2IGR1ZSB0byBSRkMgODEwNi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NDcuMjVwdDt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlVwc3RyZWFt IGdvZXMgZG93bi4gV2UgZGVwcmVjYXRlIHRoZSBwcmVmaXggKHdlIGNhbid0IG1ha2UgaXQgaW52 YWxpZCBiZWNhdXNlIG9mIHRoZSAyLWhvdXIgcnVsZSksIGFuZCBkZWNsYXJlIHRoZSBETlMgc2Vy dmVycyBpbnZhbGlkLiBXZSBjYW4ndCBkbyBhbnl0aGluZyBhYm91dCBESENQdjYuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjQ3LjI1cHQ7 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5UaGUg dXBzdHJlYW0gY29tZXMgYmFjayB3aXRoIGEgbmV3IHByZWZpeC4gV2UgYW5ub3VuY2UgdGhlIG5l dyBETlMgc2VydmVycyB1c2luZyBSRE5TUy4gQnV0IHRoZSBjbGllbnQgc3RpbGwgdXNlcyB0aGUg b3V0LW9mLWRhdGUgREhDUHY2LXByb3ZpZGVkIEROUyBzZXJ2ZXJzLCBiZWNhdXNlIFJGQyA4MTA2 IHNheXMgaXQgc2hvdWxkIHByZWZlcg0KIERIQ1B2NiBvdmVyIFJETlNTLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0Ij5JIGNhbm5vdCBsaXZlIHdpdGggYnJlYWtpbmcgdXNlciBleHBlcmllbmNlIGxp a2UgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+ PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_d521c13a59dc4e488d02515d673f671cXCHALN003ciscocom_-- From nobody Thu Apr 6 09:33: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 E51EE129569 for ; Thu, 6 Apr 2017 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PkzyDgGYAbqq for ; Thu, 6 Apr 2017 09:33:52 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 22426128854 for ; Thu, 6 Apr 2017 09:33:50 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id x125so41228988pgb.0 for ; Thu, 06 Apr 2017 09:33:50 -0700 (PDT) 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=DHMu8ln7AXAIcgNjm0lHBRe6h9GKT2SbjidvXNkuWQI=; b=LQ1Wqa7H+ZvVMqzM7d51LvMHBrlHUtOhCVGjxl8V89JaXGHBMSXsO/DaROLKXuEyZw hE220LbO7IxayKuhoew9RNbgwCmA5QQRJ0EWOHeSFHOdaTY949J2PXBSkMeZJry1zq5J WVdMwdcwqpUHjp/OnFm2oURWpUP8423bF9REPMrd/OcwGZNLsZUtdR6ZpgqX4MMp1FiP Nc7iekd5axEZm3+ndLcvIcF0ohbLtyUCv8hZBpypSrC653A8DpF0StyYz042+QGcJLja G/E+XY6hTZfDQH4P4jg0WEjYh51cloE+0BrPV/YFgQmE2BF2uH64Uij0cBZW7cuoGb6g vE4Q== 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=DHMu8ln7AXAIcgNjm0lHBRe6h9GKT2SbjidvXNkuWQI=; b=K2xhSn52/SIv3HAsFq7/r0Gsd2zKBA5F/+aqulLM0Niy6DB94nwO/ZcLsssmOEMr/e n24K48WMrch+yRWm6xfdFUU0o7Rv37g1zNn0d/ZhicJHUuVZ6RLFVg/ugZvKzkw4bkk6 OS7IixRQ0w1AJyqCwCmSgq+wYnIBQNVp5RC4g/RWukM5YjR6tm2vAtXxHo5HJ9hpM1oh nsq6qw10ZsoiIl+RZ8s/bt6lxQ+fC1Iokms/XVOwU6PJmGOVJCPqpqdmBwhxIO/IzGjv fiJS2DtwAglIw1mgt7LCcY91QihKNEAvNz7Ghph1TdnSPG21FbhtqqCQB9uM7G5S2qDY D9HQ== X-Gm-Message-State: AFeK/H1F7YnasaX0Ec4/dziBstLykBPDJiUDDdkI7NCSEywjj6aepQHZscsmPO8H9ZYspQ== X-Received: by 10.84.174.131 with SMTP id r3mr45117694plb.136.1491496429706; Thu, 06 Apr 2017 09:33:49 -0700 (PDT) Received: from ?IPv6:2620::b60:17:65a5:9972:9ffc:5799? ([2620:0:b60:17:65a5:9972:9ffc:5799]) by smtp.gmail.com with ESMTPSA id c19sm4805059pfd.85.2017.04.06.09.33.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 09:33:48 -0700 (PDT) From: Ted Lemon Message-Id: <0CD976CE-7439-4AE7-96BF-A48076F389D0@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF8105CE-C066-4F44-9302-114E89B7A9C9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 6 Apr 2017 09:33:46 -0700 In-Reply-To: Cc: v6ops@ietf.org To: Alexandre Petrescu References: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:33:55 -0000 --Apple-Mail=_BF8105CE-C066-4F44-9302-114E89B7A9C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 6, 2017, at 9:07 AM, Alexandre Petrescu = wrote: > I went through a few emergencies because of each of these. Really? You went through emergencies because you couldn't reach an NTP = server because it was hard-coded as a domain name? You went through = emergencies because your BIOS battery failed? And you think that the = solution to these emergencies is to mandate some additional network = protocol? --Apple-Mail=_BF8105CE-C066-4F44-9302-114E89B7A9C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 6, 2017, at 9:07 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
I went through a few emergencies because = of each of these.

Really?=   You went through emergencies because you = couldn't reach an NTP server because it was hard-coded as a domain name? =   You went through emergencies because your = BIOS battery failed?   And you think that the solution to these = emergencies is to mandate some additional network protocol?

= --Apple-Mail=_BF8105CE-C066-4F44-9302-114E89B7A9C9-- From nobody Thu Apr 6 09:35: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 3AAA8129552 for ; Thu, 6 Apr 2017 09:35:05 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 as_jzxUuLDrJ for ; Thu, 6 Apr 2017 09:35:02 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 05F05129569 for ; Thu, 6 Apr 2017 09:35:00 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id f84so33209127ioj.0 for ; Thu, 06 Apr 2017 09:35:00 -0700 (PDT) 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=F18TH2tnLk2c8Z2j5+ZcMTqcNg3dT8Xl9FALQ4jBqeA=; b=HOEhFhybhrKhDjV5heuKJAwu+7jiXaXHk9+fGw0tisnhgCaYjauyfXobqvknZNT1ZW xDoG2k9VUBqw36Kk6iR03CFxd+y5tv0Bb6FfifRBZaN8ymM/nzoXob0lJ19bgBIuSU5C 6m9XYRbQwIAZq/wi709RHZ6zvLaUKqiiVKamYU2YYpSGnvbJyNV4ZXRYAvUvhxqe2bfm MIz0yir+wZ6DYUSIiqFwB5wPXCZ3Tj9vF56RSbitgsMiDjHPVqw9+8C76K3M7/kDnTih lg4lFkosEdqNuYvyPWI6wlERGoj4rpbBWkCNYNoFFPO2KqHWzJ5rs/WnIV392tezgxQ3 tkXg== 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=F18TH2tnLk2c8Z2j5+ZcMTqcNg3dT8Xl9FALQ4jBqeA=; b=MMvdNIKiLC59bWsxF/RMVp31wW5nFI/QEeOvcP83XXOF4Gwe8+eCdHAkptX7DVVkuU HseGEC5iS85C0zRNIjLJyQ+VsS8KQzRUqZ57MQBJitByb57LT3ilKSU7dwi4wJcR5N/a uBtjd4/FXP5tGzEz484xoq4cyvJ+EHExRQ6yPQMOaDNQJLZh8PVujTCGcgD7Om/5Qc4/ LoB414TySR88C7slAeeTWRvUDfqZyCmZeyqgvfxm4M4ywTT1dazh1KokYRigAcLbi/Hn HKi2E7dCkZgp2zNEeXyEprgjjGb4udC9A02g034h+Wcn/rEQpp2HDKuw8Xfkifh9AKvp MNgA== X-Gm-Message-State: AFeK/H3XVWHH2blM9IfAwfQhi1ulTiac8w5ka/SYZ2VSZDzvmy7pMJZiMVc6wmmEIE4P/QVMuY3tn6nUQNeqwKCb X-Received: by 10.107.150.201 with SMTP id y192mr37904400iod.33.1491496500193; Thu, 06 Apr 2017 09:35:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.92.198 with HTTP; Thu, 6 Apr 2017 09:34:39 -0700 (PDT) In-Reply-To: References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 01:34:39 +0900 Message-ID: To: "Bernie Volz (volz)" Cc: "STARK, BARBARA H" , IPv6 Operations Content-Type: multipart/alternative; boundary=001a1140ed34146025054c821790 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:35:05 -0000 --001a1140ed34146025054c821790 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 7, 2017 at 1:30 AM, Bernie Volz (volz) wrote: > The reason it is degrades functionality is that with stateless DHCPv6 it > is impossible to implement even such basic things as "tell the client tha= t > its DNS server is now gone because the cellular network went down and cam= e > back up with a different prefix when you temporarily lost cell coverage". > This works today using RDNSS, but if we implement DHCPv6, this will stop > working for clients that support DHCPv6, even if they also support RDNSS. > > > > This is bogus. In this case the client is supposed to initiate DHCPv6 to > discover new information. Yes, RFC 3315/3736 was not as clear as it could > have been about this but that isn=E2=80=99t completely fair comparison be= cause > these were written a long time ago and the networking world was different > back then. > Please explain how the host would know that it needs to run DHCPv6 again. > But if a host detects that things may have changed (such as when a link > goes down), it would be rather silly of it not to perform an update of it= s > DHCP information. > The link did not go down. The upstream was renumbered. None of the conditions in 3315bis 18.2.3 occurred. Please don't tell me that the client needs to react to the RA with the new DNS servers by starting DHCP to request DNS servers. :-) --001a1140ed34146025054c821790 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 1:30 AM, Bernie Volz (volz) <volz@cisco.com>= wrote:

The reason it is degrades functionality is that with= stateless DHCPv6 it is impossible to implement even such basic things as &= quot;tell the client that its DNS server is now gone because the cellular n= etwork went down and came back up with a different prefix when you temporarily lost cell coverage". This wor= ks today using RDNSS, but if we implement DHCPv6, this will stop working fo= r clients that support DHCPv6, even if they also support RDNSS.

=C2=A0

This is bogus. In this case the clien= t is supposed to initiate DHCPv6 to discover new information. Yes, RFC 3315= /3736 was not as clear as it could have been about this but that isn=E2=80=99t completely fair comparison because these were = written a long time ago and the networking world was different back then.


Please explain how th= e host would know that it needs to run DHCPv6 again.
=C2=A0
=

<= span style=3D"font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73= ,125)">

But if a host detects that things may have c= hanged (such as when a link goes down), it would be rather silly of it not = to perform an update of its DHCP information.


The link did not go down. The upstream was renumb= ered. None of the conditions in 3315bis=C2=A018.2.3 occurred.
Please don't tell me that the client needs to react to the = RA with the new DNS servers by starting DHCP to request DNS servers. :-)
--001a1140ed34146025054c821790-- From nobody Thu Apr 6 09:38: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 CA8AE129567 for ; Thu, 6 Apr 2017 09:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 yYdJmSEdKfBS for ; Thu, 6 Apr 2017 09:38:18 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 017EF129579 for ; Thu, 6 Apr 2017 09:38:10 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=58220 helo=envy.e1.y.home) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cwAQA-0004ex-7N; Thu, 06 Apr 2017 16:38:06 +0000 Date: Thu, 6 Apr 2017 18:38:00 +0200 From: Tore Anderson To: Erik Kline Cc: Timothy Winters , IPv6 Operations Message-ID: <20170406183800.3e4f5ef4@envy.e1.y.home> In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:38:22 -0000 * Erik Kline > As a vendor of a device that is sometimes a router I am opposed to, > and have precisely zero interesting in, implementing a DHCPv6 relay > or server function. It adds nothing Um, =C2=ABadds nothing=C2=BB, really? To the best of my knowledge, DHCPv6 is the *only* way to provision IPv6 name servers onto hosts running Microsoft Windows. In my operational reality, =C2=ABsupport for Microsoft Windows hosts=C2=BB = is diametrically opposite to =C2=ABnothing=C2=BB. The exact same point goes for Android and RDNSS. Thus, when operating a BYOD IPv6 network, it is absolutely essential to support *both* RDNSS and DHCPv6. Otherwise you'll be excluding a significant amount of devices from being able to use your network. Tore PS: Apologies to the WG and the chairs for the misdirected hum to the list a couple of messages earlier in the thread. It appears my MUA didn't interpret the Reply-To header as I thought it would. My bad. From nobody Thu Apr 6 09:38: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 37AD8129562 for ; Thu, 6 Apr 2017 09:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hTcSD_klzYLG for ; Thu, 6 Apr 2017 09:38:27 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 DBA5E1270B4 for ; Thu, 6 Apr 2017 09:38:18 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id o21so42944190wrb.2 for ; Thu, 06 Apr 2017 09:38:18 -0700 (PDT) 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=UT+8BRka/wRe7AH16pwxMjTcdBU69skaDGDI7OMlmE8=; b=eYD01+92gN1UDsK/eyOlXfpKHj4S5lP5DYDJFNu9DQNOpViP05I80qhSLQ3+0Ef5K4 okwBHunvhRbCHq4o3Wne6hm5uI2cj4L6w/dkhVGlMnVp6Xj600LbE4o3ndOyM+aWnWi9 XEt40/YP9XzNKL/LrDZanZej0H3Mn7AGNezpjkwcSTcqzTQKlv+HQ4VjO2zfiEV3Dxfb RFsdazTxFpiDdt6ETfjtXWb9q3F1ISghzLZjdd3K8mq4Vj9BdlnKDS7MWtCwPQ7q4cMR sMSJkDxwiHaMgr8rArPZKi+3Zrj1y/nHu7eqkK/5eI/hIWcVHilb7tQIEvOzQPRr1C2y 3mTg== 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=UT+8BRka/wRe7AH16pwxMjTcdBU69skaDGDI7OMlmE8=; b=nNbm8qkx/mcltFfcmCFvdLBKEBDIMvEQdLnU5gB8FCkFKCxLKh2oY+DfqC6mSbUIcv +8CEzwGxGeqJaIw3TNtYRdMQjh7r6LwJOOsLa3ShPv3YDQH3FmleqAgd3ODvV9PEo04n ZePVxBG5tCqoJ16iqZzmbnBUy/zj2RgMhuhDlb3GLqejhORhN7D5g+IPrhaMx1zjJosv 4Cm3v+kicBu3lNHd2phMc9+YwGzB0d+U0pa7px807VqL3sUgDzFeo+D+Qz65p6NTVlCe /kb3fgGPaOmq+3G1IQrTw7JDW+RNUaw0xm8m9xR/SlFwBN0TTrcPUVrtljbbWT0zgTED De6A== X-Gm-Message-State: AN3rC/5hXGxyYAXaX3LlGgsJjk9XXUC9a66ZmBklJ8pr4w6ojS8Ob4U20n4YvqyCoBxK+g== X-Received: by 10.223.136.201 with SMTP id g9mr3947401wrg.97.1491496697306; Thu, 06 Apr 2017 09:38:17 -0700 (PDT) Received: from 221.66.20.149.in-addr.arpa (221.66.20.149.in-addr.arpa. [149.20.66.221]) by smtp.gmail.com with ESMTPSA id u9sm17143113wme.8.2017.04.06.09.38.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 09:38:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Thu, 6 Apr 2017 09:38:13 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2AF3CBC7-A275-4532-9930-784282C4D63D@gmail.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? - tethering, DHCPv6, RDNSS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:38:29 -0000 On Apr 6, 2017, at 9:28 AM, Alexandre Petrescu = wrote: >=20 >> The Android phone in my pocket is a router when I go to the coffee >> shop every morning and turn on tethering. >=20 > Tethering? Which standard is that? I believe that he is referring to RFC 7278, and by extension: https://tools.ietf.org/html/rfc6459 6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. January 2012. (Format: = TXT=3D84769 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6459) https://tools.ietf.org/html/rfc7278 7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format: TXT=3D19965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7278) https://tools.ietf.org/html/rfc7934 7934 Host Address Availability Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July 2016. (Format: TXT=3D37124 bytes) (Also BCP0204) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7934) o Extending the network (e.g., "tethering"). o /64 sharing [RFC7278]. When the topology supports it, this is a way to provide IPv6 tethering without needing to wait for network operators to deploy DHCPv6 Prefix Delegation (PD), which is only available in 3GPP release 10 or above ([RFC6459], Section 5.3). o DHCPv6 Prefix Delegation (PD) [RFC3633]. DHCPv6 PD allows the client to request and be delegated a prefix, from which it can autonomously form other addresses. If the prefix is shorter than /64, it can be divided into multiple subnets that can be further delegated to downstream clients. If the prefix is a /64, it can be extended via L2 bridging, Neighbor Discovery (ND) proxying [RFC4389], or /64 sharing [RFC7278], but it cannot be further subdivided, as a prefix longer than /64 is outside the current IPv6 specifications [RFC7421]. While the DHCPv6 Prefix Delegation specification [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD itself does not require that the client forward IPv6 packets not addressed to itself, and thus does not require that the client be an IPv6 router as defined in the IPv6 specification [RFC2460]. Also, in many cases (such as tethering, or hosting virtual machines), hosts are already forwarding IPv6 packets and thus operating as IPv6 routers as defined in the IPv6 specification [RFC2460]. From nobody Thu Apr 6 09:43: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 CF5A912955E for ; Thu, 6 Apr 2017 09:43:07 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 xS0ZDM2U6ryt for ; Thu, 6 Apr 2017 09:43:05 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001: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 06685129542 for ; Thu, 6 Apr 2017 09:43:04 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id b140so33495386iof.1 for ; Thu, 06 Apr 2017 09:43:04 -0700 (PDT) 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=f5ifjF8CovgzcDhAhtwIK/gLj4KtRglOx0BpMkLuY8M=; b=PfOu4icdQgSILQiigNlKX5sOqml7nCwIGuPai5Um4bDsJ1HOhLuo3Zu9eUChtEnzJ7 Wm2KHVxsvZp16xa4rbrK2UVGv0QhyNiB+KB7f8bEuhF2ycOH/8pU9YzUw7jfxWbZ6o9J TEUjZflhKasjbvOO7ZsRcGvMB838KS6qjxrZRLR6+rOao1nZyzLrUp+kI9GDkcKumhTA RYZa2bPFCpnQbLnC9jtt8NhSCs+RdbpuE3KaMhnp/f4MvtiO5iG3XGBER0ekcdXfbFEb QPvImH1u36UeI5EZwfabCR2QPjksE7iVcC0gpY8BVpijs6phDvAIK9vUvuEQA2Te5N0j /vcw== 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=f5ifjF8CovgzcDhAhtwIK/gLj4KtRglOx0BpMkLuY8M=; b=h0Z4ttmcfi2D5gOfooUNg5vhzlZMDUzEA6g1pUrw0jDoESL0HczKjNJ+bFyAHIFoCN eooh7p8fahrAIVNuHLgBJPDlghMhhXc3YrHEtqOMPJYYJpn4lgtLM//keBcc+swRs9he KbJb0X/Ka4JTy5t1p6V6LJGx46kseyBdHy+Z8yyGPRZVf9AzQKO6dVUCXFeZLda++FDh S0mXmsc+pDNxAgqJ+3RFXZt2aCtmEGecAAZEN/GYOjeqmJtjPzSLNx4lsGpSiaFBmp2W j1+DSfhYZn3eTEUt64ii1Ncoj6FidfCDHkgVtxUloIPBIw+dzIpqpdtDmoEfYzytpASo e8SQ== X-Gm-Message-State: AFeK/H3+PVtzISotewo0OpII0EXPdW15FIF6RND4e6wt2PT5vK2ZJ0HbJXG+swyH7CpSS88JEkET8qQOP6S6mpCS X-Received: by 10.107.150.201 with SMTP id y192mr37944658iod.33.1491496984158; Thu, 06 Apr 2017 09:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.92.198 with HTTP; Thu, 6 Apr 2017 09:42:43 -0700 (PDT) In-Reply-To: <20170406183800.3e4f5ef4@envy.e1.y.home> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 01:42:43 +0900 Message-ID: To: Tore Anderson Cc: Erik Kline , IPv6 Operations Content-Type: multipart/alternative; boundary=001a1140ed34ed0c85054c8233c5 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:43:08 -0000 --001a1140ed34ed0c85054c8233c5 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 1:38 AM, Tore Anderson wrote: > To the best of my knowledge, DHCPv6 is the *only* way to provision IPv6 > name servers onto hosts running Microsoft Windows. > We'll see how long that statement stays true. --001a1140ed34ed0c85054c8233c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 1:38 AM, Tore Anderson <tore@fud.no> wrote:
=
To the best of my knowledge, DHCPv6 is the *= only* way to provision IPv6
name servers onto hosts running Microsoft Windows.
We'll see how long that statement stays true.
--001a1140ed34ed0c85054c8233c5-- From nobody Thu Apr 6 09:48: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 5CCEE12420B for ; Thu, 6 Apr 2017 09:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bHl0maHwZmSd for ; Thu, 6 Apr 2017 09:48:45 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 C288912954A for ; Thu, 6 Apr 2017 09:48:43 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=58304 helo=envy.e1.y.home) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cwAaP-0004hv-9F; Thu, 06 Apr 2017 16:48:41 +0000 Date: Thu, 6 Apr 2017 18:48:40 +0200 From: Tore Anderson To: Lorenzo Colitti Cc: Erik Kline , IPv6 Operations Message-ID: <20170406184840.524adb1c@envy.e1.y.home> In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:48:47 -0000 * Lorenzo Colitti > On Fri, Apr 7, 2017 at 1:38 AM, Tore Anderson wrote: > > > To the best of my knowledge, DHCPv6 is the *only* way to provision > > IPv6 name servers onto hosts running Microsoft Windows. > > We'll see how long that statement stays true. Years, certainly. Decade(s), probably. Keep in mind that Windows XP, released in 2001, still has a significant install base. Tore From nobody Thu Apr 6 09:52:24 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 B96B9124234 for ; Thu, 6 Apr 2017 09:52:13 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 XhCIihxpQv3B for ; Thu, 6 Apr 2017 09:52:07 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 29F6012420B for ; Thu, 6 Apr 2017 09:52:07 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id s68so47717583vke.3 for ; Thu, 06 Apr 2017 09:52:07 -0700 (PDT) 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=54PQR0Ep9qnOL2QUyUrDVTKwQJx7T1jetYqlGGJXHKc=; b=Nk1WYKWIxLqa56YbRIAuT6sY5vdmo1Q8W/lA3cf8y8KMLsixLa+kzvkOz4T7f8lrzX 6LIqf7AzBQg1SySR8w9PCmZ/QA/H9jwf2ZI55dn6Cpn41V1WIlEL5hpj/gF0oVy+pCI/ RTIdiBCslC8Aoki3MJrFcNhCofUbFCUxTpPky+JQ1pkfKO4rf0Mzj4Wj+51rIrfoNUi1 as2ihMouUSRz+w/3gNWnezNhCajTyFaMfg04YQRX8zCnsi4zHMNRzW61XopWL1Hq8FQT dIEj3mxpat6eNID2l2TQyqleFyOyeCf+iUVMcmpPwY5l5fbQXlqFDghVoDN0GaO31huJ mKTw== 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=54PQR0Ep9qnOL2QUyUrDVTKwQJx7T1jetYqlGGJXHKc=; b=PUotod22VO8gcBQillvrfuNPFPkMa2gbI0T/i9MGmo/Oz3YkKs0WLiidkOUGtINxgT WR5TTIjE1d0aCwwifgeqBn7CSeQEH07dimWABzbbmTzrHUAFGzdonAq9pa8KGV+qlCxi GNcvep362GzGWvq/fx0k/T5UDdDawGGXnhhwSr9Nc1N12YYG091wOTPwgezGexcd131t KipREWwKe6ZRm+JzW8XDYAoM3TCatECDVl0CWv49E/xwgjM2qX0DN3tEjaJABeLcpmWm ZOHUQ/zt93JNeNZC8/84iQKZVMpEqrWzK1xiFhdkj68dPzXnWP/yHNnkiR+w+znYIOhU VnWw== X-Gm-Message-State: AFeK/H2xqwx6IEnnbhYgqC2RrUBP5nIs+jtd4Mjy4a+61K2ZkEJlT4MiU7N/gnB9GXyffUUX3vrnzu9yVfQ2yNEa X-Received: by 10.176.82.238 with SMTP id w43mr19051125uaw.171.1491497525920; Thu, 06 Apr 2017 09:52:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Thu, 6 Apr 2017 09:51:45 -0700 (PDT) In-Reply-To: <20170406184840.524adb1c@envy.e1.y.home> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 01:51:45 +0900 Message-ID: To: Tore Anderson Cc: Erik Kline , IPv6 Operations Content-Type: multipart/alternative; boundary=94eb2c18f5e2381c36054c8254c2 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:52:14 -0000 --94eb2c18f5e2381c36054c8254c2 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 1:48 AM, Tore Anderson wrote: > > > To the best of my knowledge, DHCPv6 is the *only* way to provision > > > IPv6 name servers onto hosts running Microsoft Windows. > > > > We'll see how long that statement stays true. > > Years, certainly. Decade(s), probably. Keep in mind that Windows XP, > released in 2001, still has a significant install base. > The question is what will be the situation when we remove support for DHCPv4. That is a similarly long time horizon. --94eb2c18f5e2381c36054c8254c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 1:48 AM, Tore Anderson <tore@fud.no> wrote:
=
> > To the best= of my knowledge, DHCPv6 is the *only* way to provision
> > IPv6 name servers onto hosts running Microsoft Windows.
>
> We'll see how long that statement stays true.

Years, certainly. Decade(s), probably. Keep in mind that Window= s XP,
released in 2001, still has a significant install base.

The question is what will be the situation when we remove = support for DHCPv4. That is a similarly long time horizon.
--94eb2c18f5e2381c36054c8254c2-- From nobody Thu Apr 6 09:52: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 E8408124234 for ; Thu, 6 Apr 2017 09:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 W3YA6AiEiska for ; Thu, 6 Apr 2017 09:52:43 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 8BEC512420B for ; Thu, 6 Apr 2017 09:52:43 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id o21so43542801wrb.2 for ; Thu, 06 Apr 2017 09:52:43 -0700 (PDT) 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=ihk2r4HVboTFt8MaIh5eo4gXu61mflUd1Zzi4++vPyQ=; b=dIZJEktxjyzP47ij1fJ72lboOy9j97L1t80eUvRzCxyzJLBbRqjot7Dyc1FNEze6CC kRY3xg4ZduckCj2OLAR98PvaCC4PZtkQ+KF/WCJ8wNAaNWUPr+adT59ReNx6y2ddx9jS Zpz5d9FGMlz47Th40/08KJN1FU+J/yvzr6x1KRvkdzfnVQXSDIG2Uw2YjsiYiBG83MwS 9KpcvSarI+gxAAeU2a4hz1oGTB9dr4BsWSpAdA18E/c4RR+2lhTRJMGCA26ogB7lkWPH Xk/2yXMjhB6JjVJXl+teVt9QBQXjsVlGtYW9hqeg4f/eohlX6Xr/n8jhQ9atPMNX4mR8 gfdQ== 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=ihk2r4HVboTFt8MaIh5eo4gXu61mflUd1Zzi4++vPyQ=; b=sHmfL8CE9O/8oac4P3puAzJUhdsn7N/kbRqik/MzDFJiSICrWlya4sxHvBUCw+kOJ1 aHTJYBVzDA87cuYXbz3dfTs6e2TYTMGXacFjoBTkqUq8XSBfK+l0hRsoUpgCnvw6JE6R xHyGt0N/8bF8fe3i0wB5kefpWD2Ag11je+18v/ZyVZvHSB+XI/lARMexGwU77wy19TbY E3m/3Y2qEcQtmhLro9gN+GDfEJu9ZHcpMf8w6wlejdfnUbY2vVzY8zLW8sXfdOQd9tKR WkYsKyex597OJpbeI5cDwedsbMaEg61q+ppiRxI1AaZowvC0jJLNRdfUPiSyxaXM9Q3j 1GVw== X-Gm-Message-State: AN3rC/4aR7CVopVmQ0+2mm1lwPS74U9bFkhuG0pOfB2ygrw5uw+fj6oW FzYN90MJqt5BPQ== X-Received: by 10.28.153.140 with SMTP id b134mr5968520wme.124.1491497562109; Thu, 06 Apr 2017 09:52:42 -0700 (PDT) Received: from 221.66.20.149.in-addr.arpa (221.66.20.149.in-addr.arpa. [149.20.66.221]) by smtp.gmail.com with ESMTPSA id h65sm2779334wrh.32.2017.04.06.09.52.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 09:52:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Thu, 6 Apr 2017 09:52:38 -0700 Cc: Tore Anderson , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <28F6E669-8DB5-46FB-A2BE-A6CA4F2C4855@gmail.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:52:46 -0000 > On Apr 6, 2017, at 9:42 AM, Lorenzo Colitti = wrote: >=20 > On Fri, Apr 7, 2017 at 1:38 AM, Tore Anderson wrote: > To the best of my knowledge, DHCPv6 is the *only* way to provision = IPv6 > name servers onto hosts running Microsoft Windows. >=20 > We'll see how long that statement stays true. Perhaps you have knowledge that Microsoft plans to change it? I don't.=20= I would have to say that a statement made by an operational group in the = IETF needs to address the needs of the operators in the group, which I = think Tore has pretty succinctly stated (and which fits the data = arriving in my in-box; there are a variety of viewpoints, but if I had = to call it right now, I would say that the developing consensus is for = routers to support both as MTI). If a vendor of a product, however = widely used, has an opinion, it's relevant and welcome (having myself = been from the vendor side for quite some time), but this is first and = foremost about operational viewpoints. RFC 8106 came out of 6man (https://datatracker.ietf.org/doc/rfc8106/). I = might suspect that 6man would consider a draft updating it to reverse = its recommendation that DHCPv6 be preferred over RDNSS, although that is = for its chairs to say. I think you have presented some very relevant = arguments to support the viewpoint.= From nobody Thu Apr 6 09:54: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 38D9E129482 for ; Thu, 6 Apr 2017 09:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 EsJncnyfIWCk for ; Thu, 6 Apr 2017 09:54:46 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7878012420B for ; Thu, 6 Apr 2017 09:54:45 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 1244A2730F for ; Thu, 6 Apr 2017 18:54:43 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id E9D9635846C for ; Thu, 6 Apr 2017 18:54:42 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 1B464396FA; Thu, 6 Apr 2017 18:54:44 +0200 (CEST) Date: Thu, 6 Apr 2017 18:54:44 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20170406165444.GA29346@ernw.de> References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:54:49 -0000 On Fri, Apr 07, 2017 at 01:42:43AM +0900, Lorenzo Colitti wrote: > On Fri, Apr 7, 2017 at 1:38 AM, Tore Anderson wrote: > > > To the best of my knowledge, DHCPv6 is the *only* way to provision IPv6 > > name servers onto hosts running Microsoft Windows. > > > > We'll see how long that statement stays true. I imagine some guys in Redmond mumbling "We'll see how long [Android not supporting DHCPv6] stays true". Childish stubbornness can be found in various places. At this occasion let me wholeheartedly thank both involved organizations for your continued support of the operational IPv6 community out here. Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Thu Apr 6 10:15: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 C2B931295A0 for ; Thu, 6 Apr 2017 10:15:25 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 KatHiyBV_rcl for ; Thu, 6 Apr 2017 10:15:23 -0700 (PDT) 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 BA14E12957D for ; Thu, 6 Apr 2017 10:15:20 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id d188so47946047vka.0 for ; Thu, 06 Apr 2017 10:15:20 -0700 (PDT) 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=SHqEwlkKGi9RIKoVahWz1Q2mTTwWp/0Cp9uNnoIJcfc=; b=oZmBuEuwAeyBqW2QwSMLBmj6LV4Nn6XbEImLcaujbTqC7Aep0PoKVAtvV8WZ1ME0dW 6LDT/HA86JJXAar3BAZmn0h6Zu2d/4bOHe6fqluXQc9IbJLC8DmK6d6NEbWia1HESjBS v3oh6+WuC9xwHmhKFHs+3/UqkyCwT2Qpt9H4nFbrWUag+L64ZyUfNOn4WqS+5QZReeB3 XYS77ZP5zXwDAI+I+yiSgyyLui/OFDYA51oV8REMDS0/O8iYZL0fuXK9EwEnstc0ptjf yXmOqDi6A9VXb+JyMFiA/1KlqHywtatRUauO4ofUBBB3pF9YRvoTg+eKat2okW8F7N25 368w== 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=SHqEwlkKGi9RIKoVahWz1Q2mTTwWp/0Cp9uNnoIJcfc=; b=pbV0sZITaq8QTBVdiESQFdmH8LjftfjKk2b93Mt4rSL3yBg4suG+Cs9RxZ77BQn4Qo OS8IwgIXmzYAh9gQoxfXlLdprnsD4+sJ7rB2f2A6rIwRBDZu+uuawbZNvqPdNf8Rd1Fp CcCVODk2hina9ueAAGwZ4pqWDglpJhhpDXgTv4a2HnWEV7u8C/Py/gXs7Al7t7fFlBzr lFJ6iCbt05xCHuJpD5siVvBpSg6uMIxX7N08YgVtr0v3cv8GGpbnPFgViCDGTKjUDPjD 3anph81rDAF2/aFMipFGcgsLv/wAEwfT1oJgWCivs4B8qzoOdTp3NPlND7UOR03xXYCc Uppg== X-Gm-Message-State: AN3rC/53OktEqfwOnSCHo2jeB917a9aW47Cj86tWg+v5AI25OdHwvIv37CSSpt+xO8R6A1Ux2b2436dJGzqI6J3f X-Received: by 10.176.2.104 with SMTP id 95mr384468uas.30.1491498919415; Thu, 06 Apr 2017 10:15:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Thu, 6 Apr 2017 10:14:58 -0700 (PDT) In-Reply-To: <28F6E669-8DB5-46FB-A2BE-A6CA4F2C4855@gmail.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <28F6E669-8DB5-46FB-A2BE-A6CA4F2C4855@gmail.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 02:14:58 +0900 Message-ID: To: Fred Baker Cc: Tore Anderson , IPv6 Operations Content-Type: multipart/alternative; boundary=001a1134ee3846e034054c82a756 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:15:26 -0000 --001a1134ee3846e034054c82a756 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 1:52 AM, Fred Baker wrote: > I would have to say that a statement made by an operational group in the > IETF needs to address the needs of the operators in the group, which I > think Tore has pretty succinctly stated (and which fits the data arriving > in my in-box; there are a variety of viewpoints, but if I had to call it > right now, I would say that the developing consensus is for routers to > support both as MTI). If a vendor of a product, however widely used, has an > opinion, it's relevant and welcome (having myself been from the vendor side > for quite some time), but this is first and foremost about operational > viewpoints. > Actually, this has nothing to do with a vendors and everything to do with operations. My position is that as a participant in an operational group I cannot live with a MUST that will cause this sort of damage. This problem is in no way limited to a specific vendor or a specific product, or even to all portable hotspots. It's a problem in any renumbering situation. A home network has exactly the same problem. Home routers, today, hand out DNS server addresses using DHCPv6 and RDNSS, and DHCPv6 provides no way to change those when the network is renumbered. A small enterprise using draft-ietf-rtgwg-enterprise-pa-multihoming will also have the same problem. The fact of the matter is that DHCPv6 is fundamentally unsuited to telling hosts that things have changed, and as such, *it only works well when nothing changes*. It works great when you're doing BGP multihoming or in IPv4 with NAT, but that's pretty much where it stops being effective. Many of the operators who are advocating for DHCPv6 here say that everyone uses anycast DNS anyway, and that their DNS servers have not changed for 15 years. That's great in an enterprise network that uses BGP, but the number of such networks is dwarfed by the number of home networks that *don't* use anycast DNS and *do* get renumbered. Saying that all those routers MUST implement DHCPv6, and degrade the ability of those networks to renumber like this, is fundamentally broken. RFC 8106 came out of 6man (https://datatracker.ietf.org/doc/rfc8106/). I > might suspect that 6man would consider a draft updating it to reverse its > recommendation that DHCPv6 be preferred over RDNSS, although that is for > its chairs to say. I think you have presented some very relevant arguments > to support the viewpoint. > Changing 8106 won't avoid breakage to existing implementations. If we add this MUST, then deploying a router that follows this MUST will break the ability to renumber of existing clients. This is not good operational practice and we should not do it. --001a1134ee3846e034054c82a756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 1:52 AM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
I would have to say that a statement made by an operational grou= p in the IETF needs to address the needs of the operators in the group, whi= ch I think Tore has pretty succinctly stated (and which fits the data arriv= ing in my in-box; there are a variety of viewpoints, but if I had to call i= t right now, I would say that the developing consensus is for routers to su= pport both as MTI). If a vendor of a product, however widely used, has an o= pinion, it's relevant and welcome (having myself been from the vendor s= ide for quite some time), but this is first and foremost about operational = viewpoints.




= RFC 8106 came out of 6man (https://datatracker.ietf.org/doc/rfc8106/). I might suspect that 6man would consider a draf= t updating it to reverse its recommendation that DHCPv6 be preferred over R= DNSS, although that is for its chairs to say. I think you have presented so= me very relevant arguments to support the viewpoint.
=

Changing 8106 won&#= 39;t avoid breakage to existing implementations. If we add this MUST, then = deploying a router that follows this MUST will break the ability to renumbe= r of existing clients. This is not good operational practice and we should = not do it.
--001a1134ee3846e034054c82a756-- From nobody Thu Apr 6 10:20: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 BBDB4129544 for ; Thu, 6 Apr 2017 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jJgJ5-cZ1UXU for ; Thu, 6 Apr 2017 10:20:40 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 5F3AF124234 for ; Thu, 6 Apr 2017 10:20:40 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=58788 helo=envy.e1.y.home) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cwB5K-0004qV-KL; Thu, 06 Apr 2017 17:20:38 +0000 Date: Thu, 6 Apr 2017 19:20:38 +0200 From: Tore Anderson To: Lorenzo Colitti Cc: Erik Kline , IPv6 Operations Message-ID: <20170406192038.139ec505@envy.e1.y.home> In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:20:46 -0000 * Lorenzo Colitti > On Fri, Apr 7, 2017 at 1:48 AM, Tore Anderson wrote: > > > > > To the best of my knowledge, DHCPv6 is the *only* way to > > > > provision IPv6 name servers onto hosts running Microsoft > > > > Windows. > > > > > > We'll see how long that statement stays true. > > > > Years, certainly. Decade(s), probably. Keep in mind that Windows XP, > > released in 2001, still has a significant install base. > > The question is what will be the situation when we remove support for > DHCPv4. That is a similarly long time horizon. Precisely. 10 year old Windows Vista was the first release to properly support IPv6-only networks, yet it's only now that such networks is starting to become viable (and even that might be an exaggeration). So in the same way, even if Microsoft should release a new Windows version with RDNSS support tonight, we should expect that at least 10 more years will need to pass before IPv6-only networks without stateless DHCPv6 are viable. We don't have that time. Tore From nobody Thu Apr 6 10:21: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 B0880129488 for ; Thu, 6 Apr 2017 10:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 okwBIVz_R50q for ; Thu, 6 Apr 2017 10:21:20 -0700 (PDT) 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 304731294A0 for ; Thu, 6 Apr 2017 10:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15064; q=dns/txt; s=iport; t=1491499279; x=1492708879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rltXlv6qx80ngOYJ6C+hakD9EG75UVUGMNDDVr+6J8I=; b=TyotKW0OlTZucE0jFiCbIWlgQ1MB7HWKGURce54s5uTzmL2ikAlFwNzo FckxaChMCATS3wP/t25t7OpbMStksv9D5xrvH6fM9nQqRiT/Ykvj/yam1 /IP96acjBdHM7Sal2FfKnZBi7Eal44XyvrZ/W/s+PGKP5OsyScXXnmyRn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgD+d+ZY/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYELB4NcihKRPZAhhTSCD4YiAhqDLD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECASMKTAULAgEIEQQBASgDAgICMBQJCAIEDgUIiX4IqkCCJopnAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYs+hEAtH4JQgl8FnHMBkkmCB4UuihGIXosZAR8?= =?us-ascii?q?4SzpbFYUcHYFjdYciKoEGgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,160,1488844800"; d="scan'208,217";a="229731106" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2017 17:21:18 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v36HLIrb013368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2017 17:21:18 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 12:21:17 -0500 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, 6 Apr 2017 12:21:17 -0500 From: "Bernie Volz (volz)" To: Lorenzo Colitti CC: "STARK, BARBARA H" , IPv6 Operations Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohLAlJXdnN5j0uTKcn23s0z76G4fOCAgAAIq4CAABMKgIAAHfQAgAAjSAD//6z/MIAAV0+A//+4pUA= Date: Thu, 6 Apr 2017 17:21:17 +0000 Message-ID: <2d05f1cf883944918058e1db758f761a@XCH-ALN-003.cisco.com> References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.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.195] Content-Type: multipart/alternative; boundary="_000_2d05f1cf883944918058e1db758f761aXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:21:23 -0000 --_000_2d05f1cf883944918058e1db758f761aXCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBQbGVhc2UgZG9uJ3QgdGVsbCBtZSB0aGF0IHRoZSBjbGllbnQgbmVlZHMgdG8gcmVhY3QgdG8g dGhlIFJBIHdpdGggdGhlIG5ldyBETlMgc2VydmVycyBieSBzdGFydGluZyBESENQIHRvIHJlcXVl c3QgRE5TIHNlcnZlcnMuIDotKQ0KDQpUaGUgY2xpZW50IHdvdWxkIHJlYWN0IHRvIHRoZSBSQSBo YXZpbmcgbmV3IHByZWZpeCBpbmZvcm1hdGlvbiDigJMgc3VjaCBhcyB0aGF0IHRoZSBvbGQgcHJl Zml4IHdhcyBkZXByZWNhdGVkLg0KDQoNCi0gICAgICAgICAgQmVybmllDQoNCkZyb206IExvcmVu em8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBB cHJpbCAwNiwgMjAxNyAxMjozNSBQTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNj by5jb20+DQpDYzogU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb20+OyBJUHY2IE9wZXJh dGlvbnMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gTWFraW5nIFJETlNT IGEgTVVTVD8sIGh1bSB2Mg0KDQpPbiBGcmksIEFwciA3LCAyMDE3IGF0IDE6MzAgQU0sIEJlcm5p ZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28uY29tPj4gd3Jv dGU6DQpUaGUgcmVhc29uIGl0IGlzIGRlZ3JhZGVzIGZ1bmN0aW9uYWxpdHkgaXMgdGhhdCB3aXRo IHN0YXRlbGVzcyBESENQdjYgaXQgaXMgaW1wb3NzaWJsZSB0byBpbXBsZW1lbnQgZXZlbiBzdWNo IGJhc2ljIHRoaW5ncyBhcyAidGVsbCB0aGUgY2xpZW50IHRoYXQgaXRzIEROUyBzZXJ2ZXIgaXMg bm93IGdvbmUgYmVjYXVzZSB0aGUgY2VsbHVsYXIgbmV0d29yayB3ZW50IGRvd24gYW5kIGNhbWUg YmFjayB1cCB3aXRoIGEgZGlmZmVyZW50IHByZWZpeCB3aGVuIHlvdSB0ZW1wb3JhcmlseSBsb3N0 IGNlbGwgY292ZXJhZ2UiLiBUaGlzIHdvcmtzIHRvZGF5IHVzaW5nIFJETlNTLCBidXQgaWYgd2Ug aW1wbGVtZW50IERIQ1B2NiwgdGhpcyB3aWxsIHN0b3Agd29ya2luZyBmb3IgY2xpZW50cyB0aGF0 IHN1cHBvcnQgREhDUHY2LCBldmVuIGlmIHRoZXkgYWxzbyBzdXBwb3J0IFJETlNTLg0KDQpUaGlz IGlzIGJvZ3VzLiBJbiB0aGlzIGNhc2UgdGhlIGNsaWVudCBpcyBzdXBwb3NlZCB0byBpbml0aWF0 ZSBESENQdjYgdG8gZGlzY292ZXIgbmV3IGluZm9ybWF0aW9uLiBZZXMsIFJGQyAzMzE1LzM3MzYg d2FzIG5vdCBhcyBjbGVhciBhcyBpdCBjb3VsZCBoYXZlIGJlZW4gYWJvdXQgdGhpcyBidXQgdGhh dCBpc27igJl0IGNvbXBsZXRlbHkgZmFpciBjb21wYXJpc29uIGJlY2F1c2UgdGhlc2Ugd2VyZSB3 cml0dGVuIGEgbG9uZyB0aW1lIGFnbyBhbmQgdGhlIG5ldHdvcmtpbmcgd29ybGQgd2FzIGRpZmZl cmVudCBiYWNrIHRoZW4uDQoNClBsZWFzZSBleHBsYWluIGhvdyB0aGUgaG9zdCB3b3VsZCBrbm93 IHRoYXQgaXQgbmVlZHMgdG8gcnVuIERIQ1B2NiBhZ2Fpbi4NCg0KQnV0IGlmIGEgaG9zdCBkZXRl Y3RzIHRoYXQgdGhpbmdzIG1heSBoYXZlIGNoYW5nZWQgKHN1Y2ggYXMgd2hlbiBhIGxpbmsgZ29l cyBkb3duKSwgaXQgd291bGQgYmUgcmF0aGVyIHNpbGx5IG9mIGl0IG5vdCB0byBwZXJmb3JtIGFu IHVwZGF0ZSBvZiBpdHMgREhDUCBpbmZvcm1hdGlvbi4NCg0KVGhlIGxpbmsgZGlkIG5vdCBnbyBk b3duLiBUaGUgdXBzdHJlYW0gd2FzIHJlbnVtYmVyZWQuIE5vbmUgb2YgdGhlIGNvbmRpdGlvbnMg aW4gMzMxNWJpcyAxOC4yLjMgb2NjdXJyZWQuDQoNClBsZWFzZSBkb24ndCB0ZWxsIG1lIHRoYXQg dGhlIGNsaWVudCBuZWVkcyB0byByZWFjdCB0byB0aGUgUkEgd2l0aCB0aGUgbmV3IEROUyBzZXJ2 ZXJzIGJ5IHN0YXJ0aW5nIERIQ1AgdG8gcmVxdWVzdCBETlMgc2VydmVycy4gOi0pDQo= --_000_2d05f1cf883944918058e1db758f761aXCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0Kc3Bhbi5nbWFpbC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjE2ODM2ODQ5ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTE3MTcwMjM0NDIgLTEzNzkyMjU0MzIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxMTk7DQoJbXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj4gUGxlYXNlIGRvbid0IHRlbGwgbWUgdGhhdCB0aGUgY2xp ZW50IG5lZWRzIHRvIHJlYWN0IHRvIHRoZSBSQSB3aXRoIHRoZSBuZXcgRE5TIHNlcnZlcnMgYnkg c3RhcnRpbmcgREhDUCB0byByZXF1ZXN0IEROUyBzZXJ2ZXJzLiA6LSk8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGNsaWVudCB3b3VsZCByZWFjdCB0byB0aGUgUkEgaGF2 aW5nIG5ldyBwcmVmaXggaW5mb3JtYXRpb24g4oCTIHN1Y2ggYXMgdGhhdCB0aGUgb2xkIHByZWZp eCB3YXMgZGVwcmVjYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4t PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QmVybmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMDYsIDIwMTcgMTI6MzUgUE08 YnI+DQo8Yj5Ubzo8L2I+IEJlcm5pZSBWb2x6ICh2b2x6KSAmbHQ7dm9sekBjaXNjby5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBTVEFSSywgQkFSQkFSQSBIICZsdDticzc2NTJAYXR0LmNvbSZndDs7 IElQdjYgT3BlcmF0aW9ucyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbdjZvcHNdIE1ha2luZyBSRE5TUyBhIE1VU1Q/LCBodW0gdjI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgQXByIDcsIDIw MTcgYXQgMTozMCBBTSwgQmVybmllIFZvbHogKHZvbHopICZsdDs8YSBocmVmPSJtYWlsdG86dm9s ekBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGUgcmVhc29uIGl0IGlzIGRlZ3JhZGVzIGZ1bmN0aW9uYWxpdHkgaXMgdGhh dCB3aXRoIHN0YXRlbGVzcyBESENQdjYgaXQgaXMgaW1wb3NzaWJsZSB0byBpbXBsZW1lbnQgZXZl biBzdWNoIGJhc2ljIHRoaW5ncyBhcyAmcXVvdDt0ZWxsIHRoZSBjbGllbnQgdGhhdCBpdHMgRE5T IHNlcnZlciBpcyBub3cgZ29uZSBiZWNhdXNlDQogdGhlIGNlbGx1bGFyIG5ldHdvcmsgd2VudCBk b3duIGFuZCBjYW1lIGJhY2sgdXAgd2l0aCBhIGRpZmZlcmVudCBwcmVmaXggd2hlbiB5b3UgdGVt cG9yYXJpbHkgbG9zdCBjZWxsIGNvdmVyYWdlJnF1b3Q7LiBUaGlzIHdvcmtzIHRvZGF5IHVzaW5n IFJETlNTLCBidXQgaWYgd2UgaW1wbGVtZW50IERIQ1B2NiwgdGhpcyB3aWxsIHN0b3Agd29ya2lu ZyBmb3IgY2xpZW50cyB0aGF0IHN1cHBvcnQgREhDUHY2LCBldmVuIGlmIHRoZXkgYWxzbyBzdXBw b3J0IFJETlNTLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBp cyBib2d1cy4gSW4gdGhpcyBjYXNlIHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gaW5pdGlhdGUg REhDUHY2IHRvIGRpc2NvdmVyIG5ldyBpbmZvcm1hdGlvbi4NCiBZZXMsIFJGQyAzMzE1LzM3MzYg d2FzIG5vdCBhcyBjbGVhciBhcyBpdCBjb3VsZCBoYXZlIGJlZW4gYWJvdXQgdGhpcyBidXQgdGhh dCBpc27igJl0IGNvbXBsZXRlbHkgZmFpciBjb21wYXJpc29uIGJlY2F1c2UgdGhlc2Ugd2VyZSB3 cml0dGVuIGEgbG9uZyB0aW1lIGFnbyBhbmQgdGhlIG5ldHdvcmtpbmcgd29ybGQgd2FzIGRpZmZl cmVudCBiYWNrIHRoZW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBleHBsYWlu IGhvdyB0aGUgaG9zdCB3b3VsZCBrbm93IHRoYXQgaXQgbmVlZHMgdG8gcnVuIERIQ1B2NiBhZ2Fp bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQg aWYgYSBob3N0IGRldGVjdHMgdGhhdCB0aGluZ3MgbWF5IGhhdmUgY2hhbmdlZCAoc3VjaCBhcyB3 aGVuIGEgbGluayBnb2VzIGRvd24pLCBpdCB3b3VsZCBiZSByYXRoZXINCiBzaWxseSBvZiBpdCBu b3QgdG8gcGVyZm9ybSBhbiB1cGRhdGUgb2YgaXRzIERIQ1AgaW5mb3JtYXRpb24uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBsaW5rIGRpZCBub3QgZ28gZG93bi4gVGhlIHVwc3RyZWFt IHdhcyByZW51bWJlcmVkLiBOb25lIG9mIHRoZSBjb25kaXRpb25zIGluIDMzMTViaXMmbmJzcDsx OC4yLjMgb2NjdXJyZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlBsZWFzZSBkb24ndCB0ZWxsIG1lIHRoYXQgdGhlIGNsaWVudCBuZWVkcyB0 byByZWFjdCB0byB0aGUgUkEgd2l0aCB0aGUgbmV3IEROUyBzZXJ2ZXJzIGJ5IHN0YXJ0aW5nIERI Q1AgdG8gcmVxdWVzdCBETlMgc2VydmVycy4gOi0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2d05f1cf883944918058e1db758f761aXCHALN003ciscocom_-- From nobody Thu Apr 6 10:31: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 87FA812957D for ; Thu, 6 Apr 2017 10:31:40 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 34YWwh9pLfHH for ; Thu, 6 Apr 2017 10:31:38 -0700 (PDT) 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 74756124234 for ; Thu, 6 Apr 2017 10:31:38 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id s68so48907758vke.3 for ; Thu, 06 Apr 2017 10:31:38 -0700 (PDT) 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=ZJ9H22mCBhHwzy0TGdQo8YRMZ1UJzKLqiWUmaoEbtpI=; b=msXOCMaPjcLABljDklZDh7c+TyPHDrFMST+BvLMpVICrEN+KNWtdxF8z/z7sjc0hMH WFeMbWBam814iUvuPYGPM56mDZe9CQ99kpPz4z1pKPKccd8Kzdr3MGWdDzIfZri1gWpR RfBdP34n3atVhxO/5TXCKNeHBgJZ1x05yNqG8kupeZTn22gQ27co+5muURFqEaxYGLB3 V7cHVCG2s1OKzl1qvsRKTSrp8zJjg4rKrEgsNM8anH9tGz9IRG1EdIxfG+tvmt4LdP0e eNJtT7ezxRA+7b7r5z2aFQkO7v1rLHD3x4tY0iB0rdDQ8AH4IVrNS/Lgahq11I3xkDUx UWtw== 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=ZJ9H22mCBhHwzy0TGdQo8YRMZ1UJzKLqiWUmaoEbtpI=; b=fRWutIZbwwGnfzV9z1QJA4QTHcvKcssoCK0EvbJCLOCv96uMxBgwPYD75xSvlcIWlL rvXwsFFfrxsEEr0fFlSl4ZdT+Odh47IB3C0xiVA+sCERsoWU0Rs88n7q3iDWUnPFGghP gFUibfXTyGUAvDJ9p1DLClPoGVw2YbGdfMk54FL1FtttmKGELrWA+3344HnKN7NCXnS3 y7u0w8EbU4oTVBsvMX+NUgWVg/dVZ7TR6zEiBvTEDMYKuHo5010YZtOgtsKT27gKOb5D d1RzywaJY3eLsagV+Px3yZtM/u6+ggtXALkq8ryvM6aAqj/oVl3Dt8ZLk26iKV7c/O5L R7tA== X-Gm-Message-State: AFeK/H0ngPF5xsk/5HI9CMJvPuHx14vQDcN7pv2xhpsNUslQkNB4E8ohVyAhZUHyKz9GEping7mECx8KfKul+6tY X-Received: by 10.31.60.17 with SMTP id j17mr11090219vka.45.1491499897235; Thu, 06 Apr 2017 10:31:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Thu, 6 Apr 2017 10:31:16 -0700 (PDT) In-Reply-To: <20170406192038.139ec505@envy.e1.y.home> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 02:31:16 +0900 Message-ID: To: Tore Anderson Cc: Erik Kline , IPv6 Operations Content-Type: multipart/alternative; boundary=001a11436e508f0711054c82e107 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:31:40 -0000 --001a11436e508f0711054c82e107 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 2:20 AM, Tore Anderson wrote: > So in the same way, even if Microsoft should release a new Windows > version with RDNSS support tonight, we should expect that at least 10 > more years will need to pass before IPv6-only networks without > stateless DHCPv6 are viable. > > We don't have that time. > Your network might not. But the lots of networks do. Home networks, for example. I'm pretty confident that 10 years from now the majority of home networks will still provide IPv4. (Perhaps the quality of IPv4 Internet access will be terrible, but the performance of querying your home gateway over IPv4 or IPv6 will be the same.) There are countries which have zero IPv6 deployment, even today. There are product categories like home entertainment systems or TVs where the majority of devices that don't support IPv6 at all, never mind IPv6-only. My point here is that a MUST for routers is too broad. A MUST for enterprise routers? No objection. Enterprises rarely change their network configurations, because they use VRRP, DHCPv6 failover, anycast, and a host of other technologies that we built during decades of IPv4 operation because hosts couldn't have more than one address at a time and couldn't be told that something had changed. But a MUST for dynamic networks will cause operational impact, and that's not acceptable. --001a11436e508f0711054c82e107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 2:20 AM, Tore Anderson <tore@fud.no> wrote:
=
So in the same way, even if Microsoft should release a new W= indows
version with RDNSS support tonight, we should expect that at least 10
more years will need to pass before IPv6-only networks without
stateless DHCPv6 are viable.

We don't have that time.

Your netwo= rk might not. But the lots of networks do. Home networks, for example. I= 9;m pretty confident that 10 years from now the majority of home networks w= ill still provide IPv4. (Perhaps the quality of IPv4 Internet access will b= e terrible, but the performance of querying your home gateway over IPv4 or = IPv6 will be the same.) There are countries which have zero IPv6 deployment= , even today. There are product categories like home entertainment systems = or TVs where the majority of devices that don't support IPv6 at all, ne= ver mind IPv6-only.

My point here is that a MUST f= or routers is too broad. A MUST for enterprise routers? No objection. Enter= prises rarely change their network configurations, because they use VRRP, D= HCPv6 failover, anycast, and a host of other technologies that we built dur= ing decades of IPv4 operation because hosts couldn't have more than one= address at a time and couldn't be told that something had changed. But= a MUST for dynamic networks will cause operational impact, and that's = not acceptable.
--001a11436e508f0711054c82e107-- From nobody Thu Apr 6 10:38: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 8372D12957F for ; Thu, 6 Apr 2017 10:38:09 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 uF4ibFdtqTLa for ; Thu, 6 Apr 2017 10:38:07 -0700 (PDT) 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 A142B12957D for ; Thu, 6 Apr 2017 10:38:07 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id s68so49113224vke.3 for ; Thu, 06 Apr 2017 10:38:07 -0700 (PDT) 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=JuLY0thaNeA4tUjTezp6TCVPx4oj6+CAmKbYr062daI=; b=lxDa2I9JVM9CIrZNfhLtd/5o2Q2IO5rRx8+IRjXI9yVlGaSyVxochQyze/xbiZKTMF cSkwGCsKfc+fQyK13xLIARDWpP2obYGEy31xgczCS2Txze8wJEeHvMTOhSMsowOOBXmQ ddErlTvLHf/XTjczDHVPfnyefIlN0yYU6xsGCXS+342HCUE9hgtGeaFwYaJ7ZBL0sZJs E0V0Nta6eXp0jSR11lk4tUKvDi94BTLBSd4CpPEw6caT1gxDoLbz58V+EugBXEBNhPGh P9S9OYDSt7nKuOr5wmArY5wwLMcqLIo0nfl3SIyXbolivLtFxWs6x3CBlwcjFRG0BnH3 TfPA== 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=JuLY0thaNeA4tUjTezp6TCVPx4oj6+CAmKbYr062daI=; b=t69dOE8U2MhVEPnFhYgQCJJtJwxEDPafqG8QwS5oRCkVkpxJCdAbPc2Fxu6bqxnEU6 DCQ0/hJhOEKpHT1gLO0OkBWkJdDIC3Lp43B3jRA2Zao0U2FPfVqPfYzVsG5opSbnc7is 7kkA2oQt9v6562426NLBw2uMRdrKdXCyPdSLiQyI5xoNVmieOKAwSoXwd4inBuFQWTwz knvOpWndYSPg3YWJrdxx6fJRTXbqz1UksREzyMDtEcbqjuk0RYHv35G5iTIMRYkKx37F kdQsdjpVBmCakzKfomZvwmENEdHMQB4dyHC6gTXUh7axWjMm7RCmjBbmX8qhFxT596Yj TS0g== X-Gm-Message-State: AN3rC/5oQENvNwkHbV/YmsToQIvYzoqZ6AsWuJ7bDGPfhlpNpVDfAW552TprmqvRgDu0zEWpissoxd4etvcY+tNp X-Received: by 10.159.40.231 with SMTP id d94mr3082888uad.122.1491500286441; Thu, 06 Apr 2017 10:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Thu, 6 Apr 2017 10:37:45 -0700 (PDT) In-Reply-To: <2d05f1cf883944918058e1db758f761a@XCH-ALN-003.cisco.com> References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2d05f1cf883944918058e1db758f761a@XCH-ALN-003.cisco.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 02:37:45 +0900 Message-ID: To: "Bernie Volz (volz)" Cc: "STARK, BARBARA H" , IPv6 Operations Content-Type: multipart/alternative; boundary=94eb2c123f12c1d504054c82f8d6 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:38:09 -0000 --94eb2c123f12c1d504054c82f8d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 7, 2017 at 2:21 AM, Bernie Volz (volz) wrote: > > Please don't tell me that the client needs to react to the RA with the > new DNS servers by starting DHCP to request DNS servers. :-) > > > > The client would react to the RA having new prefix information =E2=80=93 = such as > that the old prefix was deprecated. > Can you cite an implementation that does this, or even a specification that recommends or requires it? Even if you can, from a design perspective saying "we use DHCPv6 to distribute DNS information and the only way to know that that information needs to be refreshed is to listen for an RA" is absurd, given that putting the DNS servers in the RA is faster, simpler, and more reliable. --94eb2c123f12c1d504054c82f8d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 2:21 AM, Bernie Volz (volz) <volz@cisco.com>= wrote:

> Please don't tell me = that the client needs to react to the RA with the new DNS servers by starti= ng DHCP to request DNS servers. :-)

=C2=A0

The client would react to the = RA having new prefix information =E2=80=93 such as that the old prefix was = deprecated.


Can you = cite an implementation that does this, or even a specification that recomme= nds or requires it?

Even if you can, from a design= perspective saying "we use DHCPv6 to distribute DNS information and t= he only way to know that that information needs to be refreshed is to liste= n for an RA" is absurd, given that putting the DNS servers in the RA i= s faster, simpler, and more reliable.
--94eb2c123f12c1d504054c82f8d6-- From nobody Thu Apr 6 10:59:24 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 C7B0C12426E for ; Thu, 6 Apr 2017 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 d7Y-9qTf4DIb for ; Thu, 6 Apr 2017 10:59:19 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 61BB61289B5 for ; Thu, 6 Apr 2017 10:59:17 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id l7so34801366ioe.3 for ; Thu, 06 Apr 2017 10:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=518uxXUEJR49rO1LZNNr7h+UFXLAIpFu1+Q3WTTCK/o=; b=SSPbKZktQLGj+O3li7ewFEQ9mRKT1aHQSNR34IFRAjCArSkY0rTfPNHAZ/G4eAofxu iESRLe5KuBjWR06ccse1SHyvDCbpsTxpNCK9zT75XmEOMym5aQaP5XXhbzCfuMm7RSEG rUR3McQIeckt5iH5U+eTuDyeBMdMyQ98ZiUIljHH+W8rtKKqadrwmtJN40IU3WlenpUE jk+VfempoTPzojnflv/nXKdEF9gDrZYzrO0gn8rM2PU29NKu/TUWaPc2NJZhnLDBSn5Q 87NyXXtgANEEmpQ0BeRrIEXsXwcjZs14AZXT6HLbJalm6p0gg713DYTWuQZDlnVNurRR c78A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=518uxXUEJR49rO1LZNNr7h+UFXLAIpFu1+Q3WTTCK/o=; b=a7FUFaGUqTNoFDRXpx0+3IywzVuvds23Qi4R5I615BV2TsBNfwzNaRObiLU9OjBPQI Jk2nyyjGx2W+q2FqvXVUpZjoGp/4qn7wxjBkWOGp9KTvmpa5KOYd2grbeICX7fZLYctx 4cISfZ7sch3BxNTaoAS2b3qUTw6jrGIdfZp++EJjYl0eqUKXzhjmbyAehDI8Nu2gbkZu 7R9lNwlAcndA//FVozayJDjqkVA9M4GCl+oD6huNkrCZZYyv4uhaW4oPNwRW7SzjdvuB +TugByH4RIOhCHivhzaXjGFfOcZ5Wp9aH9jYNNCGgzYUsTHticV5W0bz4iIaSPcgDpQB YYFw== X-Gm-Message-State: AFeK/H18+09siHWyOtNJ4yh3igbac7dRgf7c5jrWel0B1AiCWWYw8GLTHQw79vSw/VztjWB8 X-Received: by 10.107.3.198 with SMTP id e67mr34579341ioi.179.1491501556390; Thu, 06 Apr 2017 10:59:16 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id z18sm1199429ita.16.2017.04.06.10.59.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 10:59:15 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_4360407B-2647-48DE-B626-D83F90309574" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 6 Apr 2017 10:59:14 -0700 References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> To: IPv6 Operations In-Reply-To: Message-Id: <79CEE097-2DF9-492A-94E3-8E4F18056DB4@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:59:23 -0000 --Apple-Mail=_4360407B-2647-48DE-B626-D83F90309574 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 6, 2017, at 09:19, Lorenzo Colitti wrote: >=20 > The Android phone in my pocket is a router when I go to the coffee = shop every morning and turn on tethering. As the maintainer of that = code, I absolutely do not want to spend software engineering time = writing a DHCPv6 server that is not only less capable than the RDNSS = implementation that we have now, but also degrades functionality. >=20 > The reason it is degrades functionality is that with stateless DHCPv6 = it is impossible to implement even such basic things as "tell the client = that its DNS server is now gone because the cellular network went down = and came back up with a different prefix when you temporarily lost cell = coverage". This works today using RDNSS, but if we implement DHCPv6, = this will stop working for clients that support DHCPv6, even if they = also support RDNSS. > Client gets DNS addresses from both RDNSS and DHCPv6, and prefers = DHCPv6 due to RFC 8106. > Upstream goes down. We deprecate the prefix (we can't make it invalid = because of the 2-hour rule), and declare the DNS servers invalid. We = can't do anything about DHCPv6. > The upstream comes back with a new prefix. We announce the new DNS = servers using RDNSS. But the client still uses the out-of-date = DHCPv6-provided DNS servers, because RFC 8106 says it should prefer = DHCPv6 over RDNSS. > I cannot live with breaking user experience like this. It=E2=80=99s technically not required that we break user experience like = this. We could add still more onerous requirements to work around the = abject brokenness of DHCPv6. Run a forwarding DNS resolver service in routers. Advertise it to hosts = at a ULA in both RA and DHCPv6. Reset the forwarding addresses when the = DNS information changes. If it=E2=80=99s a caching server, then be sure = to flush the cache when the upstream server addresses change. There are IPv6 routers in the real world today that do exactly this for = precisely this purpose. I know, because I wrote it that way to keep from = breaking the experience for Windows users. It caused other damage, but = consensus seemed to be that the trade-off was worth it. Do we love DHCPv6 enough to make standard requirements that keep from = breaking user experience? Somehow, I=E2=80=99m not optimistic. We could = do it, and if we did, then I=E2=80=99d have no major objection to = mandatory DHCPv6 in routers. I don=E2=80=99t expect to see any = significant appetite for it. --james woodyatt > --Apple-Mail=_4360407B-2647-48DE-B626-D83F90309574 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 6, 2017, at 09:19, Lorenzo Colitti <lorenzo@google.com> = wrote:

The Android = phone in my pocket is a router when I go to the coffee shop every = morning and turn on tethering. As the maintainer of that code, I = absolutely do not want to spend software engineering time writing a = DHCPv6 server that is not only less capable than the RDNSS = implementation that we have now, but also degrades = functionality.

The reason it is degrades functionality is that with = stateless DHCPv6 it is impossible to implement even such basic things as = "tell the client that its DNS server is now gone because the cellular = network went down and came back up with a different prefix when you = temporarily lost cell coverage". This works today using RDNSS, but if we = implement DHCPv6, this will stop working for clients that support = DHCPv6, even if they also support RDNSS.
  1. Client gets DNS addresses from = both RDNSS and DHCPv6, and prefers DHCPv6 due to RFC 8106.
  2. Upstream = goes down. We deprecate the prefix (we can't make it invalid because of = the 2-hour rule), and declare the DNS servers invalid. We can't do = anything about DHCPv6.
  3. The= upstream comes back with a new prefix. We announce the new DNS servers = using RDNSS. But the client still uses the out-of-date DHCPv6-provided = DNS servers, because RFC 8106 says it should prefer DHCPv6 over = RDNSS.
I cannot live with breaking user experience like = this.

It=E2=80= =99s technically not required that we break user experience like this. = We could add still more onerous requirements to work around the abject = brokenness of DHCPv6.

Run a = forwarding DNS resolver service in routers. Advertise it to hosts at a = ULA in both RA and DHCPv6. Reset the forwarding addresses when the DNS = information changes. If it=E2=80=99s a caching server, then be sure to = flush the cache when the upstream server addresses change.

There are IPv6 routers in the real world today = that do exactly this for precisely this purpose. I know, because I wrote = it that way to keep from breaking the experience for Windows users. It = caused other damage, but consensus seemed to be that the trade-off was = worth it.

Do we love DHCPv6 enough = to make standard requirements that keep from breaking user experience? = Somehow, I=E2=80=99m not optimistic. We could do it, and if we did, then = I=E2=80=99d have no major objection to mandatory DHCPv6 in routers. I = don=E2=80=99t expect to see any significant appetite for it.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_4360407B-2647-48DE-B626-D83F90309574-- From nobody Thu Apr 6 11:44: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 5E98A129408 for ; Thu, 6 Apr 2017 11:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 9Ln4wEkVAx3J for ; Thu, 6 Apr 2017 11:44:37 -0700 (PDT) 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 A55FF12741D for ; Thu, 6 Apr 2017 11:44:37 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v36IZDC9008955; Thu, 6 Apr 2017 14:44:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 29nrghgeu4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 14:44:27 -0400 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 v36IiQ87008644; Thu, 6 Apr 2017 14:44:26 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v36IiJrP008534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 14:44:20 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 6 Apr 2017 18:44:04 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 14:44:03 -0400 From: "STARK, BARBARA H" To: Fred Baker , Lorenzo Colitti CC: IPv6 Operations , Tore Anderson Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohJPytzlZ90JUCxvg9piYpj0aG4bByAgAAIrICAABMJgIAARnoAgAABUoCAAALFAP//1RjQ Date: Thu, 6 Apr 2017 18:44:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB1555F@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <28F6E669-8DB5-46FB-A2BE-A6CA4F2C4855@gmail.com> In-Reply-To: <28F6E669-8DB5-46FB-A2BE-A6CA4F2C4855@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.235] 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-04-06_14:, , 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-1702020001 definitions=main-1704060150 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 18:44:39 -0000 > I would have to say that a statement made by an operational group in the > IETF needs to address the needs of the operators in the group, which I th= ink > Tore has pretty succinctly stated (and which fits the data arriving in my= in- > box; there are a variety of viewpoints, but if I had to call it right now= , I would > say that the developing consensus is for routers to support both as MTI).= If a > vendor of a product, however widely used, has an opinion, it's relevant a= nd > welcome (having myself been from the vendor side for quite some time), > but this is first and foremost about operational viewpoints. I'd like to share one aspect of my response to v6ops chairs, in response to= this. The hum question also asked for thoughts on which document. What I said about which document was: - Leave RFC 7084 alone wrt this. [RFC 7084 already has delivery of DNS by = RDNSS and either stateless or stateful DHCPv6 as MTI (MUST) for "CE Routers= "; I'm opposed to introducing a DHCPv6 Relay requirement for this class of = routers; which doesn't mean they can't or shouldn't implement Relay -- it j= ust means Relay isn't relevant to the purpose of the doc.] - Make RDNSS, DHCPv6 Server (stateful), and DHCPv6 Relay MTI (MUST) in the= newly adopted draft-ali-ipv6rtr-reqs. I do think that draft needs to be mo= re clearly targeted towards non-mass-market routers (or maybe even just tar= get enterprise, if that's where the big problem is). Many of the requiremen= ts are inappropriate for mass market routers (and some should even be recom= mended against for mass market routers). I'll provide those comments when t= he next rev comes out. Note that if we do this, neither document would apply to 3GPP UEs that do t= ethering. There is still the separate and completely distinct question about possibly= evolving RFC 6434 to make RDNSS a MUST for hosts. Based on my reading of t= his thread's discussion, I'm leaning more and more towards "Yes" (away from= my previous ambivalence, of accepting "Yes" or "do nothing").=20 WRT to the separate and distinct question about evolving RFC 6434 to make D= HCPv6 (stateless or stateful) client MTI (MUST) for hosts, I continue to be= opposed. Barbara From nobody Thu Apr 6 11:55: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 C058D120326 for ; Thu, 6 Apr 2017 11:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kziuYuFkQ-em for ; Thu, 6 Apr 2017 11:55:10 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 5E61512959B for ; Thu, 6 Apr 2017 11:55:08 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=59278 helo=envy.e1.y.home) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cwCYk-0005Dk-KV; Thu, 06 Apr 2017 18:55:06 +0000 Date: Thu, 6 Apr 2017 20:55:00 +0200 From: Tore Anderson To: Lorenzo Colitti Cc: Erik Kline , IPv6 Operations Message-ID: <20170406205500.2648a200@envy.e1.y.home> In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 18:55:12 -0000 * Lorenzo Colitti > On Fri, Apr 7, 2017 at 2:20 AM, Tore Anderson wrote: >=20 > > So in the same way, even if Microsoft should release a new Windows > > version with RDNSS support tonight, we should expect that at least 10 > > more years will need to pass before IPv6-only networks without > > stateless DHCPv6 are viable. > > > > We don't have that time. >=20 > Your network might not. But the lots of networks do. Home networks, for > example. I'm pretty confident that 10 years from now the majority of home > networks will still provide IPv4. Certainly if the expectation is that IPv4 will =C2=ABalways=C2=BB be there = to save the day, we do not need DHCPv6 (or RDNSS for that matter). I'd however like to see a solution that works as well as possible today given what implemtations exist in the wild today, *without* requiring IPv4. > (Perhaps the quality of IPv4 Internet access will be terrible, but > the performance of querying your home gateway over IPv4 or IPv6 will > be the same.) [...] > But a MUST for dynamic networks will cause operational impact, and > that's not acceptable. If you're already implementing and pointing the downstream clients at a resolver cache/proxy in the router, surely you could assign a static and permanent IPv6 address (a ULA /128 for example) to it to alleviate any concerns about not being able to update it? Tore From nobody Thu Apr 6 12:01: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 2680B1292D0 for ; Thu, 6 Apr 2017 12:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 iKMqpCZOqavL for ; Thu, 6 Apr 2017 12:01:46 -0700 (PDT) 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 20231129622 for ; Thu, 6 Apr 2017 12:01:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwCf7-0000FsC; Thu, 6 Apr 2017 21:01:41 +0200 Message-Id: To: v6ops@ietf.org Cc: james woodyatt From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpr o.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <79CEE097-2DF9-492A-94E3-8E4F18056DB4@google.com> In-reply-to: Your message of "Thu, 6 Apr 2017 10:59:14 -0700 ." <79CEE097-2DF9-492A-94E3-8E4F18056DB4@google.com> Date: Thu, 06 Apr 2017 21:01:41 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 19:01:49 -0000 > There are IPv6 routers in the real world today that do exactly > this for precisely this purpose. I know, because I wrote it that > way to keep from breaking the experience for Windows users. It > caused other damage, but consensus seemed to be that the trade-off > was worth it. > > Do we love DHCPv6 enough to make standard requirements that keep > from breaking user experience? Somehow, Im not optimistic. We > could do it, and if we did, then Id have no major objection to > mandatory DHCPv6 in routers. I dont expect to see any significant > appetite for it. I managed to quickly create about 8 reasons why Lorenzo's would not have to be a problem in practice. This is one of them. In order of appearance I have: 1) A stateless DHCP server doesn't to be enabled by default. Assuming that for most hosts it just works (either because of RDNSS or because of IPv4) you can just leave disabled until you really need it. 2) Refusing to implement any kind of DHCP does not recognize the fact that there is more to DHCP then just DNS. 3) It assumes that the DHCP by default automatically announces the upstream DNS resolvers. It would be quite possible to leave that upto the user and the user might for example configure Google's public DNS resolvers which work anywhere 4) It assumes that the DNS resolvers will stop working after the phone gets a different prefix. A mobile telco can just as well configure static addresses that work anywhere in the mobile provider's network. 5) Your point. If we want to support this scenario, just include something like dnsmasq. Note that Lorenzo can just do that. There is no RFC that prohibits a local DNS resolver in a router. 6) An RA cannot actually withdraw addresses. So when the prefix changes, the validity of any addresses configured by downstream hosts is limited to two hours, but not actually withdrawn. One way around that is to cause a link down event. Obviously, hosts should try to reconfigure all resources after a link down event. Also the ones they got through DHCP 7) The lifetime can be limited to 10 minutes. Not ideal, but also not a disaster is this change happens rarely 8) The DHCP protocol supports reconfigure also for information-requests. From nobody Thu Apr 6 12:48: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 F106912961E for ; Thu, 6 Apr 2017 12:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 G-bum7Lkme2A for ; Thu, 6 Apr 2017 12:48:53 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 189C8129639 for ; Thu, 6 Apr 2017 12:48:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36JmoK8013911; Thu, 6 Apr 2017 21:48:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 78E4D209F29; Thu, 6 Apr 2017 21:48:50 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6B8A6209EDC; Thu, 6 Apr 2017 21:48:50 +0200 (CEST) Received: from [132.166.84.172] ([132.166.84.172]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36JmkuZ023930; Thu, 6 Apr 2017 21:48:47 +0200 To: Fred Baker References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2AF3CBC7-A275-4532-9930-784282C4D63D@gmail.com> Cc: v6ops@ietf.org From: Alexandre Petrescu Message-ID: <67c7e59e-bc2b-554d-7fe6-f3974e257c78@gmail.com> Date: Thu, 6 Apr 2017 21:48:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2AF3CBC7-A275-4532-9930-784282C4D63D@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? - tethering, DHCPv6, RDNSS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 19:48:55 -0000 Le 06/04/2017 à 18:38, Fred Baker a écrit : > > On Apr 6, 2017, at 9:28 AM, Alexandre Petrescu > wrote: >> >>> The Android phone in my pocket is a router when I go to the >>> coffee shop every morning and turn on tethering. >> >> Tethering? Which standard is that? > > I believe that he is referring to RFC 7278, and by extension: > > https://tools.ietf.org/html/rfc6459 6459 IPv6 in 3rd Generation > Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen, > Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. > January 2012. (Format: TXT=84769 bytes) (Status: INFORMATIONAL) (DOI: > 10.17487/RFC6459) > > https://tools.ietf.org/html/rfc7278 7278 Extending an IPv6 /64 Prefix > from a Third Generation Partnership Project (3GPP) Mobile Interface > to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format: > TXT=19965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7278) If it is so, then I think developper should understand the qualifier "INFORMATIONAL" next to this RFC7278. Developper should know from a start that that code doing tethering has no future, and it is not worth time investing in. If developper accepts that, then we can talk about the necessity of DHCPv6. (or otherwise enjoy coffee and forget tethering :-) Alex > > https://tools.ietf.org/html/rfc7934 7934 Host Address Availability > Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July > 2016. (Format: TXT=37124 bytes) (Also BCP0204) (Status: BEST CURRENT > PRACTICE) (DOI: 10.17487/RFC7934) > > o Extending the network (e.g., "tethering"). > > o /64 sharing [RFC7278]. When the topology supports it, this is a > way to provide IPv6 tethering without needing to wait for network > operators to deploy DHCPv6 Prefix Delegation (PD), which is only > available in 3GPP release 10 or above ([RFC6459], Section 5.3). > > o DHCPv6 Prefix Delegation (PD) [RFC3633]. DHCPv6 PD allows the > client to request and be delegated a prefix, from which it can > autonomously form other addresses. If the prefix is shorter than > /64, it can be divided into multiple subnets that can be further > delegated to downstream clients. If the prefix is a /64, it can be > extended via L2 bridging, Neighbor Discovery (ND) proxying [RFC4389], > or /64 sharing [RFC7278], but it cannot be further subdivided, as a > prefix longer than /64 is outside the current IPv6 specifications > [RFC7421]. While the DHCPv6 Prefix Delegation specification > [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD > itself does not require that the client forward IPv6 packets not > addressed to itself, and thus does not require that the client be an > IPv6 router as defined in the IPv6 specification [RFC2460]. Also, in > many cases (such as tethering, or hosting virtual machines), hosts > are already forwarding IPv6 packets and thus operating as IPv6 > routers as defined in the IPv6 specification [RFC2460]. > > From nobody Thu Apr 6 12:50: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 256B7129650 for ; Thu, 6 Apr 2017 12:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 5xyz6M8DIarr for ; Thu, 6 Apr 2017 12:50:56 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 A12A112961E for ; Thu, 6 Apr 2017 12:50:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36Joqes011424 for ; Thu, 6 Apr 2017 21:50:52 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0E25E209DFA for ; Thu, 6 Apr 2017 21:50:52 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 040D92083E5 for ; Thu, 6 Apr 2017 21:50:52 +0200 (CEST) Received: from [132.166.84.172] ([132.166.84.172]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36JopQw024745 for ; Thu, 6 Apr 2017 21:50:51 +0200 To: v6ops@ietf.org References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> From: Alexandre Petrescu Message-ID: <434ba61e-5f20-1c95-e24c-f333cd593be2@gmail.com> Date: Thu, 6 Apr 2017 21:50:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170406183800.3e4f5ef4@envy.e1.y.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 19:50:58 -0000 Le 06/04/2017 à 18:38, Tore Anderson a écrit : > * Erik Kline > >> As a vendor of a device that is sometimes a router I am opposed to, >> and have precisely zero interesting in, implementing a DHCPv6 relay >> or server function. It adds nothing > > Um, «adds nothing», really? > > To the best of my knowledge, DHCPv6 is the *only* way to provision IPv6 > name servers onto hosts running Microsoft Windows. YEs. But it has drawbacks, and should be improved. It lacks a lifetime. The server is there installed in Windows forever, until overwritten. That makes that after going to IETF meeting and coming back to my non-IPv6 office network, my laptop still has a DHCPv6 server configured seen with "ipconfig /all". I dont like that. Were it to have a lifetime, it would expire. But no. I am suggesting to add that lifetime in DHCPv6. Alex > > In my operational reality, «support for Microsoft Windows hosts» is > diametrically opposite to «nothing». > > The exact same point goes for Android and RDNSS. > > Thus, when operating a BYOD IPv6 network, it is absolutely essential to > support *both* RDNSS and DHCPv6. Otherwise you'll be excluding a > significant amount of devices from being able to use your network. > > Tore > > PS: Apologies to the WG and the chairs for the misdirected hum to the > list a couple of messages earlier in the thread. It appears my MUA > didn't interpret the Reply-To header as I thought it would. My bad. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Apr 6 12:51: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 DCCCA129640 for ; Thu, 6 Apr 2017 12:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 6ydXAgIwyVIp for ; Thu, 6 Apr 2017 12:51:30 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 60A3F12961E for ; Thu, 6 Apr 2017 12:51:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36JpSgI028549; Thu, 6 Apr 2017 21:51:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1DD5B209DFA; Thu, 6 Apr 2017 21:51:28 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 10DD82083E5; Thu, 6 Apr 2017 21:51:28 +0200 (CEST) Received: from [132.166.84.172] ([132.166.84.172]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36JpRF6024940; Thu, 6 Apr 2017 21:51:27 +0200 To: Ted Lemon References: <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <5229198A-C235-40C5-B93D-7E228FBEF7C3@fugue.com> <0CD976CE-7439-4AE7-96BF-A48076F389D0@fugue.com> Cc: v6ops@ietf.org From: Alexandre Petrescu Message-ID: Date: Thu, 6 Apr 2017 21:51:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0CD976CE-7439-4AE7-96BF-A48076F389D0@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 19:51:32 -0000 Le 06/04/2017 à 18:33, Ted Lemon a écrit : > On Apr 6, 2017, at 9:07 AM, Alexandre Petrescu > > wrote: >> I went through a few emergencies because of each of these. > > Really? You went through /emergencies/ because you couldn't reach an > NTP server because it was hard-coded as a domain name? You went > through /emergencies/ because your BIOS battery failed? And you think > that the solution to these emergencies is to mandate some additional > network protocol? Not that. In that threaded conversation, my point was that it is good to to rely on time offered by a server, but not good to rely on a battery, not good to consider time servers are always there. The solution to avoid that is first to reuse existing protocols to make sure time is right at boot up. Ideally, use just one protocol to configure all these parameters, with as few messages as possible. Alex > From nobody Thu Apr 6 13:03: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 CDA5712943F for ; Thu, 6 Apr 2017 13:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0BU1z5uRWIyg for ; Thu, 6 Apr 2017 13:03:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F650128954 for ; Thu, 6 Apr 2017 13:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3506; q=dns/txt; s=iport; t=1491508981; x=1492718581; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fmtgZSdsdiBanxiwXyJP415POODE2tyXWsmWZD5FtfQ=; b=jTIRET9kp0HqGOhAzJaMDjqIG0ezYW/ggvFzi1PPO+7ZLeFsz/d0Dd7F zwOwC1JILA9qnKyAFw1IiMm3aSydo3AA08+cqMezpb5TsNgIFfm6GT46o 45PUTwT14dC0pjTPz4Vo0qPjRe6cVmxYp61z0TEzuXk/wCvfn8TvH7GNd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQDSneZY/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjW6RP5VVgg8fC4V4AhqDLD8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECAQEBIRE6EAcEAgEIEQQBAQMCIwMCAgIlCxQBAgEFCAIEARIIiX4IDqlqg?= =?us-ascii?q?iaKcQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuKM4QnGS2Cb4JfBY9pjQoBhn2?= =?us-ascii?q?LTJFGk3cBHziBBVsVQYZbdYhSgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,160,1488844800"; d="scan'208";a="232800500" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2017 20:03:00 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v36K30oT011808 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2017 20:03:00 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, 6 Apr 2017 15:02:59 -0500 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, 6 Apr 2017 15:02:59 -0500 From: "Bernie Volz (volz)" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohLAlJXdnN5j0uTKcn23s0z76G4fOCAgAAIq4CAADusQIAAAnWg Date: Thu, 6 Apr 2017 20:02:59 +0000 Message-ID: <7ec53601956a4fbd9b60afe122c3aae1@XCH-ALN-003.cisco.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <434ba61e-5f20-1c95-e24c-f333cd593be2@gmail.com> In-Reply-To: <434ba61e-5f20-1c95-e24c-f333cd593be2@gmail.com> 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.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 20:03:04 -0000 PiBJIGFtIHN1Z2dlc3RpbmcgdG8gYWRkIHRoYXQgbGlmZXRpbWUgaW4gREhDUHY2Lg0KDQpUaGVy ZSBhbHJlYWR5IGlzIC0gc2VlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv cmZjNDI0Mi4gSXQgZG9lcyBoYXZlIGEgbWluIHZhbHVlIG9mIDEwIG1pbnV0ZXMuDQoNCkkgdGhp bmsgYW55IGxpZmV0aW1lIGhhcyBpc3N1ZXMgaW4gdGhlIGZhY3QgdGhhdCBpZiBzb21ldGhpbmcg aGFwcGVucyBiZWZvcmUgdGhhdCBsaWZldGltZSBleHBpcmVzLCB5b3UnbGwgaGF2ZSBvbGQgZGF0 YS4NCg0KVGhlIGxpZmV0aW1lIGlzIGdvb2QgYW5kIHNob3VsZCBiZSB1c2VkLCBidXQgdGhlIGNs aWVudCBhbHNvIG5lZWRzIHRvIHVzZSBzb21lIGtub3dsZWRnZSBvZiB3aGF0J3MgaGFwcGVuZWQg dG8gdGhlIG5ldHdvcmsgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQgc2hvdWxkIHJlZnJlc2ggKFJG QyAzMzE1LzM3MzYvIGRyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMgaGF2ZSBzb21lIGNvbmRpdGlv bnMsIHBlcmhhcHMgdGhleSBhcmUgaW5jb21wbGV0ZSkuDQoNCi0gQmVybmllDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0cmVzY3UNClNlbnQ6IFRodXJzZGF5LCBB cHJpbCAwNiwgMjAxNyAzOjUwIFBNDQpUbzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb djZvcHNdIE1ha2luZyBSRE5TUyBhIE1VU1Q/LCBodW0gdjINCg0KDQoNCkxlIDA2LzA0LzIwMTcg w6AgMTg6MzgsIFRvcmUgQW5kZXJzb24gYSDDqWNyaXQgOg0KPiAqIEVyaWsgS2xpbmUNCj4NCj4+ IEFzIGEgdmVuZG9yIG9mIGEgZGV2aWNlIHRoYXQgaXMgc29tZXRpbWVzIGEgcm91dGVyIEkgYW0g b3Bwb3NlZCB0bywgDQo+PiBhbmQgaGF2ZSBwcmVjaXNlbHkgemVybyBpbnRlcmVzdGluZyBpbiwg aW1wbGVtZW50aW5nIGEgREhDUHY2IHJlbGF5IA0KPj4gb3Igc2VydmVyIGZ1bmN0aW9uLiAgSXQg YWRkcyBub3RoaW5nDQo+DQo+IFVtLCDCq2FkZHMgbm90aGluZ8K7LCByZWFsbHk/DQo+DQo+IFRv IHRoZSBiZXN0IG9mIG15IGtub3dsZWRnZSwgREhDUHY2IGlzIHRoZSAqb25seSogd2F5IHRvIHBy b3Zpc2lvbiANCj4gSVB2NiBuYW1lIHNlcnZlcnMgb250byBob3N0cyBydW5uaW5nIE1pY3Jvc29m dCBXaW5kb3dzLg0KDQpZRXMuICBCdXQgaXQgaGFzIGRyYXdiYWNrcywgYW5kIHNob3VsZCBiZSBp bXByb3ZlZC4NCg0KSXQgbGFja3MgYSBsaWZldGltZS4gIFRoZSBzZXJ2ZXIgaXMgdGhlcmUgaW5z dGFsbGVkIGluIFdpbmRvd3MgZm9yZXZlciwgdW50aWwgb3ZlcndyaXR0ZW4uDQoNClRoYXQgbWFr ZXMgdGhhdCBhZnRlciBnb2luZyB0byBJRVRGIG1lZXRpbmcgYW5kIGNvbWluZyBiYWNrIHRvIG15 DQpub24tSVB2NiBvZmZpY2UgbmV0d29yaywgbXkgbGFwdG9wIHN0aWxsIGhhcyBhIERIQ1B2NiBz ZXJ2ZXIgY29uZmlndXJlZCBzZWVuIHdpdGggImlwY29uZmlnIC9hbGwiLiAgSSBkb250IGxpa2Ug dGhhdC4NCg0KV2VyZSBpdCB0byBoYXZlIGEgbGlmZXRpbWUsIGl0IHdvdWxkIGV4cGlyZS4gIEJ1 dCBuby4NCg0KSSBhbSBzdWdnZXN0aW5nIHRvIGFkZCB0aGF0IGxpZmV0aW1lIGluIERIQ1B2Ni4N Cg0KQWxleA0KDQo+DQo+IEluIG15IG9wZXJhdGlvbmFsIHJlYWxpdHksIMKrc3VwcG9ydCBmb3Ig TWljcm9zb2Z0IFdpbmRvd3MgaG9zdHPCuyBpcyANCj4gZGlhbWV0cmljYWxseSBvcHBvc2l0ZSB0 byDCq25vdGhpbmfCuy4NCj4NCj4gVGhlIGV4YWN0IHNhbWUgcG9pbnQgZ29lcyBmb3IgQW5kcm9p ZCBhbmQgUkROU1MuDQo+DQo+IFRodXMsIHdoZW4gb3BlcmF0aW5nIGEgQllPRCBJUHY2IG5ldHdv cmssIGl0IGlzIGFic29sdXRlbHkgZXNzZW50aWFsIA0KPiB0byBzdXBwb3J0ICpib3RoKiBSRE5T UyBhbmQgREhDUHY2LiBPdGhlcndpc2UgeW91J2xsIGJlIGV4Y2x1ZGluZyBhIA0KPiBzaWduaWZp Y2FudCBhbW91bnQgb2YgZGV2aWNlcyBmcm9tIGJlaW5nIGFibGUgdG8gdXNlIHlvdXIgbmV0d29y ay4NCj4NCj4gVG9yZQ0KPg0KPiBQUzogQXBvbG9naWVzIHRvIHRoZSBXRyBhbmQgdGhlIGNoYWly cyBmb3IgdGhlIG1pc2RpcmVjdGVkIGh1bSB0byB0aGUgDQo+IGxpc3QgYSBjb3VwbGUgb2YgbWVz c2FnZXMgZWFybGllciBpbiB0aGUgdGhyZWFkLiBJdCBhcHBlYXJzIG15IE1VQSANCj4gZGlkbid0 IGludGVycHJldCB0aGUgUmVwbHktVG8gaGVhZGVyIGFzIEkgdGhvdWdodCBpdCB3b3VsZC4gTXkg YmFkLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Thu Apr 6 13: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 7D428126B7F for ; Thu, 6 Apr 2017 13:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 OcvuvcLJuYzu for ; Thu, 6 Apr 2017 13:07:20 -0700 (PDT) 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 A71A112943F for ; Thu, 6 Apr 2017 13:07:20 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id 21so45233785pgg.1 for ; Thu, 06 Apr 2017 13:07:20 -0700 (PDT) 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=ExbeVNUorzjUP6Ht7NkLwypznIOcfcOl7yMdwfWh6M8=; b=ho6cv/oLTOvq91FeCL7FraFbRTiMpLPikvYyVYFDFvZgy3eDLvj1nNmLdci8Dp/tqx vXG1iBP2zoq3H1ib8SNkXZXEfBn7MWwe5NpcPzAfe4+qczoK8OaK8Ehz4WbprA3PEKiy eEwpIBAhGsyuRdxNtjm8Dmc1x8eUX3/KVUb4hAJSCNP4q1CeRkTU2HhvkCyfW6B/vmbI AGaZ8chOBAhkXMyt9yIA48mDwCQmpR9aNxK3gBfHmXBFRSFpqaRoRT1a4Liw4DNzhia9 UsLq+qzXrjifQx5aGSnemWFvil+SmtGND6TiQSoSB8N/y5blCQn6pbOqW5a2k1QniplY WYqg== 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=ExbeVNUorzjUP6Ht7NkLwypznIOcfcOl7yMdwfWh6M8=; b=mifggrPF2ePT1+FZAChE5JlvpLURb8P+GXGBINF3ALVDUoJqLGEuFjgr+cV3n1wwc/ tv3XgtBmOtGORid+3IsVFKuBWKgCejkVVS0hRlQDMb6tPTcDsHyGnR+LSy/Z14wp/G5p L1Y/ufw2Eh3+Ag6ahw+BaUZUARsqTyb6IG3Rp6ycCMs6ao9eiDCRtZLwE3lJO+QaBv0m NMc+fPAZ7uHXdPQmRoJar3uhuLDAS2y+HfRy+M5KXtf2RUjTJqNK8OMZ0eWyyMVG/zdj rdOXq1SnZJJThAKtFHdi+8pqH3YP82+kTYe638l0L1+nw4vsj78ACZxC3+crJQx/TYeH lU7Q== X-Gm-Message-State: AFeK/H2L788BMVtkiAza9SOoW6cu/5NmXnY6kGXpf1b/2ckESMSzw/O4sHq1Cz5oEjYsmw== X-Received: by 10.98.90.66 with SMTP id o63mr35855813pfb.54.1491509240230; Thu, 06 Apr 2017 13:07:20 -0700 (PDT) Received: from ?IPv6:2620::b60:17:65a5:9972:9ffc:5799? ([2620:0:b60:17:65a5:9972:9ffc:5799]) by smtp.gmail.com with ESMTPSA id t12sm5243251pfi.89.2017.04.06.13.07.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 13:07:19 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C12D43B8-B5A2-4D48-A247-E5ECE5DE3046" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 6 Apr 2017 13:07:16 -0700 In-Reply-To: Cc: IPv6 Operations , james woodyatt To: Philip Homburg References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpr o.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <79CEE097-2DF9-492A-94E3-8E4F18056DB4@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 20:07:22 -0000 --Apple-Mail=_C12D43B8-B5A2-4D48-A247-E5ECE5DE3046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 6, 2017, at 12:01 PM, Philip Homburg = wrote: > A stateless DHCP server doesn't to be enabled by default. So you're suggesting that the Settings panel on my Android phone should = have a checkbox for "enable DHCPv6?" --Apple-Mail=_C12D43B8-B5A2-4D48-A247-E5ECE5DE3046 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 6, 2017, at 12:01 PM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
A stateless DHCP server doesn't to be = enabled by default.

So you're suggesting that the Settings panel on my Android = phone should have a checkbox for "enable DHCPv6?"
= --Apple-Mail=_C12D43B8-B5A2-4D48-A247-E5ECE5DE3046-- From nobody Thu Apr 6 14:02: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 9FD8512963F for ; Thu, 6 Apr 2017 14:02:19 -0700 (PDT) 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 23bg2cBISaJf for ; Thu, 6 Apr 2017 14:02:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA4012714F for ; Thu, 6 Apr 2017 14:02:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwEXm-0000FsC; Thu, 6 Apr 2017 23:02:14 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpr o.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <79CEE097-2DF9-492A-94E3-8E4F18056DB4@google.com> In-reply-to: Your message of "Thu, 6 Apr 2017 13:07:16 -0700 ." Date: Thu, 06 Apr 2017 23:02:13 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 21:02:19 -0000 > So you're suggesting that the Settings panel on my Android phone > should have a checkbox for "enable DHCPv6?" As far as I can tell, some people at Google just completely refuse to implement DHCPv6, so it doesn't matter at all what we propose at this stage to make it work better. That said, in the tethering scenario, I don't expect issues, because a mobile provider is likely to have just a few dns clusters with public addresses. So in the unlikely event that hardly any hosts need DHCPv6 DNS and there is also a significant percentage of cases where it breaks, then requiring the user to enable it manually would be a good idea. Looking at it from another angle, if you don't have dnsmasq or similar on your router and you hand out the upstream DNS resolvers through DHCPv4 then you would end up in exactly the same situation as Lorenzo expects to happen with DHCPv6. (Not) surprisingly, this is not an operational issue. From nobody Thu Apr 6 14:06: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 94C0312714F for ; Thu, 6 Apr 2017 14:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Q6Ry64Lrgqp0 for ; Thu, 6 Apr 2017 14:06:25 -0700 (PDT) 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 EFBB212945E for ; Thu, 6 Apr 2017 14:06:24 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id g2so45608420pge.3 for ; Thu, 06 Apr 2017 14:06:24 -0700 (PDT) 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=5/jMM6X+tytx7ql6o8JXAnGSgShF7bfz25ogQ98X984=; b=C9G9Rt6Pb/OX7M9d76WWbFrXlFIGIBNkwuTRs4V++iO/mU3s/vnpVZumPJb0BPUG9l tci3fvBesa55S8tXsXGhx7WV58yI5Ow2NpYWGKerYNoIjlIUK+M5kR1ROfqYvCiUNiO4 N3fWSOApXpqZycgYtMxREqBk4ZOg5p4Ts5OLPe/89IlFoCgHl6YvhFJ/iLHMVORjtUad vUuj6Ia/UO5mN/IzTaxmiMPfQ/hxsjV/2+vtUXEwFSZOgCcGTAzu8UzcUgEvtZENfIIT SS6CbD/Fl7GcY1V1ripNFAjYtY07/7n5W4l98m6/9EKf76jqEsFD8hAyuuE9G3ubx4e8 Bhrg== 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=5/jMM6X+tytx7ql6o8JXAnGSgShF7bfz25ogQ98X984=; b=YkYslslYZgozyYrfb6hp3Pq2RelUH3EtuxXrUEkcXNxXL69qCmk7UNX8ra0AsBQQpX vUkTNDKk1rCoOUYI7v78y9ER2cVpErSJhYFPmP3lFN7w4tRUs58L1qNVbRTfcu9RZLvH x/gtjsMeYsudTJk+v1/+6DH6cseHBpfzItWjOjh1p+na9qsZyMYsmodE2JnUghJSinDh fCZXqF9hGeRtTIUFLoO+QyqpDPqkixiKdh3a/V6GvPb+0tWmuRHyxz/KmQwPTMFPzGMs qRtSAWunH1qmNLocy1fiDkUbNuG+vWmHnHw7dQfSrTrEURk2Mz5HBW9cZSQG4XUfrJlh p6Fw== X-Gm-Message-State: AFeK/H0Y1MsaN+H7+tEGsczJFAaZ0wImATvKfJ/3cArcT23PAptCj1fWxo2yQvhmNQOLsw== X-Received: by 10.99.119.67 with SMTP id s64mr17569343pgc.211.1491512784638; Thu, 06 Apr 2017 14:06:24 -0700 (PDT) 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 z62sm5359129pff.88.2017.04.06.14.06.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 14:06:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <434ba61e-5f20-1c95-e24c-f333cd593be2@gmail.com> Date: Thu, 6 Apr 2017 14:06:23 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8F67BA03-020F-466F-A70E-9AB0F7F6C217@gmail.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <434ba61e-5f20-1c95-e24c-f333cd593be2@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 21:06:27 -0000 > On Apr 6, 2017, at 12:50 PM, Alexandre Petrescu = wrote: >=20 > I am suggesting to add that lifetime in DHCPv6. Great suggestion to make to 6man or dhc. Not within the scope of v6ops = charter.= From nobody Thu Apr 6 14:13: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 656D3129634 for ; Thu, 6 Apr 2017 14:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GAm2vf369aHX for ; Thu, 6 Apr 2017 14:13:27 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 98AD91295E4 for ; Thu, 6 Apr 2017 14:13:27 -0700 (PDT) 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.ams1.isc.org (Postfix) with ESMTPS id A387C24AE09; Thu, 6 Apr 2017 21:12:07 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DD16116003D; Thu, 6 Apr 2017 21:12:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C80D716007B; Thu, 6 Apr 2017 21:12:07 +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 Otx9MX-xshQc; Thu, 6 Apr 2017 21:12:07 +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 4B98C16003D; Thu, 6 Apr 2017 21:12:07 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DB8A76AA312B; Fri, 7 Apr 2017 07:12:06 +1000 (AEST) To: Lorenzo Colitti Cc: "STARK, BARBARA H" , IPv6 Operations , Tore Anderson From: Mark Andrews References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpr o.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> In-reply-to: Your message of "Fri, 07 Apr 2017 01:19:14 +0900." Date: Fri, 07 Apr 2017 07:12:06 +1000 Message-Id: <20170406211206.DB8A76AA312B@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 21:13:29 -0000 In message , Lorenzo Colitti writes: > > On Thu, Apr 6, 2017 at 11:12 PM, STARK, BARBARA H wrote: > > > > As a vendor of a device that is sometimes a router I am opposed to, > and > > have precisely zero interesting in, > > > implementing a DHCPv6 relay or server function. It adds nothing, and > > can actually break clients that prefer > > > DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.​ > > > > [...] > > > > 2. You say you don't want to break clients (hosts) that prefer DHCPv6 > DNS > > over RDNSS. Since you oppose DHCPv6 relay or server (in the absence of a > > qualifier I take server to mean stateful or stateless -- so you oppose > both > > types of server?), does this mean you believe the way to prevent > breakage > > is to only offer RDNSS to clients (so their preference is irrelevant, > and > > they had better also implement RDNSS in spite of their preference)? > > > I think this is the sort of thing that Erik opposes. I thought I had sent > it to the list, but actually it was an off-list reply. > > ==== > The Android phone in my pocket is a router when I go to the coffee shop > every morning and turn on tethering. As the maintainer of that code, I > absolutely do not want to spend software engineering time writing a DHCPv6 > server that is not only less capable than the RDNSS implementation that we > have now, but also degrades functionality. And in doing so breaks any equipement that doesn't yet support RDNSS. > The reason it is degrades functionality is that with stateless DHCPv6 it > is impossible to implement even such basic things as "tell the client that > its DNS server is now gone because the cellular network went down and came > back up with a different prefix when you temporarily lost cell coverage". > This works today using RDNSS, but if we implement DHCPv6, this will stop > working for clients that support DHCPv6, even if they also support RDNSS. > > 1. Client gets DNS addresses from both RDNSS and DHCPv6, and prefers > DHCPv6 due to RFC 8106. > 2. Upstream goes down. We deprecate the prefix (we can't make it > invalid because of the 2-hour rule), and declare the DNS servers > invalid. We can't do anything about DHCPv6. > 3. The upstream comes back with a new prefix. We announce the new DNS > servers using RDNSS. But the client still uses the out-of-date > DHCPv6-provided DNS servers, because RFC 8106 says it should prefer > DHCPv6 over RDNSS. > > I cannot live with breaking user experience like this. So also bring up a ULA prefix and advertise the phone's address on the ULA prefix as the validating recursive server and offer this as well. This is what homenet does to provide stability of local services in the presence of changing upstream prefixes. There are lots of ways to solve problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Apr 6 14:20: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 7C799129496 for ; Thu, 6 Apr 2017 14:19:59 -0700 (PDT) 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 Is1Bp2YZ8RlK for ; Thu, 6 Apr 2017 14:19:57 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 B6D6212945E for ; Thu, 6 Apr 2017 14:19:56 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id b140so38649473iof.1 for ; Thu, 06 Apr 2017 14:19:56 -0700 (PDT) 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=hQ/CumGreM4beXyYCi47Hl3TOpgd0fH4s3CKmThXnk0=; b=iEHx2hJZ2k+ICm5b3/SKEEtX+USz9Ap8zzkc1xP+1hOoidg0z9/iosyMSshl1HuHCo G707T4VMnrJLaitJpC616aaiO0i9xW7lJqCP0t+wWgt7WTEwp+H08UbdJw62aIvD3yoL lxPIY8r5TBnVGHl8qRc/ICz5lFaQRhIg8cA/4U/NiAP6NwWuVeVNP+kHH3z00I075dgV ggXZhP2FMg5Y0H1eYS+hOoquY2jQ/rTnvZnVSv14FwJhl83MKmtCeF/Pp1uFiuRcMyJs RmNud7vtpDaSP3FuRJlZ0biFCDZX6KdZ038KcTQbUJObvyzjryly3E+ThXC3SCgKEQyW emIA== 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=hQ/CumGreM4beXyYCi47Hl3TOpgd0fH4s3CKmThXnk0=; b=RYenyClQw9yHY9M4itOJLN8N+rjG7mAQOTULxeSkthhxiULBUvK/kHmGSMemu7lRQf tOkBONUJ/fYYsC/rEdjCcdtOFjl0txrLQkjNycLtxYv7ik4zooXTH91reeZgB9Ttkt7t b4biOIXiSWgF5atNaoTFpbIVghJt2JF6Y7mEInIcnpOviQlSkI1aVeLetrXxZP2PZPDu krECm9RXJ4hfjC23SyJeT1Bt8iz7i0g1b/Td719DVGj9bAi4yxBxWYyzFgJ4K1wY0W0/ WceKrFKKkX8TqBBy9pGyBmvMKNd0Mqjq6zXMBFmOV6JpkUstfL+X6ss23rIdkcdzgR9u VnNQ== X-Gm-Message-State: AFeK/H11miFAEY0lohv48FmV1ARQuE9Yk8PxkUgUtx4LTdsu/MqC2dAv5z9T0+m9qR7a2g== X-Received: by 10.107.53.88 with SMTP id c85mr38113925ioa.185.1491513595926; Thu, 06 Apr 2017 14:19:55 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id f127sm1523773ite.14.2017.04.06.14.19.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 14:19:55 -0700 (PDT) To: Lorenzo Colitti , Tore Anderson References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> Cc: IPv6 Operations From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 7 Apr 2017 09:20:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 21:19:59 -0000 Lorenzo, On 07/04/2017 05:31, Lorenzo Colitti wrote: > But a MUST for dynamic networks will cause > operational impact, and that's not acceptable. I don't understand that statement. I think in essence what Bernie suggested was: when there's a connectivity change, re-initialize everything. That seems like normal defensive programming to me, especially since it seems to be generally believed that RECONFIGURE isn't much used. I do agree with your implied goal of making the host stack's connectivity as robust as possible. And I can see why RDNSS would be a better bet when both are available. But to not used stateless DHCPv6 when it's the *only* source of DNS info seems to me to go against that goal. Brian From nobody Thu Apr 6 14:27: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 D21EE1294A3 for ; Thu, 6 Apr 2017 14:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 txw02eM8lzMb for ; Thu, 6 Apr 2017 14:27:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id E6176129493 for ; Thu, 6 Apr 2017 14:27:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwEvo-0000GcC; Thu, 6 Apr 2017 23:27:04 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpr o.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <79CEE097-2DF9-492A-94E3-8E4F18056DB4@google.com> In-reply-to: Your message of "Thu, 6 Apr 2017 14:10:56 -0700 ." Date: Thu, 06 Apr 2017 23:27:03 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 21:27:07 -0000 > On Apr 6, 2017, at 2:02 PM, Philip Homburg > wrote: > > > > That said, in the tethering scenario, I don't expect issues, because a mobi > le > > provider is likely to have just a few dns clusters with public addresses. > > The attached is from my iPhone when I didn't have a WiFi link > active. Look at the DNS Server address... and no, the app doesn't > choose to tell me what *my* GUA or prefix is. I'm sure I have one. > > I don't think there is a requirement that the DNS address be a GUA. > It needs to be reachable from the systems that use it. I should have been more careful when I wrote that. It is best practice for a long time already to make sure that your resolvers are not accessible outside your own network. With as exception the few parties that provide globally accessible resolvers. So if you change providers, then you probably have to change resolvers, because even if the address is global, it is probably firewalled. So to go back to your phone, if that ULA is reachable throughout your provider's network, then it is as good as any public address. I guess the only way to find out is to manually configure this address and see if it breaks at some point. Or just watch the settings over a period of time and see if you always get the same ULA. outside. From nobody Thu Apr 6 15:03: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 3472E129676 for ; Thu, 6 Apr 2017 15:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 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, HK_RANDOM_FROM=0.001, 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=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 OhXb62kBhNnM for ; Thu, 6 Apr 2017 15:03:29 -0700 (PDT) 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 50FE4128DF3 for ; Thu, 6 Apr 2017 15:03:29 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id z204so56821721vkd.1 for ; Thu, 06 Apr 2017 15:03:29 -0700 (PDT) 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=KuMt8G4d3yLww7SRscPrjdUh5piWVIcXspfv3cCvXz0=; b=SV3ER1FjSTEUhApLhC1/6mArM7f5pOLn53NwS4Oscrw6bInwnKadASkYTwvJJw85oi i1QIjxsB3ozmdTR+sNNC4+nUtn51GKVM07Tb396hjdfi95tsqWXN7RVX1lXZs8z95yjv s+jQgL2rPL3Aju8XTKGTjRd5Xuns0zhNUH/LuOaKLCzBoQAIq52Dj7++kUXB2lu0pEsy 15zpxHDkRIH3rFihgVeONOs22N72ouk1DZ+SQGHHRn29fFx+WzD+7v69pkkwYvIicFmE /s9FH2+BHciAvfCV2/uqrb50E4XJj9py//PxIjrzTjwPzEIZPLwzLOKSfQ2V/6Am02AF rdEw== 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=KuMt8G4d3yLww7SRscPrjdUh5piWVIcXspfv3cCvXz0=; b=DxyFtvgQJ5Z8GbybWvYvBRv+nEihQOUiceVIq8KoD10jrdWLXJo6iQqSerU06jz2qA ow1wLVtL+DnsLpZqpnYOCjN1vczmNIdiwxrJ9Owj44ERIoi068+Jx9V2zfGTZHB0QLO3 VbOwCcaWnTbs5AsTVp938VjzAJ9fym6EhtTa2R8VJliv63QyqP0iScwxRQhDvYuXFW15 vippZ5+mdGDBJ5N0Na1itnc0A732sJFDnnlFPcnFKijanN7cljFMwQWvZfQ7/GZVvfoL solow1ql1s9SBg2z5nehCZp40L4FGvOTvkcqS7E7uu1mAd+dw5Vl2nJ+NNJwywupYftE DyNg== X-Gm-Message-State: AFeK/H16Bf8oMiq2qCe9kIkjp6RNRLKqveikKgshXUk1w0p40vjbli7Bs+cp+OJBYt9WcuRoJHk8UY0oXfGVAQ== X-Received: by 10.176.64.34 with SMTP id h31mr18831599uad.89.1491516208216; Thu, 06 Apr 2017 15:03:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.34.161 with HTTP; Thu, 6 Apr 2017 15:03:27 -0700 (PDT) Received: by 10.159.34.161 with HTTP; Thu, 6 Apr 2017 15:03:27 -0700 (PDT) In-Reply-To: <67c7e59e-bc2b-554d-7fe6-f3974e257c78@gmail.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2AF3CBC7-A275-4532-9930-784282C4D63D@gmail.com> <67c7e59e-bc2b-554d-7fe6-f3974e257c78@gmail.com> From: Mark Smith Date: Fri, 7 Apr 2017 08:03:27 +1000 Message-ID: To: Alexandre Petrescu Cc: v6ops list , Fred Baker Content-Type: multipart/alternative; boundary=94eb2c122e4ec4a3bb054c86adc7 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? - tethering, DHCPv6, RDNSS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 22:03:32 -0000 --94eb2c122e4ec4a3bb054c86adc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Tethering" is not a strict networking term. It is just the name that the telco industry gave to using your phone as a router between the 3G and Wifi interfaces, because they used to either prohibit it or charge for it. So don't get caught up on it, all Lorenzo was describing was a use case where a device is sometimes a host only, and sometimes=E2=80=8B both a host= and a router (sourcing/sinking packets for phone UI apps =3D host, forwarding packets for Wifi attached devices =3D router) Regards, Mark. On 7 Apr. 2017 05:49, "Alexandre Petrescu" wrote: Le 06/04/2017 =C3=A0 18:38, Fred Baker a =C3=A9crit : > > On Apr 6, 2017, at 9:28 AM, Alexandre Petrescu > wrote: > >> >> The Android phone in my pocket is a router when I go to the >>> coffee shop every morning and turn on tethering. >>> >> >> Tethering? Which standard is that? >> > > I believe that he is referring to RFC 7278, and by extension: > > https://tools.ietf.org/html/rfc6459 6459 IPv6 in 3rd Generation > Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen, > Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. > January 2012. (Format: TXT=3D84769 bytes) (Status: INFORMATIONAL) (DOI: > 10.17487/RFC6459) > > https://tools.ietf.org/html/rfc7278 7278 Extending an IPv6 /64 Prefix > from a Third Generation Partnership Project (3GPP) Mobile Interface > to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format: > TXT=3D19965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7278) > If it is so, then I think developper should understand the qualifier "INFORMATIONAL" next to this RFC7278. Developper should know from a start that that code doing tethering has no future, and it is not worth time investing in. If developper accepts that, then we can talk about the necessity of DHCPv6. (or otherwise enjoy coffee and forget tethering :-) Alex > https://tools.ietf.org/html/rfc7934 7934 Host Address Availability > Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July > 2016. (Format: TXT=3D37124 bytes) (Also BCP0204) (Status: BEST CURRENT > PRACTICE) (DOI: 10.17487/RFC7934) > > o Extending the network (e.g., "tethering"). > > o /64 sharing [RFC7278]. When the topology supports it, this is a > way to provide IPv6 tethering without needing to wait for network > operators to deploy DHCPv6 Prefix Delegation (PD), which is only > available in 3GPP release 10 or above ([RFC6459], Section 5.3). > > o DHCPv6 Prefix Delegation (PD) [RFC3633]. DHCPv6 PD allows the > client to request and be delegated a prefix, from which it can > autonomously form other addresses. If the prefix is shorter than > /64, it can be divided into multiple subnets that can be further > delegated to downstream clients. If the prefix is a /64, it can be > extended via L2 bridging, Neighbor Discovery (ND) proxying [RFC4389], > or /64 sharing [RFC7278], but it cannot be further subdivided, as a > prefix longer than /64 is outside the current IPv6 specifications > [RFC7421]. While the DHCPv6 Prefix Delegation specification > [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD > itself does not require that the client forward IPv6 packets not > addressed to itself, and thus does not require that the client be an > IPv6 router as defined in the IPv6 specification [RFC2460]. Also, in > many cases (such as tethering, or hosting virtual machines), hosts > are already forwarding IPv6 packets and thus operating as IPv6 > routers as defined in the IPv6 specification [RFC2460]. > > > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --94eb2c122e4ec4a3bb054c86adc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"Tethering" is not a strict networking ter= m. It is just the name that the telco industry gave to using your phone as = a router between the 3G and Wifi interfaces, because they used to either pr= ohibit it or charge for it.

So don't get caught up on it, all Lorenzo was describing was a use = case where a device is sometimes a host only, and sometimes=E2=80=8B both a= host and a router (sourcing/sinking packets for phone UI apps =3D host, fo= rwarding packets for Wifi attached devices =3D router)

Regards,
Mark.
<= div dir=3D"auto">

On 7 Apr. 2017 05:49, "Alexandre Petrescu" <alexandre.petrescu@gmail.com= > wrote:


Le 06/04/2017 =C3=A0 18:38, Fred Baker a =C3=A9crit :

On Apr 6, 2017, at 9:28 AM, Alexandre Petrescu
<alexa= ndre.petrescu@gmail.com> wrote:

The Android phone in my pocket is a router when I go to the
coffee shop every morning and turn on tethering.

Tethering?=C2=A0 Which standard is that?

I believe that he is referring to RFC 7278, and by extension:

https://tools.ietf.org/html/rfc6459 6459 IPv6 in 3rd G= eneration
Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen,
Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila.
January 2012. (Format: TXT=3D84769 bytes) (Status: INFORMATIONAL) (DOI:
10.17487/RFC6459)

https://tools.ietf.org/html/rfc7278 7278 Extending an = IPv6 /64 Prefix
from a Third Generation Partnership Project (3GPP) Mobile Interface
to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format:
TXT=3D19965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7278)

If it is so, then I think developper should understand the qualifier
"INFORMATIONAL" next to this RFC7278.

Developper should know from a start that that code doing tethering has
no future, and it is not worth time investing in.

If developper accepts that, then we can talk about the necessity of DHCPv6.=

(or otherwise enjoy coffee and forget tethering :-)

Alex



https://tools.ietf.org/html/rfc7934 7934 Host Address = Availability
Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July
2016. (Format: TXT=3D37124 bytes) (Also BCP0204) (Status: BEST CURRENT
PRACTICE) (DOI: 10.17487/RFC7934)

o=C2=A0 Extending the network (e.g., "tethering").

o=C2=A0 /64 sharing [RFC7278].=C2=A0 When the topology supports it, this is= a
way to provide IPv6 tethering without needing to wait for network
operators to deploy DHCPv6 Prefix Delegation (PD), which is only
available in 3GPP release 10 or above ([RFC6459], Section 5.3).

o=C2=A0 DHCPv6 Prefix Delegation (PD) [RFC3633].=C2=A0 DHCPv6 PD allows the=
client to request and be delegated a prefix, from which it can
autonomously form other addresses.=C2=A0 If the prefix is shorter than
/64, it can be divided into multiple subnets that can be further
delegated to downstream clients.=C2=A0 If the prefix is a /64, it can be extended via L2 bridging, Neighbor Discovery (ND) proxying [RFC4389],
or /64 sharing [RFC7278], but it cannot be further subdivided, as a
prefix longer than /64 is outside the current IPv6 specifications
[RFC7421].=C2=A0 While the DHCPv6 Prefix Delegation specification
[RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD
itself does not require that the client forward IPv6 packets not
addressed to itself, and thus does not require that the client be an
IPv6 router as defined in the IPv6 specification [RFC2460].=C2=A0 Also, in<= br> many cases (such as tethering, or hosting virtual machines), hosts
are already forwarding IPv6 packets and thus operating as IPv6
routers as defined in the IPv6 specification [RFC2460].



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

--94eb2c122e4ec4a3bb054c86adc7-- From nobody Thu Apr 6 15:17: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 0961E1294A8 for ; Thu, 6 Apr 2017 15:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.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 4vvTWkDk2_KG for ; Thu, 6 Apr 2017 15:17:36 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 8E9331294B0 for ; Thu, 6 Apr 2017 15:17:33 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id s68so56996726vke.3 for ; Thu, 06 Apr 2017 15:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=MLsMueqTLV+Lr61ZUONk7+EyhEGRNHa+bbkkSGWM23I=; b=NghIYh3ph9U9CegqWzG9QlWb9rmSXHJp4A63buWN9/lnog77vMddaA8coOMh2uXnhc VI1fGEkakYUyuh54pjX3AJK5KXmF6h2BRzLo/+MQLVChLm+nTlgrrJNw1ObFYDi2o53W Uxh7z0hNSutONSwu7LMUA8efFE0/bxm2Y7jkVOz7O22Za9oaEtoT7va/QaJuF6oVyNez DnDbMXGGeryj6iUuCDUIMGgBinbCk+rKbMKZG8I18+SuSvjLu5MkblDlKD+BNb3BWLzL c7cJ8ZnMx2knsnOFKLc7b9Ftpv1/kbE08AXj0EJqXZgCD6ZsAq/BE+T1ZDpABK93uv0I 4QPA== 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:content-transfer-encoding; bh=MLsMueqTLV+Lr61ZUONk7+EyhEGRNHa+bbkkSGWM23I=; b=fZdUuNxWYr78A3m+kpRj8GfxYqou128Sbv2bPTI+czPqRPqeMv3G9LiwKL3BWtJWJf V1nvTJetFAheNbMslTvQ7dUnGc1N4oP9o6dm6Hnziq6dI2ymIoSEGtoUzxHoNnnAHPHx Xq1fZnEbOR/eZJebXtw5SHLDmCDW7/WzYHCMr8XknXlQAcdmJZ3TA+viKBYIigAx5KGn Re/5Sngrh6/JneNBzxQ1n2e4Mnn5GA4fzfLiHQKMT1txK6tjegC/FG/6YYkmPvVAeaBz z+r4LbqDbzklhb9+UXNMzzEpVQBLQwofLxlYjtX/8/aJR6hUI8/uNVnHOev8hB93pFqI M8DA== X-Gm-Message-State: AFeK/H3uuHFIAto4UNft+qSGZYVQF8L0rkHZRN7iain8vJ2XspO6Xb/WjmXfkztItV4pLnOUlcZ9eSwhb5+YgA== X-Received: by 10.31.11.73 with SMTP id 70mr17080681vkl.83.1491517052403; Thu, 06 Apr 2017 15:17:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.149.72 with HTTP; Thu, 6 Apr 2017 15:17:31 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:18be:5efb:96cf:ea43] In-Reply-To: References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de> <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org> <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20170405221437.A99BB6A925A5@rock.dv.isc.org> <1a120640-a464-8938-07fe-8e3e0629825f@gmail.com> From: George Michaelson Date: Fri, 7 Apr 2017 08:17:31 +1000 Message-ID: To: "v6ops@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Eating one's own dog food X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 22:17:38 -0000 On Thu, Apr 6, 2017 at 7:31 PM, Tim Chown wrote: > I like that the IETF offers NAT64, and pure IPv6-only, and of course dual= -stack. me too. > We=E2=80=99re just bike-shedding on the default. kinda, but I think deliberately deciding to make the obvious defaults V6 'primarily' and the clean4 something you have to pick, changes the dynamic. I'm not sure thats bike-shed or advocacy. Nudge theory. Social pranksterism. Japes. So in the non-bikeshed sense, if the v6ops/6man/homenet nexus advocated to 'the man' that the default SSID(s) should be predominantly about v6, I wouldn't personally object and I might even hum. mutedly. with warrens merrie-old-clown hat on. -G From nobody Thu Apr 6 15:45:11 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BE0129690; Thu, 6 Apr 2017 15:45:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149151870349.21987.8147926404196718458@ietfa.amsl.com> Date: Thu, 06 Apr 2017 15:45:03 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 22:45:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-rfc7084-bis-00.txt Pages : 29 Date : 2017-04-06 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers several transition technologies, as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. The document obsoletes RFC 7084. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 6 16:02: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 8639112968F for ; Thu, 6 Apr 2017 16:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 MzQXx3TO8s9W for ; Thu, 6 Apr 2017 16:02:20 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 41667126E3A for ; Thu, 6 Apr 2017 16:02:20 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id c55so10073359wrc.3 for ; Thu, 06 Apr 2017 16:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=p4FR4mlDNtt/r3sj1ulWj/b++cY8qfx3hT6+BBecubA=; b=tCqB/gN6NWaBdsVVdtgKSpqzTtwkbMdTWPGlfjnzt53qGrbsbIz0AHNHQAJ3PpDK+Q hTyrbk5vUyquFwX3Lt+Daf62oh6r5tFFcbVmrWMq5R/ThAxAboIkq8z+FRt2HGm6kOI4 5fbg2T5z0X5OciT1zM8Eq4zJZXuBRCP7yX3G9fsjLCPi7jtQ0pLtYQ4pVy1xObLVfcdq ozCfKZ0PWQi/dUh9PqiuHBA5kwQ0S+AIK2AdThlu5H1lvRMBX5+N243LUAx4zCZzzrS1 XH52hUrn37JpjvCS2nu2MkJkJKQziyA8mI7vANxdrOYrZAgOdA1xQPvuSvSg09kBaXuW sOdg== 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:date:references:to:in-reply-to:message-id; bh=p4FR4mlDNtt/r3sj1ulWj/b++cY8qfx3hT6+BBecubA=; b=l6d8tQgQGsAfZM1IKKexTkBnP6irCikL1V0NNPhy2vve+tYILaQqCVw/NXedsQ+n8a Oo+WBsEuaEHDpU9GcnpHnTIAhN2NBhedMkiu2YS75y6RgK/neC43Q3/hZ2UUZk16UZgA onuikRorxsrXFosGcd30sASIaEku6dijHh9dNWyicWUa4zSD1E2F7I0BqmjBMWMIGSWr vPH9jxmHlO0rmrutM+LuqwE2PjqCCpBRjXYKfshwAPfSXBefZew8jeW5ZuCd7NrQgI7Q HyVNynZugV2JM2qY0307WoaUg0e0JqZcrEgnMJw5Ey+liSpgAJuec+Bj26CCjAXMfksb dQtQ== X-Gm-Message-State: AFeK/H1V4Fzmrh792GyUrZmkwAu72jFBZe1niJX0/b3LKNZciWlWA/as Gg2+MHQP/qYiDIYjXRg= X-Received: by 10.28.23.194 with SMTP id 185mr25684073wmx.52.1491519738550; Thu, 06 Apr 2017 16:02:18 -0700 (PDT) Received: from 199.66.20.149.in-addr.arpa (199.66.20.149.in-addr.arpa. [149.20.66.199]) by smtp.gmail.com with ESMTPSA id w186sm4039887wme.26.2017.04.06.16.02.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 16:02:17 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 6 Apr 2017 16:02:14 -0700 References: <149151870349.21987.8147926404196718458@ietfa.amsl.com> To: IPv6 Operations In-Reply-To: <149151870349.21987.8147926404196718458@ietfa.amsl.com> Message-Id: <0BBE6751-B0F3-4746-886A-29D0F6957070@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 23:02:22 -0000 This was discussed a week ago, and accepted as a working group document. > On Apr 6, 2017, at 3:45 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations of the IETF. >=20 > Title : Basic Requirements for IPv6 Customer Edge = Routers > Author : Jordi Palet Martinez > Filename : draft-ietf-v6ops-rfc7084-bis-00.txt > Pages : 29 > Date : 2017-04-06 >=20 > Abstract: > This document specifies requirements for an IPv6 Customer Edge (CE) > router. Specifically, the current version of this document focuses > on the basic provisioning of an IPv6 CE router and the provisioning > of IPv6 hosts attached to it. The document also covers several > transition technologies, as required in a world where IPv4 addresses > are no longer available, so hosts in the customer LANs with = IPv4-only > or IPv6-only applications or devices, requiring to communicate with > IPv4-only services at the Internet, are able to do so. The document > obsoletes RFC 7084. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-00 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Apr 6 16:15: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 A13B2129690 for ; Thu, 6 Apr 2017 16:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 N8bd--2iqOR3 for ; Thu, 6 Apr 2017 16:15:34 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 ED02E1293DB for ; Thu, 6 Apr 2017 16:15:33 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id g2so47979473pge.3 for ; Thu, 06 Apr 2017 16:15:33 -0700 (PDT) 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=1atOz58KECD3AzUFd1xGTOLhQIfrwFW6VosG0Lg4pF8=; b=ChpNpyrozrHCzdkdMwr+0enR5wgaPkvJvAhKxCj0cZGyykmc4BRkvLUxVHMtvQfG7Y iI+dmc8qPn1DO3l8w44QU+rEDM2d38/EK8akkqiPEEOQwXDjdZR3Ja6T4qTm9RMU4F9s uuN5BNQ6u8qTjv4RoMJNv2Lzz9rwFUysDQLGEDL0OodsbKEwzR+1T2Ox3WmmArjC7Qrj gHGJLKuYQDwdeMEXiyM87AOYL+FkQ/vW2wSd/Af2j+yv9/qV6CxvcPoASkV5K5bsbCQ1 CSGezhGr13mGHl+VMc6uPDdGLRoShTbD1p3RYCY1mEpu6/+Oa6Mf7p3jSkO+vxhkHSjn decg== 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=1atOz58KECD3AzUFd1xGTOLhQIfrwFW6VosG0Lg4pF8=; b=mulFYmsOu5c96by24Jy9IaBGcpGikLIrVOOqFNzs+4BMmukYVN6VDHqudS3+JLtrZE d0Yz5zJ5owBxIGnYTUUhrJSsdhWGr75qwEFiqjXli9aaHildGE9KS+GENUO53V3ETR8+ ggkRzBfkw3tsoAsGMh5Vnqsoz3i8pHBc0/06ozfUQghbQghau+i46WPmk0Dbo3/P2ajZ bJW80rRJ5qDlXL15dxihXkvIFjojwajfuq61j8dyjKpVu2oOfhV4AYLYHvQLOyVnlbj3 HhAbEh4gIMTayMNBPTd8PB37EfIf7Fv6HwDm2L93d6nLTYQ0NRtl3J8g+6u1nibn3DNH iVug== X-Gm-Message-State: AFeK/H1NNJWnwUqCofLZ8bMuspCN61lRBrKwTbvPJ4FulADVajLJ8LLihq4SgV1V66ZWYw== X-Received: by 10.84.241.14 with SMTP id a14mr44925759pll.117.1491520533629; Thu, 06 Apr 2017 16:15:33 -0700 (PDT) Received: from ?IPv6:2620::b60:3:f8fb:5edf:a67e:46e5? ([2620:0:b60:3:f8fb:5edf:a67e:46e5]) by smtp.gmail.com with ESMTPSA id a5sm5570486pfh.124.2017.04.06.16.15.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 16:15:32 -0700 (PDT) From: Ted Lemon Message-Id: <6F63E48F-93AC-46F7-A397-2DF9D205630C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_45E8A878-BDF7-487C-ACCD-7E17D336F751" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 6 Apr 2017 16:15:32 -0700 In-Reply-To: Cc: "v6ops@ietf.org" To: George Michaelson References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de> <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org> <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20170405221437.A99BB6A925A5@rock.dv.isc.org> <1a120640-a464-8938-07fe-8e3e0629825f@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Eating one's own dog food X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 23:15:36 -0000 --Apple-Mail=_45E8A878-BDF7-487C-ACCD-7E17D336F751 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 6, 2017, at 3:17 PM, George Michaelson wrote: > with warrens merrie-old-clown hat on. I suppose now that Warren has to act all grown-up, someone needs to wear = it. :) --Apple-Mail=_45E8A878-BDF7-487C-ACCD-7E17D336F751 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On Apr 6, 2017, at 3:17 PM, George Michaelson <ggm@algebras.org> wrote:
with warrens merrie-old-clown hat on.

I suppose now that Warren has to act all grown-up, someone needs to wear it.   :)

--Apple-Mail=_45E8A878-BDF7-487C-ACCD-7E17D336F751-- From nobody Thu Apr 6 16:34:29 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 CA97D127978 for ; Thu, 6 Apr 2017 16:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, URIBL_BLOCKED=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 cZZQHAw_Mxg2 for ; Thu, 6 Apr 2017 16:34:26 -0700 (PDT) Received: from atl4mhob04.registeredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8A512896F for ; Thu, 6 Apr 2017 16:34:26 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob04.registeredsite.com (8.14.4/8.14.4) with ESMTP id v36NYOA8025004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Apr 2017 19:34:24 -0400 Received: (qmail 3658 invoked by uid 0); 6 Apr 2017 23:34:24 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 6 Apr 2017 23:34:23 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 06 Apr 2017 19:34:18 -0400 From: Lee Howard To: George Michaelson , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] Eating one's own dog food References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de> <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org> <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20170405221437.A99BB6A925A5@rock.dv.isc.org> <1a120640-a464-8938-07fe-8e3e0629825f@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Eating one's own dog food X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 23:34:28 -0000 On 4/6/17, 6:17 PM, "v6ops on behalf of George Michaelson" wrote: > >So in the non-bikeshed sense, if the v6ops/6man/homenet nexus >advocated to 'the man' that the default SSID(s) should be >predominantly about v6, I wouldn't personally object and I might even >hum. mutedly. with warrens merrie-old-clown hat on. =B3The man=B2 in this case is Alissa. And Jim Martin. Lee From nobody Thu Apr 6 18:33: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 693CD1242F5 for ; Thu, 6 Apr 2017 18:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.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 Nn1nBLvIrSxg for ; Thu, 6 Apr 2017 18:33:43 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 4E818129551 for ; Thu, 6 Apr 2017 18:33:43 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id z204so60516279vkd.1 for ; Thu, 06 Apr 2017 18:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uSBr38YkaQPsGGtLKf34EBytwzEJqHsr2qzZZ/lAxok=; b=CpTE3qilP9yWp8gcqqpEtQyIO3tToId1KwLO8525QEWmngdarfYHNygUw5Cl5AlLkd INF0KjCTFD0NwU+8tB0UHyixGaR/Gg8JLPXnBRvyrNEYmBVxFbdOmd9ryOH5N4CTJMX1 21icln+82nl0JYdxUEdC8eU/JqKZPRuQJ3675/BjdMt77N3zpeqjotr3ak/PAj+s0DD1 PW5UtRkB96GI5nfvunviDhGmXq3cyVixuoEgRt5AHxgLVoQ3BkasyeIRc7lAB1jiKose 6jzD/zxundokENZW2tI++eTqv4dn8On6LWO7I+t4eogefQueyCI+6DMr61EoSSca9Ebt rbSw== 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=uSBr38YkaQPsGGtLKf34EBytwzEJqHsr2qzZZ/lAxok=; b=Kd4KR4GtL8DCvOiv8dMMeKfLEZoGE5j7Pt5yJWnIyWzZvBMj8KRuV84lICOFaRaurk yi2aPQA6wZp7RfkoID2ye70kECCS7QvhLqWs4f9Uyx+pVytWZ/uH8MOEdeFLbNzEssxg hRB/6nC1gOfh3H9112yE4DhUozOYTRAH+6kEbQTPJz5F9LyLTCbAeeAb8gxJlQ8xCZDE SBxDIVMMVRf9ytoYf2z0eJ/cylz0EQyMkXURaZstpGnogswyVNN+r0Hgjf7h0+UP0qbB GFCbo9DDTVPjyvTfpKqTd+C+VZXhA3PGriMqnPQw/VfdFKwBLPaqd9v/DRZk1SnMtSro U1NA== X-Gm-Message-State: AFeK/H0g2n5q4zavz5Sxm7v/uxAa0cRv+zb4zqZ5QdeVUU7Al/X8f3smV8sRuq+rCJd3TVRL8uwQKB4aBd30xQ== X-Received: by 10.31.227.198 with SMTP id a189mr16395269vkh.1.1491528822227; Thu, 06 Apr 2017 18:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.149.72 with HTTP; Thu, 6 Apr 2017 18:33:41 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:18be:5efb:96cf:ea43] In-Reply-To: References: <58DCEABE.9020302@foobar.org> <20170330113232.GD98455@ernw.de> <222478AE-7AD7-4022-938E-59D3FC8F1268@fugue.com> <58DD21A0.2060604@foobar.org> <49286e89-43df-ac6d-8c9b-981661663684@gmail.com> <20170405221437.A99BB6A925A5@rock.dv.isc.org> <1a120640-a464-8938-07fe-8e3e0629825f@gmail.com> From: George Michaelson Date: Fri, 7 Apr 2017 11:33:41 +1000 Message-ID: To: Lee Howard Cc: "v6ops@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Eating one's own dog food X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 01:33:46 -0000 ok. So we ask Alissa, but the requirement is, its RDNSS in RA only. (ducks...) -G On Fri, Apr 7, 2017 at 9:34 AM, Lee Howard wrote: > > > On 4/6/17, 6:17 PM, "v6ops on behalf of George Michaelson" > wrote: > >> >>So in the non-bikeshed sense, if the v6ops/6man/homenet nexus >>advocated to 'the man' that the default SSID(s) should be >>predominantly about v6, I wouldn't personally object and I might even >>hum. mutedly. with warrens merrie-old-clown hat on. > > =C2=B3The man=C2=B2 in this case is Alissa. And Jim Martin. > > Lee > > From nobody Thu Apr 6 23:37: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 0D5731287A5 for ; Thu, 6 Apr 2017 23:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 4UDNsxB3DbrB for ; Thu, 6 Apr 2017 23:37:40 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 DB60E1205D3 for ; Thu, 6 Apr 2017 23:37:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v376bZCD010748; Fri, 7 Apr 2017 08:37:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9B30E20272E; Fri, 7 Apr 2017 08:37:35 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8DEA5202595; Fri, 7 Apr 2017 08:37:35 +0200 (CEST) Received: from [132.166.84.50] ([132.166.84.50]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v376bYVS016402; Fri, 7 Apr 2017 08:37:35 +0200 To: "Bernie Volz (volz)" , "v6ops@ietf.org" References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <434ba61e-5f20-1c95-e24c-f333cd593be2@gmail.com> <7ec53601956a4fbd9b60afe122c3aae1@XCH-ALN-003.cisco.com> From: Alexandre Petrescu Message-ID: <042ae917-25b9-5de3-2819-63b9d9df3ee5@gmail.com> Date: Fri, 7 Apr 2017 08:37:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7ec53601956a4fbd9b60afe122c3aae1@XCH-ALN-003.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 06:37:42 -0000 Le 06/04/2017 à 22:02, Bernie Volz (volz) a écrit : >> I am suggesting to add that lifetime in DHCPv6. > > There already is - see https://datatracker.ietf.org/doc/html/rfc4242. > It does have a min value of 10 minutes. > > I think any lifetime has issues in the fact that if something happens > before that lifetime expires, you'll have old data. > > The lifetime is good and should be used, but the client also needs to > use some knowledge of what's happened to the network to determine > whether it should refresh (RFC 3315/3736/ draft-ietf-dhc-rfc3315bis > have some conditions, perhaps they are incomplete). So I guess my Windows has a big problem because it keeps that DHCPv6 server address there forever, even if I only connect to it while at the IETF meetings. Alex > > - Bernie > > -----Original Message----- From: v6ops > [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: > Thursday, April 06, 2017 3:50 PM To: v6ops@ietf.org Subject: Re: > [v6ops] Making RDNSS a MUST?, hum v2 > > > > Le 06/04/2017 à 18:38, Tore Anderson a écrit : >> * Erik Kline >> >>> As a vendor of a device that is sometimes a router I am opposed >>> to, and have precisely zero interesting in, implementing a DHCPv6 >>> relay or server function. It adds nothing >> >> Um, «adds nothing», really? >> >> To the best of my knowledge, DHCPv6 is the *only* way to provision >> IPv6 name servers onto hosts running Microsoft Windows. > > YEs. But it has drawbacks, and should be improved. > > It lacks a lifetime. The server is there installed in Windows > forever, until overwritten. > > That makes that after going to IETF meeting and coming back to my > non-IPv6 office network, my laptop still has a DHCPv6 server > configured seen with "ipconfig /all". I dont like that. > > Were it to have a lifetime, it would expire. But no. > > I am suggesting to add that lifetime in DHCPv6. > > Alex > >> >> In my operational reality, «support for Microsoft Windows hosts» is >> diametrically opposite to «nothing». >> >> The exact same point goes for Android and RDNSS. >> >> Thus, when operating a BYOD IPv6 network, it is absolutely >> essential to support *both* RDNSS and DHCPv6. Otherwise you'll be >> excluding a significant amount of devices from being able to use >> your network. >> >> Tore >> >> PS: Apologies to the WG and the chairs for the misdirected hum to >> the list a couple of messages earlier in the thread. It appears my >> MUA didn't interpret the Reply-To header as I thought it would. My >> bad. >> >> _______________________________________________ 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 Fri Apr 7 00:04: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 495EC1287A5 for ; Fri, 7 Apr 2017 00:04:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 MQoxx6X8Vf6k for ; Fri, 7 Apr 2017 00:04:35 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 A3A3412025C for ; Fri, 7 Apr 2017 00:04:35 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id z204so65761776vkd.1 for ; Fri, 07 Apr 2017 00:04:35 -0700 (PDT) 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=P3uUhe/S/jSs/yNTpiVupb9g2taaOlRdEV0+BFix8wo=; b=NEiqf9sRswu8GYYFExpkswWFjXqHx7dwrgP35Fbfgl0RhdlRqKb/kuyVXknyF9AS77 Xbk2LOckNpuYe7fJ7YMZxUj0UCyHenkPanS0qmsiy0vQBkq84Ito9/HbSYrHy6aJyKrC pluSCEUJXhngtBN2X+XHKi0S41MCcfdZ+Nf8Cd+0rT0kTMst/+Kq+y3HTl9jKNYZetLm +ewBeXssB1m6s/JZG2YsrU9UpGl2niV1+WfQAONM4N3TBH3dE0gFpnga1i7us9kAf3sT 26CGGmxDIxSJ3SIV3D9GtaBKyHTTCfPmPcgp1/UB1hJRUGDMWsicMfyHMJxza4QeJdOO 3YVg== 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=P3uUhe/S/jSs/yNTpiVupb9g2taaOlRdEV0+BFix8wo=; b=ZL27GMF7d0ucFAheBaQuvaEui0OvYclz7w40/51zfuVnVFeg6XbFYrSpyV9FMSMAI3 CyBBhGflnTPHixxLCp0+EOeSnNyGyJczv2ymrTnWBOlQUutC11N3LB53JdygVqhEPGJb Sl3o0i0u8Tt+HgsdMQBJKr+H2IlE/+9AtC11LYTWK/psM9ZzTPH4AQ7nV7of4VPzmEK/ xpEHxw0u3HyJyhIPoCO73WWFcgjBHDwfdHAt2djEnIwjwgLOcrq/oqk/iEnFTqQKhzM8 V+MCTdOLmWJgGtSskx5QwOJzro9JanmCJQN6tLzE2lKkIOnRnkb5SANeb8a03DrscgtR hqvA== X-Gm-Message-State: AFeK/H09tNGNnxFi9vCs/vAzEbOW5jKADbdiTkVBbRbqb/Iu0CeRlWvlqDBGA7xdrPwk8LIL9RJTYLYmGG+OfsyY X-Received: by 10.159.36.77 with SMTP id 71mr20738466uaq.124.1491548674517; Fri, 07 Apr 2017 00:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 00:04:13 -0700 (PDT) In-Reply-To: References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <79CEE097-2DF9-492A-94E3-8E4F18056DB4@google.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 16:04:13 +0900 Message-ID: To: Philip Homburg Cc: "v6ops@ietf.org WG" , james woodyatt Content-Type: multipart/alternative; boundary=001a113dc80ee93aa0054c8e3c8c Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:04:38 -0000 --001a113dc80ee93aa0054c8e3c8c Content-Type: text/plain; charset=UTF-8 Philip, here are the reasons why what you suggest are not desirable. Note that I use Android as an example here, but most of these reasons are not specific to Android; I'm mostly just using it as an example of a real product. On Fri, Apr 7, 2017 at 4:01 AM, Philip Homburg wrote: > 1) A stateless DHCP server doesn't to be enabled by default. Assuming that > for most hosts it just works (either because of RDNSS or because of > IPv4) > you can just leave disabled until you really need it. > Consumer devices often don't permit user configuration of this sort of thing. Such a configuration option would almost certainly not be allowed by the people who decide which options make it into mass market operating systems. So MUST implement means MUST turn on default. (Since I'm sure you're not arguing that the device MUST implement but disable it and not allow the user to enable it.) > 2) Refusing to implement any kind of DHCP does not recognize the fact that > there is more to DHCP then just DNS. > In DHCPv4 Android doesn't implement pretty much anything else than what's in the RA (IP addressing, DNS and MTU) and nobody has ever complained about that. Lots of people seem to complain about addressing though. I would deduce that those options aren't really that important for this type of device. > 3) It assumes that the DHCP by default automatically announces the upstream > DNS resolvers. It would be quite possible to leave that upto the user > and the user might for example configure Google's public DNS resolvers > which work anywhere > It announces the global address of the device so that clients get the benefit of caching. Believe it or not, this is per carrier requirements. > 4) It assumes that the DNS resolvers will stop working after the phone > gets a different prefix. A mobile telco can just as well configure > static addresses that work anywhere in the mobile provider's network. > But the product needs to work in the real world, and in the real world, telcos don't do that. > 5) Your point. If we want to support this scenario, just include something > like dnsmasq. Note that Lorenzo can just do that. There is no RFC that > prohibits a local DNS resolver in a router. > That is what it does. > 6) An RA cannot actually withdraw addresses. So when the prefix changes, > the validity of any addresses configured by downstream hosts is limited > to > two hours, but not actually withdrawn. > You don't need to withdraw addresses. You do need to withdraw DNS servers. In any case, the problem is not so much withdrawing them as updating them with new ones when the connection comes back. > One way around that is to cause a link down event. Obviously, hosts > should try to reconfigure all resources after a link down event. Also > the ones they got through DHCP > That would disrupt all communications between clients on the hotspot and make users unhappy. > 7) The lifetime can be limited to 10 minutes. Not ideal, but also not a > disaster is this change happens rarely > In a real-world product, a 10-minute outage is unacceptable. This does not necessarily happen rarely. It happens every time you lose cell signal. In some places that never happens. In some places it happens often. It is not appropriate to inconvenience those users because other people want to run DHCPv6 in their network. Given that you're arguing that routers MUST implement DHCPv6 because "some operators want it", I'm sure you'll be sympathetic to the fact that other operators (i.e., users) do *not* want it. > 8) The DHCP protocol supports reconfigure also for information-requests. > Reconfigure requires a DUID and using DUIDs has privacy implications. Cheers, Lorenzo --001a113dc80ee93aa0054c8e3c8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phil= ip,

he= re are the reasons why what you suggest are not desirable. Note that I use = Android as an example here, but most of these reasons are not specific to A= ndroid; I'm mostly just using it as an example of a real product.
=

On Fri, Apr= 7, 2017 at 4:01 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
1) A stateless DHCP = server doesn't to be enabled by default. Assuming that
=C2=A0 =C2=A0for most hosts it just works (either because of RDNSS or becau= se of IPv4)
=C2=A0 =C2=A0you can just leave disabled until you really need it.

Consumer devices often don't permit user co= nfiguration of this sort of thing. Such a configuration option would almost= certainly not be allowed by the people who decide which options make it in= to mass market operating systems. So MUST implement means MUST turn on defa= ult. (Since I'm sure you're not arguing that the device MUST implem= ent but disable it and not allow the user to enable it.)
=C2=A0
2) Refusing to implement any kind of DHCP does not recognize the fact that<= br> =C2=A0 =C2=A0there is more to DHCP then just DNS.

=
In DHCPv4 Android doesn't implement pretty much anything els= e than what's in the RA (IP addressing, DNS and MTU) and nobody has eve= r complained about that. Lots of people seem to complain about addressing t= hough. I would deduce that those options aren't really that important f= or this type of device.
=C2=A0
4) It assumes that the DNS resolvers will stop working after the phone
=C2=A0 =C2=A0gets a different prefix. A mobile telco can just as well confi= gure
=C2=A0 =C2=A0static addresses that work anywhere in the mobile provider'= ;s network.

But the product needs to wo= rk in the real world, and in the real world, telcos don't do that.
=C2=A0
5) Your point. If we want to support this scenario, just include something<= br> =C2=A0 =C2=A0like dnsmasq. Note that Lorenzo can just do that. There is no = RFC that
=C2=A0 =C2=A0prohibits a local DNS resolver in a router.

That is what it does.
=C2=A0
6) An RA cannot actually withdraw addresses. So when the prefix changes, =C2=A0 =C2=A0the validity of any addresses configured by downstream hosts i= s limited to
=C2=A0 =C2=A0two hours, but not actually withdrawn.
You don't need to withdraw addresses. You do need to withd= raw DNS servers. In any case, the problem is not so much withdrawing them a= s updating them with new ones when the connection comes back.
=C2= =A0
=C2=A0 =C2=A0One way around that is= to cause a link down event. Obviously, hosts
=C2=A0 =C2=A0should try to reconfigure all resources after a link down even= t. Also
=C2=A0 =C2=A0the ones they got through DHCP

=
That would disrupt all communications between clients on the hotspot a= nd make users unhappy.
=C2=A0
7) The lifetime can be limited to 10 minutes. Not ideal, but also not a
=C2=A0 =C2=A0disaster is this change happens rarely
In a real-world product, a 10-minute outage is unacceptable. T= his does not necessarily happen rarely. It happens every time you lose cell= signal. In some places that never happens. In some places it happens often= . It is not appropriate to inconvenience those users because other people w= ant to run DHCPv6 in their network. Given that you're arguing that rout= ers MUST implement DHCPv6 because "some operators want it", I'= ;m sure you'll be sympathetic to the fact that other operators (i.e., u= sers) do *not* want it.
=C2=A0
, IPv6 Operations , Tore Anderson Content-Type: multipart/alternative; boundary=001a1134ee386b1ca2054c8e4ecf Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:09:33 -0000 --001a1134ee386b1ca2054c8e4ecf Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 6:12 AM, Mark Andrews wrote: > > The Android phone in my pocket is a router when I go to the coffee shop > > every morning and turn on tethering. As the maintainer of that code, I > > absolutely do not want to spend software engineering time writing a > DHCPv6 > > server that is not only less capable than the RDNSS implementation that > we > > have now, but also degrades functionality. > > And in doing so breaks any equipement that doesn't yet support RDNSS. > No, it only breaks equipment that does not support RDNSS and doesn't support DHCPv4. There is no such equipment today, and it will be years or decades before there is. > So also bring up a ULA prefix and advertise the phone's address on > the ULA prefix as the validating recursive server and offer this > as well. This is what homenet does to provide stability of local > services in the presence of changing upstream prefixes. > > There are lots of ways to solve problems. > Sure. And what benefit would the added complexity of this solution (add ULA management; write a DHCPv6 server) provide the user? That they can connect with (nonexistent) equipment that doesn't support IPv4? --001a1134ee386b1ca2054c8e4ecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 6:12 AM, Mark Andrews <marka@isc.org> wrote:<= br>
> The Android p= hone in my pocket is a router when I go to the coffee shop
> every morning and turn on tethering. As the maintainer of that code, I=
> absolutely do not want to spend software engineering time writing a DH= CPv6
> server that is not only less capable than the RDNSS implementation tha= t we
> have now, but also degrades functionality.

And in doing so breaks any equipement that doesn't yet supp= ort RDNSS.

No, it only breaks equipment= that does not support RDNSS and doesn't support DHCPv4. There is no su= ch equipment today, and it will be years or decades before there is.
<= div>=C2=A0
So also bring up a ULA prefi= x and advertise the phone's address on
the ULA prefix as the validating recursive server and offer this
as well. This is what homenet does to provide stability of local
services in the presence of changing upstream prefixes.

There are lots of ways to solve problems.

Sure. And what benefit would the added complexity of this solution (add = ULA management; write a DHCPv6 server) provide the user? That they can conn= ect with (nonexistent) equipment that doesn't support IPv4?
=
--001a1134ee386b1ca2054c8e4ecf-- From nobody Fri Apr 7 00:09: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 1FF9912940D for ; Fri, 7 Apr 2017 00:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 gvMGRRVFQT8l for ; Fri, 7 Apr 2017 00:09:48 -0700 (PDT) Received: from smtp12.doorway.no (smtp12.doorway.no [212.125.205.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1E2128CFF for ; Fri, 7 Apr 2017 00:09:44 -0700 (PDT) Received: from dware1044.doorway.loc (10.0.20.54) by smtp12.doorway.no (10.0.21.42) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 7 Apr 2017 09:09:34 +0200 Received: from olen.dhcp.nlogic.no (84.208.27.142) by dware1044.doorway.loc (10.0.20.54) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 7 Apr 2017 09:09:34 +0200 To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2AF3CBC7-A275-4532-9930-784282C4D63D@gmail.com> <67c7e59e-bc2b-554d-7fe6-f3974e257c78@gmail.com> From: Ola Thoresen Message-ID: <866af7ea-227f-f337-de17-522dabd69b65@nlogic.no> Date: Fri, 7 Apr 2017 09:09:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [84.208.27.142] X-ClientProxiedBy: DWARE1041.doorway.loc (10.0.20.51) To dware1044.doorway.loc (10.0.20.54) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? - tethering, DHCPv6, RDNSS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:09:50 -0000 On 07. april 2017 00:03, Mark Smith wrote: > So don't get caught up on it, all Lorenzo was describing was a use > case where a device is sometimes a host only, and sometimes​ both a > host and a router (sourcing/sinking packets for phone UI apps = host, > forwarding packets for Wifi attached devices = router) > We need to stop pretending there is a sharp distinction between a router and a host. My mobile phone can be both, my laptop can be both - it runs several VMs and some of these are even nested VMs, Any device participating in a mesh network of some sort needs to route packets one way or another... What we need to be able to separate is the _role_ some _process_ on a device have at the moment. This means that a lot of devices that in a legacy world are "host only" might start running code that turns them into routers. And _that_ code probably needs to support both being a DHCPv6 client AND server, as it might need to accommodate PD. Whether the OS itself should have all that code included by default will probably depend on the vendor or provider. In an ideal world, that means that installing e.g. VMWare, KVM and such should depend on both a dhcpv6-server and client being installed (or bundled) on the host. And when I turn on tethering on my phone, it should probably also enable a dhcpv6-client to get a prefix, and a dhcpv6-server to be able to serve clients behind it with prefixes, should they ask for a IA-PD. This is not an argument to force install or enable DHCPv6 on all "clients" by default. We just need to make sure it is available when some software on the device changes its role to a "router". /Ola (T) From nobody Fri Apr 7 00:17: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 5B356129640 for ; Fri, 7 Apr 2017 00:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 Z6oYM9NrKGv6 for ; Fri, 7 Apr 2017 00:17:13 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 79DD5129417 for ; Fri, 7 Apr 2017 00:17:13 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id s68so65869765vke.3 for ; Fri, 07 Apr 2017 00:17:13 -0700 (PDT) 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=cz5xFEvFLd2NeMgKsBpiHHo2sUSSwtPU0TxoHsD2CQI=; b=OjJ0bpV78tZI2demRhppn08GYMPyhM9GMM59SxL1DN9UmNVeottUtq4IIr4ed+Ykwx wTRpZHaQbjebqcrm9disBGhh1pRE0EkqrWoRXlVDYmvIGtnPVtSp42VpoEmDiAtC4hWw GPzj8kEaXv5jdOW874mxYNXpccH1nyEDTSTGPtwkDkBNW+HmZBucJDCFdgjah4tGCW4a q3a3YqJhkwnSfwcc3Yq5JRaSS+RKwkaVv90dT/2uHHO4VXGZOfwEEkxd4YLtTB8oaXK2 F9zLyVkhF/EDp3huEbhgQcFxLfwsWyTolEpsRUydCsm8F0DWIowQRFJpOfz+WNNE1vtp BNeg== 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=cz5xFEvFLd2NeMgKsBpiHHo2sUSSwtPU0TxoHsD2CQI=; b=Lykz0r3BSP2fHQ1fpdelNM6mKTfaXNhw8nJoGfmKIwHulkO7igZeQdZTkX1VAjr6pb WibLmeHwEBzXWySe38dF5989uElh3vxJTKNyJKhUzSnMjOjLr6z4eq6W84iIbl0xYjEW s3ZZ1e6Vdhfbv2sgKoEFMHIVb5MNlviZq0ut//WD4wkJvEQgVJjMMiH5apfSH46AjYI5 nwRCKGhLguUoDNqPz+GgtUFiV7ipcHjwk0ATSZVoIZEh2+n6JV9FCcwvHyuRK+LGwL1j ltYKnGOW08Crd8ZmMgHBLszCCgoF5Q/6IUeJxQ1kStPJblZiQyyXoYS9mpfCOTYfQcGT 5bBA== X-Gm-Message-State: AFeK/H2vKA1iIW2Je1NyRwoYSV9a6d6lkro6PWQyVgRXCPg/Z5iiOzCjYnOT03fg7XONf/veH7S/4OIBz3j9Gs37 X-Received: by 10.31.60.17 with SMTP id j17mr12245008vka.45.1491549432395; Fri, 07 Apr 2017 00:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 00:16:51 -0700 (PDT) In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 16:16:51 +0900 Message-ID: To: Brian E Carpenter Cc: Tore Anderson , IPv6 Operations Content-Type: multipart/alternative; boundary=001a11436e5015a3ec054c8e6a23 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:17:15 -0000 --001a11436e5015a3ec054c8e6a23 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 6:20 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I don't understand that statement. I think in essence what Bernie > suggested was: when there's a connectivity change, re-initialize > everything. That seems like normal defensive programming to me, > especially since it seems to be generally believed that RECONFIGURE > isn't much used. > Sure. When all clients that we need to serve implement this behaviour, it will be safe to implement a DHCPv6 server. When that happens, let me know when that is and I'll remove that particular objection. Until then we have an operational problem. Note that if I were such a client I try to avoid ever implementing that behaviour. Some of the reasons are: - Dealing with non-deterministic behaviour during updates due to packet reordering or loss - Substantial nattery impact of spinning up a radio transmitter to send a DHCP request instead of just passively listening to an RA - Code complexity I do agree with your implied goal of making the host stack's > connectivity as robust as possible. And I can see why RDNSS > would be a better bet when both are available. But to not > used stateless DHCPv6 when it's the *only* source of DNS info > seems to me to go against that goal. > Remember we're talking about the router side of things here. In this case, RDNSS is not the only source of DNS info because we also support DHCPv4. --001a11436e5015a3ec054c8e6a23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 6:20 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
I don't understand that statement. I think in essence what B= ernie
suggested was: when there's a connectivity change, re-initialize
everything. That seems like normal defensive programming to me,
especially since it seems to be generally believed that RECONFIGURE
isn't much used.

Sure. When all cli= ents that we need to serve implement this behaviour, it will be safe to imp= lement a DHCPv6 server. When that happens, let me know when that is and I&#= 39;ll remove that particular objection. Until then we have an operational p= roblem.

Note that if I were such a client I try to= avoid ever implementing that behaviour. Some of the reasons are:
  • Dealing with non-deterministic behaviour during updates due to pac= ket reordering or loss
  • Substantial nattery impact of spinning up a = radio transmitter to send a DHCP request instead of just passively listenin= g to an RA
  • Code complexity

I do agree with your implied goal o= f making the host stack's
connectivity as robust as possible. And I can see why RDNSS
would be a better bet when both are available. But to not
used stateless DHCPv6 when it's the *only* source of DNS info
seems to me to go against that goal.

Re= member we're talking about the router side of things here. In this case= , RDNSS is not the only source of DNS info because we also support DHCPv4.<= /div>
--001a11436e5015a3ec054c8e6a23-- From nobody Fri Apr 7 00:34: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 25980128708 for ; Fri, 7 Apr 2017 00:34:26 -0700 (PDT) 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 SLwkU-a9ugWV for ; Fri, 7 Apr 2017 00:34:24 -0700 (PDT) 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 E488B1205D3 for ; Fri, 7 Apr 2017 00:34:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7ECD44A; Fri, 7 Apr 2017 09:34:21 +0200 (CEST) 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=1491550459; bh=5QGcy0Bt1PY7UaHmsHi 7azZYNIQuRtp1viiYmN4zH+Q=; b=E6IJuWjs4YgKr/eILnJjjBZKVuM5Dz/lQ9V /2BTC2auHqOhqf+qXt3YyBpWMecHI18Ixkg5m/yElMK6CjK3mSl3twTQC+EHyhNO SsolZh0l0t8deEz9SymxJspUMMmVztfwBtQTYXwNkuYe+2dSn2kD5i4N/YCm+r7G AL0NJf5s= 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 Pf5NafCBlx9n; Fri, 7 Apr 2017 09:34:19 +0200 (CEST) Received: from [192.168.0.149] (unknown [46.44.175.146]) (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 B69B649; Fri, 7 Apr 2017 09:34:18 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <0D6F5563-2CDE-4831-9907-364FA002E82C@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_94757D88-A691-48DE-9912-E7612D91ED39"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 09:34:21 +0200 In-Reply-To: Cc: Lorenzo Colitti , Tore Anderson , IPv6 Operations To: Brian E Carpenter References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:34:26 -0000 --Apple-Mail=_94757D88-A691-48DE-9912-E7612D91ED39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > I do agree with your implied goal of making the host stack's > connectivity as robust as possible. And I can see why RDNSS > would be a better bet when both are available. I fully agree > But to not > used stateless DHCPv6 when it's the *only* source of DNS info > seems to me to go against that goal. Having a DHCPv6 client implemented on the client doesn't mean it has to = use it for every single option it supports. Maybe use it but only for = things that haven't been provisioned in another way. How about: 1: Clients MUST implement both RDNSS and a DHCPv6 client 2: Both SHOULD be enabled by default so they can get connectivity on any = network 3: Clients MAY (SHOULD?) choose not to request options over DHCPv6 that = they already got through other mechanisms (i.e. RA or statically = configured) 4: If a client has all the options it needs then it MAY choose not to do = DHCPv6 at all Or worded the other way around: allow a client to basically do RA-only = unless it's missing something and then try to get that through DHCPv6. This would be a deviation of the current behaviour where clients do = SLAAC+RNDSS+DHCPv6 and use/combine all the information it got, but maybe = this would be a better way to do it. The client would work on a = DHCPv6-only network, but may choose to use only the information in the = RA whenever it can. Would this work? Cheers, Sander --Apple-Mail=_94757D88-A691-48DE-9912-E7612D91ED39 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY50EAAAoJEB7hi8LTyHy2EpcH+gOSRN5YEctuJ8mn3TpRIvry QzOwgo6Lzuhm+wUP2ldxmzWISLslop0/8us1l73NHQnyBiRz7V3dvMgDHYU6V1w+ IrXL28FzSCxcJQycQHpxcRuu+IE0IRuIdXwLwJHPKNbZ4+fsUulsbPtipFgJLLQr J8h//+x3fWY+flifEgOQMjeT68jd1zav44wVxxPlR+GlWEpo+AcXrJr1PBrEMgGw KsdOcvsX0tJ4EXHzAU4FU+t3ehioK7TXWLhHsDjkHRqubH1Cbfjc4+SxHIHlHxwS CHtJ8swB/gl2l23l1LipWg/ThdTyqRndOC0sQMznN8HcE5QxPRvKtGFa8jHtJlU= =hErB -----END PGP SIGNATURE----- --Apple-Mail=_94757D88-A691-48DE-9912-E7612D91ED39-- From nobody Fri Apr 7 01:48: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 597A7129666 for ; Fri, 7 Apr 2017 01:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mmVzRI3wKbQq for ; Fri, 7 Apr 2017 01:48:28 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 B05A31292AE for ; Fri, 7 Apr 2017 01:48:28 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id x35so55527333qtc.2 for ; Fri, 07 Apr 2017 01:48:28 -0700 (PDT) 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=Vol3DM3NlmlYfSi+Vl8SJ++tJ4X/ulLM30qhKqI4LGY=; b=X88nPGQQqi7kioGvYcFmCPLjVyDFG8RHjCDYHyGDZjja9f5LhBlQ5QAkPa1zo9RXle 9QvPJUQdl45+qz6mnq9iFb2rN5OctZxR5OaeS+TBzFXxNkSxoOiBeX3qwQaTlwhsPLPO 9Fhd5TkFYYpImYvayjd34kgAJXZil4m8eKwd2R6XbfAgnjq4hfDNaNcZMaa6kb2MbLTd e4xsx+ixM8V3Rtj7BfF8f6N/YiEBqdOIeZj1B6f7vqTzEFlJH6OfF58yg1bLb4/gPHZP Ou2EyBMyOzM94krWavPfnea7wVJKmI/d3/hfxSIuSY21kqrjA5lJhfmrdstcZoHhTkIE rlng== 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=Vol3DM3NlmlYfSi+Vl8SJ++tJ4X/ulLM30qhKqI4LGY=; b=QEcpQ0AqOpPM+aRZMnFmQNV2nhTM1E7BRmCC5DDEDHXfuN3L5QVmEYwpze1y/o9t7E ynB8RuHCjS+trba7csF4+ykr+CUNFs5IvjGYmycb1jFZ8DGmlrrPz/c1S3Je0tveWcgA K7wDoe90OOeDqqM8CO/p8qdtxuQS5SYptTb2lncVQ6B7egpE+q5+SSRCRWq0eOAJZHiz WIuhJCCq6U0fCMmrSq7sBPM26JvwByIak+Z6ncOJh1lw7BJY7zwmmKPRLutu9Jg0ZII/ p2G7TC8rFZzx8pS3YWgo226XDsf+u4tSTh+9gjLIXyjwsJe0LkxJoZuX+2bqYh6T/E4r ejsQ== X-Gm-Message-State: AFeK/H0FO6qb7TaV+c1XTTIqLqVYOpWDBGkkLVxKLgl9H6fE9UqaL7mB4cgPSXJauXbcPvmdYrjrru5B1ebizQ== X-Received: by 10.200.45.216 with SMTP id q24mr38774601qta.41.1491554907790; Fri, 07 Apr 2017 01:48:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.32.226 with HTTP; Fri, 7 Apr 2017 01:48:07 -0700 (PDT) In-Reply-To: <0D6F5563-2CDE-4831-9907-364FA002E82C@steffann.nl> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <0D6F5563-2CDE-4831-9907-364FA002E82C@steffann.nl> From: Richard Hartmann Date: Fri, 7 Apr 2017 10:48:07 +0200 Message-ID: To: Sander Steffann Cc: Brian E Carpenter , IPv6 Operations , Tore Anderson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 08:48:34 -0000 On Fri, Apr 7, 2017 at 9:34 AM, Sander Steffann wrote: > 1: Clients MUST implement both RDNSS and a DHCPv6 client > 2: Both SHOULD be enabled by default so they can get connectivity on any = network > 3: Clients MAY (SHOULD?) choose not to request options over DHCPv6 that t= hey already got through other mechanisms (i.e. RA or statically configured) > 4: If a client has all the options it needs then it MAY choose not to do = DHCPv6 at all > > Or worded the other way around: allow a client to basically do RA-only un= less it's missing something and then try to get that through DHCPv6. > > This would be a deviation of the current behaviour where clients do SLAAC= +RNDSS+DHCPv6 and use/combine all the information it got, but maybe this wo= uld be a better way to do it. The client would work on a DHCPv6-only networ= k, but may choose to use only the information in the RA whenever it can. Wo= uld this work? /me hums a happy tune. This is better than what I wrote earlier; and aligns rather well with "RA for lean, DHCPv6 for feature-rich networks". Again, the common case is that, if anything moves at all, the host moves between various networks. Thus it's that part of the whole system which should work with what it encounters, not the other way around. --=20 Richard From nobody Fri Apr 7 01:53: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 1DFFA129666 for ; Fri, 7 Apr 2017 01:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 M3tR0UNWqGTk for ; Fri, 7 Apr 2017 01:53:02 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 47B6F129646 for ; Fri, 7 Apr 2017 01:53:02 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=37590 helo=envy.e1.y.home) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cwPdb-00085W-9w; Fri, 07 Apr 2017 08:52:59 +0000 Date: Fri, 7 Apr 2017 10:52:53 +0200 From: Tore Anderson To: Lorenzo Colitti Cc: Brian E Carpenter , IPv6 Operations Message-ID: <20170407105253.44126515@envy.e1.y.home> In-Reply-To: References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 08:53:04 -0000 * Lorenzo Colitti > On Fri, Apr 7, 2017 at 6:20 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 > > I do agree with your implied goal of making the host stack's > > connectivity as robust as possible. And I can see why RDNSS > > would be a better bet when both are available. But to not > > used stateless DHCPv6 when it's the *only* source of DNS info > > seems to me to go against that goal. +1=20 > Remember we're talking about the router side of things here. In this > case, RDNSS is not the only source of DNS info because we also > support DHCPv4. You kicked off this thread calling for a MUST for routers to support RDNSS (I agree with you on that, for what it's worth). Now you appear to be making the argument that a MUST for DHCPv6=C2=B9 is not warranted because all routers and all hosts support DNS server discovery over DHCPv4 anyway. That argument, however, applies 100% against your proposed addition of a MUST for RDNSS too. You can't have it both ways. When also considering IPv4 and dual-stack, operational reality today for a BYOD network operator needing to provision attaching nodes with DNS servers can be expressed in one of these ways: 1) MUST DHCPv4 OR (MUST RDNSS AND MUST DHCPv6=C2=B9) 2) MUST DHCPv4, MAY=C2=B2 RDNSS, MAY=C2=B2 DHCPv6=C2=B9 In either case, RDNSS and DHCPv6=C2=B9 have the same "MTI level". Note that this is DHCPv6 fanboyism on my part, I don't particularly care which tool gets the job done. I would not mind at all if RDNSS got implemented in ~all hosts, and IFF that actually happens I'd be happy support a -bis that removed any requirement for DHCPv6. (PIO-X vs DHCPv6-PD, same thing.) But that's not (yet) the world we're living in, and IMHO the output of the IPv6 Operations working group needs to reflect current operational realities, not wishful thinking about how the world will look five or ten years from now. [1] Not considering stateful IA_* stuff [2] Or SHOULD Tore From nobody Fri Apr 7 02:54: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 8E5C512783A for ; Fri, 7 Apr 2017 02:54:33 -0700 (PDT) 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 mRoMlmVPB1hu for ; Fri, 7 Apr 2017 02:54:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 197111200DF for ; Fri, 7 Apr 2017 02:54:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwQb6-0000FdC; Fri, 7 Apr 2017 11:54:28 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <0D6F5563-2CDE-4831-9907-364FA002E82C@steffann.nl> In-reply-to: Your message of "Fri, 7 Apr 2017 09:34:21 +0200 ." <0D6F5563-2CDE-4831-9907-364FA002E82C@steffann.nl> Date: Fri, 07 Apr 2017 11:54:27 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 09:54:33 -0000 >Having a DHCPv6 client implemented on the client doesn't mean it has to >use it for every single option it supports. Maybe use it but only for >things that haven't been provisioned in another way. How about: > >1: Clients MUST implement both RDNSS and a DHCPv6 client >2: Both SHOULD be enabled by default so they can get connectivity on any >network >3: Clients MAY (SHOULD?) choose not to request options over DHCPv6 that >they already got through other mechanisms (i.e. RA or statically >configured) >4: If a client has all the options it needs then it MAY choose not to do >DHCPv6 at all On thing DHCP can do and RDNSS basically can't is to have per host configuration. If I want to point my laptop to a test dns resolver cluster then I can do that with DHCP without impacting anyone else. And if I do that using DHCP I can take my laptop elsewhere and it will just work. No need to mess around with any config on the host. Just a change a line in the DHCP server config. Of course, this feature will be killed of we specify that RDNSS has a higher priority. From nobody Fri Apr 7 03:15: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 9C08D127A91 for ; Fri, 7 Apr 2017 03:15:09 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 kT-KCTHknulW for ; Fri, 7 Apr 2017 03:15:07 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 D13A31243FE for ; Fri, 7 Apr 2017 03:15:05 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id s68so69750172vke.3 for ; Fri, 07 Apr 2017 03:15:05 -0700 (PDT) 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=OWkSVWMLipkkgLZO7952z5o7hFnTo58XFBtKxOv32T4=; b=j1V5MWNn7ZcmqFjA2SoI+b9xUvVT2yIO7gvKVLFM8HYnCk7JUkNpjsyDwDgPKv70+v 4Q6q0YC2Ts/SqMEFPVoCt5rc1DrdPUCX9+Bja6oIv4/X+uJwFMpEwdCVbyoZMMbJQdLT r8betpqPl0IBxpbbGrDJo1aVJhqKM/8PPF8qTK/Z0atQdVxU4RvtkM7D0EGq/dt40Zr1 UmE/mrdDNzr1CIDEUxRSM93osaE/fFqOthr0lGlscxQeuQox0V6BGi0FtTZ/8BAv+PXB Vg0jEGjJKZq+ORrbHrnLYRYZc18gCAiTzcsmd8yHM3ZXKX/vmRN8+Uqpt8jIT3NhPVq9 zojQ== 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=OWkSVWMLipkkgLZO7952z5o7hFnTo58XFBtKxOv32T4=; b=uJ/lNKyUq92oCe2FL4YFYYcc/F2+VHsAOQ+cUEzO85rhw32bPhwwXPTNLEyclMqaxH aN0Jrp+XHQAVunxp6AcIuM/UQo64vmj32pqPn+3fDRjFb3sQZFjpnGOqqz1cvZEQ/QYq s6juEjBVERXU7OULMaDiKD3vVlxcSZwl3Yw9dBea1LPUHyIiRo2sZ7l8p9S0snkfPwUw OgNy8aRq3qwM5D2952hfkyasp0Pkih5hcv+nzNBzPy519TyH3eCT4iWjBKCXByfzZokr aMn3fWHyDWIQu5l5DVgJenBwbxnEiTewKvHxjX1c2AyN2tDa6DWupAdD8p5LClFfGKiW pumA== X-Gm-Message-State: AFeK/H1OaXK4EjWawC35bsurzWspIlRn0LJJ7T4WG7SOvbvryqAg+mYIS76KqQugExCWLwa6KVMJfKFq0/Tal7Q3 X-Received: by 10.159.52.198 with SMTP id b6mr17427940uac.155.1491560104507; Fri, 07 Apr 2017 03:15:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 03:14:43 -0700 (PDT) In-Reply-To: <20170407105253.44126515@envy.e1.y.home> References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <20170407105253.44126515@envy.e1.y.home> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 19:14:43 +0900 Message-ID: To: Tore Anderson Cc: Brian E Carpenter , IPv6 Operations Content-Type: multipart/alternative; boundary=f403045e2a5a3115aa054c90e6e8 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 10:15:10 -0000 --f403045e2a5a3115aa054c90e6e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 7, 2017 at 5:52 PM, Tore Anderson wrote: > > Remember we're talking about the router side of things here. In this > > case, RDNSS is not the only source of DNS info because we also > > support DHCPv4. > > You kicked off this thread calling for a MUST for routers to support > RDNSS (I agree with you on that, for what it's worth). > The reason I called this thread was for hosts, not routers. > Now you appear to be making the argument that a MUST for DHCPv6=C2=B9 is = not > warranted because all routers and all hosts support DNS server > discovery over DHCPv4 anyway. > > That argument, however, applies 100% against your proposed addition of > a MUST for RDNSS too. You can't have it both ways. > I think you're misunderstanding my position. There are two arguments here. The way I see it, a must for DHCPv6 is harmful because DHCPv6 is technically inferior to RDNSS and thus would lead to regressions in functionality (for which I have provided examples). A MUST for RDNSS is not harmful in this way. Therefore, a MUST for RDNSS is a good idea because a) it's the more capable protocol, and b) it provides a guarantee of interoperability once old OSes have aged out. I don't think there's a contradiction there, it's just that you and I have different goals. You want everything to work everywhere, as soon as possible, without IPv4, and are willing to accept suboptimal outcomes in some parts of the network (like the regressions I provided examples of), even if that would lead to a worse outcome in the long term. That means you want DHCPv6, because you need Windows to work. I want to the best outcome in the long term and am willing to wait for it. That means I don't want DHCPv6, because for as long as IPv4 is around it's not a necessity. > Note that this is DHCPv6 fanboyism on my part, I don't particularly > care which tool gets the job done. I can see your point of view. But please do consider the effects on the long-term flexibility of host configuration in the Internet of encouraging a protocol (DHCPv6) that is both a) technically inferior to the alternative and b) familiar to many network operators, some of whom will choose it because it is familiar or easier and not because it is better. I don't want us all to be running DHCPv6 20 years from now, because it's suboptimal. I want us all to be running RDNSS, because it's better. Like I said, I wouldn't strongly oppose saying that enterprise-class routers MUST implement DHCPv6. If you're running BGP, VRRP, and DHCPv6 failover, you don't ever need to change anything, so the additional benefits of RDNSS won't help much. --f403045e2a5a3115aa054c90e6e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 5:52 PM, Tore Anderson <tore@fud.no> wrote:
=
> Remember we're tal= king about the router side of things here. In this
> case, RDNSS is not the only source of DNS info because we also
> support DHCPv4.

You kicked off this thread calling for a MUST for routers to support=
RDNSS (I agree with you on that, for what it's worth).
=

The reason I called this thread was for hosts, not rout= ers.
=C2=A0
Now you appear to= be making the argument that a MUST for DHCPv6=C2=B9 is not
warranted because all routers and all hosts support DNS server
discovery over DHCPv4 anyway.

That argument, however, applies 100% against your proposed addition of
a MUST for RDNSS too. You can't have it both ways.

I think you're misunderstanding my position. There are = two arguments here. The way I see it, a must for DHCPv6 is harmful because = DHCPv6 is technically inferior to RDNSS and thus would lead to regressions = in functionality (for which I have provided examples). A MUST for RDNSS is = not harmful in this way. Therefore, a MUST for RDNSS is a good idea because= a) it's the more capable protocol, and b) it provides a guarantee of i= nteroperability once old OSes have aged out.

I don= 't think there's a contradiction there, it's just that you and = I have different goals. You want everything to work everywhere, as soon as = possible, without IPv4, and are willing to accept suboptimal outcomes in so= me parts of the network (like the regressions I provided examples of), even= if that would lead to a worse outcome in the long term. That means you wan= t DHCPv6, because you need Windows to work.

I want= to the best outcome in the long term and am willing to wait for it. That m= eans I don't want DHCPv6, because for as long as IPv4 is around it'= s not a necessity.
=C2=A0
Not= e that this is DHCPv6 fanboyism on my part, I don't particularly
care which tool gets the job done.

I can se= e your point of view. But please do consider the effects on the long-term f= lexibility of host configuration in the Internet of encouraging a protocol = (DHCPv6) that is both a) technically inferior to the alternative and b) fam= iliar to many network operators, some of whom will choose it because it is = familiar or easier and not because it is better. I don't want us all to= be running DHCPv6 20 years from now, because it's suboptimal. I want u= s all to be running RDNSS, because it's better.

Like I said, I wouldn't strongly oppose saying that enterprise-class = routers MUST implement DHCPv6. If you're running BGP, VRRP, and DHCPv6 = failover, you don't ever need to change anything, so the additional ben= efits of RDNSS won't help much.
--f403045e2a5a3115aa054c90e6e8-- From nobody Fri Apr 7 03:18:24 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 B1339127A91 for ; Fri, 7 Apr 2017 03:18:23 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 ERzOpd3okSDx for ; Fri, 7 Apr 2017 03:18:22 -0700 (PDT) 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 D4AB1129649 for ; Fri, 7 Apr 2017 03:18:21 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id r69so69905104vke.2 for ; Fri, 07 Apr 2017 03:18:21 -0700 (PDT) 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=QO0g9fiaz7VYG703C6jUcupqtveCH+ha7qOC5X0So5g=; b=lvCQQgQNFujNgg3CvlblWHif7kVVkhelXNbbHCHsYXVeDMjJRYoQFQF1hTug7TyPnk jEWOwRgEOjD7Y8esMDjo76Z13+un1QGIQyod2u0jepFFrMJEGorepXQ6J6YL0t/XM9e9 jnxuOfZPCvoft+EzlbXg5NrnGdsZ6p0LOUlfTrE+RllyfL3SL4PsfkKoq0IPWDhucSIP HrpClm5SG+CIEuS8H2aUu3u+ue1sr/D3i0s6rWfC949mul/d1Z7wn9s5STyZynosVTyz wUBgF6WsGOFXpIFWwBmZzZQQDs13io7rKiYeiLsUp0pPRentjn6TZqmfi73vg+acbj7d yp1w== 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=QO0g9fiaz7VYG703C6jUcupqtveCH+ha7qOC5X0So5g=; b=okqDclpzAtK34ECoCiuD9KwGpwKkklyurk5vlzPGkZ8f3q3wJRPU9wjAjdyJNpc9xM rFintMjkclHbTBPcbezkKcN9spThmnZGtZgDe0r8NRXCd0yHTBMk2noD66rPokZsenJl jEYX0YEjl6YqOKT4QvlOo0mYjC+bCq22GRvA5oVUjlUeNuXI5BuJPXIFTe22PrMq3d7C TS9FR+CU9wNCIEGT+wxoX/Zi0+6SoyNWCf6CNVSab4yrQPle/MjJiMgbZ30q4k7yVE4D UMsAUlc+NovkHBP81AUFxwcyHpmf5JMXnCnoGHHMFP7K3dHIKPId7enllig6QP81GrpL eRiA== X-Gm-Message-State: AFeK/H01emlF3MRlwj+uoUP0zQ2cmxg7kVkg7l9m8/WeKirGIDH0NRxZx9h5iKe16wbBFXP2lGxNfT7YqxKgj/94 X-Received: by 10.31.60.17 with SMTP id j17mr12484917vka.45.1491560300547; Fri, 07 Apr 2017 03:18:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 03:17:59 -0700 (PDT) In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <0D6F5563-2CDE-4831-9907-364FA002E82C@steffann.nl> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 19:17:59 +0900 Message-ID: To: Philip Homburg Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11436e50e063f7054c90f16c Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 10:18:24 -0000 --001a11436e50e063f7054c90f16c Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 6:54 PM, Philip Homburg wrote: > On thing DHCP can do and RDNSS basically can't is to have per host > configuration. If I want to point my laptop to a test dns resolver cluster > then I can do that with DHCP without impacting anyone else. And if I do > that using DHCP I can take my laptop elsewhere and it will just work. > No need to mess around with any config on the host. Just a change a line > in the > DHCP server config. > That's really not a good reason to require support for DHCPv6 DNS servers. It's trivial to do what you want by pointing all your hosts at a set of DNS forwarders and configuring them to talk to different upstreams depending on who is asking. It's also much better: you can change things on the fly without waiting for the host to ask again, and you can even do useful things like send 1% of host X's DNS queries to the test cluster for canarying purposes. --001a11436e50e063f7054c90f16c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 6:54 PM, Philip Homburg <pch-v6ops-7@u-1.phico= h.com> wrote:
On thing DHCP= can do and RDNSS basically can't is to have per host
configuration. If I want to point my laptop to a test dns resolver cluster<= br> then I can do that with DHCP without impacting anyone else. And if I do
that using DHCP I can take my laptop elsewhere and it will just work.
No need to mess around with any config on the host. Just a change a line in= the
DHCP server config.

That's really n= ot a good reason to require support for DHCPv6 DNS servers. It's trivia= l to do what you want by pointing all your hosts at a set of DNS forwarders= and configuring them to talk to different upstreams depending on who is as= king.

It's also much better: you can change th= ings on the fly without waiting for the host to ask again, and you can even= do useful things like send 1% of host X's DNS queries to the test clus= ter for canarying purposes.
--001a11436e50e063f7054c90f16c-- From nobody Fri Apr 7 04:05: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 A9BA7127B31 for ; Fri, 7 Apr 2017 04:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ZK1YZl0pcVoF for ; Fri, 7 Apr 2017 04:05:41 -0700 (PDT) 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 10CB6129434 for ; Fri, 7 Apr 2017 04:05:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwRhy-0000GLC; Fri, 7 Apr 2017 13:05:38 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <0D6F5563-2CDE-4831-990 7-364FA002E82C@steffann.nl> In-reply-to: Your message of "Fri, 7 Apr 2017 19:17:59 +0900 ." Date: Fri, 07 Apr 2017 13:05:36 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:05:44 -0000 >That's really not a good reason to require support for DHCPv6 DNS servers. >It's trivial to do what you want by pointing all your hosts at a set of DNS >forwarders and configuring them to talk to different upstreams depending on >who is asking. Wow, working around the limitations of RA by making changes to a production DNS cluster. And of course, none of those hosts would ever use privacy extensions. From nobody Fri Apr 7 04:26: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 8D046127241 for ; Fri, 7 Apr 2017 04:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 Lp-JH-L3tFTI for ; Fri, 7 Apr 2017 04:26:51 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 72831128D40 for ; Fri, 7 Apr 2017 04:26:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v37BQk89008334 for ; Fri, 7 Apr 2017 13:26:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6120F20392E for ; Fri, 7 Apr 2017 13:26:46 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 57749201066 for ; Fri, 7 Apr 2017 13:26:46 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v37BQk1U029577 for ; Fri, 7 Apr 2017 13:26:46 +0200 To: v6ops@ietf.org References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2AF3CBC7-A275-4532-9930-784282C4D63D@gmail.com> <67c7e59e-bc2b-554d-7fe6-f3974e257c78@gmail.com> <866af7ea-227f-f337-de17-522dabd69b65@nlogic.no> From: Alexandre Petrescu Message-ID: Date: Fri, 7 Apr 2017 13:26:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <866af7ea-227f-f337-de17-522dabd69b65@nlogic.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? - tethering, DHCPv6, RDNSS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:26:53 -0000 Le 07/04/2017 à 09:09, Ola Thoresen a écrit : > On 07. april 2017 00:03, Mark Smith wrote: > >> So don't get caught up on it, all Lorenzo was describing was a use >> case where a device is sometimes a host only, and sometimes​ both >> a host and a router (sourcing/sinking packets for phone UI apps = >> host, forwarding packets for Wifi attached devices = router) >> > > We need to stop pretending there is a sharp distinction between a > router and a host. My mobile phone can be both, my laptop can be > both - it runs several VMs and some of these are even nested VMs, > Any device participating in a mesh network of some sort needs to > route packets one way or another... What we need to be able to > separate is the _role_ some _process_ on a device have at the > moment. > > This means that a lot of devices that in a legacy world are "host > only" might start running code that turns them into routers. I agree. In this particular case a 'tethered' smartphone is a router. It should include DHCPv6 PD Requesting Router, MAY send RAs, may not send RS, forward==1, and others. No longer is that just Host development. > And _that_ code probably needs to support both being a DHCPv6 client > AND server, as it might need to accommodate PD. Whether the OS > itself should have all that code included by default will probably > depend on the vendor or provider. Yes. Moreover, neither the vendor nor the provider should oppose politically the download of a DHCPv6-PD app from an Android (or other) store. > In an ideal world, that means that installing e.g. VMWare, KVM and > such should depend on both a dhcpv6-server and client being > installed (or bundled) on the host. And when I turn on tethering on > my phone, it should probably also enable a dhcpv6-client to get a > prefix, and a dhcpv6-server to be able to serve clients behind it > with prefixes, should they ask for a IA-PD. Sounds reasonable. > This is not an argument to force install or enable DHCPv6 on all > "clients" by default. We just need to make sure it is available when > some software on the device changes its role to a "router". I also agree. Alex > > > /Ola (T) > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 7 04:28: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 DC8B812944C for ; Fri, 7 Apr 2017 04:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 4TKPcbic-G2I for ; Fri, 7 Apr 2017 04:28:38 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 A231F12943A for ; Fri, 7 Apr 2017 04:28:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v37BSaBI021658 for ; Fri, 7 Apr 2017 13:28:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D26FE20699B for ; Fri, 7 Apr 2017 13:28:36 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C7C9720699A for ; Fri, 7 Apr 2017 13:28:36 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v37BSaKv030629 for ; Fri, 7 Apr 2017 13:28:36 +0200 To: v6ops@ietf.org References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <20170407105253.44126515@envy.e1.y.home> From: Alexandre Petrescu Message-ID: Date: Fri, 7 Apr 2017 13:28:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:28:41 -0000 Le 07/04/2017 à 12:14, Lorenzo Colitti a écrit : > On Fri, Apr 7, 2017 at 5:52 PM, Tore Anderson > wrote: > > > Remember we're talking about the router side of things here. In this > > case, RDNSS is not the only source of DNS info because we also > > support DHCPv4. > > You kicked off this thread calling for a MUST for routers to support > RDNSS (I agree with you on that, for what it's worth). > > > The reason I called this thread was for hosts, not routers. But a tethered smartphone is a Router. And you cited earlier a tethering argument in this thread. Alex > > > Now you appear to be making the argument that a MUST for DHCPv6¹ is not > warranted because all routers and all hosts support DNS server > discovery over DHCPv4 anyway. > > That argument, however, applies 100% against your proposed addition of > a MUST for RDNSS too. You can't have it both ways. > > > I think you're misunderstanding my position. There are two arguments > here. The way I see it, a must for DHCPv6 is harmful because DHCPv6 is > technically inferior to RDNSS and thus would lead to regressions in > functionality (for which I have provided examples). A MUST for RDNSS is > not harmful in this way. Therefore, a MUST for RDNSS is a good idea > because a) it's the more capable protocol, and b) it provides a > guarantee of interoperability once old OSes have aged out. > > I don't think there's a contradiction there, it's just that you and I > have different goals. You want everything to work everywhere, as soon as > possible, without IPv4, and are willing to accept suboptimal outcomes in > some parts of the network (like the regressions I provided examples of), > even if that would lead to a worse outcome in the long term. That means > you want DHCPv6, because you need Windows to work. > > I want to the best outcome in the long term and am willing to wait for > it. That means I don't want DHCPv6, because for as long as IPv4 is > around it's not a necessity. > > > Note that this is DHCPv6 fanboyism on my part, I don't particularly > care which tool gets the job done. > > > I can see your point of view. But please do consider the effects on the > long-term flexibility of host configuration in the Internet of > encouraging a protocol (DHCPv6) that is both a) technically inferior to > the alternative and b) familiar to many network operators, some of whom > will choose it because it is familiar or easier and not because it is > better. I don't want us all to be running DHCPv6 20 years from now, > because it's suboptimal. I want us all to be running RDNSS, because it's > better. > > Like I said, I wouldn't strongly oppose saying that enterprise-class > routers MUST implement DHCPv6. If you're running BGP, VRRP, and DHCPv6 > failover, you don't ever need to change anything, so the additional > benefits of RDNSS won't help much. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Apr 7 04:39: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 CEE87120046 for ; Fri, 7 Apr 2017 04:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ITEIqvj6TmGq for ; Fri, 7 Apr 2017 04:39:19 -0700 (PDT) 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 51C80126C23 for ; Fri, 7 Apr 2017 04:39:18 -0700 (PDT) Received: from [10.0.0.144] (unknown [185.69.144.6]) (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 D7A2680F0B; Fri, 7 Apr 2017 13:39:06 +0200 (CEST) To: Lorenzo Colitti , "Bernie Volz (volz)" References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2d05f1cf883944918058e1db758f761a@XCH-ALN-003.cisco.com> Cc: IPv6 Operations From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 7 Apr 2017 12:11:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:39:22 -0000 On 04/06/2017 06:37 PM, Lorenzo Colitti wrote: > On Fri, Apr 7, 2017 at 2:21 AM, Bernie Volz (volz) > wrote: > > > Please don't tell me that the client needs to react to the RA with > the new DNS servers by starting DHCP to request DNS servers. :-)____ > > __ __ > > The client would react to the RA having new prefix information – > such as that the old prefix was deprecated. > > > Can you cite an implementation that does this, or even a specification > that recommends or requires it? > > Even if you can, from a design perspective saying "we use DHCPv6 to > distribute DNS information and the only way to know that that > information needs to be refreshed is to listen for an RA" is absurd, I kind of agree with this part -- but that's the design of DHCPv6/SLAAC. e.g., you're supposed to listen to RAs before querying DHCPv6 servers. 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 Apr 7 04:40: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 C4B48120046 for ; Fri, 7 Apr 2017 04:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 COgXH6CUUXM4 for ; Fri, 7 Apr 2017 04:40:17 -0700 (PDT) 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 9E8901242F7 for ; Fri, 7 Apr 2017 04:40:16 -0700 (PDT) Received: from [10.0.0.144] (unknown [185.69.144.6]) (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 C3F7E80A7E; Fri, 7 Apr 2017 13:39:29 +0200 (CEST) To: IPv6 Operations From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> Date: Fri, 7 Apr 2017 12:28:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:40:20 -0000 Folks, I've followed the discussion in the thread "Making RDNSS a MUST?", and it would seem to me there's a misunderstanding in what "implementing"/"supporting" means. Lorenzo has elaborated on the downsides of employing stateless DHCPv6 to convey DNS information when doing tethering. However, supporting DHCPv6 does not mean Android should convey that information with DHCPv6 (whether in addition or in replacement of RDNSS). It simply means: * For routers, that the functionality needs to be available, such that if an operator decides to employ it, he/she is able to do so. * For clients, it means that the client device should implement stateless DHCPv6, such that if the network makes config information available over stateless DHCPv6, the client should be able to learn it. An Android device operating as a router (doing tethering) can refrain from employing stateless DHCPv6 to convey network configuration information, while still complying with the requirement of "implementing"/"supporting" stateless DHCPv6. Use of stateless DHCPv6 in addition to or in replacement of RDNSS ends up being an operator's decision. In the case of the Android device doing tethering, it could easily be some configuration flag that defaults to "off", or, stretching things a bit, one might even argue that since the configuration is buried in the app doing tethering, such configuration could be "stateless dhcpv6 is off, and there's no way to turn it on". Obviously, stateless DHCPv6 *client* support should be on and enabled by default for all client devices. 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 Apr 7 04:43: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 7AE05128792 for ; Fri, 7 Apr 2017 04:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 G3C3OpmV99Qe for ; Fri, 7 Apr 2017 04:43:47 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5B5120046 for ; Fri, 7 Apr 2017 04:43:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: ; Fri, 7 Apr 2017 11:44:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Fri, 7 Apr 2017 12:43:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <20170407105253.44126515@envy.e1.y.home> To: IPv6 Operations X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:43:49 -0000 Lorenzo Colitti wrote: > I don't want us all to be running DHCPv6 20 years from now, because = it's suboptimal. I want us all to be running RDNSS, because it's better. In a subset of situations. Does RDNSS provide NTP servers ? No. Does RDNSS provide per-host config = ? No. Does RDNSS allow custom options* ? No. So as I see it, you have a "all networks are very basic" PoV where = IP+router+DNS =3D=3D complete config. Many of us take a view that this = triplet is only a bare minimum and we actually need other options for = things to actually work. I'm not against RDNSS becoming MTI. But, with a vociferous subsection = apparently against DHCP which is clearly vastly superior in terms of = what it can configure, I see the end result being that everyone = implements RA+RDNSS and then it's impossible to get anything resembling = a consensus to even keep DHCP. * Example, the brand of wireless AP I use most at work supports a = customer option to provide it with a provisioning server - allowing = "plug and connect" installation where the Ap automatically appears in = the controller ready to be adopted. With DHCP, trivial, with RAs ? Typically VoIP phones use DHCP to get key information - such as their = identity and the server they need to register with. > Like I said, I wouldn't strongly oppose saying that enterprise-class = routers MUST implement DHCPv6. If you're running BGP, VRRP, and DHCPv6 = failover, you don't ever need to change anything, so the additional = benefits of RDNSS won't help much. Don't need any of BGP, VRRP, Failover to be able to provide stable = operations. In the "handset as a mobile hotspot" scenario, it's perfectly feasible = to hand out the link-local address of the WiFi interface to WiFi clients = to use as a DNS resolver. IIRC someone mentioned earlier that the mobile = networks expect tethering phones to run a cache locally to reduce = network traffic. So under what circumstances would that LL address = change - losing the cell signal and getting it back wouldn't do it. PS - I wasn't going to reply just to mention it, but early "privacy = concerns" were given as a reason not to us DHCP. Sorry - but for someone = from Google, given their business model, to raise privacy concerns is = "interesting".= From nobody Fri Apr 7 04: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 466A612944B for ; Fri, 7 Apr 2017 04:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3ZgWfb12LY3T for ; Fri, 7 Apr 2017 04:47:43 -0700 (PDT) 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 ED53B129418 for ; Fri, 7 Apr 2017 04:47:38 -0700 (PDT) Received: from [10.0.0.144] (unknown [185.69.144.6]) (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 83CC980A7E; Fri, 7 Apr 2017 13:47:35 +0200 (CEST) To: Lorenzo Colitti , Fred Baker References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <28F6E669-8DB5-46FB-A2BE-A6CA4F2C4855@gmail.com> Cc: IPv6 Operations , Tore Anderson From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <94b2314d-653c-c60c-bd1c-adbd7e013819@si6networks.com> Date: Fri, 7 Apr 2017 12:45:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:47:45 -0000 On 04/06/2017 06:14 PM, Lorenzo Colitti wrote: > Many of the operators who are advocating for DHCPv6 here say that > everyone uses anycast DNS anyway, and that their DNS servers have not > changed for 15 years. That's great in an enterprise network that uses > BGP, but the number of such networks is dwarfed by the number of home > networks that *don't* use anycast DNS and *do* get renumbered. Saying > that all those routers MUST implement DHCPv6, and degrade the ability of > those networks to renumber like this, is fundamentally broken. Implement != use. Nobody said that you have to use DHCPv6 in replacement of RDNSS, or even that you should send DNS information both via RDNSS and DHCPv6. The discussion has been about supporting both RDNSS and DHCPv6, such that an operator can make his own decision regarding whether to do RDNSS only, stateless DHCPv6 only, or RDNSS + DHCPv6. > RFC 8106 came out of 6man (https://datatracker.ietf.org/doc/rfc8106/ > ). I might suspect that > 6man would consider a draft updating it to reverse its > recommendation that DHCPv6 be preferred over RDNSS, although that is > for its chairs to say. I think you have presented some very relevant > arguments to support the viewpoint. > > Changing 8106 won't avoid breakage to existing implementations. If we > add this MUST, then deploying a router that follows this MUST will break > the ability to renumber of existing clients. This is not good > operational practice and we should not do it. Kind of off-topic here but: did you argue against the preference of DHCPv6-conveyed DNS info over that conveyed in RDNSS options while RFC8106 (or its antecessor, RFC6106) were being pursued? 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 Apr 7 04:48: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 20A58129418 for ; Fri, 7 Apr 2017 04:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8ibtR_EfF4dM for ; Fri, 7 Apr 2017 04:47:46 -0700 (PDT) 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 0A5CC128792 for ; Fri, 7 Apr 2017 04:47:45 -0700 (PDT) Received: from [10.0.0.144] (unknown [185.69.144.6]) (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 8604C80F0B; Fri, 7 Apr 2017 13:47:40 +0200 (CEST) To: Lorenzo Colitti , Tore Anderson References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> Cc: IPv6 Operations From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> Date: Fri, 7 Apr 2017 12:47:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:47:48 -0000 On 04/06/2017 05:51 PM, Lorenzo Colitti wrote: > On Fri, Apr 7, 2017 at 1:48 AM, Tore Anderson > wrote: > > > > To the best of my knowledge, DHCPv6 is the *only* way to provision > > > IPv6 name servers onto hosts running Microsoft Windows. > > > > We'll see how long that statement stays true. > > Years, certainly. Decade(s), probably. Keep in mind that Windows XP, > released in 2001, still has a significant install base. > > > The question is what will be the situation when we remove support for > DHCPv4. That is a similarly long time horizon. Users and operators will be busted by the game being played by a group of vendors. 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 Apr 7 05:41: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 320201279E5 for ; Fri, 7 Apr 2017 05:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 xHnimH_8Zukj for ; Fri, 7 Apr 2017 05:41:11 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 004AD124281 for ; Fri, 7 Apr 2017 05:41:10 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id 21so65937582pgg.1 for ; Fri, 07 Apr 2017 05:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uQH/pJdvcoMH7DZ17xUAV4MoZjrExHI0xVG4r3e+cRE=; b=RzOke4fS6anPouzMOZLe+SHOPBP9Rua3zfIIPnYpG62QCnZupOKFhE6snwAHHkUCQy h/KMEBAQsoG1oPfKK/4p+/YUll6N1bmED1S8ZWNrJPfF6X8ly1hjs6uLHt3sQNoyTjdT 2ghYZThULbxJeQ4E/Dcy7qKKg3amPDyuQsxtPyEoB4JHraeqyjbesnRcI7tlPeWqcLTR EJCz23BC7jzUQXbAZn4H7koZcZoOv/i9sWt789BPlmXssnf80MczAWwVW0qbAZV6cuRk ZCqxbSz1DVDynhwQz9fGNCSFEqgr95fAS55S2mnkLQUQVIZZ38ecHeKu1Yi0eiIFuQ0e Cz6g== 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=uQH/pJdvcoMH7DZ17xUAV4MoZjrExHI0xVG4r3e+cRE=; b=C4k5TswYHhFpkzVSd0z4iEwD6VGISGMfN8fp/CPVZx47/yQy0dPbryYkjhzfLBnh0V cz5e2gMJtbTeizyf05D7a3jrpCtSSR9spyPZpFqbJiKrk4euoLInYGlcLjWvn0pin+DJ +z8x2IuP6zlTxEMUuRRwEc6TshRkzB5zRBKVGTdgBJEtgivqqnK3n1w34cLpUrRD9xtu c1ZTf+HhjoBuW8pw8zEx8fHa/Uc3OIA3ybbUyCqV/1CmPVULYXboHFsyjZJwlGSIoYYa hK82csytYPscY+nJ+lq/UNLgZQXLV/DZJY74HyHQv0sz30opmNqJ1wtEsKXGhymlxhYr FX/A== X-Gm-Message-State: AFeK/H3FvBJA/AQ1HUmLxP07z0bCzXKJSJxTpAh9NhoTop0b+ftJ9ADekQe46b33mu4qmjXQ2uQ4yaKsmaK5uw== X-Received: by 10.99.110.6 with SMTP id j6mr42005584pgc.64.1491568870445; Fri, 07 Apr 2017 05:41:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.203 with HTTP; Fri, 7 Apr 2017 05:41:09 -0700 (PDT) Received: by 10.100.179.203 with HTTP; Fri, 7 Apr 2017 05:41:09 -0700 (PDT) In-Reply-To: <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> From: Ted Lemon Date: Fri, 7 Apr 2017 05:41:09 -0700 Message-ID: To: Fernando Gont Cc: Tore Anderson , Lorenzo Colitti , IPv6 Operations Content-Type: multipart/alternative; boundary=94eb2c19e278ae67bc054c92f08d Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:41:13 -0000 --94eb2c19e278ae67bc054c92f08d Content-Type: text/plain; charset=UTF-8 I see a lot of people talking and not hearing here. I don't have a real suggestion to make other than that the idea that you are going to convince any handset maker to change what they are doing based on this document is not realistic. So if your path to win depends on this, you are wasting your and the working group's time. On Apr 7, 2017 04:48, "Fernando Gont" wrote: > On 04/06/2017 05:51 PM, Lorenzo Colitti wrote: > > On Fri, Apr 7, 2017 at 1:48 AM, Tore Anderson > > wrote: > > > > > > To the best of my knowledge, DHCPv6 is the *only* way to > provision > > > > IPv6 name servers onto hosts running Microsoft Windows. > > > > > > We'll see how long that statement stays true. > > > > Years, certainly. Decade(s), probably. Keep in mind that Windows XP, > > released in 2001, still has a significant install base. > > > > > > The question is what will be the situation when we remove support for > > DHCPv4. That is a similarly long time horizon. > > Users and operators will be busted by the game being played by a group > of vendors. > > 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 > --94eb2c19e278ae67bc054c92f08d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see a lot of people talking and not hearing here. I don= 't have a real suggestion to make other than that the idea that you are= going to convince any handset maker to change what they are doing based on= this document is not realistic. So if your path to win depends on this, yo= u are wasting your and the working group's time.=C2=A0

On Apr 7, 2017 04:48, "= ;Fernando Gont" <fgont@si6= networks.com> wrote:
On 04/06/2017 05:51 PM, Lorenzo Colitti wrote:
> On Fri, Apr 7, 2017 at 1:48 AM, Tore Anderson <tore@fud.no
> <mailto:tore@fud.no>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0> > To the best of my knowledge, DHCPv6 is th= e *only* way to provision
>=C2=A0 =C2=A0 =C2=A0> > IPv6 name servers onto hosts running Micr= osoft Windows.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> We'll see how long that statement stays tr= ue.
>
>=C2=A0 =C2=A0 =C2=A0Years, certainly. Decade(s), probably. Keep in mind= that Windows XP,
>=C2=A0 =C2=A0 =C2=A0released in 2001, still has a significant install b= ase.
>
>
> The question is what will be the situation when we remove support for<= br> > DHCPv4. That is a similarly long time horizon.

Users and operators will be busted by the game being played by a group
of vendors.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> 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
--94eb2c19e278ae67bc054c92f08d-- From nobody Fri Apr 7 05:48: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 660141201F8 for ; Fri, 7 Apr 2017 05:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 NCDFlv1itFQ6 for ; Fri, 7 Apr 2017 05:48:13 -0700 (PDT) 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 882BF126557 for ; Fri, 7 Apr 2017 05:48:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwTJC-0000GyC; Fri, 7 Apr 2017 14:48:10 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> In-reply-to: Your message of "Fri, 7 Apr 2017 05:41:09 -0700 ." Date: Fri, 07 Apr 2017 14:48:09 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:48:15 -0000 >I see a lot of people talking and not hearing here. I don't have a real >suggestion to make other than that the idea that you are going to convince >any handset maker to change what they are doing based on this document is >not realistic. So if your path to win depends on this, you are wasting your >and the working group's time. If it has no impact, they let's just publish node requirements that all nodes SHOULD support both RDNSS and all types of DHCP (stateful for IA_NA, stateless for just DNS, etc). Any vendor that doesn't like it can just do their own thing. We don't have any police or black helicopters. I think having a MUST or a SHOULD in a BCP has huge impact. That's why there is so much opposition to writing that down. From nobody Fri Apr 7 05:50: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 ED96312945F for ; Fri, 7 Apr 2017 05:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 40lh_a2IO1tP for ; Fri, 7 Apr 2017 05:50:03 -0700 (PDT) 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 0EA7B129444 for ; Fri, 7 Apr 2017 05:49:57 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id g2so65049529pge.3 for ; Fri, 07 Apr 2017 05:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eJfM3ETdWBzu1T7SlSNIC2D7ClVNTZWKzE1mEvZZCIk=; b=DJZzu3fjD8ZJmR61bJ/V0ne1sqXIaoMw/K4wOCKATfsRJOrx4KrEYrNAUV9VbVv6oI S6oyHwQ8pk8wFeDYELS5ZXPmeHfEYt+diTotwOKYxSW1O/6ANyplrzFS4y4iqFke3/dK L3iFOXtq6+q1lV2jpkjLIIR0LrPdsdl8oY+swN21uVvDyMe8wEnbE50y0FhZm+98JCZG MW/kI+zA9zCDmqIVFt0wYFXp//LJtbk2onIIxYnF0r7TklrMdN7bv1cbg/ljdZ3Ru2kV 1uooFbGeW9gsh7HhqpBXhg4WCE9W2PFtAQWLaOYx5xP0Qf9m6XRvLuhi1WqIWYQ5gm5S X/nw== 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=eJfM3ETdWBzu1T7SlSNIC2D7ClVNTZWKzE1mEvZZCIk=; b=DZb5n/gWedEppIy+bEtPP8kqdkK+6teZ8zD80A+t+Q09Xi2j1DjFyx9+NWKwme848Q ZYdwKfRPlg7SzQZwrvm/n9jAH73XVaCEPbyif6AF0oXNIEd2q7z3SW6aWmVQSY+Em/qN Il3e5ioQxUdqIh8jxYd0ngfHYScpH0UE/sDk/uEcS3UP5sQEW/VlutCWT5MLANDYTt5G tCNwBVStXFlbPCpsZgHFB0OjYBAilt3z/HPBlscDm+R4X8HeQCASXcARn+GV8rrIdb4j ABr8XNJ15d5kwtevIOjlRiI2PCp8gDOGzxtvf/cQkQ2ER/rqlHryQf9ZxOR8FZPFvbU3 zTcA== X-Gm-Message-State: AFeK/H3mzdttmFALPU4JdZ0hDkd/9dRConTvMH6KB4kmED5gSpRDLwKjn3b30BaqfeTCUv3YAIkeb9x/i6OdTA== X-Received: by 10.84.229.137 with SMTP id c9mr49145885plk.41.1491569396711; Fri, 07 Apr 2017 05:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.203 with HTTP; Fri, 7 Apr 2017 05:49:55 -0700 (PDT) Received: by 10.100.179.203 with HTTP; Fri, 7 Apr 2017 05:49:55 -0700 (PDT) In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> From: Ted Lemon Date: Fri, 7 Apr 2017 05:49:55 -0700 Message-ID: To: Philip Homburg Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary=94eb2c1cffc00c98cd054c9310e3 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:50:06 -0000 --94eb2c1cffc00c98cd054c9310e3 Content-Type: text/plain; charset=UTF-8 I don't think there is a lot of Odin to writing that down for rdnss. The problem is that there is a large contingent who want a pony before they'll agree to it. On Apr 7, 2017 05:48, "Philip Homburg" wrote: > >I see a lot of people talking and not hearing here. I don't have a real > >suggestion to make other than that the idea that you are going to convince > >any handset maker to change what they are doing based on this document is > >not realistic. So if your path to win depends on this, you are wasting > your > >and the working group's time. > > If it has no impact, they let's just publish node requirements that all > nodes SHOULD support both RDNSS and all types of DHCP (stateful for IA_NA, > stateless for just DNS, etc). > > Any vendor that doesn't like it can just do their own thing. We don't have > any police or black helicopters. > > I think having a MUST or a SHOULD in a BCP has huge impact. That's why > there is so much opposition to writing that down. > > > --94eb2c1cffc00c98cd054c9310e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think there is a lot of Odin to writing that = down for rdnss. The problem is that there is a large contingent who want a = pony before they'll agree to it.=C2=A0
=
On Apr 7, 2017 05:48, "Philip Homburg&q= uot; <pch-v6ops-7@u-1.phic= oh.com> wrote:
Date: Fri, 07 Apr 2017 14:54:15 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:54:18 -0000 >I don't think there is a lot of Odin to writing that down for rdnss. The >problem is that there is a large contingent who want a pony before they'll >agree to it. The 'pony' is simply that all nodes SHOULD support the relevant bits of DHCP. You already said that in your opinion vendors will ignore that anyhow. So this is more of thumb-sized animated gif that features a pony. Who could object to that? And in return you get your RDNSS support. Sounds like a small price to pay. From nobody Fri Apr 7 05:59: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 0210B126557 for ; Fri, 7 Apr 2017 05:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 pxajSaAYyLDP for ; Fri, 7 Apr 2017 05:59:43 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 9E4A81242EA for ; Fri, 7 Apr 2017 05:59:42 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 21so66350973pgg.1 for ; Fri, 07 Apr 2017 05:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=flZkclitC1XvZ6Pmotd8jlGsErcWgEqEsXsbmm2wbQ0=; b=UiaNlo+qQDSi8GhnJiQG+L1RE4w5MPg43YisgtNeVKEzyUDLoN/Pts1HB2PVknSgKC POTEvyfjv/6HnuCqDRnI/VGB3t3TkGWZkAyal79cGM1hUZa11IuVNJnduUhoB0DQeiBd uVKMFWaNLtGmgk+wDlw9gU2+q5EJ22EELynkJSP/bkzoBUen5LieCWYAJStrzF7LYzqc Uk9W9mWPo9opto3G+ooMIJ4mdH/wVvRPtedRuW6yVZEYfVf5HAnjR4bKXV8M9XBV+AI+ bRUxjGJEB0kZQ3q364mNG5r3pp74s+0wQKZeDl/afvZzBxjIUYJ0EDDGc9W/HI6Hysrm Rpsg== 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=flZkclitC1XvZ6Pmotd8jlGsErcWgEqEsXsbmm2wbQ0=; b=dIOeGxb8WK3rF4G4MmI6WJ7DcYJOeIEtXFP/Axeqx+P+q4upaoGlLXLyXC+LKkkzKz nNLgcjOvZ97moTz07hQe4nTFjRYiz2rCZT8sHIi7DSOmSaH+ng8T2ECR/mAv/bclodu9 IGH5yH9QPsOBXoKL7K0Dwnpm81xITXofOQ7Qk/anTrdXFDRTz76KKK599cBf1hd0BZnv 21DwlIZ10mXnPZ+HK8Aj0eTX8/DQ9balAe09PWhvHoufSthJfJf7HaeWL6dObaxZ29gC +9T55H0kEQEZ3L62qNwssUj/Z2pYvnfDsUkU2FhmoqznJBNKW9yRkwkh4myu98sIhlwo JA7A== X-Gm-Message-State: AFeK/H1f4mKCgtSohUmFayBt1Na0i9BThW1tfIqkAykUwyQvwHFGQNKHzJKxfzdoqLn6bnpI3DbkY9GXZEDuOw== X-Received: by 10.99.108.74 with SMTP id h71mr41698465pgc.18.1491569982272; Fri, 07 Apr 2017 05:59:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.203 with HTTP; Fri, 7 Apr 2017 05:59:41 -0700 (PDT) Received: by 10.100.179.203 with HTTP; Fri, 7 Apr 2017 05:59:41 -0700 (PDT) In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> From: Ted Lemon Date: Fri, 7 Apr 2017 05:59:41 -0700 Message-ID: To: Philip Homburg Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary=94eb2c140742f38491054c933248 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:59:45 -0000 --94eb2c140742f38491054c933248 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm cool with SHOULD for DHCP relay on routers. But I hear some people insisting on MUST, and on hosts, and suggesting that we should require DHCP servers in routers, which is too=E2=80=8B much. Take a small victory: don'= t insist on the pony. On Apr 7, 2017 05:54, "Philip Homburg" wrote: > >I don't think there is a lot of Odin to writing that down for rdnss. The > >problem is that there is a large contingent who want a pony before they'= ll > >agree to it. > > The 'pony' is simply that all nodes SHOULD support the relevant bits of > DHCP. > > You already said that in your opinion vendors will ignore that anyhow. So > this is more of thumb-sized animated gif that features a pony. Who could > object to that? > > And in return you get your RDNSS support. Sounds like a small price to pa= y. > --94eb2c140742f38491054c933248 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm cool with SHOULD for DHCP relay on routers. But I= hear some people insisting on MUST, and on hosts, and suggesting that we s= hould require DHCP servers in routers, which is too=E2=80=8B much.=C2=A0 Ta= ke a small victory: don't insist on the pony.=C2=A0

On Apr 7, 2017 05:54, "Phi= lip Homburg" <pch-v6o= ps-7@u-1.phicoh.com> wrote:
>I don't think there is a lot of Odin to writing that= down for rdnss. The
>problem is that there is a large contingent who want a pony before they= 'll
>agree to it.

The 'pony' is simply that all nodes SHOULD support the relevant bit= s of
DHCP.

You already said that in your opinion vendors will ignore that anyhow. So this is more of thumb-sized animated gif that features a pony. Who could object to that?

And in return you get your RDNSS support. Sounds like a small price to pay.=
--94eb2c140742f38491054c933248-- From nobody Fri Apr 7 06:18: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 B032A129454 for ; Fri, 7 Apr 2017 06:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 sUi2MLEaLx_h for ; Fri, 7 Apr 2017 06:18:21 -0700 (PDT) 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 9403F126557 for ; Fri, 7 Apr 2017 06:18:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwTmN-0000ISC; Fri, 7 Apr 2017 15:18:19 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> In-reply-to: Your message of "Fri, 7 Apr 2017 05:59:41 -0700 ." Date: Fri, 07 Apr 2017 15:18:18 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:18:24 -0000 In your letter dated Fri, 7 Apr 2017 05:59:41 -0700 you wrote: >I'm cool with SHOULD for DHCP relay on routers. But I hear some people >insisting on MUST, and on hosts, and suggesting that we should require DHCP >servers in routers, which is too=E2=80=8B much. Take a small victory: don'= >t insist >on the pony. I'm fine with discussing just router requirements and leaving hosts to node requirements. I'd say that for routers, a MUST for RDNSS should be paired with a MUST for DHCP relay and a SHOULD for DHCP stateless server. I'm not aware of routers that do not have the resources for a DHCP relay. I.e., constrained devices tend to be hosts. If someone has a contrained device that is a router, then a SHOULD for DHCP relay makes sense. I have not heard any technical objection to a DHCP stateless server that is off by default. Likewise, if you have a configuration mechanism for RDNSS then the same can be used for DHCP stateless. If the stateless DHCP server is off by default it cannot do any harm. But I'm sure that if rough concensus can be declared that at least DHCP relay is at least a SHOULD, then we should be able to sort out other details. From nobody Fri Apr 7 06:22: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 B26421201F8 for ; Fri, 7 Apr 2017 06:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 MTWI2jtZxWGH for ; Fri, 7 Apr 2017 06:22:39 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 23E8C1242EA for ; Fri, 7 Apr 2017 06:22:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v37DMbQx050654 for ; Fri, 7 Apr 2017 15:22:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0987A202748 for ; Fri, 7 Apr 2017 15:22:37 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 005B1201066 for ; Fri, 7 Apr 2017 15:22:37 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v37DMa71020561 for ; Fri, 7 Apr 2017 15:22:36 +0200 To: v6ops@ietf.org References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2d05f1cf883944918058e1db758f761a@XCH-ALN-003.cisco.com> From: Alexandre Petrescu Message-ID: <6f21897a-a387-5a71-1bc1-cf57487ae933@gmail.com> Date: Fri, 7 Apr 2017 15:22:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:22:41 -0000 Le 07/04/2017 à 13:11, Fernando Gont a écrit : > On 04/06/2017 06:37 PM, Lorenzo Colitti wrote: >> On Fri, Apr 7, 2017 at 2:21 AM, Bernie Volz (volz) > > wrote: >> >> > Please don't tell me that the client needs to react to the RA with >> the new DNS servers by starting DHCP to request DNS servers. :-)____ >> >> __ __ >> >> The client would react to the RA having new prefix information – >> such as that the old prefix was deprecated. >> >> >> Can you cite an implementation that does this, or even a specification >> that recommends or requires it? >> >> Even if you can, from a design perspective saying "we use DHCPv6 to >> distribute DNS information and the only way to know that that >> information needs to be refreshed is to listen for an RA" is absurd, > > I kind of agree with this part -- but that's the design of DHCPv6/SLAAC. > e.g., you're supposed to listen to RAs before querying DHCPv6 servers. That order in itself may be intuitive for some, but less intuitive for others myself included. One needs time before having anything else, and that comes with DHCP. Alex > > Thanks, > From nobody Fri Apr 7 06:31: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 5211512948C for ; Fri, 7 Apr 2017 06:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 eVefvYfQk7lY for ; Fri, 7 Apr 2017 06:31:30 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 C8098127241 for ; Fri, 7 Apr 2017 06:31:30 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v37DPsMF030097; Fri, 7 Apr 2017 09:31:26 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 29p6ebw3fw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 09:31:25 -0400 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 v37DVNTa020777; Fri, 7 Apr 2017 09:31:24 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v37DVF2e020526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 09:31:18 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 7 Apr 2017 13:30:58 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Fri, 7 Apr 2017 09:30:58 -0400 From: "STARK, BARBARA H" To: Ted Lemon , Philip Homburg CC: IPv6 Ops WG Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohJPytzlZ90JUCxvg9piYpj0aG4bByAgAAIrICAABMJgIAARnoAgAABUoCAAAGpAIAAAN2AgAE9QYD//84VyoAAQ22A//++PCeAAER/gP//vZdw Date: Fri, 7 Apr 2017 13:30:58 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB163AC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.161.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_12:, , 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-1702020001 definitions=main-1704070113 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:31:32 -0000 Pj4+SSBkb24ndCB0aGluayB0aGVyZSBpcyBhIGxvdCBvZiBPZGluIHRvIHdyaXRpbmcgdGhhdCBk b3duIGZvciByZG5zcy4gVGhlDQo+Pj5wcm9ibGVtIGlzIHRoYXQgdGhlcmUgaXMgYSBsYXJnZSBj b250aW5nZW50IHdobyB3YW50IGEgcG9ueSBiZWZvcmUgdGhleSdsbA0KPj4+YWdyZWUgdG8gaXQu DQoNCj4+VGhlICdwb255JyBpcyBzaW1wbHkgdGhhdCBhbGwgbm9kZXMgU0hPVUxEIHN1cHBvcnQg dGhlIHJlbGV2YW50IGJpdHMgb2YNCj4+REhDUC4NCg0KPiBJJ20gY29vbCB3aXRoIFNIT1VMRCBm b3IgREhDUCByZWxheSBvbiByb3V0ZXJzLiBCdXQgSSBoZWFyIHNvbWUgcGVvcGxlIA0KPiBpbnNp c3Rpbmcgb24gTVVTVCwgYW5kIG9uIGhvc3RzLCBhbmQgc3VnZ2VzdGluZyB0aGF0IHdlIHNob3Vs ZCByZXF1aXJlIA0KPiBESENQIHNlcnZlcnMgaW4gcm91dGVycywgd2hpY2ggaXMgdG9vIG11Y2gu ICBUYWtlIGEgc21hbGwgdmljdG9yeTogZG9uJ3QgDQo+IGluc2lzdCBvbiB0aGUgcG9ueS4NCg0K Tm93IEknbSBjb25mdXNlZCBhZ2FpbiBhYm91dCB3aGljaCBkb2Mgd2UncmUgdGFsa2luZyBhYm91 dC4NClJlZ2FyZGluZyBhbGwgbm9kZXMuLi4uDQpSRkMgNjQzNCBmb3IgYWxsIElQdjYgbm9kZXMg YWxyZWFkeSBzYXlzOiANCiJhbGwgaG9zdHMgU0hPVUxEIGltcGxlbWVudCBhZGRyZXNzICBjb25m aWd1cmF0aW9uIHZpYSBESENQdjYiDQoiIElmIGEgaG9zdCBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0 cw0KICAgYXBwbGljYXRpb25zIG9yIG90aGVyIHByb3RvY29scyB0aGF0IHJlcXVpcmUgY29uZmln dXJhdGlvbiB0aGF0IGlzDQogICBvbmx5IGF2YWlsYWJsZSB2aWEgREhDUCwgaG9zdHMgU0hPVUxE IGltcGxlbWVudCBESENQLiINCg0KU28gc2luY2Ugbm9kZXMgYWxyZWFkeSBoYXZlIGEgU0hPVUxE IGZvciBESENQdjYgYWRkcmVzcyBhbmQgb3RoZXIgY29uZmlndXJhdGlvbiBpbmZvLCBhbmQgdGhl cmUgaXMgc3Ryb25nIG9wcG9zaXRpb24gdG8gbWFraW5nIGl0IGEgTVVTVCwgd2hhdCBtb3JlIGRv ZXMgdGhlIG5vZGUgZG9jIG5lZWQgdG8gc2F5IGFib3V0IERIQ1B2NiBpbiBvcmRlciB0byBhY2hp ZXZlIHRoZSBhYm92ZS1yZXF1ZXN0ZWQgcG9ueT8NCg0KUkZDIDY0MzQgYWxzbyBzYXlzOg0KIiBJ bXBsZW1lbnRhdGlvbnMgU0hPVUxEIGltcGxlbWVudCB0aGUgRE5TIFJBIG9wdGlvbiBbUkZDNjEw Nl0uIg0KVGhlcmUgaXMgYSAgcHJvcG9zYWwgdG8gbWFrZSB0aGlzIGEgTVVTVC4gU2luY2UgREhD UHY2IGlzIGFscmVhZHkgYSBTSE9VTEQsIGRvZXMgdGhhdCBtZWFuIHRoZSBwb255IHJhbnNvbSBp cyBtZXQ/DQoNClJlZ2FyZGluZyByb3V0ZXJzLi4uDQpXZSBoYXZlIENFIFJvdXRlcnMgd2l0aCBE SENQdjYvUkROU1MgcmVxdWlyZW1lbnRzIGRlc2NyaWJlZCBpbiBSRkMgNzA4NC4gQXMgYW4gZW1w bG95ZWUgb2YgYW4gSVNQIHdobyBpcyBpbXBhY3RlZCBieSwgd2hvc2UgbWFzcyBtYXJrZXQgY3Vz dG9tZXJzIGFyZSBpbXBhY3RlZCBieSwgYW5kIHdobyBwcm9jdXJlcyBzdWNoIENFIHJvdXRlcnMs IEknbSBzYXlpbmcgbGVhdmUgbXkgQ0Ugcm91dGVycyBhbG9uZS4gSSdtIG5vdCBhc2tpbmcgZm9y IGFkZGl0aW9uYWwgb3BlcmF0aW9uYWwgaGVscCBmcm9tIHY2b3BzLiBUaGUgQ0Ugcm91dGVycyBt eSBjb21wYW55IHByb2N1cmVzIHRoYXQgaGF2ZSBidWlsdCBpbiBEU0wgb3IgRy5mYXN0IG1vZGVt cyB3aWxsIG5vdCBiZSBpbXBsZW1lbnRpbmcgREhDUHY2IFJlbGF5IHVubGVzcyBteSBjb21wYW55 IHNheXMgc28uIFtJdCBkb2VzIGhhdmUgREhDUHY2IHNlcnZlciwgYmVjYXVzZSBzdXBwb3J0IGZv ciBJQV9QRCBmb3IgImNhc2NhZGVkIiByb3V0ZXJzIGlzIG5lY2Vzc2FyeSBmb3IgYSBnb29kIHVz ZXIgZXhwZXJpZW5jZS5dIEl0J3Mgbm90IHVwIHRvIElFVEYgYW5kIEknbSBub3QgYXNraW5nIElF VEYncyBvcGluaW9uIG9yICJoZWxwIiB3aXRoIHRoaXMuDQpUaGVyZSBhcmUgZGV2aWNlcyB0aGF0 IHN1cHBvcnQgInRldGhlcmluZyIuIFRoZSBzdXBwbGllcnMgb2YgdGhvc2UgYXJlIG5vdCByZXF1 ZXN0aW5nIGFkZGl0aW9uYWwgSUVURiBhZHZpY2UuIFRoZSB3aXJlbGVzcyBvcGVyYXRvcnMgdGhv c2UgZGV2aWNlcyBjb25uZWN0IChvbiB0aGUgV0FOKSB0byBhcmUgbm90IHJlcXVlc3RpbmcgYWRk aXRpb25hbCBhZHZpY2UuIFRoZSBjb25zdW1lcnMgdXNpbmcgdGhlIHRldGhlcmluZyBmdW5jdGlv biBhcmVuJ3QgY29tcGxhaW5pbmcgYWJvdXQgYW55dGhpbmcgYmVpbmcgYnJva2VuLiBTbyBsZWF2 ZSB0aGVtIGFsb25lLg0KV2UgaGF2ZSBlbnRlcnByaXNlIG9wZXJhdG9ycyBhc2tpbmcgZm9yIHY2 b3BzIGhlbHAgaW4gc3VwcGx5aW5nIHdoYXQgdGhleSBuZWVkIHRvIGRlcGxveSBJUHY2LiBBY3R1 YWxseSwgd2UgaGF2ZSB0aGVtIGFza2luZyBmb3Igd2hhdCB0aGV5IHdhbnQgKG1heCBmbGV4aWJp bGl0eSBhbmQgY2hvaWNlLCB3aXRoIG90aGVycyBpbmN1cnJpbmcgdGhlIGNvc3Qgb2Ygc3VwcGx5 aW5nIHRoYXQpLCBhbmQgbm90IGp1c3Qgd2hhdCB0aGV5IG5lZWQuIEJ1dCB3ZSBzaG91bGQgZm9j dXMgb24gd2hhdCB0aGV5IG5lZWQuDQpUaGVyZSBhcmUgZW50ZXJwcmlzZSBvcGVyYXRvcnMgd2hv IGFyZSBhc2tpbmcgZm9yIGhlbHAuIFY2b3BzIGlzIGluIGEgcG9zaXRpb24gdG8gaGVscCB0aGVt LCBidXQgc2hvdWxkIHJlc3RyaWN0IHRoaXMgaGVscCB0byBhc3Npc3RpbmcgdGhlbSB3aXRoIHJl cXVpcmVtZW50cyBmb3Igcm91dGVycyB0aGF0IHRoZXkgcHJvY3VyZSBhbmQgdGhhdCBhcmUgdW5k ZXIgdGhlaXIgY29udHJvbC4gVjZvcHMgaGFzIGFkb3B0ZWQgYSBkcmFmdCB0byBzdXBwbHkgc3Vj aCBhc3Npc3RhbmNlIChkcmFmdC1hbGktaXB2NnJ0ci1yZXFzKS4gSSBoYXZlIHNlZW4gbm8gYXJn dW1lbnRzIGFnYWluc3QgaGF2aW5nIHRoaXMgZG9jdW1lbnQgc2F5IHRoYXQgZW50ZXJwcmlzZSBy b3V0ZXJzIE1VU1QgaW1wbGVtZW50IERIQ1B2NiAoc3RhdGVmdWwpIHNlcnZlciAqYW5kKiBESENQ djYgUmVsYXkuIFNvLCBnb29kLCB0aGF0IHBvbnkgY2FuIGJlIGRlbGl2ZXJlZCAod2l0aCBNVVNU IGFuZCBub3QganVzdCBTSE9VTEQpLiBBbmQgc2luY2UgbWFueSBlbnRlcnByaXNlIG9wZXJhdG9y cyBzYXkgdGhleSB3YW50IHRvIGFsbG93IGFsbCBtYXNzIG1hcmtldCBkZXZpY2VzIHRvIGF0dGFj aCwgdGhpcyBkb2MgbmVlZHMgdG8gc2F5IE1VU1QgaW1wbGVtZW50IFJETlNTIChpbiB0aGUgUkEp LCBzbyBlbnRlcnByaXNlIHJvdXRlcnMgd2lsbCBtZWV0IHRoZSBuZWVkcyBvZiB0aGVzZSBvcGVy YXRvcnMuDQoNCkJhcmJhcmENCg== From nobody Fri Apr 7 06:32: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 D2A5D129461 for ; Fri, 7 Apr 2017 06:32:16 -0700 (PDT) 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 hpsLjZVKxmxL for ; Fri, 7 Apr 2017 06:32:14 -0700 (PDT) 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 A07E912948E for ; Fri, 7 Apr 2017 06:32:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id EE61E4A; Fri, 7 Apr 2017 15:32:08 +0200 (CEST) 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=1491571925; bh=6tuqMMRdaAizY1VY0CU 1JLl1DVRiShrRJbffNKVeveo=; b=RBQPEuKTqVUIp/S1Bx/FAE13ksSOWAqlvsj sIb+YtXVoUDjt66OjKoa6/Kaczj8TRq8hbV4T/y/zD+o9v0x+sxVvh3bSP9PZUxF XEEnO57o502XfrseHFrVkuzmOJxzVEQ5H0sy/wCfhPOzO2HnPJMna+wBlxOtK1gp CQ6KyVrM= 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 ruiDSEbUKv7q; Fri, 7 Apr 2017 15:32:05 +0200 (CEST) Received: from [192.168.0.149] (unknown [46.44.175.146]) (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 60A6E49; Fri, 7 Apr 2017 15:32:05 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_CAE6A669-46C0-4D36-B50B-D9BEDAEFDF0B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 15:32:04 +0200 In-Reply-To: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> Cc: IPv6 Operations To: Fernando Gont References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:32:17 -0000 --Apple-Mail=_CAE6A669-46C0-4D36-B50B-D9BEDAEFDF0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fernando, Thank you for writing sense. > I've followed the discussion in the thread "Making RDNSS a MUST?", and > it would seem to me there's a misunderstanding in what > "implementing"/"supporting" means. >=20 > Lorenzo has elaborated on the downsides of employing stateless DHCPv6 = to > convey DNS information when doing tethering. >=20 > However, supporting DHCPv6 does not mean Android should convey that > information with DHCPv6 (whether in addition or in replacement of > RDNSS). It simply means: >=20 > * For routers, that the functionality needs to be available, such that > if an operator decides to employ it, he/she is able to do so. >=20 > * For clients, it means that the client device should implement > stateless DHCPv6, such that if the network makes config information > available over stateless DHCPv6, the client should be able to learn = it. >=20 > An Android device operating as a router (doing tethering) can refrain > from employing stateless DHCPv6 to convey network configuration > information, while still complying with the requirement of > "implementing"/"supporting" stateless DHCPv6. >=20 > Use of stateless DHCPv6 in addition to or in replacement of RDNSS ends > up being an operator's decision. *This* As a network operator I am sick and tired of being forced by vendors to = build my network according to their one true vision. I perfectly well = know the characteristics of the network I'm deploying and I'd like to be = the one deciding on how to provision it, thank you very much. When = running an IPv6-only network Android is forcing my hand to make me send = RDNSS, Windows requires DHCPv6, and as an operator I have no choice but = to provide both. Even if I know that this network is very stable and = DHCPv6 would be fine, or when I know that it's very likely to change = over time and I really need the speed of RA+RDNSS. > In the case of the Android device doing > tethering, it could easily be some configuration flag that defaults to > "off", or, stretching things a bit, one might even argue that since = the > configuration is buried in the app doing tethering, such configuration > could be "stateless dhcpv6 is off, and there's no way to turn it on". Perfectly fine. And I'm happy to let Android be the network operator of = the tethering network and make the right choices of provisioning = mechanism. Same for home and small-office CPEs. An option to change the = default would be nice for those of us who know what they are doing, but = we're not the typical user group so I can understand when that's not = implemented everywhere :) > Obviously, stateless DHCPv6 *client* support should be on and enabled = by > default for all client devices. Well yes, if devices need to work in different networks (and I'd really = like to use my phone on my native 3G/4G network, while roaming, on my = home wifi and on the office wifi without having to change any settings) = then they need to support both provisioning mechanisms. So clients need to support both, and managed routers need to let the = operator choose. For unmanaged routers some configuration options would = be nice to have for advanced users. Cheers, Sander --Apple-Mail=_CAE6A669-46C0-4D36-B50B-D9BEDAEFDF0B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY55TUAAoJEB7hi8LTyHy2QKQIAJAseFNduyyKY4TzgTNZ+Vbf +XdT/miXHge1XYglToo1iDpxDRwH7cIa8fTku6XMtEIksuJwL77bvCFVntolueDn AqOiKpheKKbubziITlBS1B3jqS+eFcKckRIxC9NzAokgX/H+jaL3XWzGSBfFPEWY cmwpsp/cUoXhDnfBQ22gZd/7vHSkF1/v2c0SmzffCMkZGk/ld9QFgaYBL+m4b5w+ bz/x0NXz1gCM/I4VEJMk6RuRmjFl+TwVWNwj5g3qI/nD0l4kbgmNYvGrLaeEeqPk ZxRvI1s0ZA6bSTqa+k/f5xYZ25Tj3PgWjvk96OL70Kkr6jA6+L3hYTF5EmHj5v0= =xXnB -----END PGP SIGNATURE----- --Apple-Mail=_CAE6A669-46C0-4D36-B50B-D9BEDAEFDF0B-- From nobody Fri Apr 7 06:36: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 81A8A126C3D for ; Fri, 7 Apr 2017 06:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 541vrYiCHSLE for ; Fri, 7 Apr 2017 06:36:41 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D61891242EA for ; Fri, 7 Apr 2017 06:36:38 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v37DZHIV011314; Fri, 7 Apr 2017 09:36:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 29pbar7vqn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 09:36:36 -0400 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 v37DaZH9026923; Fri, 7 Apr 2017 09:36:35 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v37DaUE8026861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 09:36:30 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 7 Apr 2017 13:36:11 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0319.002; Fri, 7 Apr 2017 09:36:10 -0400 From: "STARK, BARBARA H" To: Philip Homburg , "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohJPytzlZ90JUCxvg9piYpj0aG4bByAgAAIrICAABMJgIAARnoAgAABUoCAAAGpAIAAAN2AgAE9QYD//84VyoAAQ22A//++PCeAAER/gP//wkqhAABzBwA= Date: Fri, 7 Apr 2017 13:36:10 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB163E4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.161.166] 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-04-07_12:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704070114 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:36:42 -0000 > I'd say that for routers, a MUST for RDNSS should be paired with a MUST f= or > DHCP relay and a SHOULD for DHCP stateless server. >=20 > I'm not aware of routers that do not have the resources for a DHCP relay. > I.e., constrained devices tend to be hosts. If someone has a contrained > device that is a router, then a SHOULD for DHCP relay makes sense. >=20 > I have not heard any technical objection to a DHCP stateless server that = is off > by default. >=20 > Likewise, if you have a configuration mechanism for RDNSS then the same > can be used for DHCP stateless. If the stateless DHCP server is off by de= fault > it cannot do any harm. >=20 > But I'm sure that if rough concensus can be declared that at least DHCP r= elay > is at least a SHOULD, then we should be able to sort out other details. For enterprise routers (newly adopted draft-ali-ipv6rtr-reqs), yes. But lea= ve my CE routers out of it. I'm not adding DHCPv6 Relay to my routers with = built-in DSL or G.fast modems. The access network expects DHCPv6 messages t= o come from the 802.1x-authenticated device. Not through it. And leave tethering routers out of it, too. 3GPP wireless providers aren't = asking for relayed DHCPv6 messages to be coming into the 3GPP wireless netw= ork. Focus on the enterprise routers. Those ar the operators asking for v6ops he= lp. Barbara From nobody Fri Apr 7 06:46: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 38EAF1242EA for ; Fri, 7 Apr 2017 06:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 E27DUQUfZ0M7 for ; Fri, 7 Apr 2017 06:46:20 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 A6A01126C3D for ; Fri, 7 Apr 2017 06:46:15 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id t68so16009050iof.0 for ; Fri, 07 Apr 2017 06:46:15 -0700 (PDT) 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=Aru2HAm8klrHFCNMQwYyXcfCBE9O6Aa3OZBUk5OVpw0=; b=yBZgKXuX91AHDvtSUwO/WY4SSVcpcUiJ8JdkGQWJLR66aIeumImMuInR0ZrpT6eUtb Q5eqroNyEbEruS/kZhKCq9Q8Ffnp6Hzy1Z5VcK6+AeNetv17qooixpgK6+btmrWbvjmJ utl9R1mQ4W5b2zqlKJ4hsaCJWqBOozG/yKpCm4b5mWegwzH6FsSzVxF9eKmt1ipT/IW7 hF1BPF7c0TcBi6pI2az8tCIjsuEGqbhIgVtfdZOB0UICu/Ii0ER+XbmJUsfHOS/lNuzq QJJmXTeAw+SplFe6zA/Zp8vOjEwX5PAdNd2wjxH+dEu66Ouvtf05Ksjfg84f/T+HxNzT aRUw== 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=Aru2HAm8klrHFCNMQwYyXcfCBE9O6Aa3OZBUk5OVpw0=; b=FAkKU2CCB+/qIOIYJEjCAMgSXpAoLYHwnajao5wXYJjTMd7p7fhyQMLFze9PvLhGe/ hKQVMQcVFvsICgpsnS4/DDLbCeucSk/oO3KNCsWo9mfYqC6dSLjQn1KYME6OHr46HQiS GlT4C/izJ1bPTV8l3E+KgwnFqL0nyJzeut+NHhH3FYr56+n6ut74NKcwAB5ZL6Ujq1bK tXR2hO7ykoukqupyu/+T6BQKoujCFW9mePmms4h1fuuVUkr9clIBa2UnFYnssbwYKH6O gKFBva8rnxiebSb5ibQAahARtLm6MUYuJSTFnGU4RteyzzvS1Asb3dicgm/zohYTo6Gt hMgg== X-Gm-Message-State: AN3rC/6yUTq5/2a3I/6pNuFkAOumcq7qcYIRwPW3chRo7nXV4GXKqx94pdPyecm+qIk98w== X-Received: by 10.107.138.7 with SMTP id m7mr1860848iod.133.1491572774755; Fri, 07 Apr 2017 06:46:14 -0700 (PDT) Received: from [172.19.131.119] ([12.130.117.88]) by smtp.gmail.com with ESMTPSA id w192sm2857934ith.7.2017.04.07.06.46.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 06:46:13 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_98E7FCA5-6337-45E5-933E-B57BC9C21C02" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 06:45:58 -0700 In-Reply-To: Cc: v6ops@ietf.org To: Philip Homburg References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:46:22 -0000 --Apple-Mail=_98E7FCA5-6337-45E5-933E-B57BC9C21C02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 7, 2017, at 6:18 AM, Philip Homburg = wrote: > I'd say that for routers, a MUST for RDNSS should be paired with a = MUST for > DHCP relay and a SHOULD for DHCP stateless server. If you haven't heard a technical objection to a SHOULD for a stateless = DHCP server, you didn't read my message where I asked what the language = would be that would specify it, and gave a list of questions that would = need to be answered. You can't just say "routers SHOULD implement = stateless DHCP." You also haven't answered Lorenzo's question about how Android is = supposed to do this when there isn't going to be a way to turn it on in = the UI, and when there is literally never going to be a DHCP server to = which the DHCP relay could relay. --Apple-Mail=_98E7FCA5-6337-45E5-933E-B57BC9C21C02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 7, 2017, at 6:18 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
I'd say that for routers, a MUST for = RDNSS should be paired with a MUST for
DHCP relay and a = SHOULD for DHCP stateless server.

If = you haven't heard a technical objection to a SHOULD for a stateless DHCP = server, you didn't read my message where I asked what the language would = be that would specify it, and gave a list of questions that would need = to be answered.   You can't just say "routers SHOULD implement = stateless DHCP."

You also haven't answered Lorenzo's question about how = Android is supposed to do this when there isn't going to be a way to = turn it on in the UI, and when there is literally never going to be a = DHCP server to which the DHCP relay could relay.

= --Apple-Mail=_98E7FCA5-6337-45E5-933E-B57BC9C21C02-- From nobody Fri Apr 7 06:53: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 757BC1294B5 for ; Fri, 7 Apr 2017 06:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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=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 ew7P3TXVsHCI for ; Fri, 7 Apr 2017 06:53:41 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 AC7DF1294B7 for ; Fri, 7 Apr 2017 06:53:41 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id y18so119600041itc.0 for ; Fri, 07 Apr 2017 06:53:41 -0700 (PDT) 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=gQVLrznwmTJqWYoVBBjJ3raOnXmR5BSRmC05CRj2V6E=; b=ccHJ4j4pHRIG2hu+BNbUzKIU4hAoMRwg3NWiSa/wAFM6Yi3xLHkZQp731kVy9StVZe 6Rq0GOdNxLZuWaE6rCjxvqPfrQooqi1hAwFirvqJHMM/VsriLaxaC2NWYHvrQeIKFFcH ikITT/iNQnadTwGZzlzbaAYv2Um8IT6L5aVe9w6SLNYgZC61FEQ+31na1Vsm3+avVhGk 6bvvSDnxJxPou3Owe89RotgVQClIeEJeEwiSZbI+9DoKVZVDoPqtE9nrfZTW0EkIvaAY 8bbIbd5GxMxF5D+0G/oJuPo05XfayjGmKrh6Bnvcv2rqvn6jRRlv/ib1FjKEq++GcKR1 vDFw== 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=gQVLrznwmTJqWYoVBBjJ3raOnXmR5BSRmC05CRj2V6E=; b=C2tLE5lBOqcIWw1UCElP8OakoDisJz6ZlFq8on8Z2ETIil7k9ckErV9jU8TgXlZzvz lVEpVUhaityBUf6zjOj2fs1GK2039cABjw0KUIksxsJzg/4noTkM84g1U2AVBwmOeJ0L 4K/xlHioBNbOzL59qLyQGNOuyjBcj8DYmhrT5FKlFbxMlEYJgx022jjtcyBO+Q9ZyayI z0qR4a0gi27Kc2KSe0JxX2+TX86/Nx834v90st1s4KFjRVr35uddDIz/lj+0kDEDCHjX 82TkvxDXYo3Kk+UYRygARi4RTHqkSzZR6l/j0Op5xuzGw1UhaKyu+OMxBVx3LQoLGK3s nkFA== X-Gm-Message-State: AFeK/H0/FgCinhF8YyMZxlRCSY1s2SQ5EAKaXvwcp8qvk6RT72H0TtjPVhr9FqiUJjIwA5ddyJsVGI2zAPoF3A== X-Received: by 10.36.16.21 with SMTP id 21mr22007334ity.66.1491573221067; Fri, 07 Apr 2017 06:53:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.184.197 with HTTP; Fri, 7 Apr 2017 06:53:20 -0700 (PDT) In-Reply-To: <12b0913b-32ce-b0c2-b57d-2dec854032f0@gmail.com> References: <6C1E351B-F8B6-4BC2-890D-993A1F081226@gmail.com> <8365a4e0-d317-ed3c-59b3-2e829ff210f3@gmail.com> <12b0913b-32ce-b0c2-b57d-2dec854032f0@gmail.com> From: Jen Linkova Date: Fri, 7 Apr 2017 15:53:20 +0200 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Outcomes from v6ops@IETF98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:53:43 -0000 On Mon, Apr 3, 2017 at 3:20 PM, Alexandre Petrescu wrote: > Le 03/04/2017 =C3=A0 00:08, Tim Chown a =C3=A9crit : > [...] >>> >>> draft-petrescu-v6ops-ipv6-power-ipv4 is a brand new draft, slipped >>> in just under the wire. The first question is whether the working >>> group is interested; there wasn't time for that discussion to >>> happen before IETF 98. If we ARE interested, what do we think of >>> it? >> >> >> It would be more interesting if the reasons for the additional power >> consumption were identified and discussed - there=E2=80=99s no sign of = this >> that I can see in the document - > > > Right - no such sign in the document, although on the email list someone > (Jen and colleagues?) tried an explanation several months ago - > something related to the header size being larger. I think you are referring to this thread: https://www.ietf.org/mail-archive/web/v6ops/current/msg25223.html --=20 SY, Jen Linkova aka Furry From nobody Fri Apr 7 06:58: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 AEF451294C5 for ; Fri, 7 Apr 2017 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 zjL1M61N8Iyi for ; Fri, 7 Apr 2017 06:58:22 -0700 (PDT) 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 DE4981294BD for ; Fri, 7 Apr 2017 06:58:21 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwUP6-0000H3C; Fri, 7 Apr 2017 15:58:20 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> In-reply-to: Your message of "Fri, 7 Apr 2017 06:45:58 -0700 ." Date: Fri, 07 Apr 2017 15:58:19 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:58:25 -0000 > If you haven't heard a technical objection to a SHOULD for a > stateless DHCP server, you didn't read my message where I asked > what the language would be that would specify it, and gave a > list of questions that would need to be answered. You can't > just say "routers SHOULD implement stateless DHCP." If you tell me all the details you are going to write down in your specification for RDNSS then I'll just copy them can replace RDNSS with stateless DHCP DNS option. So, could you please give me the requirements for RDNSS? > You also haven't answered Lorenzo's question about how Android > is supposed to do this when there isn't going to be a way to > turn it on in the UI, and when there is literally never going > to be a DHCP server to which the DHCP relay could relay. I don't know about all Android devices, so I'll just refer to my phone: - There are 3 toggles to switch on or off USB, Wifi and Bluetooth tethering - In Wifi tethering, there is - an input field for the SSID, - a drop down menu for security - a password field is you select PSK - a check box show the password Note that in wifi configuration, there are an insane number of options to configure 802.1X but also options to statically configure DNS resolvers. You are now going to tell me that with all these options, there is no space for an option the enable DHCPv6 functionality when configuring a hotspot? From nobody Fri Apr 7 07:07:29 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 3A9851286B2 for ; Fri, 7 Apr 2017 07:07:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 4TQM1NDCkJcP for ; Fri, 7 Apr 2017 07:07:25 -0700 (PDT) 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 86AF0124BFA for ; Fri, 7 Apr 2017 07:07:25 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id s68so76048178vke.3 for ; Fri, 07 Apr 2017 07:07:25 -0700 (PDT) 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=dxmeZlF2E0JCi4i0S4RKJdzvM0vVSbBPGpCw7LgqvVo=; b=Emq7nRh+0jRuZi005ATLGfmk98W38YW3b/ITvg2WBUaybzQzqvWZE+/JrITHaQ6Fx0 rqDk45PodJJvcDsjvDn0QjP97rVsIRGLU2wcFagnLs9agzpHav8SC+SqP7v5KGWmlp1V 3vQogvO3wCLNDHJTr/Fp2IKc0ki/O7CJmLc/SQkPM9RiVBybGs48PFq456Psi0X5AkiF bp8ASQL7aBK5BX4x1K+2dOYpUtS9i7SGU3j3ockm65b/ajuBdN0tPBWLiaxUveKF123f v12P13ldImw7fjf/+ShNsrZQ9B+kQtfX9iUajkgJ3zU5I+TeLe8aqljBNEoBmZ6sSn/z AW+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=dxmeZlF2E0JCi4i0S4RKJdzvM0vVSbBPGpCw7LgqvVo=; b=saqo2KjtuAHCIa5KDgCS6Xc/b/LljPXffpaGcW3rIDMYtrbKR74ZErmNNGJNi880Kv EVP08yQeoBrSqBiB3W8sI+Mc7BBzkwqwZrtt+6NhI9PUYESuFAJl4dwKFzSdwvqe5BmA LYR3k6RkI4DhPIxgrLJLPGKH9bBrhQxNoNPQpUj+vgzS9DkPQBBnULxp75CENQRbc/6b Z+GV0OeAk3VjVjJD9/FH+sWxU9Hu1mg8h8fRiiIARjX2u9VwD/4Joz1UD6CycudN8GYO 92wtFDeqZNS60fG1wifmayyRsQvDjJbhAftZtoKILxLxxcInNzQmZ78M7gLmVSOoFpSS at7A== X-Gm-Message-State: AFeK/H3WSZUTHhYGsCiLgLk2fh4c3jhx6T8nOduPtd9XXJRY7ZzMbla9kD7E3lfrUjs9TB3ikJ5b/pmEH1qOgmSp X-Received: by 10.159.32.71 with SMTP id 65mr21571301uam.72.1491574044343; Fri, 07 Apr 2017 07:07:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 07:07:03 -0700 (PDT) In-Reply-To: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 23:07:03 +0900 Message-ID: To: Philip Homburg Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=94eb2c03e8b8122ab0054c9425ec Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:07:27 -0000 --94eb2c03e8b8122ab0054c9425ec Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 10:58 PM, Philip Homburg wrote: > You are now going to tell me that with all these options, there is no > space > for an option the enable DHCPv6 functionality when configuring a hotspot? Yes, and he'd be right. In all probability, the people who make this sort of decision will (rightly) conclude that only a vanishingly small percentage of users will even have ever heard of DHCPv6, and will probably say something like, "Why do users need a setting for something they've never heard of? Is the setting necessary for things to work? Can we make things work the way the user wants without the setting?" --94eb2c03e8b8122ab0054c9425ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 10:58 PM, Philip Homburg <pch-v6ops-7@u-1.ph= icoh.com> wrote:
You are = now going to tell me that=C2=A0 with all these options, there is no space
for an option the enable DHCPv6 functionality when configuring a hotspot?

Yes, and he'd be right. In all probabili= ty, the people who make this sort of decision will (rightly) conclude that = only a vanishingly small percentage of users will even have ever heard of D= HCPv6, and will probably say something like, "Why do users need a sett= ing for something they've never heard of? Is the setting necessary for = things to work? Can we make things work the way the user wants without the = setting?"
--94eb2c03e8b8122ab0054c9425ec-- From nobody Fri Apr 7 07:16: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 87F09124B0A for ; Fri, 7 Apr 2017 07:16:48 -0700 (PDT) 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 7Uw6sNVW172x for ; Fri, 7 Apr 2017 07:16:47 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::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 D4628126557 for ; Fri, 7 Apr 2017 07:16:46 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id 68so7605247ioh.3 for ; Fri, 07 Apr 2017 07:16:46 -0700 (PDT) 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=/+uNx+IuMRRw7xJSeZHnGArAoMrq2egKw6cRIhMbzuI=; b=OriDlMwLerPRRa807vUbFO2lRM99q/5xxD9pCgh+REpKH5HB1+e21GWsjjmaz8mPqw 1nEaCnjUsPtfl9p+GjAI3gpHcq96k6bzYortAJUd5bN0QxzA0u8KBe9QLJUQhu3v9jPM dHG2Y1H404aTybA1gKN7v5Pl4eJoF4QivaSjaA5gGE8C3Wl64WRtYDHZjA+f1vnkP7Cn HRM3YaAFHw1If4wbY2cZSlpn16sN/r3slZevVzJzb5VcjL2+iwkAMeNa/DWe29ZV1EGf bSBflNsrB4IC7FqizHni7VepvAuQgjtO2TYwMQAK4k7N+NqOA3fV80FKlbxDxDpvNtVB bmgw== 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=/+uNx+IuMRRw7xJSeZHnGArAoMrq2egKw6cRIhMbzuI=; b=Wt8307lkpbDxlSEf2qXTSj8TwkcEBrMAOb3KSdGpNVGcYs4yOJOzcnZUhUxfCNfx62 uBHw03YJpkxoGaBuBdESBfpVQQOqJTotnQKdpBd5srXIa0EXydUZo82j2/ljQb25r5+H GMdjYUZZFoCtVeqOEzFZVMcEtqjz0INaHWv6X1B44EFvt2+m+LCXKFpu5EisBRoqjd1P eNCXJSr8DCpR2j1kVXKOR8PRucuGNAP+/9P1zK32hRTySSs7n/7PZb1rvVUl32laqq6i vPLxU4aJ5OA9IpTSAIqiTiSo3siPh7ZpJmQPIieyAySE4ilmSiTKKcExJFT9XVqhVgxp t1Qg== X-Gm-Message-State: AFeK/H16RA2BIsqDnhvCRYOgprS+22ViUlTL72c6LzpeqfSerAJ+ITuXSqY+H59+IdfJwQ== X-Received: by 10.107.12.40 with SMTP id w40mr39316262ioi.209.1491574606209; Fri, 07 Apr 2017 07:16:46 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id m72sm1527791ith.12.2017.04.07.07.16.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:16:45 -0700 (PDT) To: "STARK, BARBARA H" , Philip Homburg , "v6ops@ietf.org" References: <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> <2D09D61DDFA73D4C884805CC7865E6114DB163E4@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 8 Apr 2017 02:16:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB163E4@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:16:48 -0000 On 08/04/2017 01:36, STARK, BARBARA H wrote: >> I'd say that for routers, a MUST for RDNSS should be paired with a MUST for >> DHCP relay and a SHOULD for DHCP stateless server. >> >> I'm not aware of routers that do not have the resources for a DHCP relay. >> I.e., constrained devices tend to be hosts. If someone has a contrained >> device that is a router, then a SHOULD for DHCP relay makes sense. >> >> I have not heard any technical objection to a DHCP stateless server that is off >> by default. >> >> Likewise, if you have a configuration mechanism for RDNSS then the same >> can be used for DHCP stateless. If the stateless DHCP server is off by default >> it cannot do any harm. >> >> But I'm sure that if rough concensus can be declared that at least DHCP relay >> is at least a SHOULD, then we should be able to sort out other details. > > For enterprise routers (newly adopted draft-ali-ipv6rtr-reqs), yes. But leave my CE routers out of it. I'm not adding DHCPv6 Relay to my routers with built-in DSL or G.fast modems. The access network expects DHCPv6 messages to come from the 802.1x-authenticated device. Not through it. > And leave tethering routers out of it, too. 3GPP wireless providers aren't asking for relayed DHCPv6 messages to be coming into the 3GPP wireless network. > Focus on the enterprise routers. Those ar the operators asking for v6ops help. > Barbara More generally, qualify each requirement by the class of scenarios that it applies to. It's very clear from this "discussion" that one size does not fit all. Brian From nobody Fri Apr 7 07:22: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 2093B1294A1 for ; Fri, 7 Apr 2017 07:22:46 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 Ve4dCQZf8ifC for ; Fri, 7 Apr 2017 07:22:41 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 7C34E126B6D for ; Fri, 7 Apr 2017 07:22:41 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id d188so75892854vka.0 for ; Fri, 07 Apr 2017 07:22:41 -0700 (PDT) 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=54IQXPTECBJsL6Ng3jOQS5IcFQ4iYwjkjU4Xu4/faxE=; b=uA70LbhWdbNqrOfroat9u4ADtbLhKDyzVdkh3RbKASH2HLMoQg3vF5dPIFqpJ/jl88 8Ebw5U/z0NhLIYb6o/OXwD7iQtK9JxO9jn1G9U2VCyXns8Xxzd2Twg4/y9v47jYRaCQM DkQI3WnbV3FRbGRqbuSIJz1+El8HQLRb8cpm7hYs90cf9SEIb+FyPNXFz1f/KVe5rlzy xWXxw3DDHnug8l9znUP+zzIjkEYApIoj7ij6Dip3WelphZY3q+RNszJwIwMwnalCzLpC iiPWds/btIGfQnPMBXJ6Clwebc1xECMBFd75Tu0mzNNbJ5H2R0QYZB88uuFouzLWKuCt TAXw== 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=54IQXPTECBJsL6Ng3jOQS5IcFQ4iYwjkjU4Xu4/faxE=; b=Yoo5d+7Gtn8rW9x3CGUI6gj9un/jQdkl3j9/DQ6fQ8DDjZO2p7g+lnz/n3qrZnFHrj oScoSS+yN3d9uNVeVn5uix2f08A6Ve73Z4M4rcjNnxu7xopgsXRg3ut0yBV2s2eaiSK9 mID5ntv/Bl5AWq6uGYjaWH4bXouUNCxLBllcITOsZebeOemkyDGcGw4ZyxFPCXLD9lvJ Tt7t5cG2FyBqP6TnaYimDL2cTfedEOjyHo+xuwB73a2BB4RldPVpSN5ennJU/ZviNcrs /4H2QliI0M9gWVc1fi8iJpPhkoC/Ag9hpb4oR25qwFjolyc0z9BKJkDeYYR4S9mmIj6p FwKQ== X-Gm-Message-State: AN3rC/7JrtWprpUAx/TFdFGLbN56pESpvFe9Y41jO4a6J04FBQgNyuhrTrQ5YPSALmK12Ghf9CQ84528Fgzin0tD X-Received: by 10.176.2.104 with SMTP id 95mr2672131uas.30.1491574960253; Fri, 07 Apr 2017 07:22:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 07:22:19 -0700 (PDT) In-Reply-To: <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 23:22:19 +0900 Message-ID: To: Sander Steffann Cc: Fernando Gont , IPv6 Operations Content-Type: multipart/alternative; boundary=001a1134ee38a9f6b5054c945b9b Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:22:46 -0000 --001a1134ee38a9f6b5054c945b9b Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 10:32 PM, Sander Steffann wrote: > As a network operator I am sick and tired of being forced by vendors to > build my network according to their one true vision. I perfectly well know > the characteristics of the network I'm deploying and I'd like to be the one > deciding on how to provision it, thank you very much. I don't think that's a useful argument. You could just as well replace "network operator" with "software developer" and "network" with "product" and end up with a similar sentence - and neither of the two would be likely to convince the other side of the debate. --001a1134ee38a9f6b5054c945b9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 10:32 PM, Sander Steffann <sander@steffann.nl>= wrote:
As a network operator I am= sick and tired of being forced by vendors to build my network according to= their one true vision. I perfectly well know the characteristics of the ne= twork I'm deploying and I'd like to be the one deciding on how to p= rovision it, thank you very much.

I don'= ;t think that's a useful argument. You could just as well replace "= ;network operator" with "software developer" and "netwo= rk" with "product" and end up with a similar sentence - and = neither of the two would be likely to convince the other side of the debate= .
--001a1134ee38a9f6b5054c945b9b-- From nobody Fri Apr 7 07: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 F0141126C3D for ; Fri, 7 Apr 2017 07:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, 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 fRU1ko3Pfdqi for ; Fri, 7 Apr 2017 07:23:46 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 8BA7F12441E for ; Fri, 7 Apr 2017 07:13:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v37EDje5069821; Fri, 7 Apr 2017 16:13:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0639A206C7B; Fri, 7 Apr 2017 16:13:45 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id ED31A206C7A; Fri, 7 Apr 2017 16:13:44 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v37EDigE031076; Fri, 7 Apr 2017 16:13:44 +0200 From: Alexandre Petrescu To: "Bernie Volz (volz)" , "v6ops@ietf.org" References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <434ba61e-5f20-1c95-e24c-f333cd593be2@gmail.com> <7ec53601956a4fbd9b60afe122c3aae1@XCH-ALN-003.cisco.com> Message-ID: Date: Fri, 7 Apr 2017 16:13:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7ec53601956a4fbd9b60afe122c3aae1@XCH-ALN-003.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:23:48 -0000 Le 06/04/2017 à 22:02, Bernie Volz (volz) a écrit : >> I am suggesting to add that lifetime in DHCPv6. > > There already is - see https://datatracker.ietf.org/doc/html/rfc4242. > It does have a min value of 10 minutes. > > I think any lifetime has issues in the fact that if something happens > before that lifetime expires, you'll have old data. > > The lifetime is good and should be used, but the client also needs to > use some knowledge of what's happened to the network to determine > whether it should refresh (RFC 3315/3736/ draft-ietf-dhc-rfc3315bis > have some conditions, perhaps they are incomplete). Well, what example of knowledge about network change does the client need in order to stop issuing Solicits? I am asking because it is not normal that my Windows client continues to issue Solicits forever after having obtained a Server 3 months ago. Alex > > - Bernie > > -----Original Message----- From: v6ops > [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: > Thursday, April 06, 2017 3:50 PM To: v6ops@ietf.org Subject: Re: > [v6ops] Making RDNSS a MUST?, hum v2 > > > > Le 06/04/2017 à 18:38, Tore Anderson a écrit : >> * Erik Kline >> >>> As a vendor of a device that is sometimes a router I am opposed >>> to, and have precisely zero interesting in, implementing a DHCPv6 >>> relay or server function. It adds nothing >> >> Um, «adds nothing», really? >> >> To the best of my knowledge, DHCPv6 is the *only* way to provision >> IPv6 name servers onto hosts running Microsoft Windows. > > YEs. But it has drawbacks, and should be improved. > > It lacks a lifetime. The server is there installed in Windows > forever, until overwritten. > > That makes that after going to IETF meeting and coming back to my > non-IPv6 office network, my laptop still has a DHCPv6 server > configured seen with "ipconfig /all". I dont like that. > > Were it to have a lifetime, it would expire. But no. > > I am suggesting to add that lifetime in DHCPv6. > > Alex > >> >> In my operational reality, «support for Microsoft Windows hosts» is >> diametrically opposite to «nothing». >> >> The exact same point goes for Android and RDNSS. >> >> Thus, when operating a BYOD IPv6 network, it is absolutely >> essential to support *both* RDNSS and DHCPv6. Otherwise you'll be >> excluding a significant amount of devices from being able to use >> your network. >> >> Tore >> >> PS: Apologies to the WG and the chairs for the misdirected hum to >> the list a couple of messages earlier in the thread. It appears my >> MUA didn't interpret the Reply-To header as I thought it would. My >> bad. >> >> _______________________________________________ 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 Fri Apr 7 07:42: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 AE1121294C3 for ; Fri, 7 Apr 2017 07:42:30 -0700 (PDT) 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 oNBbG9BbeVXB for ; Fri, 7 Apr 2017 07:42:20 -0700 (PDT) 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 8BB3F129465 for ; Fri, 7 Apr 2017 07:42:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id D8F2C4A; Fri, 7 Apr 2017 16:42:17 +0200 (CEST) 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=1491576135; bh=TNuVtpgOpOWjYGEV6Jh kRcv5a3GcLuhl6qTZJxH1Ahg=; b=U5rGhVQjY19JMOwjY/MHNGu5R5vjE+7rljN t11I/0Md94u93AIIae5xy3mCAZv6IYl2BmqsSr0bEOLV6R8PvQ7Uydsybtur1PEj 6/gbd9b/O5QAvMwhe0q2cir8aQUZeQjUV+XMYQF9E8M6RbFEoRDnRMovL97siFBU +Zv10DQs= 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 nMn61yobCJdB; Fri, 7 Apr 2017 16:42:15 +0200 (CEST) Received: from [192.168.0.149] (unknown [46.44.175.146]) (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 1B7D449; Fri, 7 Apr 2017 16:42:15 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <69761DA6-9671-4C0D-BE05-AC8208D5B883@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_6B32E787-CAC8-46A1-B978-E874CD8DC704"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 16:42:14 +0200 In-Reply-To: Cc: Fernando Gont , IPv6 Operations To: Lorenzo Colitti References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:42:31 -0000 --Apple-Mail=_6B32E787-CAC8-46A1-B978-E874CD8DC704 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Lorenzo, >> As a network operator I am sick and tired of being forced by vendors = to build my network according to their one true vision. I perfectly well = know the characteristics of the network I'm deploying and I'd like to be = the one deciding on how to provision it, thank you very much. >=20 > I don't think that's a useful argument. You could just as well replace = "network operator" with "software developer" and "network" with = "product" and end up with a similar sentence - and neither of the two = would be likely to convince the other side of the debate. A product is used in many places with vastly different characteristics. = A network is one instance with certain characteristics. Your comparison = doesn't work... Cheers, Sander --Apple-Mail=_6B32E787-CAC8-46A1-B978-E874CD8DC704 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY56VGAAoJEB7hi8LTyHy2nAsH/3OvoQQ6xpAvvCEf67Jtxspt TsW/dmUG2Aa3LDYFtoEz3wr4CtSikJlc5Vft3phPrxax9SCTVXkatL/Q9oPN+6Xn qrIfdrzL9GXIqgF7jl2HhklxHbvzugMGZtD79GM2UcCHxRRu4z7GmbBYDDDdyEMN 9vH3NyhNGIgXCeCJN+jgy0T5e91mbxnPYpBqfXBaWlmzjK6i8x6QH9dOiUzY6jWs c0kQShIDZKp9vVE9RosC+LMpVAKAAYh8To9c14pLjWLHJ+Rrzp99UdcUHBI+wUvw g+MAlJXYW9cPKJB6Ns6DGKdguEWXGz3TZsKV5Vo7tZhcSELNe3LeM8fWow04T6o= =yjBr -----END PGP SIGNATURE----- --Apple-Mail=_6B32E787-CAC8-46A1-B978-E874CD8DC704-- From nobody Fri Apr 7 07:44: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 8CF671294BE for ; Fri, 7 Apr 2017 07:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3ieZHFI-Bmxl for ; Fri, 7 Apr 2017 07:44:04 -0700 (PDT) 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 B14BC127333 for ; Fri, 7 Apr 2017 07:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4772; q=dns/txt; s=iport; t=1491576244; x=1492785844; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XN9SHm+Rot2Oj+eWbpsc7oRU1Y5FzLdj60mWKD3e5Kk=; b=QdgsdOXsLnLy8vAOabIY5em4mEWmAWC4KDg8X8llGS1pWRHelEiToHFX ODDa5P/33QIXgb/KvWhefNJUcrkJMsAWVLUK7bhO7hrzPk7AagrYYVWZZ t4i4wAsjiSTzOXVWxmpXY5hGrQjUuI/R67TkWy+iFc7rKrH+Apk7tytOo I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBupOdY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHjXCRQ4gajT2CDx8LhXgCGoM9PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQEhEToQBwQCAQgRBAEBAwIjAwICAh8GCxQBAgEFCAIEARIIiW8DD?= =?us-ascii?q?QgOqheCJoczDYMtAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4ozglGBVhktgm+?= =?us-ascii?q?CXwWPaoxTOwGGf4Mrg3GEM5FJiwCIfgEfOIEFWxVBhlt1iCuBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,165,1488844800"; d="scan'208";a="230143670" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 14:44:03 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v37Ei3wt011729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 14:44:03 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Apr 2017 09:44:02 -0500 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; Fri, 7 Apr 2017 09:44:02 -0500 From: "Bernie Volz (volz)" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohLAlJXdnN5j0uTKcn23s0z76G4fOCAgAAIq4CAADusQIAAAnWggAGFTwD//7SEsA== Date: Fri, 7 Apr 2017 14:44:02 +0000 Message-ID: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <434ba61e-5f20-1c95-e24c-f333cd593be2@gmail.com> <7ec53601956a4fbd9b60afe122c3aae1@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.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:44:08 -0000 PiBJIGFtIGFza2luZyBiZWNhdXNlIGl0IGlzIG5vdCBub3JtYWwgdGhhdCBteSBXaW5kb3dzIGNs aWVudCBjb250aW51ZXMgdG8gaXNzdWUgU29saWNpdHMgZm9yZXZlciBhZnRlciBoYXZpbmcgb2J0 YWluZWQgYSBTZXJ2ZXIgMyBtb250aHMgYWdvLg0KDQpJZGVhbGx5LCBkZXZpY2Ugc2hvdWxkIGJl IHVzaW5nIHRoZSBNJk8gYml0cyB0byBkZXRlcm1pbmUgd2hldGhlciBESENQdjYgaXMgc3VwcG9z ZWQgdG8gcnVuIG9yIG5vdC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFs ZXhhbmRyZSBQZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb21dIA0K U2VudDogRnJpZGF5LCBBcHJpbCAwNywgMjAxNyAxMDoxMyBBTQ0KVG86IEJlcm5pZSBWb2x6ICh2 b2x6KSA8dm9sekBjaXNjby5jb20+OyB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9w c10gTWFraW5nIFJETlNTIGEgTVVTVD8sIGh1bSB2Mg0KDQoNCg0KTGUgMDYvMDQvMjAxNyDDoCAy MjowMiwgQmVybmllIFZvbHogKHZvbHopIGEgw6ljcml0IDoNCj4+IEkgYW0gc3VnZ2VzdGluZyB0 byBhZGQgdGhhdCBsaWZldGltZSBpbiBESENQdjYuDQo+DQo+IFRoZXJlIGFscmVhZHkgaXMgLSBz ZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM0MjQyLg0KPiBJdCBk b2VzIGhhdmUgYSBtaW4gdmFsdWUgb2YgMTAgbWludXRlcy4NCj4NCj4gSSB0aGluayBhbnkgbGlm ZXRpbWUgaGFzIGlzc3VlcyBpbiB0aGUgZmFjdCB0aGF0IGlmIHNvbWV0aGluZyBoYXBwZW5zIA0K PiBiZWZvcmUgdGhhdCBsaWZldGltZSBleHBpcmVzLCB5b3UnbGwgaGF2ZSBvbGQgZGF0YS4NCj4N Cj4gVGhlIGxpZmV0aW1lIGlzIGdvb2QgYW5kIHNob3VsZCBiZSB1c2VkLCBidXQgdGhlIGNsaWVu dCBhbHNvIG5lZWRzIHRvIA0KPiB1c2Ugc29tZSBrbm93bGVkZ2Ugb2Ygd2hhdCdzIGhhcHBlbmVk IHRvIHRoZSBuZXR3b3JrIHRvIGRldGVybWluZSANCj4gd2hldGhlciBpdCBzaG91bGQgcmVmcmVz aCAoUkZDIDMzMTUvMzczNi8gZHJhZnQtaWV0Zi1kaGMtcmZjMzMxNWJpcyANCj4gaGF2ZSBzb21l IGNvbmRpdGlvbnMsIHBlcmhhcHMgdGhleSBhcmUgaW5jb21wbGV0ZSkuDQoNCldlbGwsIHdoYXQg ZXhhbXBsZSBvZiBrbm93bGVkZ2UgYWJvdXQgbmV0d29yayBjaGFuZ2UgZG9lcyB0aGUgY2xpZW50 IG5lZWQgaW4gb3JkZXIgdG8gc3RvcCBpc3N1aW5nIFNvbGljaXRzPw0KDQpJIGFtIGFza2luZyBi ZWNhdXNlIGl0IGlzIG5vdCBub3JtYWwgdGhhdCBteSBXaW5kb3dzIGNsaWVudCBjb250aW51ZXMg dG8gaXNzdWUgU29saWNpdHMgZm9yZXZlciBhZnRlciBoYXZpbmcgb2J0YWluZWQgYSBTZXJ2ZXIg MyBtb250aHMgYWdvLg0KDQpBbGV4DQoNCj4NCj4gLSBCZXJuaWUNCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XSANCj4gT24gQmVoYWxmIE9mIEFsZXhhbmRyZSBQZXRyZXNjdSBTZW50Og0KPiBUaHVyc2RheSwg QXByaWwgMDYsIDIwMTcgMzo1MCBQTSBUbzogdjZvcHNAaWV0Zi5vcmcgU3ViamVjdDogUmU6DQo+ IFt2Nm9wc10gTWFraW5nIFJETlNTIGEgTVVTVD8sIGh1bSB2Mg0KPg0KPg0KPg0KPiBMZSAwNi8w NC8yMDE3IMOgIDE4OjM4LCBUb3JlIEFuZGVyc29uIGEgw6ljcml0IDoNCj4+ICogRXJpayBLbGlu ZQ0KPj4NCj4+PiBBcyBhIHZlbmRvciBvZiBhIGRldmljZSB0aGF0IGlzIHNvbWV0aW1lcyBhIHJv dXRlciBJIGFtIG9wcG9zZWQgdG8sIA0KPj4+IGFuZCBoYXZlIHByZWNpc2VseSB6ZXJvIGludGVy ZXN0aW5nIGluLCBpbXBsZW1lbnRpbmcgYSBESENQdjYgcmVsYXkgDQo+Pj4gb3Igc2VydmVyIGZ1 bmN0aW9uLiAgSXQgYWRkcyBub3RoaW5nDQo+Pg0KPj4gVW0sIMKrYWRkcyBub3RoaW5nwrssIHJl YWxseT8NCj4+DQo+PiBUbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsIERIQ1B2NiBpcyB0aGUg Km9ubHkqIHdheSB0byBwcm92aXNpb24NCj4+ICBJUHY2IG5hbWUgc2VydmVycyBvbnRvIGhvc3Rz IHJ1bm5pbmcgTWljcm9zb2Z0IFdpbmRvd3MuDQo+DQo+IFlFcy4gIEJ1dCBpdCBoYXMgZHJhd2Jh Y2tzLCBhbmQgc2hvdWxkIGJlIGltcHJvdmVkLg0KPg0KPiBJdCBsYWNrcyBhIGxpZmV0aW1lLiAg VGhlIHNlcnZlciBpcyB0aGVyZSBpbnN0YWxsZWQgaW4gV2luZG93cyANCj4gZm9yZXZlciwgdW50 aWwgb3ZlcndyaXR0ZW4uDQo+DQo+IFRoYXQgbWFrZXMgdGhhdCBhZnRlciBnb2luZyB0byBJRVRG IG1lZXRpbmcgYW5kIGNvbWluZyBiYWNrIHRvIG15DQo+IG5vbi1JUHY2IG9mZmljZSBuZXR3b3Jr LCBteSBsYXB0b3Agc3RpbGwgaGFzIGEgREhDUHY2IHNlcnZlciANCj4gY29uZmlndXJlZCBzZWVu IHdpdGggImlwY29uZmlnIC9hbGwiLiAgSSBkb250IGxpa2UgdGhhdC4NCj4NCj4gV2VyZSBpdCB0 byBoYXZlIGEgbGlmZXRpbWUsIGl0IHdvdWxkIGV4cGlyZS4gIEJ1dCBuby4NCj4NCj4gSSBhbSBz dWdnZXN0aW5nIHRvIGFkZCB0aGF0IGxpZmV0aW1lIGluIERIQ1B2Ni4NCj4NCj4gQWxleA0KPg0K Pj4NCj4+IEluIG15IG9wZXJhdGlvbmFsIHJlYWxpdHksIMKrc3VwcG9ydCBmb3IgTWljcm9zb2Z0 IFdpbmRvd3MgaG9zdHPCuyBpcyAgDQo+PiBkaWFtZXRyaWNhbGx5IG9wcG9zaXRlIHRvIMKrbm90 aGluZ8K7Lg0KPj4NCj4+IFRoZSBleGFjdCBzYW1lIHBvaW50IGdvZXMgZm9yIEFuZHJvaWQgYW5k IFJETlNTLg0KPj4NCj4+IFRodXMsIHdoZW4gb3BlcmF0aW5nIGEgQllPRCBJUHY2IG5ldHdvcmss IGl0IGlzIGFic29sdXRlbHkgZXNzZW50aWFsIA0KPj4gdG8gc3VwcG9ydCAqYm90aCogUkROU1Mg YW5kIERIQ1B2Ni4gT3RoZXJ3aXNlIHlvdSdsbCBiZSBleGNsdWRpbmcgYSANCj4+IHNpZ25pZmlj YW50IGFtb3VudCBvZiBkZXZpY2VzIGZyb20gYmVpbmcgYWJsZSB0byB1c2UgeW91ciBuZXR3b3Jr Lg0KPj4NCj4+IFRvcmUNCj4+DQo+PiBQUzogQXBvbG9naWVzIHRvIHRoZSBXRyBhbmQgdGhlIGNo YWlycyBmb3IgdGhlIG1pc2RpcmVjdGVkIGh1bSB0byB0aGUgDQo+PiBsaXN0IGEgY291cGxlIG9m IG1lc3NhZ2VzIGVhcmxpZXIgaW4gdGhlIHRocmVhZC4gSXQgYXBwZWFycyBteSBNVUEgDQo+PiBk aWRuJ3QgaW50ZXJwcmV0IHRoZSBSZXBseS1UbyBoZWFkZXIgYXMgSSB0aG91Z2h0IGl0IHdvdWxk LiBNeSBiYWQuDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gdjZvcHMgbWFpbGluZyBsaXN0IA0KPj4gdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gdjZvcHMgbWFpbGluZyBsaXN0IA0K PiB2Nm9wc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo+DQo= From nobody Fri Apr 7 07:51: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 6102D1286B2 for ; Fri, 7 Apr 2017 07:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 JizFHUFquZjQ for ; Fri, 7 Apr 2017 07:51:07 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 C69ED129465 for ; Fri, 7 Apr 2017 07:51:04 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id t68so17295994iof.0 for ; Fri, 07 Apr 2017 07:51:04 -0700 (PDT) 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=2fXf9XvHSA5hB4dMoq+sqALlbfBZRUto59rLFfEU0+w=; b=0hDScIEQovUiQcpoHDsf0lWevC3r2AB9TRg59MSO6U3HGCoXYBzA8DwyfE1fIi81SB uw442R/x6D4RWnm5wgSDbeSuVii71OlPVrzBlLXYug26EiTYELWUvsSI1crDHpGMD0aJ eD5do98bJc4yr4ohT8sUwQ6J23H5/PbFCVIFg/9taD1A6I+o0kqgtheu8s0eCgZT6P3H sfZyHxCEjG61YysvrB8/kvsqjb1wYSSt7TQzGm4AndKck8Yy8lFXTKEbmZJrcZ0P+qXN f5hwY9j0Qa6obN1K1EOCBOEFMVz9uyWoHb9lM8LiLHlvEv7o+kj7iJUMFXj3Oo0qKd/2 yl+g== 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=2fXf9XvHSA5hB4dMoq+sqALlbfBZRUto59rLFfEU0+w=; b=pd6CfRJAJ/rJf2x/YFend1zyzWa9IOzJslLzwPOGDaiFMwHpuI3EerqGWu2Yx4dP5d dC4AJ+X7t2DkXmojPRIkdlNcLrlZmucpIRvjpitiMIBnIfuVJULj3gTANFHHpBc0wC2f KDjR+DDqc0xCmttHXyej+kp06dBfZEG3avP6ql2X6jzcn2y9fk5u/0kvM7K58GrYJSkW qQeebC6EehL17aORI2oGI/Jz/My0xk1emtPny8I+095VqyCez0M0+cI7nlNKq7HWd2Qv se2lqRGC7bq+zfLU/4vW4BGbXT7OE/W0OQS16P89i9urtlo82MB21AeZSS6bRN/oHDXt cPbQ== X-Gm-Message-State: AFeK/H0XpmdK1jFv4DEX9nfxBwlLVwJ4cWTdMKEH2Cl1ofbPFvno75Jy4AFZY9Avtaz7Vw== X-Received: by 10.107.142.136 with SMTP id q130mr38031511iod.169.1491576664123; Fri, 07 Apr 2017 07:51:04 -0700 (PDT) Received: from [172.19.131.119] ([12.130.117.88]) by smtp.gmail.com with ESMTPSA id r203sm11859279itc.5.2017.04.07.07.50.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:51:03 -0700 (PDT) From: Ted Lemon Message-Id: <8B76C488-526A-4C1B-84BF-A0F23AF5A1A3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_86BF0453-85C3-49DF-A3BA-7D4F7ACA4211" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 07:50:33 -0700 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB163AC@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Philip Homburg , IPv6 Ops WG To: "STARK, BARBARA H" References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> <2D09D61DDFA73D4C884805CC7865E6114DB163AC@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:51:09 -0000 --Apple-Mail=_86BF0453-85C3-49DF-A3BA-7D4F7ACA4211 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 7, 2017, at 6:30 AM, STARK, BARBARA H wrote: > So since nodes already have a SHOULD for DHCPv6 address and other = configuration info, and there is strong opposition to making it a MUST, = what more does the node doc need to say about DHCPv6 in order to achieve = the above-requested pony? Sorry, the pony is "MUST", not "SHOULD". --Apple-Mail=_86BF0453-85C3-49DF-A3BA-7D4F7ACA4211 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 7, 2017, at 6:30 AM, STARK, BARBARA H <bs7652@att.com> = wrote:
So since nodes = already have a SHOULD for DHCPv6 address and other configuration info, = and there is strong opposition to making it a MUST, what more does the = node doc need to say about DHCPv6 in order to achieve the = above-requested pony?

Sorry, the pony is "MUST", not "SHOULD".

= --Apple-Mail=_86BF0453-85C3-49DF-A3BA-7D4F7ACA4211-- From nobody Fri Apr 7 07: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 E422E120725 for ; Fri, 7 Apr 2017 07:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 KwP-60BFZk5S for ; Fri, 7 Apr 2017 07:52:09 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 5898D1286B2 for ; Fri, 7 Apr 2017 07:52:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v37Eq7FE000703 for ; Fri, 7 Apr 2017 16:52:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7ABA6206BDB for ; Fri, 7 Apr 2017 16:52:07 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 720C3206B9E for ; Fri, 7 Apr 2017 16:52:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v37Eq7YE017272 for ; Fri, 7 Apr 2017 16:52:07 +0200 To: v6ops@ietf.org References: <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> <2D09D61DDFA73D4C884805CC7865E6114DB163E4@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Alexandre Petrescu Message-ID: Date: Fri, 7 Apr 2017 16:51:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB163E4@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:52:11 -0000 Le 07/04/2017 à 15:36, STARK, BARBARA H a écrit : [...] > Focus on the enterprise routers. Those ar the operators asking for > v6ops help. In an IPv4-only Enterprise network I have not seen DNS-in-RA, because there were no RAs. But until full IPv6 arrives, the computers already chatter IPv6. In addition to ICMPv6 messaging (NS, NA, RS, MLD) and DHCPv6 Solicit, there is also large UDPv6 traffic made of mDNS, LLMNR, SSDP NOTIFY, and WS-Discovery. So, similarly to contemplating DNS in RA, one may wonder whether to put in RS/RA any one of these name-related activities implemented by the above protocols: - reverse resolution of servers of well-known services - direct resolution like IN A web proxy auto-discovery protocol (wpad) - WebServices Discovery - even some things about 'googlecast'. In same vein, similarly to contemplating RA eliminating DHCP, one may wonder whether DNS-in-RA will make disappear these protocols (mDNS, LLMNR, SSDP NOTIFY, WS-Discovery) from Enterprise networks. Alex From nobody Fri Apr 7 07:53: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 D5EB7129415 for ; Fri, 7 Apr 2017 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 bls7drvYNRB2 for ; Fri, 7 Apr 2017 07:53:52 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 E6E60120725 for ; Fri, 7 Apr 2017 07:53:51 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id y18so120738219itc.0 for ; Fri, 07 Apr 2017 07:53:51 -0700 (PDT) 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=yImAmed/vMQpiKFBOXvs0ESggtYF7fADdrUnrW/6Cyo=; b=EV1YB2F6Vzh+0o2BzudQ77nGFroACajAOIW+djbs1K97BTNyN+RK3GmhxTW7Xz482i 17uOnylLi5WmWdqt2f7dS4tlgzFxyMPnYKCI/nCQZ7WZLLwhPcQuTxfVynfoE03CgbD7 1o3DAYGjZ1IYZua5DG1BWxbMxdIW6pArJ/BiuRpUTjl5TLCn1AbSnH/lDBXEFTwiZmxJ Xsl8VRNx/zSeG4ChRBE+n/saalW/HTVuMSWqhXz5x7mYl9a79wNIwfHOAYMzWRMweReH 1gIsVb5XPKlkU4Xydm6BSdR5FAyddE8la+eR02MO8p+bPgLgHjUTJ2VuTgIRieCSYy62 CfZA== 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=yImAmed/vMQpiKFBOXvs0ESggtYF7fADdrUnrW/6Cyo=; b=BPu1NlNhxcrN7KYTAfPt5s8fVK7OLN6IQjGK4EKbSUYpgsDjfGkAf7ylq2RuVXsS5q 25hB/8a6cWc2yEt+FRLNmUeXibXazjgHC1T4GC7upvXvttT8rigBnxA3y6drdrG1W84i tA5BDZcC69Dm9j58Tk1sVfEuGGghqOheghYx/9vT8py2GhmR4eNei8XNtOMUgxCnTrbZ PHJwUN5tDUZ/Xp/fAeTGPh3Z6QvlaJQT4rqmAyH9pczY/fcbNFdsgcpMfe0sNqH4FeiP ijp9EHvJWrrlEH2Hohgu9eilZmma+BKsp8GV6s53psCDCFCAht/CVkabGq24evOC6MnQ oJ8A== X-Gm-Message-State: AFeK/H1AzAbxkJ8/UpRq4PqGdF55A83e1U3pYrZOSCaRAzEB8+5PfFqB uyiwpvAkZzFUVw6Q+U4= X-Received: by 10.36.7.129 with SMTP id f123mr32055768itf.120.1491576831239; Fri, 07 Apr 2017 07:53:51 -0700 (PDT) Received: from [172.19.131.119] ([12.130.117.88]) by smtp.gmail.com with ESMTPSA id f19sm2496178itf.19.2017.04.07.07.53.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:53:50 -0700 (PDT) From: Ted Lemon Message-Id: <37F80144-58B7-4061-B73B-8F7F56ECAD15@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F76D377D-65EB-41B5-BECB-3F14BF6DC0AA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 07:53:38 -0700 In-Reply-To: Cc: v6ops@ietf.org To: Philip Homburg References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:53:54 -0000 --Apple-Mail=_F76D377D-65EB-41B5-BECB-3F14BF6DC0AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 7, 2017, at 6:58 AM, Philip Homburg = wrote: > You are now going to tell me that with all these options, there is no = space > for an option the enable DHCPv6 functionality when configuring a = hotspot? No, there's no way to explain it. And what exactly is it that you are = going to type in? The IP address of the DHCP server the relay is = supposed to forward to? The WPA stuff is pretty hairy, but it's actually required to get on the = network. A DHCP relay in a phone not only isn't required, but won't = work. --Apple-Mail=_F76D377D-65EB-41B5-BECB-3F14BF6DC0AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 7, 2017, at 6:58 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
You are now going to tell me that =  with all these options, there is no space
for an option the enable DHCPv6 functionality = when configuring a hotspot?

No, there's no way to explain it.   And = what exactly is it that you are going to type in?   The IP address = of the DHCP server the relay is supposed to forward to?

The WPA stuff is pretty = hairy, but it's actually required to get on the network.   A DHCP = relay in a phone not only isn't required, but won't work.

= --Apple-Mail=_F76D377D-65EB-41B5-BECB-3F14BF6DC0AA-- From nobody Fri Apr 7 07:54: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 53F00120725 for ; Fri, 7 Apr 2017 07:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 zqMinN-nFQaf for ; Fri, 7 Apr 2017 07:54:56 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 820191287A0 for ; Fri, 7 Apr 2017 07:54:56 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 19so24726908itj.1 for ; Fri, 07 Apr 2017 07:54:56 -0700 (PDT) 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=fwad5hmr78OXWfmsLm84cZKR6smQQCGzsmIZne06xkA=; b=DuWWGrjFRyzz4N0M1gLKTP8DdkTzNdjGMEZIV5oqozF8qwof5JAvTzJlCaqA07S7SL wkW8PYiroqgX/OVCeX5TxodPcadIzgxQmU4T56i5SmHYHYNHF4tIV/I4crd8FcuCA/xQ NqgZtfo1TOP7Gochskc8vaE08D3aZFm84e9Ay1omycEO+18L6QImwqa8JYO3AettXSSV f++icVP/1N8FDvvNkgj1paFAE9a09jQAdg5EQzKe70fiZNKuMAro6uTDwCExYubX4T18 kw/9y7kH7II5VNpfIvuVhdviHUlJTVJIDQ3YUjEYuq7BJ1XMnknJi5sdo8hgMGd2lWQp lj+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 :in-reply-to:cc:to:references; bh=fwad5hmr78OXWfmsLm84cZKR6smQQCGzsmIZne06xkA=; b=IEiZLSsrUOcIuZf8eB0pP9zuFkFBL26jLjPyP3jd7eyw7/hBHavUzX3WLrrH1xC4YC 3M7Z1w6XlfwfvQTwZ/Pr1SNAlRgNfQKZ2fGiDEOaKr7j7/VrLjwCnfv/sFNATIjN+u4J nVj5yPtOyoqmwywXTpY9DC2GilmiRBablk3lnWvOhu5fF9CQT/QByrq50wMShNm43Z7N /pjQ6weCZZt+or4NbswagWqWc8Ci/utpEGiFgBHQQ06HMiLH/qvUehcCkJFTQQaQ4tiV xomogVjcgl9jvQTwrmKc0vR/unIV8DQClctCKf6IVAi6fRTfKMbmP6PsttgSy7HdWhc0 nlug== X-Gm-Message-State: AN3rC/6Qo5KmuJWurDb79isitbkqMN83jVvb+kzSUR7L5MIjd8ME9pZy+ja+EI6PgdVhDw== X-Received: by 10.36.253.73 with SMTP id m70mr1994016ith.19.1491576895950; Fri, 07 Apr 2017 07:54:55 -0700 (PDT) Received: from [172.19.131.119] ([12.130.117.88]) by smtp.gmail.com with ESMTPSA id k68sm2508165iod.13.2017.04.07.07.54.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:54:55 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D924FAD7-310A-4417-80AE-C448C369D4C7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 07:54:43 -0700 In-Reply-To: Cc: v6ops@ietf.org To: Philip Homburg References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:54:58 -0000 --Apple-Mail=_D924FAD7-310A-4417-80AE-C448C369D4C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 7, 2017, at 6:58 AM, Philip Homburg = wrote: > If you tell me all the details you are going to write down in your > specification for RDNSS then I'll just copy them can replace RDNSS = with > stateless DHCP DNS option. But that's just it, Phillip. RDNSS is _way_ simpler than DHCP. = You're already doing ND. So it really is just one line for RDNSS. --Apple-Mail=_D924FAD7-310A-4417-80AE-C448C369D4C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 7, 2017, at 6:58 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
If you tell me all the details you are = going to write down in your
specification for = RDNSS then I'll just copy them can replace RDNSS with
stateless DHCP DNS option.

But = that's just it, Phillip.   RDNSS is _way_ simpler than DHCP.   = You're already doing ND.   So it really is just one line for = RDNSS.

= --Apple-Mail=_D924FAD7-310A-4417-80AE-C448C369D4C7-- From nobody Fri Apr 7 08:05: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 DA35D120725 for ; Fri, 7 Apr 2017 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 5DUOnVMjpjjQ for ; Fri, 7 Apr 2017 08:05:52 -0700 (PDT) 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 1241E1270A0 for ; Fri, 7 Apr 2017 08:05:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwVSQ-0000GjC; Fri, 7 Apr 2017 17:05:50 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> <37F80144-58B7-4061-B73B-8F7F56ECAD15@fugue.com> In-reply-to: Your message of "Fri, 7 Apr 2017 07:53:38 -0700 ." <37F80144-58B7-4061-B73B-8F7F56ECAD15@fugue.com> Date: Fri, 07 Apr 2017 17:05:49 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:05:55 -0000 In your letter dated Fri, 7 Apr 2017 07:53:38 -0700 you wrote: >No, there's no way to explain it. And what exactly is it that you are >going to type in? The IP address of the DHCP server the relay is >supposed to forward to? For a tethering, the most useful is a stateless DHCP server that serves DNS and other options. In some cases, a DHCP relay can also be useful, so a dialog box that allows either a hostname or an IPv6 literal would be required. Note that for tethering having both a stateful DHCP server and a DHCP relay present but default disabled would be best. (Only now I realise that RFC 3315, Section 20 requires a DHCPv6 relay to default to the All_DHCP_Servers multicast address. Obviously, that doesn't make any sense. I'm not even aware in what context it would make sense.) From nobody Fri Apr 7 08:08: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 17E901270A0 for ; Fri, 7 Apr 2017 08:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 edeGjip-EMmC for ; Fri, 7 Apr 2017 08:08:36 -0700 (PDT) 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 9D35A1287A0 for ; Fri, 7 Apr 2017 08:08:33 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v37F5qvU045066; Fri, 7 Apr 2017 11:08:28 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 29p8jw0fj0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 11:08:28 -0400 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 v37F8RU0027490; Fri, 7 Apr 2017 11:08:28 -0400 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 v37F8GAH027351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 11:08:19 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 7 Apr 2017 15:08:08 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Fri, 7 Apr 2017 11:08:08 -0400 From: "STARK, BARBARA H" To: Lorenzo Colitti , Sander Steffann CC: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means Thread-Index: AQHSr5PF894NvLNn+0GQ99FSzNrLeqG6KpYAgAAOCoD//8F0UA== Date: Fri, 7 Apr 2017 15:08:07 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.161.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_12:, , 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-1702020001 definitions=main-1704070126 Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:08:38 -0000 Pj4gQXMgYSBuZXR3b3JrIG9wZXJhdG9yIEkgYW0gc2ljayBhbmQgdGlyZWQgb2YgYmVpbmcgZm9y Y2VkIGJ5IHZlbmRvcnMgdG8gDQo+PiBidWlsZCBteSBuZXR3b3JrIGFjY29yZGluZyB0byB0aGVp ciBvbmUgdHJ1ZSB2aXNpb24uIEkgcGVyZmVjdGx5IHdlbGwga25vdyANCj4+IHRoZSBjaGFyYWN0 ZXJpc3RpY3Mgb2YgdGhlIG5ldHdvcmsgSSdtIGRlcGxveWluZyBhbmQgSSdkIGxpa2UgdG8gYmUg dGhlIG9uZSANCj4+IGRlY2lkaW5nIG9uIGhvdyB0byBwcm92aXNpb24gaXQsIHRoYW5rIHlvdSB2 ZXJ5IG11Y2guDQoNCj4gSSBkb24ndCB0aGluayB0aGF0J3MgYSB1c2VmdWwgYXJndW1lbnQuIFlv dSBjb3VsZCBqdXN0IGFzIHdlbGwgcmVwbGFjZSAibmV0d29yayANCj4gb3BlcmF0b3IiIHdpdGgg InNvZnR3YXJlIGRldmVsb3BlciIgYW5kICJuZXR3b3JrIiB3aXRoICJwcm9kdWN0IiBhbmQgZW5k IA0KPiB1cCB3aXRoIGEgc2ltaWxhciBzZW50ZW5jZSAtIGFuZCBuZWl0aGVyIG9mIHRoZSB0d28g d291bGQgYmUgbGlrZWx5IHRvIGNvbnZpbmNlIA0KPiB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgZGVi YXRlLg0KDQpMb3JlbnpvIGlzIHJpZ2h0LiBXaGF0IEknbSByZWFkaW5nIGlzIHRoYXQgc29tZSBl bnRlcnByaXNlIG9wZXJhdG9ycyB3YW50IHRvIHVzZSBJRVRGIHRvIHRyeSB0byBmb3JjZSBHb29n bGUgdG8gaW1wbGVtZW50IERIQ1B2NiBjbGllbnQgaW4gQW5kcm9pZC4gDQpJdCBpcyBib3RoIGlu YXBwcm9wcmlhdGUgYW5kIGluZWZmZWN0aXZlIHRvIHRyeSB0byB1c2UgSUVURiB0byBidWxseSBh IHNpbmdsZSBjb21wYW55IGludG8gZG9pbmcgd2hhdCB5b3Ugd2FudCwganVzdCBiZWNhdXNlIGl0 J3Mgd2hhdCB5b3Ugd2FudC4NCkl0J3MgaW5lZmZlY3RpdmUgYmVjYXVzZSBJRVRGIFJGQ3MgdGhh dCBhbiBpbXBsZW1lbnRlciBkaXNhZ3JlZXMgd2l0aCBhbmQgZG9lc24ndCB3YW50IHRvIGltcGxl bWVudCBhcmUgaW5jcmVkaWJseSBlYXN5IHRvIGlnbm9yZS4gVHJ1c3QgbWUgLS0gSSBrbm93Lg0K SXQncyBpbmFwcHJvcHJpYXRlIGJlY2F1c2UgdGhhdCdzIG5vdCB3aGF0IElFVEYgc2hvdWxkIGJl IHVzZWQgZm9yLCBhbmQgaXQgbWFrZXMgSUVURiBsb29rIGJhZC4NClNvbWUgb3RoZXIgZW50ZXJw cmlzZXMgaGF2ZSBpbmRpY2F0ZWQgdGhleSBhcmUgd2lsbGluZyB0byBhY2NlcHQgQW5kcm9pZCBh cyBpcyAoanVzdCBiZWNhdXNlIHNvbWUgZW50ZXJwcmlzZXMgZG9uJ3Qgd2FudCB0bywgZG9lc24n dCBtZWFuIHRoYXQgYWxsIGRvbid0IHdhbnQgdG8pLiBCdXQgd2hhdCB0aGV5IG5lZWQgYXJlIGVu dGVycHJpc2Ugcm91dGVycyAodGhhdCB0aGV5IHByb2N1cmUsIGNvbnRyb2wsIGFuZCBhZG1pbmlz dGVyKSB0byBzdXBwb3J0IFJETlNTIGluIHNlbnQgUkFzLiBUaGV5IHdhbnQgSUVURiB0byBoZWxw IGdldCB0aGUgbWVzc2FnZSBvdXQgdG8gZW50ZXJwcmlzZSByb3V0ZXIgbWFudWZhY3R1cmVycyB0 aGF0IHRoaXMgaXMgaGlnaGx5IGRlc2lyZWQgKGUuZy4sIE1VU1QgaW4gYW4gSW5mb3JtYXRpb25h bCBlbnRlcnByaXNlIHJvdXRlciBSRkMpLiBFbnRlcnByaXNlIHJvdXRlciBtYW51ZmFjdHVyZXJz IGRvbid0IHNlZW0gdG8gYmUgZmlnaHRpbmcgdGhpcy4gRW50ZXJwcmlzZSBvcGVyYXRvcnMgd2hv IGRvbid0IHdhbnQgdG8gZG8gUkROU1MgY2FuIGRpc2FibGUgKG9yIG5vdCBlbmFibGUpIGl0LiBT byBmb3IgZW50ZXJwcmlzZSBvcGVyYXRvcnMsIGxldCdzIGZvY3VzIG9uIHByb3ZpZGluZyB0aGVt IHdpdGggcmVxdWlyZW1lbnRzIGZvciBlbnRlcnByaXNlIHJvdXRlcnMgdGhleSBjYW4gdGFrZSB0 byB0aGVpciBlbnRlcnByaXNlIHJvdXRlciB2ZW5kb3JzLg0KDQpJZiBzb21lIGVudGVycHJpc2Vz IHdhbnQgdG8gY29udGludWUgcHJlc3N1cmluZyBHb29nbGUsIHRoZXkgc2hvdWxkIHVzZSBtZXRo b2RzIGV4dGVybmFsIHRvIElFVEYuIFRoZXkgY2FuIHB1YmxpY2x5IHJlZnVzZSB0byBzdXBwbHkg dGhlaXIgZW1wbG95ZWVzIHdpdGggQW5kcm9pZCBkZXZpY2VzLCBnb2luZyBmb3J3YXJkIChvbGQg QW5kcm9pZCBkZXZpY2VzIHdpbGwgYmUgbG9uZyBnb25lIGJlZm9yZSBJUHY0IGRpc2FwcGVhcnMp LiBUaGV5IGNhbiB3cml0ZSBibG9ncyBlbmNvdXJhZ2luZyBjb25zdW1lcnMgdG8gc3RheSBhd2F5 IGZyb20gQW5kcm9pZCBkZXZpY2VzIHVudGlsIERIQ1B2NiBpcyBpbXBsZW1lbnRlZC4gVGhleSBj YW4gImFzc2lzdCIgcG9wdWxhciB0ZWNoIHNpdGVzIHdpdGggYXJ0aWNsZXMuIFRoZXkgY2FuIHBh cnRpY2lwYXRlIGluIGVudGVycHJpc2UgY29tcGFueSB0cmFkZSBhc3NvY2lhdGlvbnMgdG8gdHJ5 IHRvIHNlbmQgYSB1bmlmaWVkIG1lc3NhZ2UgYWdhaW5zdCBlbnRlcnByaXNlIHVzZSBvZiBjdXJy ZW50IEFuZHJvaWQuIEV0Yy4gTm90IElFVEYuDQpCYXJiYXJhDQo= From nobody Fri Apr 7 08:14: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 738A9129455 for ; Fri, 7 Apr 2017 08:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 BEfQuo4-u7cq for ; Fri, 7 Apr 2017 08:14:14 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 F37DE1270A0 for ; Fri, 7 Apr 2017 08:14:13 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v37F5om0046178; Fri, 7 Apr 2017 11:14:09 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 29p6ujfh49-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 11:14:08 -0400 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 v37FE73C001267; Fri, 7 Apr 2017 11:14:07 -0400 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 v37FE1Ii001168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 11:14:01 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 7 Apr 2017 15:13:48 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Fri, 7 Apr 2017 11:13:48 -0400 From: "STARK, BARBARA H" To: Ted Lemon CC: Philip Homburg , IPv6 Ops WG Thread-Topic: [v6ops] Making RDNSS a MUST?, hum v2 Thread-Index: AQHSrohJPytzlZ90JUCxvg9piYpj0aG4bByAgAAIrICAABMJgIAARnoAgAABUoCAAAGpAIAAAN2AgAE9QYD//84VyoAAQ22A//++PCeAAER/gP//vZdwAAwsa4AAB7p30A== Date: Fri, 7 Apr 2017 15:13:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB1653F@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> <2D09D61DDFA73D4C884805CC7865E6114DB163AC@GAALPA1MSGUSRBF.ITServices.sbc.com> <8B76C488-526A-4C1B-84BF-A0F23AF5A1A3@fugue.com> In-Reply-To: <8B76C488-526A-4C1B-84BF-A0F23AF5A1A3@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.161.166] 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-04-07_12:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704070126 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:14:15 -0000 >> So since nodes already have a SHOULD for DHCPv6 address and other=20 >> configuration info, and there is strong opposition to making it a MUST,= =20 >> what more does the node doc need to say about DHCPv6 in order to=20 >> achieve the above-requested pony? > Sorry, the pony is "MUST", not "SHOULD". Foul! You deleted the preceding context, which was specifically in reply to= Philip Homburg saying: " The 'pony' is simply that all nodes SHOULD support the relevant bits of D= HCP." I realize that other people want different ponies. I was just trying to see= if Philip's pony was still outstanding wrt node requirements.=20 Barbara From nobody Fri Apr 7 08:24:24 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 5014012773A for ; Fri, 7 Apr 2017 08:24:22 -0700 (PDT) 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 9BItPYQDTLAY for ; Fri, 7 Apr 2017 08:24:21 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 770F2120725 for ; Fri, 7 Apr 2017 08:24:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwVkG-0000FkC; Fri, 7 Apr 2017 17:24:16 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> <2D09D61DDFA73D4C884805CC7865E6114DB163AC@GAALPA1MSGUSRBF.ITServices.sbc.com> <8B76C488-526A-4C1B-84BF-A0F23AF5A1A3@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DB1653F@GAALPA1MSGUSRBF.ITServices.sbc.com> In-reply-to: Your message of "Fri, 7 Apr 2017 15:13:47 +0000 ." <2D09D61DDFA73D4C884805CC7865E6114DB1653F@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 07 Apr 2017 17:24:15 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:24:22 -0000 > Foul! You deleted the preceding context, which was specifically in > reply to Philip Homburg saying: " The 'pony' is simply that all > nodes SHOULD support the relevant bits of DHCP." I realize that > other people want different ponies. I was just trying to see if > Philip's pony was still outstanding wrt node requirements. My pony is that wherever we require something related to RA/SLAAC/RDNSS we require a similar thing from DHCP. Note similar. I'm not saying a MUST has to be paired with a MUST. In many cases a SHOULD is perfectly fine. Also note that my pony allows for exceptions for technical contraints. No need for low power devices to implement both. No need to relay DHCP requests to a multicast address on a 3GPP link if the link specification says that that should not be done. From nobody Fri Apr 7 08:27: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 7AA82127BA3 for ; Fri, 7 Apr 2017 08:27:47 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 ahDMxIwv_Pq0 for ; Fri, 7 Apr 2017 08:27:45 -0700 (PDT) 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 8050612773A for ; Fri, 7 Apr 2017 08:27:45 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r69so78931062vke.2 for ; Fri, 07 Apr 2017 08:27:45 -0700 (PDT) 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=HAXHZIanegxNrPM92rKB2VU4NPwJYc4Q19IVt9AgXhQ=; b=st5v2i2thqeApAVXusB/tvu79mdSJmrPMbTbg6uf5UPCKvSTm/P2eM3TpchxDjB0C6 AEOwAkADWaT/iCfBG9cbXaCnXMmfJ894+0yygWBJuD1DS07CXbsJOmlwGodf09OsbwJV dOQ/1YkzfVTVaBC9eAEBU1/HFFA/fjqejnp2cWaRIiKzTyrWBBcB3y6ESgloZPBJPrSI YcT2xdXZaxrD5c6q/vEGaeRfHEXogSFPUX9SVS7AlbpnDEn6CXDxCEQ1ZAMukxbEllcU IgsPtuhJRuhv1nND/V/T6o3IWX0+E4WeiQJd5/yuGk4HbXv7gW+qhx2l00lF9r4C4g3x cHxA== 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=HAXHZIanegxNrPM92rKB2VU4NPwJYc4Q19IVt9AgXhQ=; b=MX9oUDz+S2U2o3Em9kTM7CZMMpFmfhZPyzeOvccScq0k1so9LWyiLPgBdxYZ74pSqq 5itB4HYlhRi0WKfXcUMiwH8ysfhI3NWfspXLQgtH6sNn0RBVcUUdM1/drZv5EPltIgFp 7spwzkoUKciMJPpK9DtXXp2pnTXR6+jBFL+c/B3sFlBVRBMulkhX1bzIMQf5FHXi0FaL trdLmFI2NgTLOkJA/PhJkFw9vqWYq+CJ2qrd41sr5jicVNOZM1iSdLK15ONqGixJQ1Um auHOJNmUEdygH2koeNBSrBs3ooZ5RtEJ3rbQFQk/fNIFXhCcv+0OdoYQlnt3y+Je/FgI wR3A== X-Gm-Message-State: AFeK/H1jZt/u03w0EHdkVm21MKHtTflIi/W5Efh9nrI2nor1Bz/7GjQHwVQWbT1W61RhzuGqJ6XOlpiQN0sozirx X-Received: by 10.159.32.71 with SMTP id 65mr21780015uam.72.1491578864374; Fri, 07 Apr 2017 08:27:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 08:27:23 -0700 (PDT) In-Reply-To: <69761DA6-9671-4C0D-BE05-AC8208D5B883@steffann.nl> References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <69761DA6-9671-4C0D-BE05-AC8208D5B883@steffann.nl> From: Lorenzo Colitti Date: Sat, 8 Apr 2017 00:27:23 +0900 Message-ID: To: Sander Steffann Cc: Fernando Gont , IPv6 Operations Content-Type: multipart/alternative; boundary=94eb2c03e8b85ddc57054c954474 Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:27:47 -0000 --94eb2c03e8b85ddc57054c954474 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 11:42 PM, Sander Steffann wrote: > A product is used in many places with vastly different characteristics. A > network is one instance with certain characteristics. Your comparison > doesn't work... > Actually it does. Those networks don't need to use a different provisioning protocol. The proof is the fact that in IPv4 they all use pretty much the same one: DHCPv4. I think it's likely we'll eventually end up with only one provisioning protocol in IPv6, too. The point I think many are missing here is that if we want end-to-end connectivity. we'd better hope that that protocol is not DHCPv6. The reason this is important is simple: DHCPv6 is fundamentally not good at to updating information, because it's a pull model. But end-to-end connectivity requires that the endpoints know what's going on. So If you want end-to-end, you have exactly two options: 1. The network doesn't change. 2. When the network changes, you can tell the endpoints what changed. If the network changes, and you can't tell the endpoints what changed, then your only option is to break end-to-end. We've probably all forgotten how end-to-end works because for the last years/decades, the dominant networking technology was IPv4, and in most networks, IPv4 stopped providing end to end years or decades ago. DHCPv4 is absolutely fine if all you want to do is return 192.168.1.1 and 192.168.1.1 never changes, or if you return an IPv4 address in PI space, and that never changes. But if we want to bring end-to-end back with IPv6, we need to re-learn how to build end-to-end networks. You can't do that with DHCPv6. --94eb2c03e8b85ddc57054c954474 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 11:42 PM, Sander Steffann <sander@steffann.nl>= wrote:
A produ= ct is used in many places with vastly different characteristics. A network = is one instance with certain characteristics. Your comparison doesn't w= ork...

Actually it does. Those networks= don't need to use a different provisioning protocol. The proof is the = fact that in IPv4 they all use pretty much the same one: DHCPv4.
=
I think it's likely we'll eventually end up with onl= y one provisioning protocol in IPv6, too. The point I think many are missin= g here is that if we want end-to-end connectivity. we'd better hope tha= t that protocol is not DHCPv6.

The reason this is = important is simple: DHCPv6 is fundamentally not good at to updating inform= ation, because it's a pull model. But end-to-end connectivity requires = that the endpoints know what's going on. So If you want end-to-end, you= have exactly two options:
  1. The network doesn't change= .
  2. When the network changes, you can tell the endpoints what changed= .
If the network changes, and you can't tell the endpoint= s what changed, then your only option is to break end-to-end.

We've probably all forgotten how end-to-end works bec= ause for the last years/decades, the dominant networking technology was IPv= 4, and in most networks, IPv4 stopped providing end to end years or decades= ago. DHCPv4 is absolutely fine if all you want to do is return 192.168.1.1= and 192.168.1.1 never changes, or if you return an IPv4 address in PI spac= e, and that never changes.

But if we want to bring= end-to-end back with IPv6, we need to re-learn how to build end-to-end net= works. You can't do that with DHCPv6.
--94eb2c03e8b85ddc57054c954474-- From nobody Fri Apr 7 08: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 3B47B1294B8 for ; Fri, 7 Apr 2017 08:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zUumz_DnSuxH for ; Fri, 7 Apr 2017 08:57:37 -0700 (PDT) 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 4E6EE1293D6 for ; Fri, 7 Apr 2017 08:57:37 -0700 (PDT) Received: from [IPv6:2a02:c7d:316d:1c00:918:7e63:13c4:9496] (unknown [IPv6:2a02:c7d:316d:1c00:918:7e63:13c4:9496]) (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 560B7800A4; Fri, 7 Apr 2017 17:57:35 +0200 (CEST) To: "STARK, BARBARA H" , Lorenzo Colitti , Sander Steffann References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: IPv6 Operations From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <8a870ce8-cf7c-f498-c805-02e26514cfcc@si6networks.com> Date: Fri, 7 Apr 2017 16:56:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:57:40 -0000 On 04/07/2017 04:08 PM, STARK, BARBARA H wrote: > > If some enterprises want to continue pressuring Google, they should > use methods external to IETF. They can publicly refuse to supply > their employees with Android devices, going forward (old Android > devices will be long gone before IPv4 disappears). They can write > blogs encouraging consumers to stay away from Android devices until > DHCPv6 is implemented. They can "assist" popular tech sites with > articles. They can participate in enterprise company trade > associations to try to send a unified message against enterprise use > of current Android. Etc. Not IETF. Barbara I don't think this discussion is about pressuring anyone. It's about a situation in which operators and users are paying the price for a battle between vendors. I want to be able to deploy an IPv6 network that supports at least the major OSes, and don't find it encouraging to have to add duplicate functionality because different router and client OS implement mismatching subsets of the possible mechanisms to get the network running. That's an operational problem on which this wg should have a say. 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 Apr 7 09:03: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 0806D1294BC for ; Fri, 7 Apr 2017 09:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mOWvb0FRMmPP for ; Fri, 7 Apr 2017 09:03:40 -0700 (PDT) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFF01294B8 for ; Fri, 7 Apr 2017 09:03:38 -0700 (PDT) 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 v37G3bj0019683 for ; Fri, 7 Apr 2017 12:03:37 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v37G3bj0019683 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1491581017; bh=vmg6Y8DQkMowXxcMxnV7e4t5HsJZz2hElSUw1Ft8Kwc=; h=Date:From:To:Subject:References:In-Reply-To; b=NDTwQ1tB41pE09TLhIsOF2y7SdH7dWEdw21wC+iZbhmsSisUJqYYaSsGaCkr7FLQR Gx6gZsPwyxeVk9kMx35dLJv8YXkg0JNaUrXmp0Xilgt1T1C2SP2lNy323whiDeYXY/ kBvBA6Se2Dbzl5n4kl0ocJdNEMKdkucNS6KqWfqw= 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 v37G3buL019680 for ; Fri, 7 Apr 2017 12:03:37 -0400 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 v37G3a5C024549 for ; Fri, 7 Apr 2017 12:03:37 -0400 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 8C139E0F5E; Fri, 7 Apr 2017 12:03:36 -0400 (EDT) Date: Fri, 7 Apr 2017 12:03:36 -0400 From: Chuck Anderson To: v6ops@ietf.org Message-ID: <20170407160336.GN4764@angus.ind.wpi.edu> References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <69761DA6-9671-4C0D-BE05-AC8208D5B883@steffann.nl> 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=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_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, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 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_PHRASE1_B 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, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:03:43 -0000 On Sat, Apr 08, 2017 at 12:27:23AM +0900, Lorenzo Colitti wrote: > On Fri, Apr 7, 2017 at 11:42 PM, Sander Steffann wrote: > > > A product is used in many places with vastly different characteristics. A > > network is one instance with certain characteristics. Your comparison > > doesn't work... > > > > Actually it does. Those networks don't need to use a different provisioning > protocol. The proof is the fact that in IPv4 they all use pretty much the > same one: DHCPv4. That's because DHCPv4 is flexible enough to support multiple different types of deployments. > I think it's likely we'll eventually end up with only one provisioning > protocol in IPv6, too. The point I think many are missing here is that if > we want end-to-end connectivity. we'd better hope that that protocol is not > DHCPv6. > > The reason this is important is simple: DHCPv6 is fundamentally not good at > to updating information, because it's a pull model. But end-to-end > connectivity requires that the endpoints know what's going on. So If you > want end-to-end, you have exactly two options: > > 1. The network doesn't change. > 2. When the network changes, you can tell the endpoints what changed. > > If the network changes, and you can't tell the endpoints what changed, then > your only option is to break end-to-end. > > We've probably all forgotten how end-to-end works because for the last > years/decades, the dominant networking technology was IPv4, and in most > networks, IPv4 stopped providing end to end years or decades ago. DHCPv4 is > absolutely fine if all you want to do is return 192.168.1.1 and 192.168.1.1 > never changes, or if you return an IPv4 address in PI space, and that never > changes. I run a /16 that is not NATed. With DHCPv4. Without the theoretical problems you pose. > But if we want to bring end-to-end back with IPv6, we need to re-learn how > to build end-to-end networks. You can't do that with DHCPv6. That is only one consideration out of many. RA doesn't support per-host configuration, centralized management/tracking, and separation of duties. DHCPv6 does support RECONFIGURE. DUIDs are not any more of a privacy concern than MAC addresses are. From nobody Fri Apr 7 09:32: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 9D522129515 for ; Fri, 7 Apr 2017 09:32:18 -0700 (PDT) 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, 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=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 6HD867F1k9Ub for ; Fri, 7 Apr 2017 09:32:16 -0700 (PDT) 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 903151294E5 for ; Fri, 7 Apr 2017 09:31:08 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id y18so578439wmh.0 for ; Fri, 07 Apr 2017 09:31:08 -0700 (PDT) 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=44KHJy43ex9sbivWkQpDrgslR+FZ/JCuKEBh4MvmHp8=; b=qrCF6dufT4TFNGkGSfpF0kSpTsuy4dYZGfyJcaZRr8pTbcMlbL5EhkRgfaCB9/ikLi Ojhy53vFHwzq0nJ2jzYi5aMGh4wiwkslao9wll14OqkGWS2Nqj3GR7LKB+Sc+2W+1Ruk PWlxIHglB4JItHves5dlizF4O8SwEssJD8vJtfqIn/xlzpnMwEhX+2peP78WQFNm/4B6 TNnSB8SZ3nR0ex7LeaNjTqaDBix+Ck+G8e/4OyqeU1F2G6pg+LNd3N+24qk4yPJh3hz+ rQ3Ne/1j/QBVewo1uDRH72FOumIvFibzQ4Nv1mamX7SiUxGzXdPlxo7lLB/I4eoneNFb Xh9A== 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=44KHJy43ex9sbivWkQpDrgslR+FZ/JCuKEBh4MvmHp8=; b=d0kpiIby5DoIPO+EiqBfUw+XiNpSsbhSsYcfDk7MzUwC93FcnWuK3iqJ2hJXWC2QMD c0DwY//BRBq+yZ426YW/GsK2Ogqhkkfm72ftfDKRolwoKhgLm34J+ml+RPwODSEt8RMi 1k0JrDZtjdLVB3sGezyJNiMsUiB0GJoA3c3nZELKl9SuDAnWaWO547Vvh0BFfDJKqsif 55otBW9Y04Sh8ZSuUg2UTu0CPtHkiK5yJ7xMSRiR+M09yz5wWC0b96kjAecY0u2jG+3l 2Kq99KzTL5C3VDzgvAL4/Y2hLW/PAwekkHPxv2ykrk0wHvyeBOFCuyCrgbqIa8uUPWRq 9yBg== X-Gm-Message-State: AN3rC/5sCmOM0s2YwoZgSYrM/gRcX5fheLuZ8BfiTdNWCuiu2IwfQLrb mauWcXv7RwvfZQ== X-Received: by 10.28.136.81 with SMTP id k78mr217626wmd.36.1491582667122; Fri, 07 Apr 2017 09:31:07 -0700 (PDT) Received: from 204.66.20.149.in-addr.arpa (204.66.20.149.in-addr.arpa. [149.20.66.204]) by smtp.gmail.com with ESMTPSA id o22sm6540922wro.45.2017.04.07.09.31.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 09:31:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 7 Apr 2017 09:31:04 -0700 Cc: Lorenzo Colitti , Sander Steffann , Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:32:19 -0000 > On Apr 7, 2017, at 8:08 AM, STARK, BARBARA H wrote: >=20 > What I'm reading is that some enterprise operators want to use IETF to = try to force Google to implement DHCPv6 client in Android.=20 > It is both inappropriate and ineffective to try to use IETF to bully a = single company into doing what you want, just because it's what you = want. For the record, I think there is also a subtext of bullying Microsoft = into implementing RDNSS, and I think Sander's complaint about vendors = trying to force their vision of the world has merit. Yes, there is an = attempted forcing function here. It goes both ways.= From nobody Fri Apr 7 09:35: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 240701294FA for ; Fri, 7 Apr 2017 09:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 shqxgXEx6jAV for ; Fri, 7 Apr 2017 09:35:36 -0700 (PDT) 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 BD33D124282 for ; Fri, 7 Apr 2017 09:35:33 -0700 (PDT) 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 v37GZ2m8010617; Fri, 7 Apr 2017 12:35:29 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 29pd1au85v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 12:35:29 -0400 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 v37GZRdp017040; Fri, 7 Apr 2017 12:35:28 -0400 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 v37GZLbm016970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 12:35:23 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 7 Apr 2017 16:35:16 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Fri, 7 Apr 2017 12:35:15 -0400 From: "STARK, BARBARA H" To: Fernando Gont , Lorenzo Colitti , Sander Steffann CC: IPv6 Operations Thread-Topic: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means Thread-Index: AQHSr5PF894NvLNn+0GQ99FSzNrLeqG6KpYAgAAOCoD//8F0UIAAWL+A///E4SA= Date: Fri, 7 Apr 2017 16:35:14 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB1666A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> <8a870ce8-cf7c-f498-c805-02e26514cfcc@si6networks.com> In-Reply-To: <8a870ce8-cf7c-f498-c805-02e26514cfcc@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.161.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_14:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704070136 Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:35:39 -0000 PiBJIHdhbnQgdG8gYmUgYWJsZSB0byBkZXBsb3kgYW4gSVB2NiBuZXR3b3JrIHRoYXQgc3VwcG9y dHMgYXQgbGVhc3QgdGhlIG1ham9yDQo+IE9TZXMsIGFuZCBkb24ndCBmaW5kIGl0IGVuY291cmFn aW5nIHRvIGhhdmUgdG8gYWRkIGR1cGxpY2F0ZSBmdW5jdGlvbmFsaXR5DQo+IGJlY2F1c2UgZGlm ZmVyZW50IHJvdXRlciBhbmQgY2xpZW50IE9TIGltcGxlbWVudCBtaXNtYXRjaGluZyBzdWJzZXRz IG9mDQo+IHRoZSBwb3NzaWJsZSBtZWNoYW5pc21zIHRvIGdldCB0aGUgbmV0d29yayBydW5uaW5n Lg0KPiANCj4gVGhhdCdzIGFuIG9wZXJhdGlvbmFsIHByb2JsZW0gb24gd2hpY2ggdGhpcyB3ZyBz aG91bGQgaGF2ZSBhIHNheS4NCg0KVGhhdCdzIGFuIG9wZXJhdGlvbmFsIHByb2JsZW0gdGhhdCBJ U1BzIGZhY2VkIHllYXJzIGFnbyB3aGVuIHdyaXRpbmcgQ0Ugcm91dGVyIHJlcXVpcmVtZW50cy4g V2UgKElTUCBvcGVyYXRvcnMpIGRlY2lkZWQgdGhlIGNvcnJlY3QgYXBwcm9hY2ggd2FzIGZvciBD RSByb3V0ZXJzIHRvIGRlbGl2ZXIgRE5TIGluZm8gdmlhIFJETlNTIGFuZCBESENQdjYuIElTUHMg aGF2ZW4ndCBleHBlcmllbmNlZCBpc3N1ZXMgd2l0aCB0aGUgQ0Ugcm91dGVycyBkb2luZyB0aGlz LiBUaGUgQ0Ugcm91dGVyIHZlbmRvcnMgZGlkIG5vdCBvYmplY3Qgb3IgcHVzaCBiYWNrIChpLmUu LCB0aGV5IGRpZCBub3QgZmluZCBpdCB0b28gZGlmZmljdWx0IHRvIGRvKS4gVmFzdCBudW1iZXJz IG9mIGNvbnN1bWVycyBub3cgaGF2ZSBJUHY2IHdpdGhvdXQgZXZlbiBrbm93aW5nIGl0ICh0aGUg c2lnbiBvZiBhIHN1Y2Nlc3NmdWwgZGVwbG95bWVudCkuIFRoZSBkZWNpc2lvbiBoYXMgcHJvZHVj ZWQgbm8gb3BlcmF0aW9uYWwgaGVhZGFjaGVzLiBUaGUgZHVwbGljYXRlIGZ1bmN0aW9uYWxpdHkg aGFzIGNhdXNlZCBubyBwcm9ibGVtcy4gV2hpbGUgaGF2aW5nIGR1cGxpY2F0ZSBmdW5jdGlvbmFs aXR5IGltcGxlbWVudGVkIGFuZCBlbmFibGVkIGluIHRoZSByb3V0ZXIgbWF5IG5vdCBiZSAiZW5j b3VyYWdpbmciLCBpdCBpcyBub3Qgb3BlcmF0aW9uYWxseSBkaWZmaWN1bHQgdG8gZG8sIGFuZCB0 aGUgcm91dGVyIHZlbmRvcnMgZGlkIG5vdCBzdHJ1Z2dsZSB3aXRoIGltcGxlbWVudGluZyBpdC4N CkJhcmJhcmENCg== From nobody Fri Apr 7 09:50: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 18339129539 for ; Fri, 7 Apr 2017 09:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 asdaMoq3wBV8 for ; Fri, 7 Apr 2017 09:50:54 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 6130912942F for ; Fri, 7 Apr 2017 09:50:54 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=34708 helo=envy.e1.y.home) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cwX63-0001jb-W6; Fri, 07 Apr 2017 16:50:52 +0000 Date: Fri, 7 Apr 2017 18:50:46 +0200 From: Tore Anderson To: Lorenzo Colitti Cc: Brian E Carpenter , IPv6 Operations Message-ID: <20170407185046.569fede6@envy.e1.y.home> In-Reply-To: References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <20170407105253.44126515@envy.e1.y.home> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:50:57 -0000 * Lorenzo Colitti > On Fri, Apr 7, 2017 at 5:52 PM, Tore Anderson wrote: > > > You kicked off this thread calling for a MUST for routers to support > > RDNSS (I agree with you on that, for what it's worth). > > The reason I called this thread was for hosts, not routers. You asked for both, actually: https://mailarchive.ietf.org/arch/msg/v6ops/5JOK6RRzjNgSSMJBmBKPFrHluxY To be clear, I do support both. Having RDNSS in all (new) hosts and all (new) routers would indeed be an improvement, regardless of what (if anything) we say about stateless DHCPv6 at the same time. > The way I see it, a must for DHCPv6 is harmful because DHCPv6 is > technically inferior to RDNSS and thus would lead to regressions in > functionality (for which I have provided examples). A MUST for RDNSS > is not harmful in this way. Therefore, a MUST for RDNSS is a good > idea because a) it's the more capable protocol, and b) it provides a > guarantee of interoperability once old OSes have aged out. Having DHCPv6 service in the network can only possibly be harmful in this manner only if the hosts actually decide to make use of it. For example, Android hosts don't do DHCPv6, period. Regardless of what the network offers. Thus the Android users will be totally insulated from any of the perceived "DHCPv6 harm" or regressions. > I don't think there's a contradiction there, it's just that you and I > have different goals. You want everything to work everywhere, as soon > as possible, without IPv4, and are willing to accept suboptimal > outcomes in some parts of the network (like the regressions I > provided examples of), even if that would lead to a worse outcome in > the long term. That means you want DHCPv6, because you need Windows > to work. Indeed, I do think having current Windows hosts being completely unable to make use of an IPv6-only network is a much worse outcome, than having the same hosts being able to use the network while lacking a mechanism to easily change the assigned DNS server address on the fly. But having this today does not preclude working towards an RDNSS-only world long term, see below. > I want to the best outcome in the long term and am willing to wait > for it. That means I don't want DHCPv6, because for as long as IPv4 > is around it's not a necessity. [...] > I can see your point of view. But please do consider the effects on > the long-term flexibility of host configuration in the Internet of > encouraging a protocol (DHCPv6) that is both a) technically inferior > to the alternative and b) familiar to many network operators, some of > whom will choose it because it is familiar or easier and not because > it is better. I don't want us all to be running DHCPv6 20 years from > now, because it's suboptimal. I want us all to be running RDNSS, > because it's better. Acknowledging that stateless DHCPv6 is a necessity for pure IPv6 networks today does not preclude us from working towards eventually changing that: Android could behave like today, getting DNS servers from RDNSS only. This makes providing RDNSS a necessity for IPv6-only network operators, and insulates Android users from any possible "DHCPv6 harm". The Apple folks on this list have stated a preference for RDNSS, too, so although their nodes also support DHCPv6, perhaps they could be persuaded to give RDNSS information preference above DHCPv6 (assuming that's not already the case), to prevent the "DHCPv6 harm". For example, not bothering with acquiring/using DNS servers from DHCPv6 if a RDNSS option was present in the RA(s) received. Or perhaps even remove the stateless DHCPv6 client functionality entirely. Then you'd only need Microsoft to follow suit to reach critical mass. Who knows what they're planning... (I have noticed you've been dropping some hints that you might be better informed than the rest of us about this, but that doesn't really help us make any more informed decisions.) Only at this point, and after most of the current install base has been updated/replaced accordingly and RDNSS support has become ubiquitous, would it make sense to reconsider the new operational reality and state that having stateless DHCPv6 in the network for DNS server signaling has become entirely optional/redundant. Tore From nobody Fri Apr 7 09:57: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 B0C8C1296CF for ; Fri, 7 Apr 2017 09:57:32 -0700 (PDT) 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 T5hIn4j5Lk05 for ; Fri, 7 Apr 2017 09:57:30 -0700 (PDT) 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 F07DC12957C for ; Fri, 7 Apr 2017 09:57:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B93284A; Fri, 7 Apr 2017 18:57:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1491584245; bh=x/Omxci+hR9IduqvtgneY+TQm8LVPgPpW0Q9orm8XiI=; b=B zPajljB9Ov3nY1WxBC5GhGak7+w1sfvUA3N3BTS84NgiI86t5mEfsVdYRuCbqADg 4AhRozG+02q8Hk6p7CZifwAgDGk/+po35N46OEhe1vNjuw++I1hspYqqDQikpiWc uoT4+M4/pFRJzep//ct9ab1MFjI9ccqBUYdKIm+HW4= 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 DEFwUarqWdtb; Fri, 7 Apr 2017 18:57:25 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:9300:d136:71c7:3b5e:24d7] (unknown [IPv6:2a02:a213:a300:9300:d136:71c7:3b5e:24d7]) (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 6A59C49; Fri, 7 Apr 2017 18:57:25 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann X-Mailer: iPhone Mail (14E277) In-Reply-To: Date: Fri, 7 Apr 2017 18:57:24 +0200 Cc: "STARK, BARBARA H" , Lorenzo Colitti , Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Fred Baker Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:57:33 -0000 Hi Fred, > For the record, I think there is also a subtext of bullying Microsoft into= implementing RDNSS, and I think Sander's complaint about vendors trying to f= orce their vision of the world has merit. Yes, there is an attempted forcing= function here. It goes both ways. Thank you, that is indeed what I meant. I want the operator to be in control= of how to run the network, without being forced by vendors. There's indeed s= ome pushing, but it's merely pushing back after having been pushed for too l= ong... Cheers, Sander From nobody Fri Apr 7 09:58: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 AE938129582 for ; Fri, 7 Apr 2017 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=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 aRUCRfa1WmvC for ; Fri, 7 Apr 2017 09:58:15 -0700 (PDT) Received: from atl4mhob21.registeredsite.com (atl4mhob21.registeredsite.com [209.17.115.115]) by ietfa.amsl.com (Postfix) with ESMTP id 9621412945C for ; Fri, 7 Apr 2017 09:58:15 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob21.registeredsite.com (8.14.4/8.14.4) with ESMTP id v37GwDbp033028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Apr 2017 12:58:14 -0400 Received: (qmail 11528 invoked by uid 0); 7 Apr 2017 16:58:13 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 7 Apr 2017 16:58:11 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 07 Apr 2017 12:58:06 -0400 From: Lee Howard To: Lorenzo Colitti , Sander Steffann CC: Fernando Gont , IPv6 Operations Message-ID: Thread-Topic: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3574414690_147896784" Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:58:18 -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_3574414690_147896784 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: v6ops on behalf of Lorenzo Colitti Date: Friday, April 7, 2017 at 10:22 AM To: Sander Steffann Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means > On Fri, Apr 7, 2017 at 10:32 PM, Sander Steffann wrote: >> As a network operator I am sick and tired of being forced by vendors to build >> my network according to their one true vision. I perfectly well know the >> characteristics of the network I'm deploying and I'd like to be the one >> deciding on how to provision it, thank you very much. > > I don't think that's a useful argument. You could just as well replace > "network operator" with "software developer" and "network" with "product" and > end up with a similar sentence - and neither of the two would be likely to > convince the other side of the debate. Is there an architectural principle you would appeal to, to resolve the conflict? Lee --B_3574414690_147896784 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable


From: v6ops <v6ops-bounces@ietf.org> on behalf of Lorenzo Colitti <= lorenzo@google.com>
Date: Friday, April 7, 2017 at 10:22 AM
To: Sander Steffann <sander@steffann.nl>
Cc: Fernando Gont <fgo= nt@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means

On Fri, Apr 7, 2017 a= t 10:32 PM, Sander Steffann <sander@steffann.nl> wrote:
As a network operator I am sick and tired of being forced = by vendors to build my network according to their one true vision. I perfect= ly well know the characteristics of the network I'm deploying and I'd like t= o be the one deciding on how to provision it, thank you very much.

I don't think that's a useful argument. You could jus= t as well replace "network operator" with "software developer" and "network"= with "product" and end up with a similar sentence - and neither of the two = would be likely to convince the other side of the debate.
<= /div>

Is there an architectural princ= iple you would appeal to, to resolve the conflict?

= Lee

--B_3574414690_147896784-- From nobody Fri Apr 7 10:14:53 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E66129582 for ; Fri, 7 Apr 2017 10:14:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149158529223.11171.12600171265401779922.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 10:14:52 -0700 From: IETF Secretariat Archived-At: Subject: [v6ops] Milestones changed for v6ops WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:14:52 -0000 Changed milestone "Describe a Translation solution for IPv6-only data centers", resolved as "Done". Changed milestone "Describe emerging IPv6 allocations to hosts", resolved as "Done". Changed milestone "Update RFC 6145 Translation in view of operational experience", resolved as "Done". Changed milestone "File report on behavior of IPv6 traffic with Extension Headers", resolved as "Done". Changed milestone "Describe routing choices and trade-offs for enterprise and service provider networks", set due date to July 2017 from March 2016. URL: https://datatracker.ietf.org/wg/v6ops/about/ From nobody Fri Apr 7 12:23:54 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5686C12894E for ; Fri, 7 Apr 2017 12:23:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149159303335.11183.3312553279817485410.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 12:23:53 -0700 From: IETF Secretariat Archived-At: Subject: [v6ops] Milestones changed for v6ops WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:23:53 -0000 Changed milestone "File recommendation on how to build a commercial WiFi network", set state to active from review, accepting new milestone. Changed milestone "Prefix for use by IPv4/IPv6 translators in a network", set state to active from review, accepting new milestone. Changed milestone "Adivce on use of ULAs in networks", set state to active from review, accepting new milestone, set description to "Advice on use of ULAs in networks". Changed milestone "Update RFC 7084 (IPv6 CE Requirements)", set state to active from review, accepting new milestone. Changed milestone "Update RFC 6555 with experience", set state to active from review, accepting new milestone. Changed milestone "Requirements for IPv6 Routers in a general purpose network", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/v6ops/about/ From nobody Fri Apr 7 13:16: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 83AE1126B7F for ; Fri, 7 Apr 2017 13:16:49 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 uTD-fiK9VDC1 for ; Fri, 7 Apr 2017 13:16:47 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 C32F71243FE for ; Fri, 7 Apr 2017 13:16:47 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id 21so76016037pgg.1 for ; Fri, 07 Apr 2017 13:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=aUWfuYK94eM+Z3K4WlLTb3cSzPdYZFSy8gZXX+KwQsI=; b=YX+z5DHCZ7MPySnqHNEEP9kxCKNAYzRyJPUsZY1Io/L2aIQrgz/UBOTM+mwvSOL+fX SanUzXH+SV90FqPkGmJ0wZNTB8dt1rHyWZunrW2+Sd+wfDxdVcriqslvb4AG6LQXed/I DZSC+2rpJGdMhpcH2iww0CSfV3UEu+Wv4+daXe50X1C/9XNxw6ReI1j3q1hV7YuVR01O UlH1GBiWiF/sdkEGrbi8XLd142bm/r8EsYtF9U0+L9khYggzUs055EuPY3Ej7b72YVZB u/2mP0WTr0nFgipWXlXM2wqt36KJiO9tUaCfBuhk1Y8NVYQOSYK0by1VlLV3aQEX6Cmv RNAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=aUWfuYK94eM+Z3K4WlLTb3cSzPdYZFSy8gZXX+KwQsI=; b=i96kLvnIfSYWKmDGNMPt2ssidQrZ/7rhUwae/lEGKRKw4vnzUDOLWKS/FR64BXdOfD QpZRsHtKKk/XNVAQ0wuCfzBiyMaAH9MLO6nVGXkrmooQhhnYROtlS/Pm06Tlu3+gCzZs 1foWZK9bAVpBWzeNSdjihVsCGUhTxLbLv/yz1IaKOAqPI2H3+H3dhYouTQtWSitNqofp SPm5RXysjM+L8pfJ2eYbnMHwFgY11SR/0lTprE+cqqJqSHL/am/eYEtGN+sNNq5ncK2g BDnBleXO2IrN8r9LbXQEOF3g7o74ZKuz5MCkF2zG/GBD+K8tgMgHxNW6T6ryQpIogFd7 lx3Q== X-Gm-Message-State: AFeK/H3I/RhYFFJE4rX1zHq/8nB7pFVYh5VEK34igEVzA4FvusdsmGfxAKjiO2FT0KorUM5o X-Received: by 10.98.163.79 with SMTP id s76mr42043070pfe.32.1491596207128; Fri, 07 Apr 2017 13:16:47 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id h14sm11153222pgn.64.2017.04.07.13.16.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 13:16:46 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_B13C2283-9DF7-4615-B489-471B61D68FD7" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 7 Apr 2017 13:16:45 -0700 References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <79CEE097-2DF9-492A-94E3-8E4F18056DB4@google.com> To: "v6ops@ietf.org WG" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:16:49 -0000 --Apple-Mail=_B13C2283-9DF7-4615-B489-471B61D68FD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 7, 2017, at 00:04, Lorenzo Colitti wrote: >=20 > One way around that is to cause a link down event. Obviously, hosts > should try to reconfigure all resources after a link down event. = Also > the ones they got through DHCP >=20 > That would disrupt all communications between clients on the hotspot = and make users unhappy. Not to mention an additional problem: hosts do a lot of potentially = undesirable things after a link-down event, e.g. roam to another SSID, = switch to their own cellular interface, etc. Some of those things end up = charging users money when they happen. --james woodyatt > --Apple-Mail=_B13C2283-9DF7-4615-B489-471B61D68FD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 7, 2017, at 00:04, Lorenzo Colitti <lorenzo@google.com> = wrote:

   One way = around that is to cause a link down event. Obviously, hosts
   should try to reconfigure all resources after a = link down event. Also
   the ones they got = through DHCP

That would disrupt all communications between clients = on the hotspot and make users unhappy.

Not to mention an additional problem: hosts do a = lot of potentially undesirable things after a link-down event, e.g. roam = to another SSID, switch to their own cellular interface, etc. Some of = those things end up charging users money when they happen.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_B13C2283-9DF7-4615-B489-471B61D68FD7-- From nobody Fri Apr 7 13:48: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 9AFA01205F0 for ; Fri, 7 Apr 2017 13:48:45 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 ZI0Gl6G6UFwe for ; Fri, 7 Apr 2017 13:48:43 -0700 (PDT) Received: from mta05.svc.cra.dublin.eircom.net (mta05.svc.cra.dublin.eircom.net [159.134.118.221]) by ietfa.amsl.com (Postfix) with SMTP id 68F9E128B8D for ; Fri, 7 Apr 2017 13:48:38 -0700 (PDT) Received: (qmail 7792 messnum 7345756 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 7 Apr 2017 20:48:35 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (HELO avas03) (213.94.190.15) by mta05.svc.cra.dublin.eircom.net (qp 7792) with SMTP; 7 Apr 2017 20:48:35 -0000 Received: from [192.168.1.6] ([86.45.37.230]) by Cloudmark Gateway with SMTP id wao7cTQEe5iSXwao7cTQNR; Fri, 07 Apr 2017 21:48:35 +0100 X-CNFS-Analysis: v=2.2 cv=M/09E24s c=1 sm=1 tr=0 a=kvhl2hrZG42DSHFjhA0PKA==:117 a=kvhl2hrZG42DSHFjhA0PKA==:17 a=AATv7NCgaQTBfzcxz48A:9 a=QEXdDO2ut3YA:10 a=YIFp4CTrripBJriUD-cA:9 a=5IZm_j6SvooPrpms:21 a=_W_S_7VecoQA:10 From: Ross Chandler Message-Id: <8EC7BC59-7292-4408-8C13-3527665C588D@eircom.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF5BCC07-B545-4B01-80BC-6DADB6D7B25E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 21:46:30 +0100 In-Reply-To: <20170407185046.569fede6@envy.e1.y.home> Cc: IPv6 Operations To: Tore Anderson References: <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <20170406192038.139ec505@envy.e1.y.home> <20170407105253.44126515@envy.e1.y.home> <20170407185046.569fede6@envy.e1.y.home> X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfM4CKY6lrAA/fdI2Hbztg0yoN2w/NzOZAAQMIWbDt4kj5Ifni6bAFp4IgnOKRwDiRGw0ubyqElzX8QHmE9jFDVx3tcTbxPawpqNXjdRjbvE9maqqp+X2 4AMFRaH4+SOQ2EQkysZpCjmte44BjT2XEVtOIDEw33ixX2Ndu1+bDpuMswBFiEKdJpV//rTTyxtp8Q== Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:48:46 -0000 --Apple-Mail=_FF5BCC07-B545-4B01-80BC-6DADB6D7B25E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Apr 2017, at 17:50, Tore Anderson wrote: >=20 > The Apple folks on this list have stated a preference for RDNSS, too, > so although their nodes also support DHCPv6, perhaps they could be > persuaded to give RDNSS information preference above DHCPv6 (assuming > that's not already the case), to prevent the "DHCPv6 harm". For > example, not bothering with acquiring/using DNS servers from DHCPv6 if > a RDNSS option was present in the RA(s) received. Or perhaps even > remove the stateless DHCPv6 client functionality entirely. Tried that using Google DNS in DHCPv6 and it looks like they put them = all in the list.=20 Perhaps there=E2=80=99s a cmdline tool for seeing the state of Happy = Eyeballs of DNS server addresses.=20 I have seen macOS not use name servers that are listed as Reachable here = when they don=E2=80=99t respond to DNS queries. $ scutil --dns DNS configuration =20 resolver #1 search domain[0] : home nameserver[0] : 2001:4860:4860::8888 nameserver[1] : 2001:4860:4860::8844 nameserver[2] : fe80::1%en0 nameserver[3] : 192.168.1.254 nameserver[4] : 192.168.1.254 if_index : 5 (en0) flags : Request A records, Request AAAA records reach : Reachable --Apple-Mail=_FF5BCC07-B545-4B01-80BC-6DADB6D7B25E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 7 Apr 2017, at 17:50, Tore Anderson <tore@fud.no> = wrote:

The Apple = folks on this list have stated a preference for RDNSS, too,
so although their nodes also support DHCPv6, perhaps they = could be
persuaded to give RDNSS information preference = above DHCPv6 (assuming
that's not already the case), to = prevent the "DHCPv6 harm". For
example, not bothering with = acquiring/using DNS servers from DHCPv6 if
a RDNSS option = was present in the RA(s) received. Or perhaps even
remove = the stateless DHCPv6 client functionality entirely.

Tried that = using Google DNS in DHCPv6 and it looks like they put them all in the = list. 
Perhaps there=E2=80=99s a cmdline tool for seeing = the state of Happy Eyeballs of DNS server addresses. 
I = have seen macOS not use name servers that are listed as Reachable here = when they don=E2=80=99t respond to DNS queries.

$ scutil --dns
DNS = configuration

 

resolver = #1
  search domain[0] : home
  = nameserver[0] : 2001:4860:4860::8888
  = nameserver[1] : 2001:4860:4860::8844
  = nameserver[2] : fe80::1%en0
  = nameserver[3] : 192.168.1.254
  = nameserver[4] : 192.168.1.254
  = if_index : 5 (en0)
  flags    : Request A = records, Request AAAA records
  = reach    : Reachable

= --Apple-Mail=_FF5BCC07-B545-4B01-80BC-6DADB6D7B25E-- From nobody Fri Apr 7 14: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 AF686127867 for ; Fri, 7 Apr 2017 14:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aKEIBt5YuAQS for ; Fri, 7 Apr 2017 14:11:45 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 04298120454 for ; Fri, 7 Apr 2017 14:11:45 -0700 (PDT) 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.ams1.isc.org (Postfix) with ESMTPS id CF45C24AE08; Fri, 7 Apr 2017 21:10:24 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1E90316007E; Fri, 7 Apr 2017 21:10:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0A0B7160083; Fri, 7 Apr 2017 21:10:25 +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 lO32LSvhNQit; Fri, 7 Apr 2017 21:10:24 +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 AFDEF16007E; Fri, 7 Apr 2017 21:10:24 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BE32F6B00B6E; Sat, 8 Apr 2017 07:10:21 +1000 (AEST) To: Lorenzo Colitti Cc: "STARK, BARBARA H" , IPv6 Operations , Tore Anderson From: Mark Andrews References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170406211206.DB8A76AA312B@rock.dv.isc.org> In-reply-to: Your message of "Fri, 07 Apr 2017 16:09:07 +0900." Date: Sat, 08 Apr 2017 07:10:21 +1000 Message-Id: <20170407211021.BE32F6B00B6E@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 21:11:47 -0000 In message , Lorenzo Colitti writes: > --001a1134ee386b1ca2054c8e4ecf > Content-Type: text/plain; charset=UTF-8 > > On Fri, Apr 7, 2017 at 6:12 AM, Mark Andrews wrote: > > > > The Android phone in my pocket is a router when I go to the coffee shop > > > every morning and turn on tethering. As the maintainer of that code, I > > > absolutely do not want to spend software engineering time writing a > > DHCPv6 > > > server that is not only less capable than the RDNSS implementation that > > we > > > have now, but also degrades functionality. > > > > And in doing so breaks any equipement that doesn't yet support RDNSS. > > > > No, it only breaks equipment that does not support RDNSS and doesn't > support DHCPv4. There is no such equipment today, and it will be years or > decades before there is. So, I'm not allowed to test host in IPv6 only mode when tethering! Good to know. Hosts are NOT REQUIRED to turn on IPv4. I actully do tests like this occasionally. I turn off IPv4. I see what is reachable in a pure IPv6 only environment. Google isn't reachable. There are no IPv6 servers for google.com. Your job is to provide equipement that provides a working IPv6 network regardless of how the host is configured. You are not doing that. > > So also bring up a ULA prefix and advertise the phone's address on > > the ULA prefix as the validating recursive server and offer this > > as well. This is what homenet does to provide stability of local > > services in the presence of changing upstream prefixes. > > > > There are lots of ways to solve problems. > > > > Sure. And what benefit would the added complexity of this solution (add ULA > management; write a DHCPv6 server) provide the user? That they can connect > with (nonexistent) equipment that doesn't support IPv4? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Apr 7 14:35: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 CA56B1200C1 for ; Fri, 7 Apr 2017 14:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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=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 PfoRmUNc2yDE for ; Fri, 7 Apr 2017 14:35:50 -0700 (PDT) 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 9C0ED127097 for ; Fri, 7 Apr 2017 14:35:50 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id x125so77379493pgb.0 for ; Fri, 07 Apr 2017 14:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=rHv5fdihZgHfTPzgIzzcAIV6CbWKGHCIon+NqO+Tq2w=; b=flweyQxCfPbayahAYPVINxviT+Yi/+7bL50WKdCjuBoBR2REeSaPYbr4EnfaKccG2a rBxpXZedTd5O8kinaiumtVxVyKlIWlrEE65i0r36Au0FBUhMPGUYRO/1c0l+tqrE3AmK w4EXmmW5OouyA7U2Gq0UZkjOGkqkEQtbemzecXdwT0wDmqORd3jrnq91bohx+Ajy5WRJ sbQEtAusnF120o4XtiUt2T4znhN6nktw6OyoktEIgV2vAt8PuMYF8CIC+B6XvNZndIfD myTwDH9c8xvdXkf26vmxkq/kfFLGL3Fj0L/QIbObSmEIan/seN4NLyHlC34ym1oWMLli W0zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=rHv5fdihZgHfTPzgIzzcAIV6CbWKGHCIon+NqO+Tq2w=; b=nknV5VQfkseBRWvscPhUAVGReqjHzx4VVPc4tS6uVbdOmmuSfFvEmClSfxQ48bZthz 1QceLRdcGo9KmTAok0ao1cEyzA1p6gxDtujqDVAADuYrviOY6l0y9wici+75hKLeFLv/ Y1xt53B2gq8DyUgsBDHU/BmEg4nig3LG9IwSUgBHO+pHDfF09FFYiLWLH9I0MwrH7pXX Y1zAYS+o9T3Lkfi9NCRhbn5eESqaABt4wNMGHvI5nxvOIQsKk3OWsRWuVHXmn/diciXS Pa8g85Qj1lrdVSMMxzdTy13coNH2TZ02cBkgTjtQXWAXmQyYGvmBv9BQzeK9dXZA9n+U l5DA== X-Gm-Message-State: AFeK/H1sje2HcN5q0MXBqwcsAO5gU7yR/H/9Dh6eTdjQA9jxO9paMphqvqRy/GgbTkQ5gX7f X-Received: by 10.99.62.4 with SMTP id l4mr42548508pga.172.1491600949921; Fri, 07 Apr 2017 14:35:49 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id a87sm3108471pfe.34.2017.04.07.14.35.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 14:35:49 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_5CC944B1-FA99-4569-A356-EFE77E0B0485" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 7 Apr 2017 14:35:48 -0700 References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> To: IPv6 Operations In-Reply-To: Message-Id: <2181CCCB-D020-49BE-911F-49B6A9964A02@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 21:35:53 -0000 --Apple-Mail=_5CC944B1-FA99-4569-A356-EFE77E0B0485 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 7, 2017, at 09:58, Lee Howard wrote: >=20 > Is there an architectural principle you would appeal to, to resolve = the conflict? I can=E2=80=99t answer for Lorenzo or Sander, but where I would start = with the three architectural principles of Vitruvius: firmitas, = utilitas, venustas, i.e. a good architecture is 1) durable, stands up = robustly to deteriorating environmental conditions, and still remains in = good condition; 2) suitable for the purposes for which people are using = it; and 3) aesthetically pleasing. A good network needs first to be durable, second to be suitable, and = third to be aesthetically pleasing. A good network has to last at least = as long as the most durable host in the network, and often longer. It = must be suitable for all the disparate uses that the population of hosts = are making of it. And it needs to be aesthetically pleasing: which in = the context of communication networks, it must be seamless and invisible = to the people using it. Wherever the communication network itself = becomes visible to the people using it, there is where the network is = brutalizing its users. An aesthetically pleasing network is invisible. A good host implementation, on the contrary, reverses the order of = these. Indeed, a good host implementation need not be durable. It could = be totally disposable, designed to run until its battery is discharged, = then recycled for scrap. It need only be durable while in use, and its = lifetime can be short by design. It should be suitable for the purposes = that people have for it, but these could be special purposes, and in = some cases a suitable purpose is simply to be a thing of beauty. First = and foremost, a host implementation should always be aesthetically = pleasing. It must delight the people who use it. The experience of using = it must be intuitively easy, bringing delight to the people encountering = it, and invisibility is rarely the desired quality of a host = implementation, as opposed to a network. Everything in host = implementations is secondary to aesthetics. Following the principles above, it seems easy for me to say that a good = router provides the necessary infrastructure to be robust and lasting, = suitable for seamless and invisible use by a large and diverse = population, with the widest variety of hosts, i.e. those that use RDNSS = only, those that only use DHCPv6 (stateless, stateful or both), those = that have differing methods of combining the two, etc. Likewise, following the same principles, a good host implementation is = designed first and foremost to delight the individual owner of the = system. It should use either RDNSS or DHCPv6 or both, as the case may = be, in whatever combination is necessary, to provide the best possible = user experience in the typical usage scenarios people have for it. As an = architectural matter, IETF should take great care to insist that the = choice for equipment makers is truly OPTIONAL in both cases. One or the = other of them, possibly both, will very likely be necessary to provide = an aesthetically pleasing user experience, but which choice the host = implementation designer makes is a matter between the equipment maker = and the equipment user. --james woodyatt > --Apple-Mail=_5CC944B1-FA99-4569-A356-EFE77E0B0485 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 7, 2017, at 09:58, Lee Howard <Lee@asgard.org> = wrote:

Is there an architectural principle you would = appeal to, to resolve the conflict?

I can=E2=80=99t answer = for Lorenzo or Sander, but where I would start with the three = architectural principles of Vitruvius: firmitas, utilitas, venustas, = i.e. a good architecture is 1) durable, stands up robustly to = deteriorating environmental conditions, and still remains in good = condition; 2) suitable for the purposes for which people are using it; = and 3) aesthetically pleasing.

A good network needs first to be = durable, second to be suitable, and third to be aesthetically pleasing. = A good network has to last at least as long as the most durable host in = the network, and often longer. It must be suitable for all the disparate = uses that the population of hosts are making of it. And it needs to be = aesthetically pleasing: which in the context of communication networks, = it must be seamless and invisible to the people using it. Wherever the = communication network itself becomes visible to the people using it, = there is where the network is brutalizing its users. An aesthetically = pleasing network is invisible.

A good host implementation, on the = contrary, reverses the order of these. Indeed, a good host = implementation need not be durable. It could be totally disposable, = designed to run until its battery is discharged, then recycled for = scrap. It need only be durable while in use, and its lifetime can be = short by design. It should be suitable for the purposes that people have = for it, but these could be special purposes, and in some cases a = suitable purpose is simply to be a thing of beauty. First and foremost, = a host implementation should always be aesthetically pleasing. It must = delight the people who use it. The experience of using it must be = intuitively easy, bringing delight to the people encountering it, and = invisibility is rarely the desired quality of a host implementation, as = opposed to a network. Everything in host implementations is secondary to = aesthetics.

Following the principles above, it seems easy for me to say = that a good router provides the necessary infrastructure to be robust = and lasting, suitable for seamless and invisible use by a large and = diverse population, with the widest variety of hosts, i.e. those that = use RDNSS only, those that only use DHCPv6 (stateless, stateful or = both), those that have differing methods of combining the two, = etc.

Likewise, = following the same principles, a good host implementation is designed = first and foremost to delight the individual owner of the system. It = should use either RDNSS or DHCPv6 or both, as the case may be, in = whatever combination is necessary, to provide the best possible user = experience in the typical usage scenarios people have for it. As an = architectural matter, IETF should take great care to insist that the = choice for equipment makers is truly OPTIONAL in both cases. One or the = other of them, possibly both, will very likely be necessary to provide = an aesthetically pleasing user experience, but which choice the host = implementation designer makes is a matter between the equipment maker = and the equipment user.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_5CC944B1-FA99-4569-A356-EFE77E0B0485-- From nobody Fri Apr 7 18:21: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 40A601279EB for ; Fri, 7 Apr 2017 18:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 oTBdT2z8FbRG for ; Fri, 7 Apr 2017 18:21:47 -0700 (PDT) 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 9C5FD128896 for ; Fri, 7 Apr 2017 18:21:42 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id a1so27048uaf.3 for ; Fri, 07 Apr 2017 18:21:42 -0700 (PDT) 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=u2BbbOd3w3K73AR4ATvN1J2q/e8ryDE4CJNaPFnGRBE=; b=vNTDUNQO+6XFDHmMUS3JbXHIiJ2SKH0nnzXaaZkt//zw2/hAHx8aZfv99FGnEhQ4dj YV+ulbn7fM2YQGOIO1i66Vs71/aYS1wm19ffXfDrW8XXrMCmXEDY3Wg+ha0wZCVqZ9JT 9+Wovj3zKCTXwpTgg8a3+siB4QnKdd5p07ZQ40COZT4RkGPKmVSQUpd5zdKxA84CWHCK QuMC6alpe5J9yaxWDJoZT0BVvOf7m5s8wyBPWXNFpVw/pEF04FwdXT/3zSm4KhvhxiDw 2AxLLE/cNqGFWxRfcBsBJnwzc6k8O9tE93aKQ/9W3rLTz4qSUHhTn/s1x+gplKtfseYU +Kow== 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=u2BbbOd3w3K73AR4ATvN1J2q/e8ryDE4CJNaPFnGRBE=; b=iJDGwKxhtMk9R5Tjy9WTfJHRaiKFF73hm5EDQZiYiz28B63QDLa0qsR+wZFkUyxjUc AEbUhgmWSqP3lIuqoNhB5d5wPqDuUSFvUt317zyNUvBO2C8sVSUbzfKs6lrvBJqepdkJ wma74J7AFN0CldSrh1UnOXupYDpx+u74BC+g2B7OHNs6/y9NTPHHmLIAoqwhLqGgy99b fnXPQuC0Wu/MCv2w4AM+LlCL9tV2JwuHUzf0A1/NOU8gye/8n+owYe4iW8x/fU8qTgXJ tdp8fXvyp+/KrgODopxhi8Sjr0tTPSePVhgOWQOQyC/jyJ5K1Rm89cUyePJpsu7GpX4V XFfA== X-Gm-Message-State: AN3rC/4wYLTnxmPbjxgzWa5E35SB9YlF2KauolqxoicEyX9LHUBf8XZ4JjcvwA8vzFIYuFzFTrMaBQugXW5PCl5O X-Received: by 10.176.2.104 with SMTP id 95mr4045648uas.30.1491614501369; Fri, 07 Apr 2017 18:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 18:21:20 -0700 (PDT) In-Reply-To: <20170407160336.GN4764@angus.ind.wpi.edu> References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <69761DA6-9671-4C0D-BE05-AC8208D5B883@steffann.nl> <20170407160336.GN4764@angus.ind.wpi.edu> From: Lorenzo Colitti Date: Sat, 8 Apr 2017 10:21:20 +0900 Message-ID: To: Chuck Anderson Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a1134ee387f839a054c9d90c9 Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 01:21:49 -0000 --001a1134ee387f839a054c9d90c9 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 8, 2017 at 1:03 AM, Chuck Anderson wrote: > > > We've probably all forgotten how end-to-end works because for the last > > years/decades, the dominant networking technology was IPv4, and in most > > networks, IPv4 stopped providing end to end years or decades ago. DHCPv4 > is > > absolutely fine if all you want to do is return 192.168.1.1 and > 192.168.1.1 > > never changes, or if you return an IPv4 address in PI space, and that > never > > changes. > > I run a /16 that is not NATed. With DHCPv4. Without the theoretical > problems you pose. > Sure, if you have $650,000 worth of IPv4 addresses and slots in the global routing table you can do that. I said "most" networks. > DHCPv6 does support RECONFIGURE. Not in the real world - and even if it did, what are you going to do ? Renumber a link somewhere in your network by telling your centralized DHCPv6 server sitting in a datacenter somewhere to issue a reconfigure to a client that's sitting in another building? What protocol are you going to use to do that, and how is it going to scale? And what failure properties will it have if the network partitions? DUIDs are not any more of a privacy concern than MAC addresses are. > But the industry is moving towards random MAC addresses because static MAC addresses facilitate tracking, and users are beginning to understand that. --001a1134ee387f839a054c9d90c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 8, 2017 at 1:03 AM, Chuck Anderson <cra@wpi.edu> wrote:> = We've probably all forgotten how end-to-end works because for the last<= br> > years/decades, the dominant networking technology was IPv4, and in mos= t
> networks, IPv4 stopped providing end to end years or decades ago. DHCP= v4 is
> absolutely fine if all you want to do is return 192.168.1.1 and 192.16= 8.1.1
> never changes, or if you return an IPv4 address in PI space, and that = never
> changes.

I run a /16 that is not NATed.=C2=A0 With DHCPv4.=C2=A0 Without the = theoretical
problems you pose.

Sure, if you have $6= 50,000 worth of IPv4 addresses and slots in the global routing table you ca= n do that. I said "most" networks.
=C2=A0
DHCPv6 does support RECONFIGURE.<= /blockquote>

Not in the real world - and even if it did,= what are you going to do ? Renumber a link somewhere in your network by te= lling your centralized DHCPv6 server sitting in a datacenter somewhere to i= ssue a reconfigure to a client that's sitting in another building? What= protocol are you going to use to do that, and how is it going to scale? An= d what failure properties will it have if the network partitions?

DUIDs are not = any more of a privacy concern than MAC addresses are.
=
But the industry is moving towards random MAC addresses beca= use static MAC addresses facilitate tracking, and users are beginning to un= derstand that.
--001a1134ee387f839a054c9d90c9-- From nobody Fri Apr 7 18:49: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 821A212896F for ; Fri, 7 Apr 2017 18:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 U7_9OR5wbyZG for ; Fri, 7 Apr 2017 18:49:40 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 E9165129353 for ; Fri, 7 Apr 2017 18:49:39 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id d188so87801959vka.0 for ; Fri, 07 Apr 2017 18:49:39 -0700 (PDT) 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=4JjacjISuKmXe0MikpMxyIAyKH1SMp0rUMyrdHR7I9o=; b=OxIYLmYSHnttl3hlCJEZW9ejVRscgbpOjxE+oGmO3B1AzDHP5pLDmW8vCEiroIaRVi BWIo/EOJqBUkzzAEvMpc8KlLY14G0i5uY7uICryJ96W7c3di3fARswkHf+8wUCQYv71A vOKJ3YQgruoT+amV5MlOCNt/Krou5c7PKoakAIL23dGbICW6vs+e7huBJwHSlI5Auadn rsoJ9Shkx7NlKQ3QnFnhb1BRZjBfF6APb7rE3Vjr2JyHfVtnVNGWZna2F7wzNMBPxx7y bcVjvqbqYg5EeHLxnBCkb0Xl7nMs0RS+9u5/6cC/PlITcL164cnhODKtSmY0lPrvnsnd pqUg== 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=4JjacjISuKmXe0MikpMxyIAyKH1SMp0rUMyrdHR7I9o=; b=nr6k68/wCRUI57Ha6QmoY3yU5U4C3V61lypIT1sgyhtX/S/dFStEPxMUU1snU3mQrV bVN5WA2DS8I9b3C4VVu3S1Y3E9qzH+Nv2gNdwIK5OfPjs/qEcItft/2nBhyObYLQWYyU fvSyaUnVcOZTCmG+9SLFpjoJ0HyIHn09w/EDOZKB3trq6BBnysGuzuTbwRp0k//O83VB hzUth4WAXxqLwbIa1P8Hyc8Fg79YIwQb2PQo/Hw9e4vqQcHGgYxXJv3v/frddxgEkSkN wOXwrnkMuVQy3FvBTc5YA6itsF1RopHnSj3oQLJQEZxm5DaMjiZTT46gW4BAkz5w7ZWP blTw== X-Gm-Message-State: AFeK/H1NYcgbOF2DPiTCGvIoeHaoOCYqhtF2A6tqazX2AKKn67catiAsi3Ouo+CB4VlKQ0Wj23Ph7LLgMEKlVL+8 X-Received: by 10.31.11.73 with SMTP id 70mr20056397vkl.83.1491616178840; Fri, 07 Apr 2017 18:49:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 18:49:17 -0700 (PDT) In-Reply-To: <20170407211021.BE32F6B00B6E@rock.dv.isc.org> References: <58E253B4.9010501@foobar.org> <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170406211206.DB8A76AA312B@rock.dv.isc.org> <20170407211021.BE32F6B00B6E@rock.dv.isc.org> From: Lorenzo Colitti Date: Sat, 8 Apr 2017 10:49:17 +0900 Message-ID: To: Mark Andrews Cc: "STARK, BARBARA H" , IPv6 Operations , Tore Anderson Content-Type: multipart/alternative; boundary=001a11437e887b8d50054c9df41b Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 01:49:42 -0000 --001a11437e887b8d50054c9df41b Content-Type: text/plain; charset=UTF-8 On Sat, Apr 8, 2017 at 6:10 AM, Mark Andrews wrote: > > No, it only breaks equipment that does not support RDNSS and doesn't > > support DHCPv4. There is no such equipment today, and it will be years or > > decades before there is. > > So, I'm not allowed to test host in IPv6 only mode when tethering! > Good to know. Hosts are NOT REQUIRED to turn on IPv4. > What do you mean? You can certainly configure your tethered host as IPv6-only. The host can get its DNS servers through RDNSS or static configuration. Like I said, I think adding support for DHCPv6 here would make things worse, not better, because it would provide broken connectivity to clients that are capable of both when the upstream prefix changes. > I actully do tests like this occasionally. I turn off IPv4. I see > what is reachable in a pure IPv6 only environment. > > Google isn't reachable. There are no IPv6 servers for google.com. > Unfortunately, every time we've looked at the data, the conclusion has been that it would cause unwarranted user impact. IIRC the most recent blocker was a major US ISP whose clients would experience breakage if even just one NS record was dual-stacked. It's not an infrastructure problem: the servers have supported IPv6 for years, and some zones like google.fi do have IPv6 NS records. --001a11437e887b8d50054c9df41b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 8, 2017 at 6:10 AM, Mark Andrews <marka@isc.org> wrote:<= br>
> No, it only breaks equipment that does not support RDNSS and doesn= 9;t
> support DHCPv4. There is no such equipment today, and it will be years= or
> decades before there is.

So, I'm not allowed to test host in IPv6 only mode when tetherin= g!
Good to know.=C2=A0 Hosts are NOT REQUIRED to turn on IPv4.

What do you mean? You can certainly configure your tet= hered host as IPv6-only. The host can get its DNS servers through RDNSS or = static configuration. Like I said, I think adding support for DHCPv6 here w= ould make things worse, not better, because it would provide broken connect= ivity to clients that are capable of both when the upstream prefix changes.=
=C2=A0
I actully do tests like this occasionally.=C2=A0 I turn off IPv4.=C2=A0 I s= ee
what is reachable in a pure IPv6 only environment.

Google isn't reachable.=C2=A0 There are no IPv6 servers for google.com.
=

Unfortunately, every time we've looked= at the data, the conclusion has been that it would cause unwarranted user = impact. IIRC the most recent blocker was a major US ISP whose clients would= experience breakage if even just one NS record was dual-stacked. It's = not an infrastructure problem: the servers have supported IPv6 for years, a= nd some zones like google.fi do have IPv6 = NS records.
--001a11437e887b8d50054c9df41b-- From nobody Sat Apr 8 14:30: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 EAA1B120326 for ; Sat, 8 Apr 2017 14:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[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 w_-1sCP0nXY6 for ; Sat, 8 Apr 2017 14:30:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D626212426E for ; Sat, 8 Apr 2017 14:30:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cwxvz-0000FHC; Sat, 8 Apr 2017 23:30:15 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> In-reply-to: Your message of "Fri, 7 Apr 2017 07:54:43 -0700 ." Date: Sat, 08 Apr 2017 23:30:13 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 21:30:21 -0000 >But that's just it, Phillip. RDNSS is _way_ simpler than DHCP. >You're already doing ND. So it really is just one line for RDNSS. That does not compute. The hard part is not writing a simple stateless DHCP server that can insert a DNS option. But if you think that is really complex: A router MUST/SHOULD contain a 'stateless' DHCPv6 server that supports the DHCPv6 DNS configuration options. From nobody Sat Apr 8 16:28: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 9159312714F for ; Sat, 8 Apr 2017 16:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 memk6dmCulSc for ; Sat, 8 Apr 2017 16:27:58 -0700 (PDT) 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 BA674127A90 for ; Sat, 8 Apr 2017 16:27:58 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id i34so83644987qtc.0 for ; Sat, 08 Apr 2017 16:27:58 -0700 (PDT) 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=IwOlI56yChixxCsOGcpvnTUTCS+ZX8Y9GTyW3cI3GQE=; b=FNenBjnxGttZKVyeNRC1UGV2DqEW5Qc+XKl+/8n9l6BW0d/cHu/QUAvct8TwgzF7zn 4tKTMZijRWnh7YyAdgQXg28vK2m8r813B0MvwRAuMchrjWbiN2Wj4WpIY3H5sTBzSpL2 4pJqylJbr3fGzWZ12UXfhBS2KgEWsUwydTnWJ/h5hMk/dvbnrwkGkxNienhCTy5weMG/ OgO5j5OjHacWfjZ05TLuv6wr3kbDdpnX945C0PLojs8OzcgxWwEsFvXENXy3j7Gv/uHK 9aqi12v3yFyInIBQYFVHJrU3oi8DkG/ge+4YKMuZ7aW778tc2TRZxXlCtJBQ+YdZizxU HV8A== 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=IwOlI56yChixxCsOGcpvnTUTCS+ZX8Y9GTyW3cI3GQE=; b=F6v7gQ6xPuIpKI9nQeTWhFYsWRTMZDojq3d2bHBPxj6qrBJ2Bmx36bqzJyAUlKnfoB 6X/6jjOnFLCZoKihooNWGC3p6TsvYoHhD7yIInoE/nUgWBc+j2G5qw9JR81PpPJqhzG4 hEUonbOwXlQXFHSPVQf23CetyUy4R4kAI6x+ntjcl0s0K6fcG59pYVdSKWZc0wFGACsF gyZ0eaeRGZg4fmmvKJCZ45KDd9ctw5o8Dhx6OU04dh4EV/nkYcqM18h+Qeq4u9yWsIgy lypPrnDZ5o8rRfjBkqXCCcZvchrb/7odcC9xS7BRyhnjvaC54dNIZGjrYhBAxCdOwium VdnA== X-Gm-Message-State: AFeK/H2buIAk/gYKVHr7sa+Un+gD9e+PyoSfsMaOnEaO9DyXJRyRoxAy2ebwN1XfCppZUw== X-Received: by 10.200.38.3 with SMTP id u3mr47579897qtu.203.1491694077958; Sat, 08 Apr 2017 16:27:57 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e5sm5907967qtc.6.2017.04.08.16.27.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 16:27:56 -0700 (PDT) From: Ted Lemon Message-Id: <7AE7D1D3-120A-439F-AE9B-278167544E91@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_32317412-7DCA-4509-9A74-7A83631BC377" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 8 Apr 2017 19:27:54 -0400 In-Reply-To: Cc: v6ops@ietf.org To: Philip Homburg References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 23:28:01 -0000 --Apple-Mail=_32317412-7DCA-4509-9A74-7A83631BC377 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 8, 2017, at 5:30 PM, Philip Homburg = wrote: > A router MUST/SHOULD contain a 'stateless' DHCPv6 server that supports = the > DHCPv6 DNS configuration options. Did you not read my earlier message where I explained why this wasn't as = simple as what you've written?= --Apple-Mail=_32317412-7DCA-4509-9A74-7A83631BC377 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 8, 2017, at 5:30 PM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
A router MUST/SHOULD contain a = 'stateless' DHCPv6 server that supports the
DHCPv6 DNS configuration = options.

Did= you not read my earlier message where I explained why this wasn't as = simple as what you've written?
= --Apple-Mail=_32317412-7DCA-4509-9A74-7A83631BC377-- From nobody Sun Apr 9 01:35: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 6765D1252BA for ; Sun, 9 Apr 2017 01:35:48 -0700 (PDT) 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 HRay7LFYdX4Z for ; Sun, 9 Apr 2017 01:35:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6F71201F2 for ; Sun, 9 Apr 2017 01:35:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cx8Jz-0000GvC; Sun, 9 Apr 2017 10:35:43 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> <7AE7D1D3-120A-439F-AE9B-278167544E91@fugue.com> In-reply-to: Your message of "Sat, 8 Apr 2017 19:27:54 -0400 ." <7AE7D1D3-120A-439F-AE9B-278167544E91@fugue.com> Date: Sun, 09 Apr 2017 10:35:42 +0200 Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 08:35:48 -0000 >Did you not read my earlier message where I explained why this wasn't as >simple as what you've written? I stopped reading when I realized that whose questions could or would have to be answered for RDNSS as well. (Of course there are some DHCP specific issues. If you include both a DHCP server and a relay agent you have have knob to select which one to use. Big deal) From nobody Sun Apr 9 06:03: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 CE92712947D for ; Sun, 9 Apr 2017 06:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 jZQjbtyinlrM for ; Sun, 9 Apr 2017 06:03:46 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 3E357126C23 for ; Sun, 9 Apr 2017 06:03:46 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p22so91315179qka.3 for ; Sun, 09 Apr 2017 06:03:46 -0700 (PDT) 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=TLn0VbxWMZMk7FqzTV556P7mzp1f1CVWCByyhZTmp8E=; b=DaR6ttpSSkbeFysqGulgFaSNAF1bKav8UsXjskuSVXNGSzZ6G4DniWvdpxhSe/YLjF fbvJaGFv2oL/LWD4WfZgb/qhw3ahArVn5EStbl0oRWuNNCnwa5UZBuCbvSqmVb6Z2cLb Wbrc1kx7zlJdABZp2ADk8sXpuxs3ORGqvg4aTJoBkNSj1g3F6xWm7Gluq85stkTMc7Ru pfZaBfP6kA1tOwS0wG78jv25JZjSjZCtEVvUUjWSk9YguMau0h9gNznJBv8y87ktTKus kjIw2GIfCmt45Phcz3HljQ6Zwzwl2lxqPrI09Bz+PLEBY5uD3RzdvKtKC19LDuYFW/jc tKEQ== 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=TLn0VbxWMZMk7FqzTV556P7mzp1f1CVWCByyhZTmp8E=; b=s5cQccrjGmXkoyJuesBo/rWcG5EodbTyJibxM8Cjo1/dox/nAsRKDKEa+whXLAsmuU 1pq/71jnphKhso/nnEPMwWTQGF6+eXNykFKBCCsvHk501SJFCPU/BxW3WFff556ptQhK tgGW3Qh2IvSftF4eKH/LrQjPZG8pFQYnH8TV0XpIXhVBs83WD+VX6Hh0tb2dnleSmffE BtqoRk8ATZrr3sZC04qvhYV+4LskK6xLiT0MuIx14ERCOEw6SIPJF8sKIH5JZASebKIX jbtqR7PzJwDeGo5vLXsUUYOr0NOWm6rz0E6j7YfI3aUT+iCeJpB6zMj5Qyf/rv8CgYYI 6fmA== X-Gm-Message-State: AN3rC/4reECC6gdCatTJBgMb4thNgg6pJGulTGr5oD6/ap8B7mvI0EPN8vIMZQebiRuSaw== X-Received: by 10.55.111.71 with SMTP id k68mr18789455qkc.117.1491743025373; Sun, 09 Apr 2017 06:03:45 -0700 (PDT) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m68sm6852283qki.4.2017.04.09.06.03.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 06:03:44 -0700 (PDT) From: Ted Lemon Message-Id: <3E0852E5-9B13-48FC-A4F6-FE704EC229C6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8E6C9004-7A4E-435A-AF66-A816CFA1246D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 9 Apr 2017 09:03:43 -0400 In-Reply-To: Cc: v6ops@ietf.org To: Philip Homburg References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <20170406124635.0fb20504@echo.ms.redpill-linpro.com> <20170406183800.3e4f5ef4@envy.e1.y.home> <20170406184840.524adb1c@envy.e1.y.home> <1083adcc-06a2-8096-2724-a9774245e357@si6networks.com> <7AE7D1D3-120A-439F-AE9B-278167544E91@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 13:03:48 -0000 --Apple-Mail=_8E6C9004-7A4E-435A-AF66-A816CFA1246D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 9, 2017, at 4:35 AM, Philip Homburg = wrote: > I stopped reading when I realized that whose questions could or would = have > to be answered for RDNSS as well. No they wouldn't, because RDNSS isn't stateful and you aren't adding a = protocol, since you're already doing RA. But I suppose I'm just = wasting electrons typing this. --Apple-Mail=_8E6C9004-7A4E-435A-AF66-A816CFA1246D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 9, 2017, at 4:35 AM, Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
I stopped reading when I realized that = whose questions could or would have
to be answered for = RDNSS as well.

No they wouldn't, because RDNSS isn't stateful and you aren't = adding a protocol, since you're already doing RA.   But I suppose = I'm just wasting electrons typing this.

= --Apple-Mail=_8E6C9004-7A4E-435A-AF66-A816CFA1246D-- From nobody Mon Apr 10 03:40: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 9484F129481 for ; Mon, 10 Apr 2017 03:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 lpg_w2i0HjzV for ; Mon, 10 Apr 2017 03:40:06 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id D532B129483 for ; Mon, 10 Apr 2017 03:40:04 -0700 (PDT) Received: from [IPv6:2620::930:0:141e:1996:975a:477] ([IPv6:2620:0:930:0:141e:1996:975a:477]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v3AAd3rZ011869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Apr 2017 03:39:04 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPad Mail (14E304) In-Reply-To: <20170405160421.GB28135@angus.ind.wpi.edu> Date: Mon, 10 Apr 2017 03:39:02 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <93620F01-2D65-4D22-8224-E2FB87E8781F@delong.com> References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> <20170405154854.GA28135@angus.ind.wpi.edu> <6A2D3B74-ED15-4E32-8A0D-548C921A3B5D@fugue.com> <20170405160421.GB28135@angus.ind.wpi.edu> To: Chuck Anderson X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 10 Apr 2017 03:39:04 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 10:40:08 -0000 > On Apr 5, 2017, at 09:04, Chuck Anderson wrote: >=20 >> On Wed, Apr 05, 2017 at 08:53:47AM -0700, Ted Lemon wrote: >>> On Apr 5, 2017, at 8:48 AM, Chuck Anderson wrote: >>> Why are DNS resolvers a link-specific parameter that needs to be >>> distributed to clients at all? Can't they just use some other >>> discovery mechanism to find a resolver or do full-recursion w/DNSSEC >>> validation? >>=20 >> Because end-users would suffer if they didn't use the configured resolver= : the DNS protocol is designed with caching in mind, and at this point CDNs u= se DNS extensively. So if you don't use the local resolver, you will see m= ajor performance issues. But yeah, aside from that quibble, what you are s= aying makes a lot of sense (seriously!). :) >=20 > Okay, so can't clients just do a mDNS request to find a local resolver? Because what we really need here is a third auto one mechanism... NOT >=20 > I have a strong dislike of involving the router in distributing > higher-layer parameters like RDNSS and DNSSL. It causes real Nobody is suggesting you have to use it. Just that we want to pressure route= r and host developers to make it available in the toolbox for operators to c= hoose. > operational problems when the DNS infrastructure and routers are > maintained by different teams. Also, having DNS resolvers distributed > by routers means there is no fate-sharing between the provider of the > service and the distributor of the configuration. This sounds like a perfectly valid reason to choose DHCP in the circumstance= s where it applies, but in cases where they are the same team, there is real= benefit to having RDNSS and DNSSL as an option so as not to have to maintai= n a DHCP server. > If a DNS server > goes down, how do all the routers in the network magically get updated > with new DNS server configuration to distribute to the clients? The word "anycast" comes to mind. > With DHCP, the DNS server can and often is co-located with the DHCP > server. I think occasionally would be a more accurate statement than "often", but be= that as it may, it's not always the case and it's just as often that the ro= uter provides a local DNS resolver or proxy service meaning that there's at l= east as good a case for fate sharing on the router as on the DHCP server. This is why I am arguing for mandatory implementation and let the operator c= hoose the features that work best in their particular environment. Unfortuna= tely, if we don't require implementation, then the operator has only the cho= ices made available to him by the vendors in question where there may not ne= cessarily exist a compatible subset across all vendors in his environment. Owen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 10 03:53: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 53F22126CE8 for ; Mon, 10 Apr 2017 03:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 1QxJ_NEucyZC for ; Mon, 10 Apr 2017 03:53:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDBE12441E for ; Mon, 10 Apr 2017 03:53:01 -0700 (PDT) Received: from [IPv6:2620::930:0:141e:1996:975a:477] ([IPv6:2620:0:930:0:141e:1996:975a:477]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v3AApxsX013026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Apr 2017 03:51:59 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPad Mail (14E304) In-Reply-To: Date: Mon, 10 Apr 2017 03:51:59 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4CE0482C-EB71-4F70-8B95-CCEA09D56C22@delong.com> References: <6778e48f-250e-30ca-6d57-a8d87c8f0dd6@dougbarton.us> <73E59C4C-AC31-4456-B807-CE92490A5D51@thehobsons.co.uk> <7063c729-70f5-40b0-51b2-1d89bb28d7c0@dougbarton.us> <2ff28a1e-f11f-b924-8105-4f4de4e1804a@dougbarton.us> <58E253B4.9010501@foobar.org> <914! B3454-58A 4-4130-8B90-6371100D619D@fugue.com> To: Simon Hobson X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 10 Apr 2017 03:52:00 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 10:53:03 -0000 > On Apr 5, 2017, at 14:24, Simon Hobson wrote: >=20 > Ted Lemon wrote: >=20 >> ... and, by the way, you are _insane_ if you trust the DHCP server to tel= l you what NTP server to talk to, but that's a side issue >=20 > Vs trusting some random device broadcasting a claim that it's a legitimate= router on the network ? >=20 Meh >=20 >=20 > Erik Kline wrote: >=20 >> Specifically, consider the case where 2 RAs are sent on the network each w= ith different PIOs, RIOs, and RDNSS sets. End nodes can associate all this i= nformation with each next hop, and make better, logically consistent use of e= ssentially two different networks a la RFCs 7556 and 8028. >=20 > One thing that slightly concerns me is all this determination to put decis= ions into the device, rather than the network. In effect, fundamental decisi= ons are made by which may well be a device which the networ= k admin has zero control over. >=20 This is inherent in peer to peer networking. Unless you have a way to reject= a host that is statically configured with information that is valid for the= local network it is attached to, you inherently trust the operator of the h= ost (if not the host itself) to make those decisions, whether you intend to o= r not. >=20 >=20 > Chuck Anderson wrote: >=20 >> Why are DNS resolvers a link-specific parameter that needs to be >> distributed to clients at all? Can't they just use some other >> discovery mechanism to find a resolver or do full-recursion w/DNSSEC >> validation? >=20 > That's a good question. Not even private DNS zones answers that one - a ho= st wouldn't know which interface it needed to use until it knows the IP addr= ess of the destination and look it up in the routing table. And it won't kno= w the IP address until it's done the DNS query. The short answer is that it isn't necessarily a link-specific parameter, but= if you want to have a zeroconf host, then you have to have some way for it t= o learn something about DNS in its environment. Since all of the configurati= on information mechanisms currently available are link-parameter focused, it= seems that is the hammer we have. I think there is an extremely valid argument that creating yet another type o= f hammer is _NOT_ a useful alternative here. We have perfectly functional wa= ys to solve this using the two existing hammers (RDNSS/DHCP6). The biggest p= roblem we have at this point is that neither one is required so implementati= ons are sketchy in terms of compatibility and operator choice. Owen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 10 05:43: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 B5043126BF0 for ; Mon, 10 Apr 2017 05:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tum.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H76YiBeHRLwr for ; Mon, 10 Apr 2017 05:43:02 -0700 (PDT) Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff8a]) (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 1B97E12940D for ; Mon, 10 Apr 2017 05:43:02 -0700 (PDT) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout2.mail.lrz.de (Postfix) with ESMTP id 3w1qbR6qczzyRK for ; Mon, 10 Apr 2017 14:42:59 +0200 (CEST) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= mime-version:content-transfer-encoding:content-id:content-type :content-type:content-language:accept-language:message-id:date :date:subject:subject:from:from:received:received:received :received; s=postout; t=1491828179; bh=pgzEqqbP7RxCMFrwafXam/Wru u5P8wEqf//9aq8Xngk=; b=Vv2Wd7EUSwC9qR3Yy0xFy/IJS7ow8aiArsc5Eh5XB qvy34/ybwprenIhQDELWehhWngUiJUXktWC4o8ic4taO+qPOpe3yuGCwxuz1uAMe 3slzpZzueiyk+IlJZAsk4OpfMz6GQHPAGlFYvk6WmNpho1UNKWrYp5gSzHL+YcmK 2sr7yCMDFBue9CG+3QYAtz9X+2lk5BvWq5+hVj6nl/FBlH/VjnyHZIUaq4Xj1FHs /CdV/0WyM/lVUUfE2B+xSS46/dk8DCQjO+kO4jUyI8yMjsoOQoNpZ2am9c8eOKNR i0RnZao6Dz+MBbVn7Dk7lDi2fw7+jVbn8CN03JkGTmefw== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout2.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id wozWmf-sG_3H for ; Mon, 10 Apr 2017 14:42:59 +0200 (CEST) Received: from BADWLRZ-SWMBX02.ads.mwn.de (BADWLRZ-SWMBX02.ads.mwn.de [IPv6:2001:4ca0:0:108::158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX02", Issuer "BADWLRZ-SWMBX02" (not verified)) by postout2.mail.lrz.de (Postfix) with ESMTPS id 3w1qbR1HlxzySt for ; Mon, 10 Apr 2017 14:42:59 +0200 (CEST) Received: from BADWLRZ-SWMBX02.ads.mwn.de (2001:4ca0:0:108::158) by BADWLRZ-SWMBX02.ads.mwn.de (2001:4ca0:0:108::158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32; Mon, 10 Apr 2017 14:42:56 +0200 Received: from BADWLRZ-SWMBX02.ads.mwn.de ([fe80::19fa:4919:5296:5c3b]) by BADWLRZ-SWMBX02.ads.mwn.de ([fe80::19fa:4919:5296:5c3b%14]) with mapi id 15.01.0669.032; Mon, 10 Apr 2017 14:42:56 +0200 From: "Bajpai, Vaibhav" To: "v6ops@ietf.org" Thread-Topic: review: draft-pauly-v6ops-happy-eyeballs-update-01 Thread-Index: AQHSsff6UkOO3VKiIkq7L+eRJOTysw== Date: Mon, 10 Apr 2017 12:42:56 +0000 Message-ID: <01906ec6-9bfa-4205-a730-b9c08326e90e@BADWLRZ-SWMBX02.ads.mwn.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [131.159.24.54] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [v6ops] review: draft-pauly-v6ops-happy-eyeballs-update-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 12:43:04 -0000 DQo+IEFuIFVwZGF0ZSB0byBIYXBweSBFeWViYWxscw0KPiBkcmFmdC1wYXVseS12Nm9wcy1oYXBw eS1leWViYWxscy11cGRhdGUtMDENCg0KVGhlIGRyYWZ0IGlzIHRyeWluZyB0byBkbyAyIHRoaW5n cyBhdCBvbmNlIChkZXNjcmliZSBBcHBsZSdzIGltcGxlbWVudGF0aW9uDQphbmQgcHJvdmlkZSBh IFJGQyA2NTU1IHVwZGF0ZSkgd2hpY2ggaXMgbWl4aW5nIHRoaW5ncyB1cC4gRm9yIGluc3RhbmNl LCANCmFmdGVyIGhhdmluZyByZWFkIHRoZSBkcmFmdCwgSSBlbmQgdXAgZ2V0dGluZyBtb3JlIGNv bmZ1c2VkIG9uIHdoYXQgQXBwbGUncw0KaW1wbGVtZW50YXRpb24gYWN0dWFsbHkgZG9lcy4gU2Vl IGJlbG93IGZvciBkZXRhaWxzLg0KDQpNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHNoZWxmIHRo aXMgZHJhZnQgZm9yIG5vdywgYnV0IGZpcnN0IGRlc2NyaWJlIA0KQXBwbGUncyBpbXBsZW1lbnRh dGlvbiBhcyBhbiBpbmZvcm1hdGlvbmFsIFJGQy4gVGhpcyBzaG91bGQgZ28gcXVpY2sgYW5kIGJl DQp2ZXJ5IHVzZWZ1bCB0byB0aGUgY29tbXVuaXR5LiBJIGFncmVlIHRoYXQgUkZDIDY1NTUgbmVl ZHMgYW4gdXBkYXRlIChzZWUgW2FdDQpmb3IgZGV0YWlscyksIGJ1dCBwZXJoYXBzIGl0IGlzIGVh c2llciB0byBkbyBvbmNlIF4gaXMgZG9uZSwgc28gdGhhdCB3ZSBjYW4gDQpjaGVycnkgcGljayBn b29kIHBhcnRzIGZyb20gQXBwbGUncyBleHBlcmllbmNlIChhbmQgZnJvbSBvdGhlcnMgd2hvIGhh dmUgDQpsb25naXR1ZGluYWwgSEUgZGF0YXNldHMsIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2Up IHRvIHVwZGF0ZSBSRkMgNjU1NS4NCg0KW2FdIGh0dHBzOi8vZG9pLm9yZy8xMC4xMTQ1LzI5NTk0 MjQuMjk1OTQyOQ0KDQotLSBWYWliaGF2DQoNCg0KDQpkZXRhaWxzDQotLS0tLS0tDQoNCg0KLS0g VGhlIGRyYWZ0IG5lZWRzIHRvIGV4cGxpY2l0bHkgc3RhdGUgd2hhdCBpcyB0aGUgcHJvYmxlbSB3 aXRoIGN1cnJlbnQgUkZDDQo2NTU1IGRlc2NyaXB0aW9uIGFuZCB3aHkgaXQgbmVlZHMgYW4gdXBk YXRlLg0KDQotLSBJdCBpcyBub3QgY2xlYXIgaG93IHRoZSByZWNvbW1lbmRhdGlvbnMgbWFkZSBp biB0aGlzIGRyYWZ0IFtiXSByZWxhdGUgdG8NCkFwcGxlJ3MgW2NdIGltcGxlbWVudGF0aW9uLg0K DQpbYl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhdWx5LXY2b3BzLWhhcHB5 LWV5ZWJhbGxzLXVwZGF0ZS0wMQ0KW2NdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cyMjQ1NS5odG1sDQoNCg0KDQoNCi8vIMKnMzogSG9zdG5h bWUgUmVzb2x1dGlvbiBRdWVyeSBIYW5kbGluZw0KDQotLSAnSWYgb25lIHF1ZXJ5IGZhaWxzIHRv IHJldHVybiwgb3IgdGFrZXMgc2lnbmlmaWNhbnRseSBsb25nZXIgdG8gcmV0dXJuJw0KDQpob3cg bG9uZyBpcyBzaWduaWZpY2FudGx5IGxvbmc/DQoNCg0KDQotLSAnVGhpcyBkZWxheSB3aWxsIGJl IHJlZmVycmVkIHRvIGFzIHRoZSAiUmVzb2x1dGlvbiBEZWxheSIuICBUaGUgUkVDT01NRU5ERUQN CnZhbHVlIGZvciB0aGUgUmVzb2x1dGlvbiBEZWxheSBpcyA1MCBtaWxsaXNlY29uZHMu4oCZDQoN CmhvdyBpcyB0aGlzIHZhbHVlIG9mIDUwIG1zIGRldGVybWluZWQ/IERvZXNuJ3QgQXBwbGUncyBp bXBsZW1lbnRhdGlvbiB1c2UgYSANCjI1IG1zIHRpbWVyIGluc3RlYWQ/IFthXQ0KDQoNCg0KW2Fd IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cy MjQ1NS5odG1sDQoNCi0tIHdoYXQgaXMgYSAnc3RhZ2dlcmVkJyBjb25uZWN0aW9uPw0KDQotLSBJ biB3aGF0ICUgb2YgY2FzZXMgeW91IHNlZSB0aGF0IEROUyBxdWVyaWVzIGFyZSBtYWRlIG92ZXIg djYgdHJhbnNwb3J0Pw0KDQotLSBJbiB3aGF0ICUgb2YgY2FzZXMsIHlvdSBzZWUgdGhhdCBBQUFB IHF1ZXJpZXMgbm90IGNhY2hlZCwgYnV0IEEgcXVlcmllcw0KYXJlPyBJcyB0aGlzIGludmFyaWFu dCBvZiB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQ/DQoNCg0KDQovLyDCpzQ6IFNvcnRpbmcgQWRk cmVzc2VzDQoNCi0tICdJZiB0aGUgY2xpZW50IGlzIHN0YXRlZnVsIGFuZCBoYXMgaGlzdG9yeSBv ZiBleHBlY3RlZCByb3VuZC10cmlwDQogICB0aW1lcyAoUlRUKSBmb3IgdGhlIHJvdXRlc+KAmQ0K DQpIb3cgbG9uZyBzaG91bGQgYmUgdGhlIGhpc3Rvcnk/DQoNCg0KLS0gJ1RoaXMgaGlzdG9yaWNh bCBkYXRhIE1VU1QgTk9UIGJlIHVzZWQgYWNyb3NzIG5ldHdvcmtzLCBhbmQgU0hPVUxEIGJlDQpm bHVzaGVkIG9uIG5ldHdvcmsgY2hhbmdlcy7igJkNCg0KVW5jbGVhciB3aGF0IHlvdSBtZWFuIGJ5 IG5ldHdvcmsgY2hhbmdlLCBhbiBleGFtcGxlIGhlcmUgd291bGQgYmUgbmljZS4NCg0KDQovLyDC pzU6IENvbm5lY3Rpb24gQXR0ZW1wdHMNCg0KLS0gJ1RoaXMgZGVsYXkgaXMgcmVmZXJyZWQgdG8g YXMgdGhlICJDb25uZWN0aW9uIEF0dGVtcHQgRGVsYXkiLiAgT25lDQpyZWNvbW1lbmRlZCB2YWx1 ZSBmb3IgdGhpcyBkZWxheSBpcyAyNTAgbWlsbGlzZWNvbmRzLuKAmQ0KDQpIb3cgaXMgdGhpcyB2 YWx1ZSBkZXRlcm1pbmVkPyBUaGlzIGlzIG5vdCB3aGF0IEFwcGxlJ3MgaW1wbGVtZW50YXRpb24g W2FdIA0KZG9lcyByaWdodD8gVGhlbiBob3cgZG8geW91IHJlY29tbWVuZCB0aGlzIHZhbHVlPw0K DQpbYV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50 L21zZzIyNDU1Lmh0bWwNCg0KLS0gJ1RoZSByZWNvbW1lbmRlZCBmb3JtdWxhIGZvciBjYWxjdWxh dGluZyB0aGUgZGVsYXkgYWZ0ZXIgc3RhcnRpbmcgYQ0KY29ubmVjdGlvbiBhdHRlbXB0IGlzOiBN QVgoIDEuMjUgKiBSVFRfTUVBTiArIDQgKiBSVFRfVkFSSUFOQ0UsIDIgKiBSVFRfTUVBTg0KKSwg d2hlcmUgdGhlIFJUVCB2YWx1ZXMgYXJlIGJhc2VkIG9uIHRoZSBzdGF0aXN0aWNzIGZvciBwcmV2 aW91cyBhZGRyZXNzDQp1c2VkLuKAmQ0KDQpIb3cgaXMgdGhpcyBmb3JtdWxhIGRldGVybWluZWQ/ IFdoeSBkb2VzIHRoaXMgZ2l2ZSBnb29kIHJlc3VsdHM/DQoNCi0tICcuLi4gYWxsIG90aGVyIGNv bm5lY3Rpb25zIGF0dGVtcHRzIHRoYXQgaGF2ZSBub3QgeWV0DQogICBzdWNjZWVkZWQgU0hPVUxE IGJlIGNhbmNlbGxlZC7igJkNCg0KSSB0aGluayB5b3UgbWVhbiB0ZXJtaW5hdGVkLg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClZhaWJoYXYgQmFqcGFpDQp3d3cudmFpYmhhdmJh anBhaS5jb20NCg0KUG9zdGRvY3RvcmFsIFJlc2VhcmNoZXINClRVIE11bmljaCwgR2VybWFueQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0= From nobody Mon Apr 10 06:06: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 F3E07128959 for ; Mon, 10 Apr 2017 06:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 BDJn8ISFwFQB for ; Mon, 10 Apr 2017 06:06:32 -0700 (PDT) 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 E59F71273E2 for ; Mon, 10 Apr 2017 06:06:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2CB97A2; Mon, 10 Apr 2017 15:06:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491829588; bh=lJomDFKtc5nAX86D81yodgWfQYa+3KSOmjItigz0waQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=HU7JbC1T0lmlDhGoQePfEjHUZSh/whqGE3cfmubEh3jNTehb+zhhYU58LeYV6yeEU h/hOolc3PDPRL11RlVm5Ksa3LpMIjLoEpUzpGJ2AjfDLjkf2uoHko1duLhBJtdTZQ3 eWNq7yIShH7aVa4jd9V6p+2OCRyi74rjLGwDqEMY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1310B88; Mon, 10 Apr 2017 15:06:28 +0200 (CEST) Date: Mon, 10 Apr 2017 15:06:28 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti cc: IPv6 Operations In-Reply-To: Message-ID: References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <3125FCC8-F68D-418F-920D-8FBE5D34C840@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DB14DF1@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170406211206.DB8A76AA312B@rock.dv.isc.org> <20170407211021.BE32F6B00B6E@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: Subject: [v6ops] IPv6 NS operational problem Re: Making RDNSS a MUST?, hum v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:06:34 -0000 On Sat, 8 Apr 2017, Lorenzo Colitti wrote: > Unfortunately, every time we've looked at the data, the conclusion has > been that it would cause unwarranted user impact. IIRC the most recent > blocker was a major US ISP whose clients would experience breakage if > even just one NS record was dual-stacked. It's not an infrastructure > problem: the servers have supported IPv6 for years, and some zones like > google.fi do have IPv6 NS records. I'd be very interested in understanding the reason for the failure you describe. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 10 10:18:49 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B3F1294EF; Mon, 10 Apr 2017 10:18:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149184472769.3090.16879574400162488716@ietfa.amsl.com> Date: Mon, 10 Apr 2017 10:18:47 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:18:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Happy Eyeballs Version 2: Better Connectivity Using Concurrency Authors : Tommy Pauly David Schinazi Filename : draft-ietf-v6ops-rfc6555bis-00.txt Pages : 9 Date : 2017-04-09 Abstract: Many communication protocols operated over the modern Internet uses host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a higher chance of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 10 10:23:32 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E597129517 for ; Mon, 10 Apr 2017 10:23:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149184501111.3140.4006987129001604817.idtracker@ietfa.amsl.com> Date: Mon, 10 Apr 2017 10:23:31 -0700 From: IETF Secretariat Archived-At: Subject: [v6ops] Milestones changed for v6ops WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:23:31 -0000 Changed milestone "Update RFC 6555 with experience", added draft-ietf-v6ops-rfc6555bis to milestone, removed draft-pauly-v6ops-happy-eyeballs-update from milestone. URL: https://datatracker.ietf.org/wg/v6ops/about/ From nobody Mon Apr 10 10: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 7217B129A9B for ; Mon, 10 Apr 2017 10:43:51 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=apple.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 qKcw3tzqN-JE for ; Mon, 10 Apr 2017 10:43:49 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 95478129A8F for ; Mon, 10 Apr 2017 10:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491846227; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=exxFK2jteyDNk1AvlBO0NAuUyWY+WrOfBHZt1IghPjg=; b=kOLXsXtp6Y/Cf3Zo+zugzXS+roBkuBTskPnTMjF26Q5xyqFeOnGFh4QbbF0YxXeP Y2Bj+6wgfik+pETydCwSSG3PGviPc6C5qIgPMnYqeHrKrtta6e9PX+aXvm6EskQa qYA6Q7w+ZA9atw7SrX/Ad3KI+BrAjltWrI9XIRik3H8Tyl+nrqQQiQdl0W3559Dn JWJGCLFVpHTp9Z9TRRnDTC60tIbQmwZzJ/7bnUM+Dxi8LpNw7+DGjJjGespYuk1T Hxy+Ed1doAM1xNoMrRAaSdFb9uzLsSoJTX860G5jXfASeAXxnpkt0aeZ8Ay/CpS/ B2avocRibP9ApBnlrAVpRQ==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id BB.C8.23264.354CBE85; Mon, 10 Apr 2017 10:43:47 -0700 (PDT) X-AuditID: 11ab0216-e218d9a000005ae0-99-58ebc4538070 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay7.apple.com (Apple SCV relay) with SMTP id 8C.63.19944.254CBE85; Mon, 10 Apr 2017 10:43:47 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hn1Bn/5Hhfsa8HxFC4XKqw)" Received: from [17.153.19.54] (unknown [17.153.19.54]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OO7008N2FWVV920@kencur.apple.com> for v6ops@ietf.org; Mon, 10 Apr 2017 10:43:46 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: References: <149184472785.3090.17232934855800683894.idtracker@ietfa.amsl.com> To: IPv6 Ops WG Date: Mon, 10 Apr 2017 10:43:45 -0700 X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCYqht85HWEwZ2l6hanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpyjCxgLDvpU/OzsZm9g7HTpYuTkkBAwkfg4fydjFyMXh5DA fkaJPRvWsMIkDkyawA6RWMEosfHfEWaQBK+AoMSPyfdYQGxmgTCJPfvWMkMUTWKS2NH+lQkk ISwgLdF14S7QJA4ONgEtiQNrjCDCUhJfHp1jgZhjI7F5+nOwmUICvhI7Jz0HWywioCCx4/9O sDEsAqoSK/uPsUMcJCvx6flPsIMkBBawSdxcuptpAqPALCQ3zUJyE4StJfH9UStQnAPIlpc4 eF4WIqwp8ezeJ3YIW1viybsLrAsY2VYxCucmZuboZuYZGeklFhTkpOol5+duYgQF8momsR2M 914bHmIU4GBU4uFdsOh1hBBrYllxZe4hRmkOFiVx3sAvryKEBNITS1KzU1MLUovii0pzUosP MTJxcEo1MFZMtir3SWvxeN2acGf92o/qbyad/7Al4e2Ev6FfRB9serrXvH5KZN3BZdMjLZVm dp9cJCVwMyLDZ3FwVt3vuasPal2QmvJhy4oE76AP540Tblc7t3VmlIRzHjdNme3I18P8ymt+ /4zA+1OLecpX1V2xC6+a2VFmf/vgm//9s5Z19F14JPVJdp8SS3FGoqEWc1FxIgA/CqsQRQIA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUiON1OTTf4yOsIg/5Jghanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpyjCxgLDvpU/OzsZm9g7HTpYuTkkBAwkTgwaQJ7FyMXh5DA CkaJjf+OMIMkeAUEJX5MvscCYjMLhEns2beWGaJoEpPEjvavTCAJYQFpia4Ld1m7GDk42AS0 JA6sMYIIS0l8eXSOBWKOjcTm6c/BZgoJ+ErsnPScFcQWEVCQ2PF/J9gYFgFViZX9x9ghDpKV +PT8J/sERt5ZSM6YheQMCFtL4vujVqA4B5AtL3HwvCxEWFPi2b1P7BC2tsSTdxdYFzCyrWIU KErNSaw010ssKMhJ1UvOz93ECAq7hsLUHYyNy60OMQpwMCrx8BZUvI4QYk0sK67MPcQowcGs JMKrdwgoxJuSWFmVWpQfX1Sak1p8iHEiI9DRE5mlRJPzgVGRVxJvaGJiYGJsbGZsbG5iTkth JXHeG4ufRwgJpCeWpGanphakFsEcxcTBKdXAyO1xNr71iu3pv8mLz6bwcVhtmcx+fZvR7FO6 LBGGuZU7c5aFiSVM2qgUxGrC/LN1AeP5ryy7av7OtLeqdYtpy7+3tWuateOkmZ4q960Mf+/a 4fmrRJ0jLFCyPsBD2fHr1YbzQlI3jTP9toZ91Lz20ml6UNSuI/pFFfOfbDweJlB2bsvX7c5r lViKMxINtZiLihMB09en/a4CAAA= Archived-At: Subject: [v6ops] Happy Eyeballs v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:43:51 -0000 --Boundary_(ID_hn1Bn/5Hhfsa8HxFC4XKqw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi v6ops, We've updated our "Update to Happy Eyeballs" document to address feedback received so far: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00 Main changes since the previous version: - Draft is now a v6ops working group document - Draft name is now rfc6555bis - Title changed to "Happy Eyeballs Version 2: Better Connectivity Using Concurrency" The rationale here is that this is different enough from RFC6555 that it warrants a slightly new name, however we didn't want to completely change the name since people always refer to the old name which causes confusion (e.g. SSL/TLS). For reference RFC6555 has title "Happy Eyeballs: Success with Dual-Stack Hosts" - Draft now obsoletes 6555 (if approved) - Changed wording to be more generic than IPv6/v4 fallback - Added details on timeout computation and bounds - Added possibility to change timeout without updating document - Added a limitations sections declaring PMTUD and application-layer failures out of scope Diff viewer: https://tools.ietf.org/rfcdiff?url1=draft-pauly-v6ops-happy-eyeballs-update-01&url2=draft-ietf-v6ops-rfc6555bis-00.txt https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-pauly-v6ops-happy-eyeballs-update-01&url2=draft-ietf-v6ops-rfc6555bis-00.txt Thanks to everyone who sent feedback, and please let us know if this addresses yours. David > Begin forwarded message: > > > A new version of I-D, draft-ietf-v6ops-rfc6555bis-00.txt > has been successfully submitted by David Schinazi and posted to the > IETF repository. > > Name: draft-ietf-v6ops-rfc6555bis > Revision: 00 > Title: Happy Eyeballs Version 2: Better Connectivity Using Concurrency > Document date: 2017-04-08 > Group: v6ops > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc6555bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ > Htmlized: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-00 > > > Abstract: > Many communication protocols operated over the modern Internet uses > host names. These often resolve to multiple IP addresses, each of > which may have different performance and connectivity > characteristics. Since specific addresses or address families (IPv4 > or IPv6) may be blocked, broken, or sub-optimal on a network, clients > that attempt multiple connections in parallel have a higher chance of > establishing a connection sooner. This document specifies > requirements for algorithms that reduce this user-visible delay and > provides an example algorithm. --Boundary_(ID_hn1Bn/5Hhfsa8HxFC4XKqw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi v6ops,

We've updated our "Update to Happy Eyeballs" document to = address feedback received so far:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00<= /div>

Main changes = since the previous version:
- Draft is now a v6ops = working group document
- Draft name is now = rfc6555bis
- Title changed to "Happy Eyeballs = Version 2: Better Connectivity Using Concurrency"
= The rationale here is that this is different enough from RFC6555 = that it warrants
a slightly new name, however we = didn't want to completely change the name
since = people always refer to the old name which causes confusion (e.g. = SSL/TLS).
For reference RFC6555 has title = "Happy Eyeballs: Success with Dual-Stack Hosts"
- = Draft now obsoletes 6555 (if approved)
- Changed = wording to be more generic than IPv6/v4 fallback
- = Added details on timeout computation and bounds
- = Added possibility to change timeout without updating document
- Added a limitations sections declaring PMTUD and = application-layer failures out of scope

Diff viewer:
https://tools.ietf.org/rfcdiff?url1=3Ddraft-pauly-v6ops-happy-e= yeballs-update-01&url2=3Ddraft-ietf-v6ops-rfc6555bis-00.txt
<= div class=3D"">https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Dd= raft-pauly-v6ops-happy-eyeballs-update-01&url2=3Ddraft-ietf-v6ops-rfc6= 555bis-00.txt

Thanks to everyone who sent feedback, and please let us know = if this addresses yours.
David


Begin forwarded message:

A new version of I-D, draft-ietf-v6ops-rfc6555bis-00.txt
has been successfully submitted by David Schinazi and posted = to the
IETF repository.

Name: = = draft-ietf-v6ops-rfc6555bis
Revision: 00
Title:= = Happy Eyeballs Version 2: Better Connectivity Using = Concurrency
Document date: 2017-04-08
Group:= = v6ops
Pages: 9
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc6555bi= s-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/
Htmlized:       https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00<= br class=3D"">Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555b= is-00


Abstract:
  Many communication protocols operated over the = modern Internet uses
  host names.  These = often resolve to multiple IP addresses, each of
=   which may have different performance and connectivity
  characteristics.  Since specific addresses = or address families (IPv4
  or IPv6) may be = blocked, broken, or sub-optimal on a network, clients
=   that attempt multiple connections in parallel have a higher = chance of
  establishing a connection sooner. =  This document specifies
  requirements = for algorithms that reduce this user-visible delay and
=   provides an example algorithm.

= --Boundary_(ID_hn1Bn/5Hhfsa8HxFC4XKqw)-- From nobody Mon Apr 10 12:32: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 E2DAC129AB6 for ; Mon, 10 Apr 2017 12:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 AELL2qmqaW5x for ; Mon, 10 Apr 2017 12:32:26 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 16B55129AC5 for ; Mon, 10 Apr 2017 12:32:26 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id z109so15606482wrb.1 for ; Mon, 10 Apr 2017 12:32:25 -0700 (PDT) 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=oZrf2sooz+knvjN2mV3TNJoBE+3bRXAQI9Oti1kkyuU=; b=jZtdmYz1TT1+m/pq5hhwJYvWQsauJWO7/GdPQ5syVscxrE9eE0S0tHSxUjF6gtIEIt I5Uh/QSPtGa4dSHiKreu43vorkBAEJsLvqaO9hw7biV2Spj2b2CKB5oNg5xIm7kWw9u6 U4GQbISwNBVWLg5/ZKueWmUf6FKTjQI1mGVaVeckW7TAnGVB1WKNPdVU7DeTwVw6tXbS kNBu1pTeWylzWaHskd6tpJ4E07+axdgk6jXmxrUoooCpYzsLMBCpb+mR/tm57VA6vbmR ea7CvDvdirHD8ybBY1UB/hXpPk56oig5wOm8Y1SgKcm2eTPLDFwBuvKO32EBMQG5/U12 +qeA== 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=oZrf2sooz+knvjN2mV3TNJoBE+3bRXAQI9Oti1kkyuU=; b=XraK4uvPPUdlbBjkbjpAFhu+9kGa+s2Spb2lBqSDcmjf2kAokdgSYDHenPn0iIYxxK lkkKgQEL7NvksKfFHEpgkxidKCYTES13Qc2H8QcE+ZroV3/pXlqIiSuXAq47bxzAur23 mtbKSIpXTVy67WFVXFeVRtFlixVVkUpU3H2oZmmj6EH5pSDpQtgfpKB9UZ/2jsh8c+KC VStq7E+UuaLtbeoHR67go21/g4Z9/mzO62OlwBi0cluUHf5eDwlPUgIdZZB3zZe5a4y3 4U5rBsW1BFPHoHhmyTVu0su6CTelOOw4cxn5X1Ma1T/Pi0ML27S4mfuX33hOcj8bxdAg r2sA== X-Gm-Message-State: AFeK/H2s+ivN8ane7eSn9wEBp9C8rifIVqMahHmBgR0mvphRSMIx1yx/ZVdYUX6s8FEOxQ== X-Received: by 10.223.128.194 with SMTP id 60mr39819182wrl.175.1491852744440; Mon, 10 Apr 2017 12:32:24 -0700 (PDT) Received: from 210.66.20.149.in-addr.arpa (210.66.20.149.in-addr.arpa. [149.20.66.210]) by smtp.gmail.com with ESMTPSA id j2sm1199736wrd.28.2017.04.10.12.32.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 12:32:23 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <64DBCDD0-187C-42DD-A17B-7FE249874546@gmail.com> Date: Mon, 10 Apr 2017 12:32:20 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] State of play in April, with comments and questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:32:28 -0000 This is the state in the working group at this instant. WG: In WG Last Call 2017-03-15 draft-ietf-v6ops-unique-ipv6-prefix-per-host 2017-03-15 draft-ietf-v6ops-v4v6-xlat-prefix WG: Unupdated WG Document 2016-11-13 draft-ietf-v6ops-design-choices WG: Updated WG Document 2017-04-10 draft-ietf-v6ops-rfc6555bis 2017-04-06 draft-ietf-v6ops-rfc7084-bis 2017-03-13 draft-ietf-v6ops-ula-usage-considerations Individual Submission: Unupdated=20 2017-03-27 draft-templin-v6ops-pdhost 2017-03-13 draft-gont-v6ops-host-configuration 2017-03-13 draft-petrescu-v6ops-ipv6-power-ipv4 2017-02-24 draft-shi-v6ops-caba 2017-02-18 draft-ali-ipv6rtr-reqs 2017-01-28 draft-xli-v6ops-cernet-deployment Note that the WGLC for draft-ietf-v6ops-unique-ipv6-prefix-per-host = opened March 14 closes tomorrow, and there has been little comment. The = chairs would really appreciate commentary... I will open a two week WGLC on draft-ietf-v6ops-v4v6-xlat-prefix = immediately following the close of that WGLC.=20 I note draft-ietf-v6ops-ula-usage-considerations as "updated" although = the date is before IETF 98. That's because we didn't discuss it. I'm not = sensing a groundswell of support for a interim meeting in May where we = might, so let me simply say that a review of the document on-list would = be appreciated. We have also had no comment from the working group on = draft-petrescu-v6ops-ipv6-power-ipv4, which was similarly filed late and = could be discussed in an interim meeting. Interest? I'm expecting two more working group document updates, = draft-ietf-v6ops-design-choices and one resulting from = draft-ali-ipv6rtr-reqs. New individual submissions are also welcome, as = always. Following on the charter change, any commentary on networks = considering turning native IPv4 off (whether that's to simplify to = IPv6-only or simply to move IPv4 to an overlay) is also welcome.= From nobody Mon Apr 10 13:00: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 6B39F129AB7 for ; Mon, 10 Apr 2017 13:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4-QAoOpF6FR for ; Mon, 10 Apr 2017 13:00:12 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44242127241 for ; Mon, 10 Apr 2017 13:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491854410; x=1492459210; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=AJ1j/p3UAd1t5uCyCnY/8Akdh QVjEoS7m7O97t06CRE=; b=UzkvrLFor7Lj1bvykHblCzWdYlAg9aW0mhXUD5yxn K9kETxQkYWIKpOcZWj9ofJITtGkOOSQOsf7/XsQTGQcHiO/0bQLBdQ2qh1tdGHu8 4/n/kB148xcmreLl4MoeJc/D6I+7rcVB0bhNOmNRrRzFI/J/2ktHSBKoxUIIGzMB yU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=mvibmZxfdQtaMzdsuPs7UqNuIOlfcBx/4zdSM19GJJgXxFRQKqGmLs4XBK9O meyBAWTSntIWG/mpnRYtlRF7i6k1Mu1gjGUAAQBiY8RH7F4pEPLv+eBQF 7MRqduKunAFkX2TFmy0yZP4yg5lHhxU5rWv4enWV59KlAlr5M2bAkw=; X-MDAV-Processed: mail.consulintel.es, Mon, 10 Apr 2017 22:00:10 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 10 Apr 2017 22:00:09 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005405827.msg for ; Mon, 10 Apr 2017 22:00:08 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170410:md50005405827::NJ7BM66rAz2Pn/Ap:0000LC0D X-Return-Path: prvs=12734d7f60=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Mon, 10 Apr 2017 22:00:03 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <931B0ECE-B13D-4682-B2B5-DC436F07486C@consulintel.es> Thread-Topic: [v6ops] State of play in April, with comments and questions References: <64DBCDD0-187C-42DD-A17B-7FE249874546@gmail.com> In-Reply-To: <64DBCDD0-187C-42DD-A17B-7FE249874546@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] State of play in April, with comments and questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 20:00:14 -0000 I=E2=80=99ve read again, both: draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 and draft-ietf-v6ops-v4v6-xlat-prefix-00 and agree with their contents, and don=E2=80=99t see any reason for them to= not pass the WGLC. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: Fecha: lunes, 10 de abril de 2017, 21:32 Para: IPv6 Operations Asunto: [v6ops] State of play in April, with comments and questions This is the state in the working group at this instant. =20 WG: In WG Last Call 2017-03-15 draft-ietf-v6ops-unique-ipv6-prefix-per-host 2017-03-15 draft-ietf-v6ops-v4v6-xlat-prefix =20 WG: Unupdated WG Document 2016-11-13 draft-ietf-v6ops-design-choices =20 WG: Updated WG Document 2017-04-10 draft-ietf-v6ops-rfc6555bis 2017-04-06 draft-ietf-v6ops-rfc7084-bis 2017-03-13 draft-ietf-v6ops-ula-usage-considerations =20 Individual Submission: Unupdated=20 2017-03-27 draft-templin-v6ops-pdhost 2017-03-13 draft-gont-v6ops-host-configuration 2017-03-13 draft-petrescu-v6ops-ipv6-power-ipv4 2017-02-24 draft-shi-v6ops-caba 2017-02-18 draft-ali-ipv6rtr-reqs 2017-01-28 draft-xli-v6ops-cernet-deployment =20 Note that the WGLC for draft-ietf-v6ops-unique-ipv6-prefix-per-host ope= ned March 14 closes tomorrow, and there has been little comment. The chairs= would really appreciate commentary... =20 I will open a two week WGLC on draft-ietf-v6ops-v4v6-xlat-prefix immedi= ately following the close of that WGLC.=20 =20 I note draft-ietf-v6ops-ula-usage-considerations as "updated" although = the date is before IETF 98. That's because we didn't discuss it. I'm not se= nsing a groundswell of support for a interim meeting in May where we might,= so let me simply say that a review of the document on-list would be apprec= iated. =20 We have also had no comment from the working group on draft-petrescu-v6= ops-ipv6-power-ipv4, which was similarly filed late and could be discussed = in an interim meeting. Interest? =20 I'm expecting two more working group document updates, draft-ietf-v6ops= -design-choices and one resulting from draft-ali-ipv6rtr-reqs. New individu= al submissions are also welcome, as always. Following on the charter change= , any commentary on networks considering turning native IPv4 off (whether t= hat's to simplify to IPv6-only or simply to move IPv4 to an overlay) is als= o welcome. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Apr 10 23:24: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 604E8126CF9 for ; Mon, 10 Apr 2017 23:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 MXY_ODEXIT1c for ; Mon, 10 Apr 2017 23:24:04 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB34B12709D for ; Mon, 10 Apr 2017 23:24:03 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id F2948405D6; Tue, 11 Apr 2017 08:24:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 5C6D6160087; Tue, 11 Apr 2017 08:23:50 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 08:23:50 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSq/r4UyGW5qWPi0GDxpk71O+v4qG/t9sA Date: Tue, 11 Apr 2017 06:23:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 06:24:05 -0000 SGkgSm9yZGksIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKT1JESSBQQUxFVA0KPiBNQVJUSU5FWg0KPiBF bnZvecOpwqA6IGRpbWFuY2hlIDIgYXZyaWwgMjAxNyAyMzo0OA0KPiDDgMKgOiB2Nm9wc0BpZXRm Lm9yZw0KPiBPYmpldMKgOiBSZTogW3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXY2b3BzLXJmYzcwODQtYmlzLQ0KPiAwMC50eHQNCj4gDQo+IEhpIGFsbCwNCj4gDQo+ IEnigJl2ZSBzdWJtaXR0ZWQgV0cgMDAgZm9yIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12Nm9wcy1yZmM3MDg0LWJpcw0KPiANCj4g SSB0cmllZCB0byBpbmNvcnBvcmF0ZSBhbGwgdGhlIGlucHV0cyB0aGF0IEkgY2FwdHVyZWQgaW4g dGhlIG1lZXRpbmcsDQo+IGhvcGVmdWxseSBkaWRu4oCZdCBtaXNzIGFueXRoaW5nISwgcGx1cyBz b21lIG1pbm9yIGVkaXRzLg0KPiANCj4gSGVyZSBpcyB0aGUgc3VtbWFyeSBmb3IgdGhlIGNoYW5n ZXM6DQo+IA0KPiAxKSBBZGRlZCBhbiBhbm5leCAoQSkgcmVnYXJkaW5nIHRoZSBjb2RlIGNvbnNp ZGVyYXRpb25zIGFzIEkgbWVudGlvbiBpbiBteQ0KPiBwcmVzZW50YXRpb24uDQo+IDIpIEFkZGVk IGFuIGFubmV4IChCKSB3aXRoIHRoZSBjaGFuZ2VzIGZyb20gdGhlIG9yaWdpbmFsIFJGQzcwODQu DQo+IDMpIFRyYW5zaXRpb24gbWVjaGFuaXNtcyBpbiBhbHBoYWJldGljYWwgb3JkZXIuDQo+IDQp IENoYW5nZWQgdGhlIElQdjYtaW4tSVB2NCB0cmFuc2l0aW9uIG1lY2hhbmlzbSAoNlJEIGFuZCA2 aW40KSB0byBNQVkNCj4gaW5zdGVhZCBvZiBTSE9VTEQuDQoNCltNZWRdIEkgc3VnZ2VzdCB0byBk ZWxldGUgdGhlc2UgdHdvIHNlY3Rpb25zOiANCg0KICAgICAgIDUuNC4yLiAgNmluNCAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2DQogICAgICAgNS40 LjMuICA2cmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTcNCg0KVGhlIHJldmlzaW9uIG9mIFJGQzcwODQgc2hvdWxkIElNSE8gZm9jdXMgb24gSVB2 NiBmZWF0dXJlcyArIHJlcXVpcmVtZW50cyB0byBvZmZlciBJUHY0IHNlcnZpY2UgY29udGludWl0 eSBvdmVyIGFuIElQdjYgbmV0d29yay4gDQoNCj4gNSkgQWRkZWQgYSBuZXcgc2VjdGlvbiByZWdh cmRpbmcgSVB2NCBtdWx0aWNhc3Qgc3VwcG9ydCBpbiBJUHY2LW9ubHktV0FOLg0KPiA2KSBBZGRl ZCBzb21lIHRleHQgcmVnYXJkaW5nIHRoZSBQQ1Agc3VwcG9ydCB0byBsZWFybiBQTEFUIGluZm8g aW4gNDY0WExBVA0KPiAoUkZDIDcyMjUpLg0KPiANCj4gSeKAmXZlIG9uZSBxdWVzdGlvbiBmb3Ig dGhlIFdHLg0KPiANCj4gSW4gYWxsIHRoZSBJUHY0LWluLUlQdjYgdHJhbnNpdGlvbiBtZWNoYW5p c21zLCBJ4oCZbSByZXF1aXJpbmc6DQo+IOKAnFRoZSBDRSByb3V0ZXIgTVVTVCBzdXBwb3J0IHRo ZSBESENQdjQtb3Zlci1ESENQdjYgKERIQ1A0bzYpIHRyYW5zcG9ydA0KPiBkZXNjcmliZWQgaW4g W1JGQzczNDFdLuKAnQ0KPiANCj4gSSBnb3QgYSBjb21tZW50IHRoYXQgdGhpcyBpcyBub3QgbmVl ZGVkLCBob3dldmVyLCBteSBmZWVsaW5nIGlzIHRoYXQgdGhlDQo+IGNvbmZpZ3VyYXRpb24gb2Yg Y2VydGFpbiBJUHY0IHBhcmFtZXRlcnMgZm9yIHRoZSBDUEUsIGR1cmluZyB0aGUNCj4gdHJhbnNp dGlvbiwgYXJlIHN0aWxsIG5lZWRlZCBhbmQgdGhlIElTUCBtYXkgbmVlZCB0aGF0Lg0KPiANCj4g U28sIHRoZSBxdWVzdGlvbiBpcywgd2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhpcz8NCg0KW01l ZF0gREhDUHY0LW92ZXItREhDUHY2IGlzIG5vdCBhIHJlcXVpcmVkIGZvciBtYW55IG9mIHRoZSB0 ZWNobmlxdWVzIGxpc3RlZCBpbiB0aGlzIGRyYWZ0LiBJIHN1Z2dlc3QgdG8gZGVsZXRlIGl0IGZy b20gdGhlIHRleHQuIA0KDQo+IA0KPiBQbGVhc2UsIG5vdGUgdGhhdCB0aGUgb3JpZ2luYWwgUkZD NzA4NCBkaWRu4oCZdCBjb25zaWRlcmVkIHRoaXMgKFJGQzczNDENCj4gZGlkbuKAmXQgZXhpc3Qg d2hlbiBpdCB3YXMgcHVibGlzaGVkKSwgc28gdGhlIGFjdHVhbCB2ZXJzaW9uIGlzIHJlcXVlc3Rp bmcNCj4gdGhpcyBub3QganVzdCBmb3IgdGhlIG5ldyBzdXBwb3J0ZWQgdHJhbnNpdGlvbiBtZWNo YW5pc21zIChsdzRvNiwgTUFQIFQvRSwNCj4gNDY0WExBVCksIGJ1dCBhbHNvIGZvciBEUy1MaXRl Lg0KPiANCj4gUGxlYXNlIHByb3ZpZGUgaW5wdXRzIEFTQVAuIEkgd2lsbCBsaWtlIHRvIGF2b2lk IGhhdmluZyB0aGlzIGRvY3VtZW50DQo+IHNsZWVwaW5nIGZvciB0b28gbWFueSB3ZWVrcywgYW5k IG15IGdvYWwgaXMgdG8gcHVibGlzaCBhIG5ldyB2ZXJzaW9uIGluDQo+IGFib3V0IDIgd2Vla3Mg d2l0aCBhbnkgY29tbWVudHMgcmVjZWl2ZWQuDQo+IA0KDQpbTWVkXSBJIGhhdmUgdGhlIGZvbGxv d2luZyBjb21tZW50cyBhYm91dCB0aGUgTkFUIHJlcXVpcmVtZW50czoNCg0KT0xEOg0KICAgTFc0 TzYtNDogIFRoZSBJUHY2IENFIHJvdXRlciBNVVNUIHBlcmZvcm0gSVB2NCBOZXR3b3JrIEFkZHJl c3MNCiAgICAgICAgICAgICBUcmFuc2xhdGlvbiAoTkFUKSBvbiBJUHY0IHRyYWZmaWMgZW5jYXBz dWxhdGVkIHVzaW5nIGx3NG82Lg0KDQpUaGlzIG9uZSBzaG91bGQgbWVudGlvbiBwb3J0IHJlc3Ry aWN0ZWQgTkFULiBGV0lXLCB5b3UgY2FuIHJldXNlIHRoZSBzYW1lIHdvcmRpbmcgaW4gUkZDNzU5 NjoNCg0KIiAgQW4gbHdCNCBNVVNUIHN1cHBvcnQgZHluYW1pYyBwb3J0LXJlc3RyaWN0ZWQgSVB2 NCBhZGRyZXNzDQogICBwcm92aXNpb25pbmcuICBUaGUgcG9ydC1zZXQgYWxnb3JpdGhtIGZvciBw cm92aXNpb25pbmcgdGhpcyBpcw0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xIG9mIFtSRkM3 NTk3XS4gIEZvciBsdzRvNiwgdGhlIG51bWJlciBvZg0KICAgYS1iaXRzIFNIT1VMRCBiZSAwLCB0 aHVzIGFsbG9jYXRpbmcgYSBzaW5nbGUgY29udGlndW91cyBwb3J0IHNldCB0bw0KICAgZWFjaCBs d0I0LiIgDQoNCg0KT0xEOg0KICAgTUFQKi00OiAgVGhlIElQdjYgQ0Ugcm91dGVyIE1VU1QgcGVy Zm9ybSBJUHY0IE5ldHdvcmsgQWRkcmVzcw0KICAgICAgICAgICAgVHJhbnNsYXRpb24gKE5BVCkg b24gSVB2NCB0cmFmZmljIGVuY2Fwc3VsYXRlZCB1c2luZyBNQVAtKi4NCg0KSWRlbSBhcyBhYm92 ZS4gUG9ydC1yZXN0cmljdGVkIE5BVCBzaG91bGQgYmUgbWVudGlvbmVkIGV4cGxpY2l0bHkuIFlv dSBjYW4gcmV1c2UgdGhpcyB0ZXh0IGZyb20gUkZDNzU5Ny9SRkM3NTk5Og0KDQogICBUaGUgTkFU NDQgaW1wbGVtZW50ZWQgaW4gdGhlIE1BUCBDRSBTSE9VTEQgY29uZm9ybSB0byB0aGUgYmVoYXZp b3INCiAgIGFuZCBiZXN0IGN1cnJlbnQgcHJhY3RpY2VzIGRvY3VtZW50ZWQgaW4gW1JGQzQ3ODdd LCBbUkZDNTUwOF0sIGFuZA0KICAgW1JGQzUzODJdLiAgSW4gTUFQIGFkZHJlc3Mtc2hhcmluZyBt b2RlIChkZXRlcm1pbmVkIGJ5IHRoZSBNQVANCiAgIGRvbWFpbiAvIHJ1bGUgY29uZmlndXJhdGlv biBwYXJhbWV0ZXJzKSwgdGhlIG9wZXJhdGlvbiBvZiB0aGUgTkFUNDQNCiAgIE1VU1QgYmUgcmVz dHJpY3RlZCB0byB0aGUgYXZhaWxhYmxlIHBvcnQgbnVtYmVycyBkZXJpdmVkIHZpYSB0aGUNCiAg IEJhc2ljIE1hcHBpbmcgUnVsZS4NCg0KRnVydGhlciwgSSBzdWdnZXN0IHRvIHJlbW92ZSBwb2lu dGVycyB0byBpbmRpdmlkdWFsIGRyYWZ0cy4gDQoNClRoYW5rIHlvdS4NCg0KPiBSZWdhcmRzLA0K PiBKb3JkaQ0KPiANCj4gDQo+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IERlOiA8aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiBSZXNwb25kZXIgYTogPGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4NCj4gRmVjaGE6IGRvbWluZ28sIDIgZGUgYWJyaWwgZGUgMjAxNywgMjI6NTcNCj4g UGFyYTogSm9yZGkgUGFsZXQgPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPiwgSm9yZGkgUGFs ZXQgTWFydGluZXoNCj4gPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0KPiBBc3VudG86IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdjZvcHMtcmZjNzA4NC1iaXMtMDAudHh0 DQo+IA0KPiANCj4gICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12Nm9wcy1yZmM3MDg0 LWJpcy0wMC50eHQNCj4gICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9y ZGkgUGFsZXQgTWFydGluZXogYW5kIHBvc3RlZCB0bw0KPiB0aGUNCj4gICAgIElFVEYgcmVwb3Np dG9yeS4NCj4gDQo+ICAgICBOYW1lOgkJZHJhZnQtdjZvcHMtcmZjNzA4NC1iaXMNCj4gICAgIFJl dmlzaW9uOgkwMA0KPiAgICAgVGl0bGU6CQlCYXNpYyBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3Vz dG9tZXIgRWRnZSBSb3V0ZXJzDQo+ICAgICBEb2N1bWVudCBkYXRlOgkyMDE3LTAzLTMxDQo+ICAg ICBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiAgICAgUGFnZXM6CQkyOQ0KPiAgICAg VVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC12Nm9wcy0NCj4gcmZjNzA4NC1iaXMtMDAudHh0DQo+ICAgICBTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdjZvcHMtcmZjNzA4NC0NCj4gYmlz Lw0KPiAgICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC12Nm9wcy1yZmM3MDg0LWJpcy0wMA0KPiAgICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtdjZvcHMtDQo+IHJmYzcwODQtYmlzLTAw DQo+IA0KPiANCj4gICAgIEFic3RyYWN0Og0KPiAgICAgICAgVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgcmVxdWlyZW1lbnRzIGZvciBhbiBJUHY2IEN1c3RvbWVyIEVkZ2UgKENFKQ0KPiAgICAgICAg cm91dGVyLiAgU3BlY2lmaWNhbGx5LCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1l bnQgZm9jdXNlcw0KPiAgICAgICAgb24gdGhlIGJhc2ljIHByb3Zpc2lvbmluZyBvZiBhbiBJUHY2 IENFIHJvdXRlciBhbmQgdGhlIHByb3Zpc2lvbmluZw0KPiAgICAgICAgb2YgSVB2NiBob3N0cyBh dHRhY2hlZCB0byBpdC4gIFRoZSBkb2N1bWVudCBhbHNvIGNvdmVycyBzZXZlcmFsDQo+ICAgICAg ICB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcywgYXMgcmVxdWlyZWQgaW4gYSB3b3JsZCB3aGVyZSBJ UHY0DQo+IGFkZHJlc3Nlcw0KPiAgICAgICAgYXJlIG5vIGxvbmdlciBhdmFpbGFibGUsIHNvIGhv c3RzIGluIHRoZSBjdXN0b21lciBMQU5zIHdpdGggSVB2NC0NCj4gb25seQ0KPiAgICAgICAgb3Ig SVB2Ni1vbmx5IGFwcGxpY2F0aW9ucyBvciBkZXZpY2VzLCByZXF1aXJpbmcgdG8gY29tbXVuaWNh dGUgd2l0aA0KPiAgICAgICAgSVB2NC1vbmx5IHNlcnZpY2VzIGF0IHRoZSBJbnRlcm5ldCwgYXJl IGFibGUgdG8gZG8gc28uICBUaGUNCj4gZG9jdW1lbnQNCj4gICAgICAgIG9ic29sZXRlcyBSRkMg NzA4NC4NCj4gDQo+IA0KPiANCj4gDQo+ICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+ICAg ICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KPiANCj4gICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KPiANCj4g DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KPiBJUHY0IGlzIG92ZXINCj4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5l dyBJbnRlcm5ldCA/DQo+IGh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMNCj4gVGhlIElQdjYgQ29t cGFueQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24g d2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRp b24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwocykg bmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdh cmUNCj4gdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBv ZiB0aGUgY29udGVudHMgb2YgdGhpcw0KPiBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVk IGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZv cHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0K From nobody Tue Apr 11 00:13: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 D709212942F for ; Tue, 11 Apr 2017 00:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5yTGJ8NkvHi5 for ; Tue, 11 Apr 2017 00:13:12 -0700 (PDT) Received: from tyo161.gate.nec.co.jp (tyo161.gate.nec.co.jp [114.179.232.161]) (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 8858C1292D0 for ; Tue, 11 Apr 2017 00:13:12 -0700 (PDT) Received: from mailgate02.nec.co.jp ([114.179.233.122]) by tyo161.gate.nec.co.jp (8.15.1/8.15.1) with ESMTPS id v3B7D2Ex019999 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Apr 2017 16:13:02 +0900 Received: from mailsv01.nec.co.jp (mailgate-v.nec.co.jp [10.204.236.94]) by mailgate02.nec.co.jp (8.15.1/8.15.1) with ESMTP id v3B7D2DE018500; Tue, 11 Apr 2017 16:13:02 +0900 Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv01.nec.co.jp (8.15.1/8.15.1) with ESMTP id v3B7BTbq022801; Tue, 11 Apr 2017 16:13:02 +0900 Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.152] [10.38.151.152]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-2792561; Tue, 11 Apr 2017 16:12:32 +0900 Received: from BPXM24GP.gisp.nec.co.jp ([10.38.151.216]) by BPXC24GP.gisp.nec.co.jp ([10.38.151.152]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 16:12:31 +0900 From: Masanobu Kawashima To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSq/r051VRiY1r8UGAZU/aDYUbgKG/xgjA Date: Tue, 11 Apr 2017 07:12:31 +0000 Message-ID: <81A3232BEF82944C8F23DB1CFE276F0F49392E71@BPXM24GP.gisp.nec.co.jp> References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.141.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 07:13:16 -0000 DQpIaSBKb3JkaSwgDQoNCkkgaGF2ZSBjb21tZW50cy4gDQoNCj4gSW4gYWxsIHRoZSBJUHY0LWlu LUlQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc21zLCBJ4oCZbSByZXF1aXJpbmc6DQo+IOKAnFRoZSBD RSByb3V0ZXIgTVVTVCBzdXBwb3J0IHRoZSBESENQdjQtb3Zlci1ESENQdjYgKERIQ1A0bzYpIHRy YW5zcG9ydCBkZXNjcmliZWQgaW4gW1JGQzczNDFdLuKAnQ0KPiANCj4gSSBnb3QgYSBjb21tZW50 IHRoYXQgdGhpcyBpcyBub3QgbmVlZGVkLCBob3dldmVyLCBteSBmZWVsaW5nIGlzIHRoYXQgdGhl IGNvbmZpZ3VyYXRpb24gb2YgY2VydGFpbiBJUHY0IHBhcmFtZXRlcnMgZm9yDQo+IHRoZSBDUEUs IGR1cmluZyB0aGUgdHJhbnNpdGlvbiwgYXJlIHN0aWxsIG5lZWRlZCBhbmQgdGhlIElTUCBtYXkg bmVlZCB0aGF0Lg0KDQpUaGV5IG1heSBuZWVkIHRoYXQgZnVuY3Rpb24uIEhvd2V2ZXIsIGl0IGRl cGVuZHMgb24gdGhlaXIgbmV0d29yayBlbnZpcm9ubWVudCwgZXRjLiANClNvLCBJIHdpbGwgYWdy ZWUgd2l0aCBpdCBpZiBpdCB3aWxsIGJlICdNQVknLiANCg0KQXMgZm9yIHJlcXVpcmVtZW50IFs0 NjRYTEFULTNdLCBSRkM1NjI1IGlzIG1lbnRpb25lZCBhYm91dCBETlMgUHJveHkgDQpJbXBsZW1l bnRhdGlvbiBHdWlkZWxpbmVzLiBJdCBpcyBub3QganVzdCBmb3IgNDY0WExBVC4gDQpXZSBzaG91 bGQgcmVtb3ZlIGl0IG9yIG1heSB3cml0ZSBpdCBpbiBvdGhlciBzZWN0aW9uIGlmIGl0IGlzIHVz ZWZ1bC4gDQoNClJlZ2FyZHMsIA0KTWFzYW5vYnUgDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PSANCiBORUMgUGxhdGZvcm1zLCBMdGQuICAgICANCiBBY2Nlc3MtRGV2aWNlIERpdmlzaW9uICAN CiBLQVdBU0hJTUEgTWFzYW5vYnUgICAgICANCj09PT09PT09PT09PT09PT09PT09PT09PSANCg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIFttYWlsdG86djZv cHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaDQo+ IFNlbnQ6IE1vbmRheSwgQXByaWwgMDMsIDIwMTcgNjo0OCBBTQ0KPiBUbzogdjZvcHNAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC12Nm9wcy1yZmM3MDg0LWJpcy0wMC50eHQNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEnigJl2 ZSBzdWJtaXR0ZWQgV0cgMDAgZm9yIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12Nm9wcy1yZmM3MDg0LWJpcw0KPiANCj4gSSB0cmll ZCB0byBpbmNvcnBvcmF0ZSBhbGwgdGhlIGlucHV0cyB0aGF0IEkgY2FwdHVyZWQgaW4gdGhlIG1l ZXRpbmcsIGhvcGVmdWxseSBkaWRu4oCZdCBtaXNzIGFueXRoaW5nISwgcGx1cyBzb21lIG1pbm9y DQo+IGVkaXRzLg0KPiANCj4gSGVyZSBpcyB0aGUgc3VtbWFyeSBmb3IgdGhlIGNoYW5nZXM6DQo+ IA0KPiAxKSBBZGRlZCBhbiBhbm5leCAoQSkgcmVnYXJkaW5nIHRoZSBjb2RlIGNvbnNpZGVyYXRp b25zIGFzIEkgbWVudGlvbiBpbiBteSBwcmVzZW50YXRpb24uDQo+IDIpIEFkZGVkIGFuIGFubmV4 IChCKSB3aXRoIHRoZSBjaGFuZ2VzIGZyb20gdGhlIG9yaWdpbmFsIFJGQzcwODQuDQo+IDMpIFRy YW5zaXRpb24gbWVjaGFuaXNtcyBpbiBhbHBoYWJldGljYWwgb3JkZXIuDQo+IDQpIENoYW5nZWQg dGhlIElQdjYtaW4tSVB2NCB0cmFuc2l0aW9uIG1lY2hhbmlzbSAoNlJEIGFuZCA2aW40KSB0byBN QVkgaW5zdGVhZCBvZiBTSE9VTEQuDQo+IDUpIEFkZGVkIGEgbmV3IHNlY3Rpb24gcmVnYXJkaW5n IElQdjQgbXVsdGljYXN0IHN1cHBvcnQgaW4gSVB2Ni1vbmx5LVdBTi4NCj4gNikgQWRkZWQgc29t ZSB0ZXh0IHJlZ2FyZGluZyB0aGUgUENQIHN1cHBvcnQgdG8gbGVhcm4gUExBVCBpbmZvIGluIDQ2 NFhMQVQgKFJGQyA3MjI1KS4NCj4gDQo+IEnigJl2ZSBvbmUgcXVlc3Rpb24gZm9yIHRoZSBXRy4N Cj4gDQo+IEluIGFsbCB0aGUgSVB2NC1pbi1JUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcywgSeKA mW0gcmVxdWlyaW5nOg0KPiDigJxUaGUgQ0Ugcm91dGVyIE1VU1Qgc3VwcG9ydCB0aGUgREhDUHY0 LW92ZXItREhDUHY2IChESENQNG82KSB0cmFuc3BvcnQgZGVzY3JpYmVkIGluIFtSRkM3MzQxXS7i gJ0NCj4gDQo+IEkgZ290IGEgY29tbWVudCB0aGF0IHRoaXMgaXMgbm90IG5lZWRlZCwgaG93ZXZl ciwgbXkgZmVlbGluZyBpcyB0aGF0IHRoZSBjb25maWd1cmF0aW9uIG9mIGNlcnRhaW4gSVB2NCBw YXJhbWV0ZXJzIGZvcg0KPiB0aGUgQ1BFLCBkdXJpbmcgdGhlIHRyYW5zaXRpb24sIGFyZSBzdGls bCBuZWVkZWQgYW5kIHRoZSBJU1AgbWF5IG5lZWQgdGhhdC4NCj4gDQo+IFNvLCB0aGUgcXVlc3Rp b24gaXMsIHdoYXQgZG8geW91IHRoaW5rIGFib3V0IHRoaXM/DQo+IA0KPiBQbGVhc2UsIG5vdGUg dGhhdCB0aGUgb3JpZ2luYWwgUkZDNzA4NCBkaWRu4oCZdCBjb25zaWRlcmVkIHRoaXMgKFJGQzcz NDEgZGlkbuKAmXQgZXhpc3Qgd2hlbiBpdCB3YXMgcHVibGlzaGVkKSwgc28gdGhlIGFjdHVhbA0K PiB2ZXJzaW9uIGlzIHJlcXVlc3RpbmcgdGhpcyBub3QganVzdCBmb3IgdGhlIG5ldyBzdXBwb3J0 ZWQgdHJhbnNpdGlvbiBtZWNoYW5pc21zIChsdzRvNiwgTUFQIFQvRSwgNDY0WExBVCksIGJ1dCBh bHNvIGZvcg0KPiBEUy1MaXRlLg0KPiANCj4gUGxlYXNlIHByb3ZpZGUgaW5wdXRzIEFTQVAuIEkg d2lsbCBsaWtlIHRvIGF2b2lkIGhhdmluZyB0aGlzIGRvY3VtZW50IHNsZWVwaW5nIGZvciB0b28g bWFueSB3ZWVrcywgYW5kIG15IGdvYWwgaXMgdG8gcHVibGlzaA0KPiBhIG5ldyB2ZXJzaW9uIGlu IGFib3V0IDIgd2Vla3Mgd2l0aCBhbnkgY29tbWVudHMgcmVjZWl2ZWQuDQo+IA0KPiBSZWdhcmRz LA0KPiBKb3JkaQ0KPiANCj4gDQo+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IERlOiA8 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiBSZXNwb25kZXIgYTogPGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4NCj4gRmVjaGE6IGRvbWluZ28sIDIgZGUgYWJyaWwgZGUgMjAxNywgMjI6NTcN Cj4gUGFyYTogSm9yZGkgUGFsZXQgPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPiwgSm9yZGkg UGFsZXQgTWFydGluZXogPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0KPiBBc3VudG86IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdjZvcHMtcmZjNzA4NC1iaXMtMDAudHh0 DQo+IA0KPiANCj4gICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12Nm9wcy1yZmM3MDg0 LWJpcy0wMC50eHQNCj4gICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9y ZGkgUGFsZXQgTWFydGluZXogYW5kIHBvc3RlZCB0byB0aGUNCj4gICAgIElFVEYgcmVwb3NpdG9y eS4NCj4gDQo+ICAgICBOYW1lOgkJZHJhZnQtdjZvcHMtcmZjNzA4NC1iaXMNCj4gICAgIFJldmlz aW9uOgkwMA0KPiAgICAgVGl0bGU6CQlCYXNpYyBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3VzdG9t ZXIgRWRnZSBSb3V0ZXJzDQo+ICAgICBEb2N1bWVudCBkYXRlOgkyMDE3LTAzLTMxDQo+ICAgICBH cm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiAgICAgUGFnZXM6CQkyOQ0KPiAgICAgVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12 Nm9wcy1yZmM3MDg0LWJpcy0wMC50eHQNCj4gICAgIFN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12Nm9wcy1yZmM3MDg0LWJpcy8NCj4gICAgIEh0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdjZvcHMtcmZj NzA4NC1iaXMtMDANCj4gICAgIEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LXY2b3BzLXJmYzcwODQtYmlzLTAwDQo+IA0KPiANCj4gICAg IEFic3RyYWN0Og0KPiAgICAgICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcmVxdWlyZW1lbnRz IGZvciBhbiBJUHY2IEN1c3RvbWVyIEVkZ2UgKENFKQ0KPiAgICAgICAgcm91dGVyLiAgU3BlY2lm aWNhbGx5LCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1lbnQgZm9jdXNlcw0KPiAg ICAgICAgb24gdGhlIGJhc2ljIHByb3Zpc2lvbmluZyBvZiBhbiBJUHY2IENFIHJvdXRlciBhbmQg dGhlIHByb3Zpc2lvbmluZw0KPiAgICAgICAgb2YgSVB2NiBob3N0cyBhdHRhY2hlZCB0byBpdC4g IFRoZSBkb2N1bWVudCBhbHNvIGNvdmVycyBzZXZlcmFsDQo+ICAgICAgICB0cmFuc2l0aW9uIHRl Y2hub2xvZ2llcywgYXMgcmVxdWlyZWQgaW4gYSB3b3JsZCB3aGVyZSBJUHY0IGFkZHJlc3Nlcw0K PiAgICAgICAgYXJlIG5vIGxvbmdlciBhdmFpbGFibGUsIHNvIGhvc3RzIGluIHRoZSBjdXN0b21l ciBMQU5zIHdpdGggSVB2NC1vbmx5DQo+ICAgICAgICBvciBJUHY2LW9ubHkgYXBwbGljYXRpb25z IG9yIGRldmljZXMsIHJlcXVpcmluZyB0byBjb21tdW5pY2F0ZSB3aXRoDQo+ICAgICAgICBJUHY0 LW9ubHkgc2VydmljZXMgYXQgdGhlIEludGVybmV0LCBhcmUgYWJsZSB0byBkbyBzby4gIFRoZSBk b2N1bWVudA0KPiAgICAgICAgb2Jzb2xldGVzIFJGQyA3MDg0Lg0KPiANCj4gDQo+IA0KPiANCj4g ICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiAgICAgVGhl IElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zl cg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cDovL3d3dy5j b25zdWxpbnRlbC5lcw0KPiBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiBUaGlzIGVsZWN0cm9uaWMg bWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBj b25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZQ0KPiBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5n LA0KPiBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0 aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQuDQo+IA0KPiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2 b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Tue Apr 11 00:29: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 B47C31270A3 for ; Tue, 11 Apr 2017 00:29:02 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zzz2k05uZOVo for ; Tue, 11 Apr 2017 00:29:01 -0700 (PDT) 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 631E21272E1 for ; Tue, 11 Apr 2017 00:28:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C4B12A2; Tue, 11 Apr 2017 09:28:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491895736; bh=IDPwZnKZkHkVtHb35ZGy3g3xYCQD+fZrjGXRNukVuy4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=r11QYdXVRDipQEFZxxYvwrEaF2QyTypkfLcFUzfaZSy+BcTYPQBgL7xiiYmiKCB8e 2ZxilMxGoWSdCr64At5p4yR2D8t+uw1md+9yKlFZ0rqA37pd87EfCk9RsCSW88I5Fo +n258fFT378ZIcbufzYJMudhHnN8y9g9IH21ZhUQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C227D88; Tue, 11 Apr 2017 09:28:56 +0200 (CEST) Date: Tue, 11 Apr 2017 09:28:56 +0200 (CEST) From: Mikael Abrahamsson To: mohamed.boucadair@orange.com cc: "jordi.palet@consulintel.es" , "v6ops@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Message-ID: References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 07:29:03 -0000 On Tue, 11 Apr 2017, mohamed.boucadair@orange.com wrote: > [Med] DHCPv4-over-DHCPv6 is not a required for many of the techniques > listed in this draft. I suggest to delete it from the text. Hm, we still need to keep it for the mechanisms that actually need this, like lw4o6. I understand if it's removed for the ones that do not need it. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 11 02:39: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 5C9EF1204DA for ; Tue, 11 Apr 2017 02:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 jAnkr2zgSrRc for ; Tue, 11 Apr 2017 02:39:47 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F0D127ABE for ; Tue, 11 Apr 2017 02:39:47 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 55C4EC05B5; Tue, 11 Apr 2017 11:39:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 397A418007D; Tue, 11 Apr 2017 11:39:45 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 11:39:44 +0200 From: To: Mikael Abrahamsson CC: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSspVIzmlAwfRUe0KsIOjrv0EYcaG/56kQ Date: Tue, 11 Apr 2017 09:39:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4B8D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 09:39:49 -0000 Re-, I think we are in agreement, Mikael.=20 Actually, the only RFC that cites DHCPv4 over DHCPv6 is RFC7596. So, at mos= t that item may be listed for lw4o6 but be removed from other sections. Note that for RFC7596, it says the following:=20 " If stateful IPv4 configuration or ^^ additional IPv4 configuration information is required, DHCP 4o6 [RFC7341] MUST be used." And=20 In addition to the DHCPv6-based mechanism described in Section 5.1, several other IPv4 provisioning protocols have been suggested. These protocols MAY be implemented. These alternatives include: o DHCPv4 over DHCPv6: [RFC7341] describes implementing DHCPv4 messages over an IPv6-only service provider's network. This enables leasing of IPv4 addresses and makes DHCPv4 options available to the DHCPv4-over-DHCPv6 client. An lwB4 MAY implement ^^^^^^^^^^^^^^^^^^^^^^ [RFC7341] and [Dyn-Shared-v4Alloc] to retrieve a shared IPv4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ address with a set of ports.=20 Cheers, Med > -----Message d'origine----- > De=A0: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Envoy=E9=A0: mardi 11 avril 2017 09:29 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: jordi.palet@consulintel.es; v6ops@ietf.org > Objet=A0: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bi= s- > 00.txt >=20 > On Tue, 11 Apr 2017, mohamed.boucadair@orange.com wrote: >=20 > > [Med] DHCPv4-over-DHCPv6 is not a required for many of the techniques > > listed in this draft. I suggest to delete it from the text. >=20 > Hm, we still need to keep it for the mechanisms that actually need this, > like lw4o6. >=20 > I understand if it's removed for the ones that do not need it. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 11 06:37: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 13704129BBD for ; Tue, 11 Apr 2017 06:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOEidCxFVYAC for ; Tue, 11 Apr 2017 06:37:45 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14704129B9E for ; Tue, 11 Apr 2017 06:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491917863; x=1492522663; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=hGYgjYAJa/LwWXmU3dB8gdxpu SPMgAlXBLfygsbQrt8=; b=aSMIKrcTBJboquOu2Nx9rtMUAz7Y6QqeimdkbqvaY h3+78q7/xcc6d5GHveFcXgEOv7F5EHxQ44NsBAmZ7OMAjQN+dVTyOfKVxBmHw2Jh SD5Q9JwJgDpnVUPYondXoTOxH0qA9qE5jPcRafOoypI1ypz6xy+NeB54j1M2ILE0 3w= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cZcSXhgRcJuA9UVMYhTTDLtjdAUkae7wj3BcS7fl8X/qGOttqNa3b2PqfFfJ rWXKTunsizd04lfGg+x4tA/73VLVu7G+YymfIF0nm5ZqtTPOZ/W9KNPVt SnP+w8kp6nv3SmbA0kzWIVspctV/dz0gIXu7psJuY0/hIBTXnsygH4=; X-MDAV-Processed: mail.consulintel.es, Tue, 11 Apr 2017 15:37:43 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 11 Apr 2017 15:37:41 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406258.msg for ; Tue, 11 Apr 2017 15:37:39 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170411:md50005406258::4SAINlEM025imtsJ:0000323E X-Return-Path: prvs=1274da9a4c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 11 Apr 2017 15:37:37 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <830DC02A-27B1-44BD-ABA3-712BDD14BA28@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4B8D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4B8D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 13:37:47 -0000 Hi all, Thanks all for the inputs. Responding on this to Mohamed, Masanobu and Mikael. Fully agree. I=E2=80=99m editing a new version, which will remove the DHCP = 4o6 for MAP E/T and only keep it as a must for lw4o6. Masanobu, I think it should be a must, to conform with RFC7596, where is al= ready a MUST. Mohamed, Dyn-Shared-v4Alloc is already RFC7618. In RFC7596, it is a MAY, an= d seems to be applicable to both lw4o6 and MAP-E. Do you have an opinion ab= out if we should make more explicit it, by including as MAY support for RFC= 7618 for both (lw4o6 and MAP-E) ? Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: martes, 11 de abril de 2017, 11:39 Para: Mikael Abrahamsson CC: "jordi.palet@consulintel.es" , "v6ops@ietf.= org" Asunto: RE: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00= .txt Re-, =20 I think we are in agreement, Mikael.=20 =20 Actually, the only RFC that cites DHCPv4 over DHCPv6 is RFC7596. So, at= most that item may be listed for lw4o6 but be removed from other sections. =20 Note that for RFC7596, it says the following:=20 =20 " If stateful IPv4 configuration or ^^ additional IPv4 configuration information is required, DHCP 4o6 [RFC7341] MUST be used." =20 And=20 =20 In addition to the DHCPv6-based mechanism described in Section 5.1, several other IPv4 provisioning protocols have been suggested. Thes= e protocols MAY be implemented. These alternatives include: o DHCPv4 over DHCPv6: [RFC7341] describes implementing DHCPv4 messages over an IPv6-only service provider's network. This enables leasing of IPv4 addresses and makes DHCPv4 options available to the DHCPv4-over-DHCPv6 client. An lwB4 MAY implemen= t ^^^^^^^^^^^^^^^^^^^^= ^^ [RFC7341] and [Dyn-Shared-v4Alloc] to retrieve a shared IPv4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ address with a set of ports.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Envoy=C3=A9 : mardi 11 avril 2017 09:29 > =C3=80 : BOUCADAIR Mohamed IMT/OLN > Cc : jordi.palet@consulintel.es; v6ops@ietf.org > Objet : Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-= bis- > 00.txt >=20 > On Tue, 11 Apr 2017, mohamed.boucadair@orange.com wrote: >=20 > > [Med] DHCPv4-over-DHCPv6 is not a required for many of the techniqu= es > > listed in this draft. I suggest to delete it from the text. >=20 > Hm, we still need to keep it for the mechanisms that actually need th= is, > like lw4o6. >=20 > I understand if it's removed for the ones that do not need it. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Apr 11 07:07: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 F312B1294BD for ; Tue, 11 Apr 2017 07:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB34GUh3SLqC for ; Tue, 11 Apr 2017 07:07:55 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899DA1294E6 for ; Tue, 11 Apr 2017 07:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491919662; x=1492524462; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=c/FP6yeowS/RcHtVB9zjMLDmJ HFmIG7qd7vrcn0AiJA=; b=JeCK4Nz8PeUm7AI5hCW8B6phCKqJ80JZDxsiGqAzX mLQD5ROdjC3lhhauapFkkzGWfdzO7u7KrvIR1UsvGdEmup+ipwMF9Y/qIJh5NV4C vC/ifVtcGdRZEu8MetgM2jTgkMFHr9v37u6Ajtt79NioJ3aR8o7WEcdcGOD/Fl25 1g= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=TEewR4blxKwm/Ve1GyJzlq5cqxXp6F4mVG8nlbEOqKLihk1nkIBkaJ7bAZdJ P+i82MSUUKJ6jHI0hN6Ho7qBDPIFZmH3LdFdp0Rtzxh9nE2ydeUd+6Pu8 EWokXy5P6mStsOop7i1Wpg2oXvQcv4mctmVmlUgVycVuUpZ/RNIiEI=; X-MDAV-Processed: mail.consulintel.es, Tue, 11 Apr 2017 16:07:42 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 11 Apr 2017 16:07:41 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406271.msg for ; Tue, 11 Apr 2017 16:07:40 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170411:md50005406271::QCEGJliIrI+eaYI/:00000/w4 X-Return-Path: prvs=1274da9a4c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 11 Apr 2017 16:07:35 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <56AF43EF-3967-46AC-A0CC-487C00AEBB29@consulintel.es> Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <81A3232BEF82944C8F23DB1CFE276F0F49392E71@BPXM24GP.gisp.nec.co.jp> In-Reply-To: <81A3232BEF82944C8F23DB1CFE276F0F49392E71@BPXM24GP.gisp.nec.co.jp> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:07:58 -0000 Hi Masanobu, Regarding RFC5625, I think you=E2=80=99re right. Even if this is explicitly mention in section 6.4 of RFC6877, it is also me= ntion in other transition mechanism. Unless I heard otherwise from the WG, I think it will be correct to remove = it from 464XLAT and include it as a general LAN requirement. Regards, Jordi =20 -----Mensaje original----- De: Masanobu Kawashima Responder a: Fecha: martes, 11 de abril de 2017, 9:12 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: New Version Notification for draft-v6ops-rfc7084-bis-00.txt =20 Hi Jordi,=20 =20 I have comments.=20 =20 > In all the IPv4-in-IPv6 transition mechanisms, I=E2=80=99m requiring: > =E2=80=9CThe CE router MUST support the DHCPv4-over-DHCPv6 (DHCP4o6) = transport described in [RFC7341].=E2=80=9D >=20 > I got a comment that this is not needed, however, my feeling is that = the configuration of certain IPv4 parameters for > the CPE, during the transition, are still needed and the ISP may need= that. =20 They may need that function. However, it depends on their network envir= onment, etc.=20 So, I will agree with it if it will be 'MAY'.=20 =20 As for requirement [464XLAT-3], RFC5625 is mentioned about DNS Proxy=20 Implementation Guidelines. It is not just for 464XLAT.=20 We should remove it or may write it in other section if it is useful.= =20 =20 Regards,=20 Masanobu=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=20 NEC Platforms, Ltd. =20 Access-Device Division =20 KAWASHIMA Masanobu =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=20 =20 =20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of JORDI PALET = MARTINEZ > Sent: Monday, April 03, 2017 6:48 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084= -bis-00.txt >=20 > Hi all, >=20 > I=E2=80=99ve submitted WG 00 for this document. >=20 > https://datatracker.ietf.org/doc/draft-v6ops-rfc7084-bis >=20 > I tried to incorporate all the inputs that I captured in the meeting,= hopefully didn=E2=80=99t miss anything!, plus some minor > edits. >=20 > Here is the summary for the changes: >=20 > 1) Added an annex (A) regarding the code considerations as I mention = in my presentation. > 2) Added an annex (B) with the changes from the original RFC7084. > 3) Transition mechanisms in alphabetical order. > 4) Changed the IPv6-in-IPv4 transition mechanism (6RD and 6in4) to MA= Y instead of SHOULD. > 5) Added a new section regarding IPv4 multicast support in IPv6-only-= WAN. > 6) Added some text regarding the PCP support to learn PLAT info in 46= 4XLAT (RFC 7225). >=20 > I=E2=80=99ve one question for the WG. >=20 > In all the IPv4-in-IPv6 transition mechanisms, I=E2=80=99m requiring: > =E2=80=9CThe CE router MUST support the DHCPv4-over-DHCPv6 (DHCP4o6) = transport described in [RFC7341].=E2=80=9D >=20 > I got a comment that this is not needed, however, my feeling is that = the configuration of certain IPv4 parameters for > the CPE, during the transition, are still needed and the ISP may need= that. >=20 > So, the question is, what do you think about this? >=20 > Please, note that the original RFC7084 didn=E2=80=99t considered this= (RFC7341 didn=E2=80=99t exist when it was published), so the actual > version is requesting this not just for the new supported transition = mechanisms (lw4o6, MAP T/E, 464XLAT), but also for > DS-Lite. >=20 > Please provide inputs ASAP. I will like to avoid having this document= sleeping for too many weeks, and my goal is to publish > a new version in about 2 weeks with any comments received. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: > Responder a: > Fecha: domingo, 2 de abril de 2017, 22:57 > Para: Jordi Palet , Jordi Palet Martinez = > Asunto: New Version Notification for draft-v6ops-rfc7084-bis-00.txt >=20 >=20 > A new version of I-D, draft-v6ops-rfc7084-bis-00.txt > has been successfully submitted by Jordi Palet Martinez and poste= d to the > IETF repository. >=20 > Name: draft-v6ops-rfc7084-bis > Revision: 00 > Title: Basic Requirements for IPv6 Customer Edge Routers > Document date: 2017-03-31 > Group: Individual Submission > Pages: 29 > URL: https://www.ietf.org/internet-drafts/draft-v6ops-= rfc7084-bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-v6ops-rfc7= 084-bis/ > Htmlized: https://tools.ietf.org/html/draft-v6ops-rfc7084-b= is-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-v6ops= -rfc7084-bis-00 >=20 >=20 > Abstract: > This document specifies requirements for an IPv6 Customer Edge= (CE) > router. Specifically, the current version of this document fo= cuses > on the basic provisioning of an IPv6 CE router and the provisi= oning > of IPv6 hosts attached to it. The document also covers severa= l > transition technologies, as required in a world where IPv4 add= resses > are no longer available, so hosts in the customer LANs with IP= v4-only > or IPv6-only applications or devices, requiring to communicate= with > IPv4-only services at the Internet, are able to do so. The do= cument > obsoletes RFC 7084. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of= submission > until the htmlized version and diff are available at tools.ietf.o= rg. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be > for the use of the individual(s) named above. If you are not the inte= nded recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, including at= tached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Apr 11 07:21: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 07A3F129C36 for ; Tue, 11 Apr 2017 07:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 qyOsfQ9PcTHQ for ; Tue, 11 Apr 2017 07:21:05 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4D71294DF for ; Tue, 11 Apr 2017 07:21:04 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 0444CC0740; Tue, 11 Apr 2017 16:21:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id B0FC3120070; Tue, 11 Apr 2017 16:21:02 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 16:21:02 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSssjVEH7Z1st15kCgQ7cbzdg7kaHANwwg Date: Tue, 11 Apr 2017 14:21:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4BB22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4B8D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <830DC02A-27B1-44BD-ABA3-712BDD14BA28@consulintel.es> In-Reply-To: <830DC02A-27B1-44BD-ABA3-712BDD14BA28@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:21:07 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSk9SREkgUEFMRVQNCj4gTUFSVElORVoNCj4gRW52b3nD qcKgOiBtYXJkaSAxMSBhdnJpbCAyMDE3IDE1OjM4DQo+IMOAwqA6IHY2b3BzQGlldGYub3JnDQo+ IE9iamV0wqA6IFJlOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt djZvcHMtcmZjNzA4NC1iaXMtDQo+IDAwLnR4dA0KPiANCj4gSGkgYWxsLA0KPiANCj4gVGhhbmtz IGFsbCBmb3IgdGhlIGlucHV0cy4NCj4gDQo+IFJlc3BvbmRpbmcgb24gdGhpcyB0byBNb2hhbWVk LCBNYXNhbm9idSBhbmQgTWlrYWVsLg0KPiANCj4gRnVsbHkgYWdyZWUuIEnigJltIGVkaXRpbmcg YSBuZXcgdmVyc2lvbiwgd2hpY2ggd2lsbCByZW1vdmUgdGhlIERIQ1AgNG82IGZvcg0KPiBNQVAg RS9UDQoNCltNZWRdIE9LLCB0aGFuayB5b3UuICBJIGd1ZXNzIGl0IHdhcyBhbHNvIHJlbW92ZWQg Zm9yIERTLUxpdGUgYW5kIFhMQVQuDQoNCiBhbmQgb25seSBrZWVwIGl0IGFzIGEgbXVzdCBmb3Ig bHc0bzYuDQo+IA0KPiBNYXNhbm9idSwgSSB0aGluayBpdCBzaG91bGQgYmUgYSBtdXN0LCB0byBj b25mb3JtIHdpdGggUkZDNzU5Niwgd2hlcmUgaXMNCj4gYWxyZWFkeSBhIE1VU1QuDQo+IA0KPiBN b2hhbWVkLCBEeW4tU2hhcmVkLXY0QWxsb2MgaXMgYWxyZWFkeSBSRkM3NjE4LiBJbiBSRkM3NTk2 LCBpdCBpcyBhIE1BWSwNCj4gYW5kIHNlZW1zIHRvIGJlIGFwcGxpY2FibGUgdG8gYm90aCBsdzRv NiBhbmQgTUFQLUUuIERvIHlvdSBoYXZlIGFuIG9waW5pb24NCj4gYWJvdXQgaWYgd2Ugc2hvdWxk IG1ha2UgbW9yZSBleHBsaWNpdCBpdCwgYnkgaW5jbHVkaW5nIGFzIE1BWSBzdXBwb3J0IGZvcg0K PiBSRkM3NjE4IGZvciBib3RoIChsdzRvNiBhbmQgTUFQLUUpID8NCg0KW01lZF0gQSBzaW1wbGUg YXBwcm9hY2ggaXMgdG8gZm9sbG93IHRoZSByZXF1aXJlbWVudHMgYXMgd29yZGVkIGluIFJGQzc1 OTYgYW5kIFJGQzc1OTcsIGkuZS4sOg0KKiBubyBtZW50aW9uIG9mIFJGQzc2MTggZm9yIE1BUC1F DQoqIHVzZSB0aGUgc2FtZSB3b3JkaW5nIGFzIGluIFJGQzc1OTYgZm9yIGx3NG82OiBNQVkuICAN Cg0KPiANCj4gUmVnYXJkcywNCj4gSm9yZGkNCj4gDQo+IA0KPiAtLS0tLU1lbnNhamUgb3JpZ2lu YWwtLS0tLQ0KPiBEZTogPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IFJlc3BvbmRl ciBhOiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gRmVjaGE6IG1hcnRlcywgMTEg ZGUgYWJyaWwgZGUgMjAxNywgMTE6MzkNCj4gUGFyYTogTWlrYWVsIEFicmFoYW1zc29uIDxzd21p a2VAc3dtLnBwLnNlPg0KPiBDQzogImpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzIiA8am9yZGku cGFsZXRAY29uc3VsaW50ZWwuZXM+LA0KPiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9y Zz4NCj4gQXN1bnRvOiBSRTogW3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXY2b3BzLXJmYzcwODQtYmlzLQ0KPiAwMC50eHQNCj4gDQo+ICAgICBSZS0sDQo+IA0KPiAg ICAgSSB0aGluayB3ZSBhcmUgaW4gYWdyZWVtZW50LCBNaWthZWwuDQo+IA0KPiAgICAgQWN0dWFs bHksIHRoZSBvbmx5IFJGQyB0aGF0IGNpdGVzIERIQ1B2NCBvdmVyIERIQ1B2NiBpcyBSRkM3NTk2 LiBTbywNCj4gYXQgbW9zdCB0aGF0IGl0ZW0gbWF5IGJlIGxpc3RlZCBmb3IgbHc0bzYgYnV0IGJl IHJlbW92ZWQgZnJvbSBvdGhlcg0KPiBzZWN0aW9ucy4NCj4gDQo+ICAgICBOb3RlIHRoYXQgZm9y IFJGQzc1OTYsIGl0IHNheXMgdGhlIGZvbGxvd2luZzoNCj4gDQo+ICAgICAiIElmIHN0YXRlZnVs IElQdjQgY29uZmlndXJhdGlvbiBvcg0KPiAgICAgICBeXg0KPiAgICAgICAgYWRkaXRpb25hbCBJ UHY0IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gaXMgcmVxdWlyZWQsIERIQ1AgNG82DQo+ICAg ICAgICBbUkZDNzM0MV0gTVVTVCBiZSB1c2VkLiINCj4gDQo+ICAgICBBbmQNCj4gDQo+ICAgICAg ICBJbiBhZGRpdGlvbiB0byB0aGUgREhDUHY2LWJhc2VkIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4g U2VjdGlvbiA1LjEsDQo+ICAgICAgICBzZXZlcmFsIG90aGVyIElQdjQgcHJvdmlzaW9uaW5nIHBy b3RvY29scyBoYXZlIGJlZW4gc3VnZ2VzdGVkLg0KPiBUaGVzZQ0KPiAgICAgICAgcHJvdG9jb2xz IE1BWSBiZSBpbXBsZW1lbnRlZC4gIFRoZXNlIGFsdGVybmF0aXZlcyBpbmNsdWRlOg0KPiAgICAg ICAgbyAgREhDUHY0IG92ZXIgREhDUHY2OiBbUkZDNzM0MV0gZGVzY3JpYmVzIGltcGxlbWVudGlu ZyBESENQdjQNCj4gICAgICAgICAgIG1lc3NhZ2VzIG92ZXIgYW4gSVB2Ni1vbmx5IHNlcnZpY2Ug cHJvdmlkZXIncyBuZXR3b3JrLiAgVGhpcw0KPiAgICAgICAgICAgZW5hYmxlcyBsZWFzaW5nIG9m IElQdjQgYWRkcmVzc2VzIGFuZCBtYWtlcyBESENQdjQgb3B0aW9ucw0KPiAgICAgICAgICAgYXZh aWxhYmxlIHRvIHRoZSBESENQdjQtb3Zlci1ESENQdjYgY2xpZW50LiAgQW4gbHdCNCBNQVkNCj4g aW1wbGVtZW50DQo+IA0KPiBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ICAgICAgICAgICBbUkZD NzM0MV0gYW5kIFtEeW4tU2hhcmVkLXY0QWxsb2NdIHRvIHJldHJpZXZlIGEgc2hhcmVkIElQdjQN Cj4gICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4gICAgICAg ICAgIGFkZHJlc3Mgd2l0aCBhIHNldCBvZiBwb3J0cy4NCj4gDQo+ICAgICBDaGVlcnMsDQo+ICAg ICBNZWQNCj4gDQo+ICAgICA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiAgICAgPiBE ZSA6IE1pa2FlbCBBYnJhaGFtc3NvbiBbbWFpbHRvOnN3bWlrZUBzd20ucHAuc2VdDQo+ICAgICA+ IEVudm95w6kgOiBtYXJkaSAxMSBhdnJpbCAyMDE3IDA5OjI5DQo+ICAgICA+IMOAIDogQk9VQ0FE QUlSIE1vaGFtZWQgSU1UL09MTg0KPiAgICAgPiBDYyA6IGpvcmRpLnBhbGV0QGNvbnN1bGludGVs LmVzOyB2Nm9wc0BpZXRmLm9yZw0KPiAgICAgPiBPYmpldCA6IFJlOiBbdjZvcHNdIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdjZvcHMtDQo+IHJmYzcwODQtYmlzLQ0KPiAgICAg PiAwMC50eHQNCj4gICAgID4NCj4gICAgID4gT24gVHVlLCAxMSBBcHIgMjAxNywgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gICAgID4NCj4gICAgID4gPiBbTWVkXSBESENQ djQtb3Zlci1ESENQdjYgaXMgbm90IGEgcmVxdWlyZWQgZm9yIG1hbnkgb2YgdGhlDQo+IHRlY2hu aXF1ZXMNCj4gICAgID4gPiBsaXN0ZWQgaW4gdGhpcyBkcmFmdC4gSSBzdWdnZXN0IHRvIGRlbGV0 ZSBpdCBmcm9tIHRoZSB0ZXh0Lg0KPiAgICAgPg0KPiAgICAgPiBIbSwgd2Ugc3RpbGwgbmVlZCB0 byBrZWVwIGl0IGZvciB0aGUgbWVjaGFuaXNtcyB0aGF0IGFjdHVhbGx5IG5lZWQNCj4gdGhpcywN Cj4gICAgID4gbGlrZSBsdzRvNi4NCj4gICAgID4NCj4gICAgID4gSSB1bmRlcnN0YW5kIGlmIGl0 J3MgcmVtb3ZlZCBmb3IgdGhlIG9uZXMgdGhhdCBkbyBub3QgbmVlZCBpdC4NCj4gICAgID4NCj4g ICAgID4gLS0NCj4gICAgID4gTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dt LnBwLnNlDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KPiBJUHY0IGlzIG92ZXINCj4gQXJlIHlvdSByZWFkeSBmb3Ig dGhlIG5ldyBJbnRlcm5ldCA/DQo+IGh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMNCj4gVGhlIElQ djYgQ29tcGFueQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3Jt YXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlkZW50aWFsLiBUaGUgaW5m b3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1 YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg YmUgYXdhcmUNCj4gdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9y IHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcw0KPiBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0 dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QN Cj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0K From nobody Tue Apr 11 07:24: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 3E3DE129C4A for ; Tue, 11 Apr 2017 07:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 7cp2SAXT87Uu for ; Tue, 11 Apr 2017 07:24:45 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47785129C47 for ; Tue, 11 Apr 2017 07:24:45 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 026A01013A8; Tue, 11 Apr 2017 16:24:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id D22DB6007A; Tue, 11 Apr 2017 16:24:43 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 16:24:43 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSss0NoQbajmlzEEiD927GOLcee6HAODmg Date: Tue, 11 Apr 2017 14:24:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4BB36@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <81A3232BEF82944C8F23DB1CFE276F0F49392E71@BPXM24GP.gisp.nec.co.jp> <56AF43EF-3967-46AC-A0CC-487C00AEBB29@consulintel.es> In-Reply-To: <56AF43EF-3967-46AC-A0CC-487C00AEBB29@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:24:47 -0000 UmUtLA0KDQpQbGVhc2Ugbm90ZSB0aGF0IFJGQzYzMzMgc2F5cyB0aGUgZm9sbG93aW5nOiANCg0K IkFzIHN1Y2gsIHRoZSBCNCBlbGVtZW50IFNIT1VMRA0KICAgaW1wbGVtZW50IGEgRE5TIHByb3h5 LCBmb2xsb3dpbmcgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiBbUkZDNTYyNV0uIg0KDQpVc2luZyBh IE1VU1QgZm9yIFJGQzU2MjUgZm9yIGFsbCB0aGUgbWVjaGFuaXNtcyB3aWxsIGNvbmZsaWN0IHdp dGggdGhlIHRleHQgYWJvdmUgZnJvbSBSRkM2MzMzLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKT1JESSBQQUxFVA0KPiBNQVJUSU5FWg0KPiBF bnZvecOpwqA6IG1hcmRpIDExIGF2cmlsIDIwMTcgMTY6MDgNCj4gw4DCoDogdjZvcHNAaWV0Zi5v cmcNCj4gT2JqZXTCoDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC12Nm9wcy1yZmM3MDg0LWJpcy0NCj4gMDAudHh0DQo+IA0KPiBIaSBNYXNhbm9idSwNCj4g DQo+IFJlZ2FyZGluZyBSRkM1NjI1LCBJIHRoaW5rIHlvdeKAmXJlIHJpZ2h0Lg0KPiANCj4gRXZl biBpZiB0aGlzIGlzIGV4cGxpY2l0bHkgbWVudGlvbiBpbiBzZWN0aW9uIDYuNCBvZiBSRkM2ODc3 LCBpdCBpcyBhbHNvDQo+IG1lbnRpb24gaW4gb3RoZXIgdHJhbnNpdGlvbiBtZWNoYW5pc20uDQo+ IA0KPiBVbmxlc3MgSSBoZWFyZCBvdGhlcndpc2UgZnJvbSB0aGUgV0csIEkgdGhpbmsgaXQgd2ls bCBiZSBjb3JyZWN0IHRvIHJlbW92ZQ0KPiBpdCBmcm9tIDQ2NFhMQVQgYW5kIGluY2x1ZGUgaXQg YXMgYSBnZW5lcmFsIExBTiByZXF1aXJlbWVudC4NCj4gDQo+IFJlZ2FyZHMsDQo+IEpvcmRpDQo+ IA0KPiANCj4gLS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6IE1hc2Fub2J1IEthd2Fz aGltYSA8a2F3YXNoaW1hbUB2eC5qcC5uZWMuY29tPg0KPiBSZXNwb25kZXIgYTogPGthd2FzaGlt YW1AdnguanAubmVjLmNvbT4NCj4gRmVjaGE6IG1hcnRlcywgMTEgZGUgYWJyaWwgZGUgMjAxNywg OToxMg0KPiBQYXJhOiAiam9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXMiIDxqb3JkaS5wYWxldEBj b25zdWxpbnRlbC5lcz4sDQo+ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPg0KPiBB c3VudG86IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXY2b3BzLXJmYzcw ODQtYmlzLTAwLnR4dA0KPiANCj4gDQo+ICAgICBIaSBKb3JkaSwNCj4gDQo+ICAgICBJIGhhdmUg Y29tbWVudHMuDQo+IA0KPiAgICAgPiBJbiBhbGwgdGhlIElQdjQtaW4tSVB2NiB0cmFuc2l0aW9u IG1lY2hhbmlzbXMsIEnigJltIHJlcXVpcmluZzoNCj4gICAgID4g4oCcVGhlIENFIHJvdXRlciBN VVNUIHN1cHBvcnQgdGhlIERIQ1B2NC1vdmVyLURIQ1B2NiAoREhDUDRvNikNCj4gdHJhbnNwb3J0 IGRlc2NyaWJlZCBpbiBbUkZDNzM0MV0u4oCdDQo+ICAgICA+DQo+ICAgICA+IEkgZ290IGEgY29t bWVudCB0aGF0IHRoaXMgaXMgbm90IG5lZWRlZCwgaG93ZXZlciwgbXkgZmVlbGluZyBpcyB0aGF0 DQo+IHRoZSBjb25maWd1cmF0aW9uIG9mIGNlcnRhaW4gSVB2NCBwYXJhbWV0ZXJzIGZvcg0KPiAg ICAgPiB0aGUgQ1BFLCBkdXJpbmcgdGhlIHRyYW5zaXRpb24sIGFyZSBzdGlsbCBuZWVkZWQgYW5k IHRoZSBJU1AgbWF5DQo+IG5lZWQgdGhhdC4NCj4gDQo+ICAgICBUaGV5IG1heSBuZWVkIHRoYXQg ZnVuY3Rpb24uIEhvd2V2ZXIsIGl0IGRlcGVuZHMgb24gdGhlaXIgbmV0d29yaw0KPiBlbnZpcm9u bWVudCwgZXRjLg0KPiAgICAgU28sIEkgd2lsbCBhZ3JlZSB3aXRoIGl0IGlmIGl0IHdpbGwgYmUg J01BWScuDQo+IA0KPiAgICAgQXMgZm9yIHJlcXVpcmVtZW50IFs0NjRYTEFULTNdLCBSRkM1NjI1 IGlzIG1lbnRpb25lZCBhYm91dCBETlMgUHJveHkNCj4gICAgIEltcGxlbWVudGF0aW9uIEd1aWRl bGluZXMuIEl0IGlzIG5vdCBqdXN0IGZvciA0NjRYTEFULg0KPiAgICAgV2Ugc2hvdWxkIHJlbW92 ZSBpdCBvciBtYXkgd3JpdGUgaXQgaW4gb3RoZXIgc2VjdGlvbiBpZiBpdCBpcyB1c2VmdWwuDQo+ IA0KPiAgICAgUmVnYXJkcywNCj4gICAgIE1hc2Fub2J1DQo+IA0KPiAgICAgPT09PT09PT09PT09 PT09PT09PT09PT09DQo+ICAgICAgTkVDIFBsYXRmb3JtcywgTHRkLg0KPiAgICAgIEFjY2Vzcy1E ZXZpY2UgRGl2aXNpb24NCj4gICAgICBLQVdBU0hJTUEgTWFzYW5vYnUNCj4gICAgID09PT09PT09 PT09PT09PT09PT09PT09PQ0KPiANCj4gDQo+ICAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ICAgICA+IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpPUkRJIFBBTEVUDQo+IE1BUlRJTkVaDQo+ICAgICA+IFNlbnQ6IE1vbmRh eSwgQXByaWwgMDMsIDIwMTcgNjo0OCBBTQ0KPiAgICAgPiBUbzogdjZvcHNAaWV0Zi5vcmcNCj4g ICAgID4gU3ViamVjdDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC12Nm9wcy0NCj4gcmZjNzA4NC1iaXMtMDAudHh0DQo+ICAgICA+DQo+ICAgICA+IEhpIGFs bCwNCj4gICAgID4NCj4gICAgID4gSeKAmXZlIHN1Ym1pdHRlZCBXRyAwMCBmb3IgdGhpcyBkb2N1 bWVudC4NCj4gICAgID4NCj4gICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdjZvcHMtcmZjNzA4NC1iaXMNCj4gICAgID4NCj4gICAgID4gSSB0cmllZCB0byBpbmNv cnBvcmF0ZSBhbGwgdGhlIGlucHV0cyB0aGF0IEkgY2FwdHVyZWQgaW4gdGhlDQo+IG1lZXRpbmcs IGhvcGVmdWxseSBkaWRu4oCZdCBtaXNzIGFueXRoaW5nISwgcGx1cyBzb21lIG1pbm9yDQo+ICAg ICA+IGVkaXRzLg0KPiAgICAgPg0KPiAgICAgPiBIZXJlIGlzIHRoZSBzdW1tYXJ5IGZvciB0aGUg Y2hhbmdlczoNCj4gICAgID4NCj4gICAgID4gMSkgQWRkZWQgYW4gYW5uZXggKEEpIHJlZ2FyZGlu ZyB0aGUgY29kZSBjb25zaWRlcmF0aW9ucyBhcyBJIG1lbnRpb24NCj4gaW4gbXkgcHJlc2VudGF0 aW9uLg0KPiAgICAgPiAyKSBBZGRlZCBhbiBhbm5leCAoQikgd2l0aCB0aGUgY2hhbmdlcyBmcm9t IHRoZSBvcmlnaW5hbCBSRkM3MDg0Lg0KPiAgICAgPiAzKSBUcmFuc2l0aW9uIG1lY2hhbmlzbXMg aW4gYWxwaGFiZXRpY2FsIG9yZGVyLg0KPiAgICAgPiA0KSBDaGFuZ2VkIHRoZSBJUHY2LWluLUlQ djQgdHJhbnNpdGlvbiBtZWNoYW5pc20gKDZSRCBhbmQgNmluNCkgdG8NCj4gTUFZIGluc3RlYWQg b2YgU0hPVUxELg0KPiAgICAgPiA1KSBBZGRlZCBhIG5ldyBzZWN0aW9uIHJlZ2FyZGluZyBJUHY0 IG11bHRpY2FzdCBzdXBwb3J0IGluIElQdjYtDQo+IG9ubHktV0FOLg0KPiAgICAgPiA2KSBBZGRl ZCBzb21lIHRleHQgcmVnYXJkaW5nIHRoZSBQQ1Agc3VwcG9ydCB0byBsZWFybiBQTEFUIGluZm8g aW4NCj4gNDY0WExBVCAoUkZDIDcyMjUpLg0KPiAgICAgPg0KPiAgICAgPiBJ4oCZdmUgb25lIHF1 ZXN0aW9uIGZvciB0aGUgV0cuDQo+ICAgICA+DQo+ICAgICA+IEluIGFsbCB0aGUgSVB2NC1pbi1J UHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcywgSeKAmW0gcmVxdWlyaW5nOg0KPiAgICAgPiDigJxU aGUgQ0Ugcm91dGVyIE1VU1Qgc3VwcG9ydCB0aGUgREhDUHY0LW92ZXItREhDUHY2IChESENQNG82 KQ0KPiB0cmFuc3BvcnQgZGVzY3JpYmVkIGluIFtSRkM3MzQxXS7igJ0NCj4gICAgID4NCj4gICAg ID4gSSBnb3QgYSBjb21tZW50IHRoYXQgdGhpcyBpcyBub3QgbmVlZGVkLCBob3dldmVyLCBteSBm ZWVsaW5nIGlzIHRoYXQNCj4gdGhlIGNvbmZpZ3VyYXRpb24gb2YgY2VydGFpbiBJUHY0IHBhcmFt ZXRlcnMgZm9yDQo+ICAgICA+IHRoZSBDUEUsIGR1cmluZyB0aGUgdHJhbnNpdGlvbiwgYXJlIHN0 aWxsIG5lZWRlZCBhbmQgdGhlIElTUCBtYXkNCj4gbmVlZCB0aGF0Lg0KPiAgICAgPg0KPiAgICAg PiBTbywgdGhlIHF1ZXN0aW9uIGlzLCB3aGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGlzPw0KPiAg ICAgPg0KPiAgICAgPiBQbGVhc2UsIG5vdGUgdGhhdCB0aGUgb3JpZ2luYWwgUkZDNzA4NCBkaWRu 4oCZdCBjb25zaWRlcmVkIHRoaXMNCj4gKFJGQzczNDEgZGlkbuKAmXQgZXhpc3Qgd2hlbiBpdCB3 YXMgcHVibGlzaGVkKSwgc28gdGhlIGFjdHVhbA0KPiAgICAgPiB2ZXJzaW9uIGlzIHJlcXVlc3Rp bmcgdGhpcyBub3QganVzdCBmb3IgdGhlIG5ldyBzdXBwb3J0ZWQgdHJhbnNpdGlvbg0KPiBtZWNo YW5pc21zIChsdzRvNiwgTUFQIFQvRSwgNDY0WExBVCksIGJ1dCBhbHNvIGZvcg0KPiAgICAgPiBE Uy1MaXRlLg0KPiAgICAgPg0KPiAgICAgPiBQbGVhc2UgcHJvdmlkZSBpbnB1dHMgQVNBUC4gSSB3 aWxsIGxpa2UgdG8gYXZvaWQgaGF2aW5nIHRoaXMNCj4gZG9jdW1lbnQgc2xlZXBpbmcgZm9yIHRv byBtYW55IHdlZWtzLCBhbmQgbXkgZ29hbCBpcyB0byBwdWJsaXNoDQo+ICAgICA+IGEgbmV3IHZl cnNpb24gaW4gYWJvdXQgMiB3ZWVrcyB3aXRoIGFueSBjb21tZW50cyByZWNlaXZlZC4NCj4gICAg ID4NCj4gICAgID4gUmVnYXJkcywNCj4gICAgID4gSm9yZGkNCj4gICAgID4NCj4gICAgID4NCj4g ICAgID4gLS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCj4gICAgID4gRGU6IDxpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+DQo+ICAgICA+IFJlc3BvbmRlciBhOiA8aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPg0KPiAgICAgPiBGZWNoYTogZG9taW5nbywgMiBkZSBhYnJpbCBkZSAyMDE3LCAyMjo1 Nw0KPiAgICAgPiBQYXJhOiBKb3JkaSBQYWxldCA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+ LCBKb3JkaSBQYWxldCBNYXJ0aW5leg0KPiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+DQo+ ICAgICA+IEFzdW50bzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12Nm9wcy1y ZmM3MDg0LWJpcy0wMC50eHQNCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gICAgIEEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC12Nm9wcy1yZmM3MDg0LWJpcy0wMC50eHQNCj4gICAgID4gICAg IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9yZGkgUGFsZXQgTWFydGluZXog YW5kDQo+IHBvc3RlZCB0byB0aGUNCj4gICAgID4gICAgIElFVEYgcmVwb3NpdG9yeS4NCj4gICAg ID4NCj4gICAgID4gICAgIE5hbWU6CQlkcmFmdC12Nm9wcy1yZmM3MDg0LWJpcw0KPiAgICAgPiAg ICAgUmV2aXNpb246CTAwDQo+ICAgICA+ICAgICBUaXRsZToJCUJhc2ljIFJlcXVpcmVtZW50cyBm b3IgSVB2NiBDdXN0b21lciBFZGdlIFJvdXRlcnMNCj4gICAgID4gICAgIERvY3VtZW50IGRhdGU6 CTIwMTctMDMtMzENCj4gICAgID4gICAgIEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ ICAgICA+ICAgICBQYWdlczoJCTI5DQo+ICAgICA+ICAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LQ0KPiB2Nm9wcy1yZmM3MDg0LWJp cy0wMC50eHQNCj4gICAgID4gICAgIFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC12Nm9wcy0NCj4gcmZjNzA4NC1iaXMvDQo+ICAgICA+ICAgICBI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXY2b3BzLXJm YzcwODQtDQo+IGJpcy0wMA0KPiAgICAgPiAgICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtDQo+IHY2b3BzLXJmYzcwODQtYmlzLTAw DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICAgICBBYnN0cmFjdDoNCj4gICAgID4gICAgICAg IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJlcXVpcmVtZW50cyBmb3IgYW4gSVB2NiBDdXN0b21l cg0KPiBFZGdlIChDRSkNCj4gICAgID4gICAgICAgIHJvdXRlci4gIFNwZWNpZmljYWxseSwgdGhl IGN1cnJlbnQgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50DQo+IGZvY3VzZXMNCj4gICAgID4gICAg ICAgIG9uIHRoZSBiYXNpYyBwcm92aXNpb25pbmcgb2YgYW4gSVB2NiBDRSByb3V0ZXIgYW5kIHRo ZQ0KPiBwcm92aXNpb25pbmcNCj4gICAgID4gICAgICAgIG9mIElQdjYgaG9zdHMgYXR0YWNoZWQg dG8gaXQuICBUaGUgZG9jdW1lbnQgYWxzbyBjb3ZlcnMNCj4gc2V2ZXJhbA0KPiAgICAgPiAgICAg ICAgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMsIGFzIHJlcXVpcmVkIGluIGEgd29ybGQgd2hlcmUg SVB2NA0KPiBhZGRyZXNzZXMNCj4gICAgID4gICAgICAgIGFyZSBubyBsb25nZXIgYXZhaWxhYmxl LCBzbyBob3N0cyBpbiB0aGUgY3VzdG9tZXIgTEFOcyB3aXRoDQo+IElQdjQtb25seQ0KPiAgICAg PiAgICAgICAgb3IgSVB2Ni1vbmx5IGFwcGxpY2F0aW9ucyBvciBkZXZpY2VzLCByZXF1aXJpbmcg dG8NCj4gY29tbXVuaWNhdGUgd2l0aA0KPiAgICAgPiAgICAgICAgSVB2NC1vbmx5IHNlcnZpY2Vz IGF0IHRoZSBJbnRlcm5ldCwgYXJlIGFibGUgdG8gZG8gc28uICBUaGUNCj4gZG9jdW1lbnQNCj4g ICAgID4gICAgICAgIG9ic29sZXRlcyBSRkMgNzA4NC4NCj4gICAgID4NCj4gICAgID4NCj4gICAg ID4NCj4gICAgID4NCj4gICAgID4gICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lDQo+IG9mIHN1Ym1pc3Npb24NCj4gICAgID4g ICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQN Cj4gdG9vbHMuaWV0Zi5vcmcuDQo+ICAgICA+DQo+ICAgICA+ICAgICBUaGUgSUVURiBTZWNyZXRh cmlhdA0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAg Pg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQo+ICAgICA+IElQdjQgaXMgb3Zlcg0KPiAgICAgPiBBcmUgeW91 IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gICAgID4gaHR0cDovL3d3dy5jb25zdWxp bnRlbC5lcw0KPiAgICAgPiBUaGUgSVB2NiBDb21wYW55DQo+ICAgICA+DQo+ICAgICA+IFRoaXMg ZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2 aWxlZ2VkDQo+IG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRv IGJlDQo+ICAgICA+IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3Zl LiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4gaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQg YW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsDQo+ICAgICA+IGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2Yg dGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGluY2x1ZGluZw0KPiBhdHRhY2hlZCBm aWxlcywgaXMgcHJvaGliaXRlZC4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgID4g djZvcHMgbWFpbGluZyBsaXN0DQo+ICAgICA+IHY2b3BzQGlldGYub3JnDQo+ICAgICA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gDQo+IA0KPiANCj4gDQo+ ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gSVB2NCBp cyBvdmVyDQo+IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiBodHRwOi8v d3d3LmNvbnN1bGludGVsLmVzDQo+IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ry b25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2Vk IG9yDQo+IGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZv ciB0aGUgdXNlIG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlDQo+IHRoYXQgYW55IGRpc2Nsb3N1 cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMN Cj4gaW5mb3JtYXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4N Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Tue Apr 11 07:42: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 41C15129C43 for ; Tue, 11 Apr 2017 07:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvbG-HNqkdkR for ; Tue, 11 Apr 2017 07:42:04 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A713F129529 for ; Tue, 11 Apr 2017 07:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491921722; x=1492526522; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=RRT8uyg9m4pg0t4GmDtBINDPQ FC7siJxRtAiQ5nSEss=; b=LDyoJojfP1D7W4wsdbhnG7YhU0NajPgnxHZ6QGZUH fgONBDSTiGv44iXJIUkoIUTqpo2w3+pti10IOVHO+APZb7pV083kmB5KGPEJFIOV X6xEwGik+Re50ppGvqUnglK9XyVeYXbEzj9Eqcq8a/rPDNcfO1G08si+s67pBchf iY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=KfbplijI/GkjkE2pj/AA23yfFpcS2iG7xjK6qBqTK13s7M6Oe9GoN8WSt+DB liryGPLCHzrzW6rz3GMJywrlX95K8m5XGbDADOVnRofsSB4v5Wrjt4XRr weKyUPn4LYVhBQ/TbzEDdgklXJBOzs9vEwFcXPkC15LE8BN0y4qfrA=; X-MDAV-Processed: mail.consulintel.es, Tue, 11 Apr 2017 16:42:02 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 11 Apr 2017 16:42:01 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406294.msg for ; Tue, 11 Apr 2017 16:42:00 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170411:md50005406294::t00peBdY+PXFoDYp:00008Jbv X-Return-Path: prvs=1274da9a4c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 11 Apr 2017 16:41:58 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <61B3DBD5-CB04-42CC-AF8F-E629E8E44F9B@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4B8D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <830DC02A-27B1-44BD-ABA3-712BDD14BA28@consulintel.es> <787AE7BB302AE849A7480A190F8B933009E4BB22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4BB22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:42:06 -0000 Hi Mohamed, In-line Saludos, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: martes, 11 de abril de 2017, 16:21 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00= .txt Re-, =20 Please see inline.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET > MARTINEZ > Envoy=C3=A9 : mardi 11 avril 2017 15:38 > =C3=80 : v6ops@ietf.org > Objet : Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-= bis- > 00.txt >=20 > Hi all, >=20 > Thanks all for the inputs. >=20 > Responding on this to Mohamed, Masanobu and Mikael. >=20 > Fully agree. I=E2=80=99m editing a new version, which will remove the= DHCP 4o6 for > MAP E/T =20 [Med] OK, thank you. I guess it was also removed for DS-Lite and XLAT. =20 and only keep it as a must for lw4o6. [Jordi] Yes, *only* keeping it for lw4o6 >=20 > Masanobu, I think it should be a must, to conform with RFC7596, where= is > already a MUST. >=20 > Mohamed, Dyn-Shared-v4Alloc is already RFC7618. In RFC7596, it is a M= AY, > and seems to be applicable to both lw4o6 and MAP-E. Do you have an op= inion > about if we should make more explicit it, by including as MAY support= for > RFC7618 for both (lw4o6 and MAP-E) ? =20 [Med] A simple approach is to follow the requirements as worded in RFC7= 596 and RFC7597, i.e.,: * no mention of RFC7618 for MAP-E * use the same wording as in RFC7596 for lw4o6: MAY. =20 [Jordi] I=E2=80=99m also considering using MAY for MAP-E, as it seems that,= according to RFC7618 applicability statement it is used in certain configu= rations of MAP-E. =20 >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: > Responder a: > Fecha: martes, 11 de abril de 2017, 11:39 > Para: Mikael Abrahamsson > CC: "jordi.palet@consulintel.es" , > "v6ops@ietf.org" > Asunto: RE: [v6ops] New Version Notification for draft-v6ops-rfc7084-= bis- > 00.txt >=20 > Re-, >=20 > I think we are in agreement, Mikael. >=20 > Actually, the only RFC that cites DHCPv4 over DHCPv6 is RFC7596. = So, > at most that item may be listed for lw4o6 but be removed from other > sections. >=20 > Note that for RFC7596, it says the following: >=20 > " If stateful IPv4 configuration or > ^^ > additional IPv4 configuration information is required, DHCP 4o= 6 > [RFC7341] MUST be used." >=20 > And >=20 > In addition to the DHCPv6-based mechanism described in Section= 5.1, > several other IPv4 provisioning protocols have been suggested. > These > protocols MAY be implemented. These alternatives include: > o DHCPv4 over DHCPv6: [RFC7341] describes implementing DHCPv4 > messages over an IPv6-only service provider's network. Thi= s > enables leasing of IPv4 addresses and makes DHCPv4 options > available to the DHCPv4-over-DHCPv6 client. An lwB4 MAY > implement >=20 > ^^^^^^^^^^^^^^^^^^^^^^ > [RFC7341] and [Dyn-Shared-v4Alloc] to retrieve a shared IPv= 4 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > address with a set of ports. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > Envoy=C3=A9 : mardi 11 avril 2017 09:29 > > =C3=80 : BOUCADAIR Mohamed IMT/OLN > > Cc : jordi.palet@consulintel.es; v6ops@ietf.org > > Objet : Re: [v6ops] New Version Notification for draft-v6ops- > rfc7084-bis- > > 00.txt > > > > On Tue, 11 Apr 2017, mohamed.boucadair@orange.com wrote: > > > > > [Med] DHCPv4-over-DHCPv6 is not a required for many of the > techniques > > > listed in this draft. I suggest to delete it from the text. > > > > Hm, we still need to keep it for the mechanisms that actually n= eed > this, > > like lw4o6. > > > > I understand if it's removed for the ones that do not need it. > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be a= ware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Apr 11 07:48: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 A0D50129C66 for ; Tue, 11 Apr 2017 07:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UjZgkMTND82 for ; Tue, 11 Apr 2017 07:47:55 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02FB129C64 for ; Tue, 11 Apr 2017 07:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491922073; x=1492526873; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=gbvP+I8M87cwM4hT2YfG5tVoA 6iPCkjlKe2WV8nvUZo=; b=ms+zlYOs0jEJEj/Iq7Ivs/EA3dMYHuGEOBt7LTfnO WyNw9dc6b5zWNLQXLftZI2Zth8dekG+9QLSqBhEHl0LJ1Krezu1oibMO65NxWPXy OqYQYwFEvBkgVwj2mCdzEhZoYFoPVoGfFlOLErzjI7bGV7xJN3dpFKbFdaUdeQNU FE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cb69uG0522Ohlbp2UX4V4qE++Ge5KeLW6psqQjWx0cdEVtxVoVJ61Xrx9ue1 n14atuDBqZHB0gj59xzPNTrBZ9dwv6p+F8XHoqEtTeV60Z8obDZV8+38m BF82tvlVdvm2u4++jxuc6Qgx9rVfPFLqSZzbpeZF7ZQV+rqRYyEGss=; X-MDAV-Processed: mail.consulintel.es, Tue, 11 Apr 2017 16:47:53 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 11 Apr 2017 16:47:51 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406300.msg for ; Tue, 11 Apr 2017 16:47:51 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170411:md50005406300::/ai7hpucSJ/OSvu+:00007T9C X-Return-Path: prvs=1274da9a4c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 11 Apr 2017 16:47:47 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <81A3232BEF82944C8F23DB1CFE276F0F49392E71@BPXM24GP.gisp.nec.co.jp> <56AF43EF-3967-46AC-A0CC-487C00AEBB29@consulintel.es> <787AE7BB302AE849A7480A190F8B933009E4BB36@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4BB36@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:47:58 -0000 You=E2=80=99re right. I=E2=80=99ve double checked all the transition mechs = and all them use should for the DNS proxy, so I will keep the same. Saludos, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: martes, 11 de abril de 2017, 16:24 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: New Version Notification for draft-v6ops-rfc7084-bis-00.txt Re-, =20 Please note that RFC6333 says the following:=20 =20 "As such, the B4 element SHOULD implement a DNS proxy, following the recommendations of [RFC5625]." =20 Using a MUST for RFC5625 for all the mechanisms will conflict with the = text above from RFC6333.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET > MARTINEZ > Envoy=C3=A9 : mardi 11 avril 2017 16:08 > =C3=80 : v6ops@ietf.org > Objet : Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-= bis- > 00.txt >=20 > Hi Masanobu, >=20 > Regarding RFC5625, I think you=E2=80=99re right. >=20 > Even if this is explicitly mention in section 6.4 of RFC6877, it is a= lso > mention in other transition mechanism. >=20 > Unless I heard otherwise from the WG, I think it will be correct to r= emove > it from 464XLAT and include it as a general LAN requirement. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: Masanobu Kawashima > Responder a: > Fecha: martes, 11 de abril de 2017, 9:12 > Para: "jordi.palet@consulintel.es" , > "v6ops@ietf.org" > Asunto: RE: New Version Notification for draft-v6ops-rfc7084-bis-00.t= xt >=20 >=20 > Hi Jordi, >=20 > I have comments. >=20 > > In all the IPv4-in-IPv6 transition mechanisms, I=E2=80=99m requ= iring: > > =E2=80=9CThe CE router MUST support the DHCPv4-over-DHCPv6 (DHC= P4o6) > transport described in [RFC7341].=E2=80=9D > > > > I got a comment that this is not needed, however, my feeling is= that > the configuration of certain IPv4 parameters for > > the CPE, during the transition, are still needed and the ISP ma= y > need that. >=20 > They may need that function. However, it depends on their network > environment, etc. > So, I will agree with it if it will be 'MAY'. >=20 > As for requirement [464XLAT-3], RFC5625 is mentioned about DNS Pr= oxy > Implementation Guidelines. It is not just for 464XLAT. > We should remove it or may write it in other section if it is use= ful. >=20 > Regards, > Masanobu >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > NEC Platforms, Ltd. > Access-Device Division > KAWASHIMA Masanobu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 >=20 > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of JORDI = PALET > MARTINEZ > > Sent: Monday, April 03, 2017 6:48 AM > > To: v6ops@ietf.org > > Subject: Re: [v6ops] New Version Notification for draft-v6ops- > rfc7084-bis-00.txt > > > > Hi all, > > > > I=E2=80=99ve submitted WG 00 for this document. > > > > https://datatracker.ietf.org/doc/draft-v6ops-rfc7084-bis > > > > I tried to incorporate all the inputs that I captured in the > meeting, hopefully didn=E2=80=99t miss anything!, plus some minor > > edits. > > > > Here is the summary for the changes: > > > > 1) Added an annex (A) regarding the code considerations as I me= ntion > in my presentation. > > 2) Added an annex (B) with the changes from the original RFC708= 4. > > 3) Transition mechanisms in alphabetical order. > > 4) Changed the IPv6-in-IPv4 transition mechanism (6RD and 6in4)= to > MAY instead of SHOULD. > > 5) Added a new section regarding IPv4 multicast support in IPv6= - > only-WAN. > > 6) Added some text regarding the PCP support to learn PLAT info= in > 464XLAT (RFC 7225). > > > > I=E2=80=99ve one question for the WG. > > > > In all the IPv4-in-IPv6 transition mechanisms, I=E2=80=99m requ= iring: > > =E2=80=9CThe CE router MUST support the DHCPv4-over-DHCPv6 (DHC= P4o6) > transport described in [RFC7341].=E2=80=9D > > > > I got a comment that this is not needed, however, my feeling is= that > the configuration of certain IPv4 parameters for > > the CPE, during the transition, are still needed and the ISP ma= y > need that. > > > > So, the question is, what do you think about this? > > > > Please, note that the original RFC7084 didn=E2=80=99t considere= d this > (RFC7341 didn=E2=80=99t exist when it was published), so the actual > > version is requesting this not just for the new supported trans= ition > mechanisms (lw4o6, MAP T/E, 464XLAT), but also for > > DS-Lite. > > > > Please provide inputs ASAP. I will like to avoid having this > document sleeping for too many weeks, and my goal is to publish > > a new version in about 2 weeks with any comments received. > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: > > Responder a: > > Fecha: domingo, 2 de abril de 2017, 22:57 > > Para: Jordi Palet , Jordi Palet Mar= tinez > > > Asunto: New Version Notification for draft-v6ops-rfc7084-bis-00= .txt > > > > > > A new version of I-D, draft-v6ops-rfc7084-bis-00.txt > > has been successfully submitted by Jordi Palet Martinez and > posted to the > > IETF repository. > > > > Name: draft-v6ops-rfc7084-bis > > Revision: 00 > > Title: Basic Requirements for IPv6 Customer Edge Routers > > Document date: 2017-03-31 > > Group: Individual Submission > > Pages: 29 > > URL: https://www.ietf.org/internet-drafts/draft- > v6ops-rfc7084-bis-00.txt > > Status: https://datatracker.ietf.org/doc/draft-v6op= s- > rfc7084-bis/ > > Htmlized: https://tools.ietf.org/html/draft-v6ops-rfc= 7084- > bis-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft= - > v6ops-rfc7084-bis-00 > > > > > > Abstract: > > This document specifies requirements for an IPv6 Custome= r > Edge (CE) > > router. Specifically, the current version of this docum= ent > focuses > > on the basic provisioning of an IPv6 CE router and the > provisioning > > of IPv6 hosts attached to it. The document also covers > several > > transition technologies, as required in a world where IP= v4 > addresses > > are no longer available, so hosts in the customer LANs w= ith > IPv4-only > > or IPv6-only applications or devices, requiring to > communicate with > > IPv4-only services at the Internet, are able to do so. = The > document > > obsoletes RFC 7084. > > > > > > > > > > Please note that it may take a couple of minutes from the t= ime > of submission > > until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privi= leged > or confidential. The information is intended to be > > for the use of the individual(s) named above. If you are not th= e > intended recipient be aware that any disclosure, copying, > > distribution or use of the contents of this information, includ= ing > attached files, is prohibited. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be a= ware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Apr 11 07:56: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 B496B129C36 for ; Tue, 11 Apr 2017 07:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 dEnelX84wZC5 for ; Tue, 11 Apr 2017 07:56:14 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B81C1294F4 for ; Tue, 11 Apr 2017 07:56:14 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 0C4C7C1139; Tue, 11 Apr 2017 16:56:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id DF803180067; Tue, 11 Apr 2017 16:56:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 16:56:12 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSstHVMwvEswgZH0moMuoFQdOCt6HAQKWw Date: Tue, 11 Apr 2017 14:56:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4BBE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4B8D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <830DC02A-27B1-44BD-ABA3-712BDD14BA28@consulintel.es> <787AE7BB302AE849A7480A190F8B933009E4BB22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <61B3DBD5-CB04-42CC-AF8F-E629E8E44F9B@consulintel.es> In-Reply-To: <61B3DBD5-CB04-42CC-AF8F-E629E8E44F9B@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:56:17 -0000 UmUtLA0KDQpMaXN0aW5nIFJGQzc2MTggZm9yIE1BUC1FIGlzIG9kZCBpZiBESENQdjQgb3ZlciBE SENQdjYgaXMgbm90IHJlcXVpcmVkIGZvciBNQVAtRS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSk9SREkgUEFMRVQNCj4gTUFSVElORVoNCj4g RW52b3nDqcKgOiBtYXJkaSAxMSBhdnJpbCAyMDE3IDE2OjQyDQo+IMOAwqA6IHY2b3BzQGlldGYu b3JnDQo+IE9iamV0wqA6IFJlOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtdjZvcHMtcmZjNzA4NC1iaXMtDQo+IDAwLnR4dA0KPiANCj4gSGkgTW9oYW1lZCwNCj4g DQo+IEluLWxpbmUNCj4gDQo+IFNhbHVkb3MsDQo+IEpvcmRpDQo+IA0KPiANCj4gLS0tLS1NZW5z YWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0K PiBSZXNwb25kZXIgYTogPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IEZlY2hhOiBt YXJ0ZXMsIDExIGRlIGFicmlsIGRlIDIwMTcsIDE2OjIxDQo+IFBhcmE6ICJqb3JkaS5wYWxldEBj b25zdWxpbnRlbC5lcyIgPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPiwNCj4gInY2b3BzQGll dGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQo+IEFzdW50bzogUkU6IFt2Nm9wc10gTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12Nm9wcy1yZmM3MDg0LWJpcy0NCj4gMDAudHh0DQo+ IA0KPiAgICAgUmUtLA0KPiANCj4gICAgIFBsZWFzZSBzZWUgaW5saW5lLg0KPiANCj4gICAgIENo ZWVycywNCj4gICAgIE1lZA0KPiANCj4gICAgID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+ICAgICA+IERlIDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBEZSBs YSBwYXJ0IGRlIEpPUkRJIFBBTEVUDQo+ICAgICA+IE1BUlRJTkVaDQo+ICAgICA+IEVudm95w6kg OiBtYXJkaSAxMSBhdnJpbCAyMDE3IDE1OjM4DQo+ICAgICA+IMOAIDogdjZvcHNAaWV0Zi5vcmcN Cj4gICAgID4gT2JqZXQgOiBSZTogW3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXY2b3BzLQ0KPiByZmM3MDg0LWJpcy0NCj4gICAgID4gMDAudHh0DQo+ICAgICA+DQo+ ICAgICA+IEhpIGFsbCwNCj4gICAgID4NCj4gICAgID4gVGhhbmtzIGFsbCBmb3IgdGhlIGlucHV0 cy4NCj4gICAgID4NCj4gICAgID4gUmVzcG9uZGluZyBvbiB0aGlzIHRvIE1vaGFtZWQsIE1hc2Fu b2J1IGFuZCBNaWthZWwuDQo+ICAgICA+DQo+ICAgICA+IEZ1bGx5IGFncmVlLiBJ4oCZbSBlZGl0 aW5nIGEgbmV3IHZlcnNpb24sIHdoaWNoIHdpbGwgcmVtb3ZlIHRoZSBESENQDQo+IDRvNiBmb3IN Cj4gICAgID4gTUFQIEUvVA0KPiANCj4gICAgIFtNZWRdIE9LLCB0aGFuayB5b3UuICBJIGd1ZXNz IGl0IHdhcyBhbHNvIHJlbW92ZWQgZm9yIERTLUxpdGUgYW5kDQo+IFhMQVQuDQo+IA0KPiAgICAg IGFuZCBvbmx5IGtlZXAgaXQgYXMgYSBtdXN0IGZvciBsdzRvNi4NCj4gDQo+IFtKb3JkaV0gWWVz LCAqb25seSoga2VlcGluZyBpdCBmb3IgbHc0bzYNCj4gDQo+ICAgICA+DQo+ICAgICA+IE1hc2Fu b2J1LCBJIHRoaW5rIGl0IHNob3VsZCBiZSBhIG11c3QsIHRvIGNvbmZvcm0gd2l0aCBSRkM3NTk2 LA0KPiB3aGVyZSBpcw0KPiAgICAgPiBhbHJlYWR5IGEgTVVTVC4NCj4gICAgID4NCj4gICAgID4g TW9oYW1lZCwgRHluLVNoYXJlZC12NEFsbG9jIGlzIGFscmVhZHkgUkZDNzYxOC4gSW4gUkZDNzU5 NiwgaXQgaXMgYQ0KPiBNQVksDQo+ICAgICA+IGFuZCBzZWVtcyB0byBiZSBhcHBsaWNhYmxlIHRv IGJvdGggbHc0bzYgYW5kIE1BUC1FLiBEbyB5b3UgaGF2ZSBhbg0KPiBvcGluaW9uDQo+ICAgICA+ IGFib3V0IGlmIHdlIHNob3VsZCBtYWtlIG1vcmUgZXhwbGljaXQgaXQsIGJ5IGluY2x1ZGluZyBh cyBNQVkNCj4gc3VwcG9ydCBmb3INCj4gICAgID4gUkZDNzYxOCBmb3IgYm90aCAobHc0bzYgYW5k IE1BUC1FKSA/DQo+IA0KPiAgICAgW01lZF0gQSBzaW1wbGUgYXBwcm9hY2ggaXMgdG8gZm9sbG93 IHRoZSByZXF1aXJlbWVudHMgYXMgd29yZGVkIGluDQo+IFJGQzc1OTYgYW5kIFJGQzc1OTcsIGku ZS4sOg0KPiAgICAgKiBubyBtZW50aW9uIG9mIFJGQzc2MTggZm9yIE1BUC1FDQo+ICAgICAqIHVz ZSB0aGUgc2FtZSB3b3JkaW5nIGFzIGluIFJGQzc1OTYgZm9yIGx3NG82OiBNQVkuDQo+IA0KPiBb Sm9yZGldIEnigJltIGFsc28gY29uc2lkZXJpbmcgdXNpbmcgTUFZIGZvciBNQVAtRSwgYXMgaXQg c2VlbXMgdGhhdCwNCj4gYWNjb3JkaW5nIHRvIFJGQzc2MTggYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQgaXQgaXMgdXNlZCBpbiBjZXJ0YWluDQo+IGNvbmZpZ3VyYXRpb25zIG9mIE1BUC1FLg0KPiAN Cj4gICAgID4NCj4gICAgID4gUmVnYXJkcywNCj4gICAgID4gSm9yZGkNCj4gICAgID4NCj4gICAg ID4NCj4gICAgID4gLS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCj4gICAgID4gRGU6IDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiAgICAgPiBSZXNwb25kZXIgYTogPG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ICAgICA+IEZlY2hhOiBtYXJ0ZXMsIDExIGRlIGFicmls IGRlIDIwMTcsIDExOjM5DQo+ICAgICA+IFBhcmE6IE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtl QHN3bS5wcC5zZT4NCj4gICAgID4gQ0M6ICJqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcyIgPGpv cmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPiwNCj4gICAgID4gInY2b3BzQGlldGYub3JnIiA8djZv cHNAaWV0Zi5vcmc+DQo+ICAgICA+IEFzdW50bzogUkU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC12Nm9wcy0NCj4gcmZjNzA4NC1iaXMtDQo+ICAgICA+IDAwLnR4 dA0KPiAgICAgPg0KPiAgICAgPiAgICAgUmUtLA0KPiAgICAgPg0KPiAgICAgPiAgICAgSSB0aGlu ayB3ZSBhcmUgaW4gYWdyZWVtZW50LCBNaWthZWwuDQo+ICAgICA+DQo+ICAgICA+ICAgICBBY3R1 YWxseSwgdGhlIG9ubHkgUkZDIHRoYXQgY2l0ZXMgREhDUHY0IG92ZXIgREhDUHY2IGlzIFJGQzc1 OTYuDQo+IFNvLA0KPiAgICAgPiBhdCBtb3N0IHRoYXQgaXRlbSBtYXkgYmUgbGlzdGVkIGZvciBs dzRvNiBidXQgYmUgcmVtb3ZlZCBmcm9tIG90aGVyDQo+ICAgICA+IHNlY3Rpb25zLg0KPiAgICAg Pg0KPiAgICAgPiAgICAgTm90ZSB0aGF0IGZvciBSRkM3NTk2LCBpdCBzYXlzIHRoZSBmb2xsb3dp bmc6DQo+ICAgICA+DQo+ICAgICA+ICAgICAiIElmIHN0YXRlZnVsIElQdjQgY29uZmlndXJhdGlv biBvcg0KPiAgICAgPiAgICAgICBeXg0KPiAgICAgPiAgICAgICAgYWRkaXRpb25hbCBJUHY0IGNv bmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gaXMgcmVxdWlyZWQsIERIQ1ANCj4gNG82DQo+ICAgICA+ ICAgICAgICBbUkZDNzM0MV0gTVVTVCBiZSB1c2VkLiINCj4gICAgID4NCj4gICAgID4gICAgIEFu ZA0KPiAgICAgPg0KPiAgICAgPiAgICAgICAgSW4gYWRkaXRpb24gdG8gdGhlIERIQ1B2Ni1iYXNl ZCBtZWNoYW5pc20gZGVzY3JpYmVkIGluDQo+IFNlY3Rpb24gNS4xLA0KPiAgICAgPiAgICAgICAg c2V2ZXJhbCBvdGhlciBJUHY0IHByb3Zpc2lvbmluZyBwcm90b2NvbHMgaGF2ZSBiZWVuDQo+IHN1 Z2dlc3RlZC4NCj4gICAgID4gVGhlc2UNCj4gICAgID4gICAgICAgIHByb3RvY29scyBNQVkgYmUg aW1wbGVtZW50ZWQuICBUaGVzZSBhbHRlcm5hdGl2ZXMgaW5jbHVkZToNCj4gICAgID4gICAgICAg IG8gIERIQ1B2NCBvdmVyIERIQ1B2NjogW1JGQzczNDFdIGRlc2NyaWJlcyBpbXBsZW1lbnRpbmcN Cj4gREhDUHY0DQo+ICAgICA+ICAgICAgICAgICBtZXNzYWdlcyBvdmVyIGFuIElQdjYtb25seSBz ZXJ2aWNlIHByb3ZpZGVyJ3MgbmV0d29yay4NCj4gVGhpcw0KPiAgICAgPiAgICAgICAgICAgZW5h YmxlcyBsZWFzaW5nIG9mIElQdjQgYWRkcmVzc2VzIGFuZCBtYWtlcyBESENQdjQgb3B0aW9ucw0K PiAgICAgPiAgICAgICAgICAgYXZhaWxhYmxlIHRvIHRoZSBESENQdjQtb3Zlci1ESENQdjYgY2xp ZW50LiAgQW4gbHdCNCBNQVkNCj4gICAgID4gaW1wbGVtZW50DQo+ICAgICA+DQo+ICAgICA+IF5e Xl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4gICAgID4gICAgICAgICAgIFtSRkM3MzQxXSBhbmQgW0R5 bi1TaGFyZWQtdjRBbGxvY10gdG8gcmV0cmlldmUgYSBzaGFyZWQNCj4gSVB2NA0KPiAgICAgPiAg ICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiAgICAgPiAgICAg ICAgICAgYWRkcmVzcyB3aXRoIGEgc2V0IG9mIHBvcnRzLg0KPiAgICAgPg0KPiAgICAgPiAgICAg Q2hlZXJzLA0KPiAgICAgPiAgICAgTWVkDQo+ICAgICA+DQo+ICAgICA+ICAgICA+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiAgICAgPiAgICAgPiBEZSA6IE1pa2FlbCBBYnJhaGFtc3Nv biBbbWFpbHRvOnN3bWlrZUBzd20ucHAuc2VdDQo+ICAgICA+ICAgICA+IEVudm95w6kgOiBtYXJk aSAxMSBhdnJpbCAyMDE3IDA5OjI5DQo+ICAgICA+ICAgICA+IMOAIDogQk9VQ0FEQUlSIE1vaGFt ZWQgSU1UL09MTg0KPiAgICAgPiAgICAgPiBDYyA6IGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVz OyB2Nm9wc0BpZXRmLm9yZw0KPiAgICAgPiAgICAgPiBPYmpldCA6IFJlOiBbdjZvcHNdIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdjZvcHMtDQo+ICAgICA+IHJmYzcwODQtYmlz LQ0KPiAgICAgPiAgICAgPiAwMC50eHQNCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gT24g VHVlLCAxMSBBcHIgMjAxNywgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4g ICAgID4gICAgID4NCj4gICAgID4gICAgID4gPiBbTWVkXSBESENQdjQtb3Zlci1ESENQdjYgaXMg bm90IGEgcmVxdWlyZWQgZm9yIG1hbnkgb2YgdGhlDQo+ICAgICA+IHRlY2huaXF1ZXMNCj4gICAg ID4gICAgID4gPiBsaXN0ZWQgaW4gdGhpcyBkcmFmdC4gSSBzdWdnZXN0IHRvIGRlbGV0ZSBpdCBm cm9tIHRoZSB0ZXh0Lg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiBIbSwgd2Ugc3RpbGwg bmVlZCB0byBrZWVwIGl0IGZvciB0aGUgbWVjaGFuaXNtcyB0aGF0IGFjdHVhbGx5DQo+IG5lZWQN Cj4gICAgID4gdGhpcywNCj4gICAgID4gICAgID4gbGlrZSBsdzRvNi4NCj4gICAgID4gICAgID4N Cj4gICAgID4gICAgID4gSSB1bmRlcnN0YW5kIGlmIGl0J3MgcmVtb3ZlZCBmb3IgdGhlIG9uZXMg dGhhdCBkbyBub3QgbmVlZCBpdC4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gLS0NCj4g ICAgID4gICAgID4gTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dtLnBwLnNl DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gICAgID4gSVB2 NCBpcyBvdmVyDQo+ICAgICA+IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0K PiAgICAgPiBodHRwOi8vd3d3LmNvbnN1bGludGVsLmVzDQo+ICAgICA+IFRoZSBJUHY2IENvbXBh bnkNCj4gICAgID4NCj4gICAgID4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5m b3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQNCj4gb3INCj4gICAgID4gY29uZmlkZW50 aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhl DQo+ICAgICA+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgYmUNCj4gYXdhcmUNCj4gICAgID4gdGhhdCBhbnkgZGlzY2xvc3Vy ZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YNCj4gdGhp cw0KPiAgICAgPiBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9o aWJpdGVkLg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgPiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gICAgID4gdjZvcHNAaWV0Zi5vcmcNCj4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4gDQo+IA0KPiANCj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiBJUHY0IGlzIG92ZXINCj4gQXJl IHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+IGh0dHA6Ly93d3cuY29uc3VsaW50 ZWwuZXMNCj4gVGhlIElQdjYgQ29tcGFueQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2Ug Y29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlk ZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2Yg dGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgYmUgYXdhcmUNCj4gdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywg ZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcw0KPiBpbmZvcm1hdGlv biwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KPiANCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9w cyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Tue Apr 11 08:04: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 9732612EA8C for ; Tue, 11 Apr 2017 08:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MxozgEHH9Vh for ; Tue, 11 Apr 2017 08:04:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B208412EAA6 for ; Tue, 11 Apr 2017 08:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491923062; x=1492527862; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=NFf/EjxYb1+mqlh95btArbBhR 5cnQjOtQMg0eUpT1pE=; b=FXz3AkcJ1GXOfAwwRJT3N2TrxKxO7gWUuKw9rpdh1 8fBcK7/Qo+HQ7raB4q6b+/NtxaiCuEHqNCwip4odNXeftcP/yB0no7MS5zOGBw7M DIj8JRoczi6rHTVijMfbCIC+7ZiMP97NZSgqw7r0XIYQ1mJ3oRguH1ujuCjJWPki l4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ebvoMTIF9v8N6zOhbVpq4gaUm7owi0wV9hZWkEuDjaOciYddpuI2udouRkLM 5wFHHsDJ5l58yK2Wk1g9JimHPl7UODbgc/zSoIZro8cLvgtv6fFC+L3Kw YidYEXOivRVk9G7OiN4dDVZgX8SDInhGhYqQGmygWu9oyTu8s2RT/k=; X-MDAV-Processed: mail.consulintel.es, Tue, 11 Apr 2017 17:04:22 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 11 Apr 2017 17:04:21 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406313.msg for ; Tue, 11 Apr 2017 17:04:21 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170411:md50005406313::83UT18uk8uxEb4WW:00001D+X X-Return-Path: prvs=1274da9a4c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 11 Apr 2017 17:04:17 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:04:30 -0000 Hi again ;-) See in-line. Saludos, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: martes, 11 de abril de 2017, 8:23 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: New Version Notification for draft-v6ops-rfc7084-bis-00.txt Hi Jordi,=20 =20 Please see inline. =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET > MARTINEZ > Envoy=C3=A9 : dimanche 2 avril 2017 23:48 > =C3=80 : v6ops@ietf.org > Objet : Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-= bis- > 00.txt >=20 > Hi all, >=20 > I=E2=80=99ve submitted WG 00 for this document. >=20 > https://datatracker.ietf.org/doc/draft-v6ops-rfc7084-bis >=20 > I tried to incorporate all the inputs that I captured in the meeting, > hopefully didn=E2=80=99t miss anything!, plus some minor edits. >=20 > Here is the summary for the changes: >=20 > 1) Added an annex (A) regarding the code considerations as I mention = in my > presentation. > 2) Added an annex (B) with the changes from the original RFC7084. > 3) Transition mechanisms in alphabetical order. > 4) Changed the IPv6-in-IPv4 transition mechanism (6RD and 6in4) to MA= Y > instead of SHOULD. =20 [Med] I suggest to delete these two sections:=20 =20 5.4.2. 6in4 . . . . . . . . . . . . . . . . . . . . . . . . 1= 6 5.4.3. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 1= 7 =20 The revision of RFC7084 should IMHO focus on IPv6 features + requiremen= ts to offer IPv4 service continuity over an IPv6 network.=20 [Jordi] I fully agree with the focus of this document to be IPv6-only acces= s and IPv4 as an overlay service. However, it also makes sense to find a co= mpromise, considering that this support was already required in the previou= s version of this document for IPv6-in-IPv4 technologies and it has actuall= y been included in the products in the market. What I see is the situation = of many ISPs that start with either dual-stack in the WAN or IPv6-in-IPv4 w= hen dual-stack is not possible, and then they move to IPv6-only when they r= un-out of IPv4 addresses. Keeping 6in4 protocols support avoids the ISPs to= replace the CE, but do a gradual =E2=80=9Cmigration=E2=80=9D from IPv4-onl= y-WAN to IPv6-only-WAN. This is why I think is reasonable to keep them but = only as MAY instead of SHOULD (as in the original RFC7084). =20 > 5) Added a new section regarding IPv4 multicast support in IPv6-only-= WAN. > 6) Added some text regarding the PCP support to learn PLAT info in 46= 4XLAT > (RFC 7225). >=20 > I=E2=80=99ve one question for the WG. >=20 > In all the IPv4-in-IPv6 transition mechanisms, I=E2=80=99m requiring: > =E2=80=9CThe CE router MUST support the DHCPv4-over-DHCPv6 (DHCP4o6) = transport > described in [RFC7341].=E2=80=9D >=20 > I got a comment that this is not needed, however, my feeling is that = the > configuration of certain IPv4 parameters for the CPE, during the > transition, are still needed and the ISP may need that. >=20 > So, the question is, what do you think about this? =20 [Med] DHCPv4-over-DHCPv6 is not a required for many of the techniques l= isted in this draft. I suggest to delete it from the text.=20 [Jordi] I think the status is now clear from the previous emails exchanged. =20 >=20 > Please, note that the original RFC7084 didn=E2=80=99t considered this= (RFC7341 > didn=E2=80=99t exist when it was published), so the actual version is= requesting > this not just for the new supported transition mechanisms (lw4o6, MAP= T/E, > 464XLAT), but also for DS-Lite. >=20 > Please provide inputs ASAP. I will like to avoid having this document > sleeping for too many weeks, and my goal is to publish a new version = in > about 2 weeks with any comments received. >=20 =20 [Med] I have the following comments about the NAT requirements: =20 OLD: LW4O6-4: The IPv6 CE router MUST perform IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated using lw4o6= . =20 This one should mention port restricted NAT. FWIW, you can reuse the sa= me wording in RFC7596: =20 " An lwB4 MUST support dynamic port-restricted IPv4 address provisioning. The port-set algorithm for provisioning this is described in Section 5.1 of [RFC7597]. For lw4o6, the number of a-bits SHOULD be 0, thus allocating a single contiguous port set to each lwB4."=20 =20 =20 OLD: MAP*-4: The IPv6 CE router MUST perform IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated using MAP-*. =20 Idem as above. Port-restricted NAT should be mentioned explicitly. You = can reuse this text from RFC7597/RFC7599: =20 The NAT44 implemented in the MAP CE SHOULD conform to the behavior and best current practices documented in [RFC4787], [RFC5508], and [RFC5382]. In MAP address-sharing mode (determined by the MAP domain / rule configuration parameters), the operation of the NAT44 MUST be restricted to the available port numbers derived via the Basic Mapping Rule. [Jordi] Yes, this has been already modified in the version I=E2=80=99m work= ing on. I don=E2=80=99t think is necessary to include the full text, just a= reference to port-restricted, as we are in any case mandating the usage of= each of the transition mechs RFCs. =20 Further, I suggest to remove pointers to individual drafts.=20 [Jordi] I guess you refer to draft-li-intarea-nat64-prefix-dhcp-option ? I= =E2=80=99m still considering it =E2=80=A6 I=E2=80=99m keeping the text at t= he time being for some more discussion about that option and also this docu= ment itself. =20 Thank you. =20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: > Responder a: > Fecha: domingo, 2 de abril de 2017, 22:57 > Para: Jordi Palet , Jordi Palet Martinez > > Asunto: New Version Notification for draft-v6ops-rfc7084-bis-00.txt >=20 >=20 > A new version of I-D, draft-v6ops-rfc7084-bis-00.txt > has been successfully submitted by Jordi Palet Martinez and poste= d to > the > IETF repository. >=20 > Name: draft-v6ops-rfc7084-bis > Revision: 00 > Title: Basic Requirements for IPv6 Customer Edge Routers > Document date: 2017-03-31 > Group: Individual Submission > Pages: 29 > URL: https://www.ietf.org/internet-drafts/draft-v6ops- > rfc7084-bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-v6ops-rfc7= 084- > bis/ > Htmlized: https://tools.ietf.org/html/draft-v6ops-rfc7084-b= is-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-v6ops= - > rfc7084-bis-00 >=20 >=20 > Abstract: > This document specifies requirements for an IPv6 Customer Edge= (CE) > router. Specifically, the current version of this document fo= cuses > on the basic provisioning of an IPv6 CE router and the provisi= oning > of IPv6 hosts attached to it. The document also covers severa= l > transition technologies, as required in a world where IPv4 > addresses > are no longer available, so hosts in the customer LANs with IP= v4- > only > or IPv6-only applications or devices, requiring to communicate= with > IPv4-only services at the Internet, are able to do so. The > document > obsoletes RFC 7084. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.o= rg. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be a= ware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Apr 11 08:11: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 0E45512EA6A for ; Tue, 11 Apr 2017 08:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBK8fkWzqdqC for ; Tue, 11 Apr 2017 08:11:43 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C45129C6F for ; Tue, 11 Apr 2017 08:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491923502; x=1492528302; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=ea0U7PlVJCTWxAjNo9CA+Zqhyk7JahmQ8D/fV7O81Qk=; b=khaSCs9DI/ESH SS+369xKeSywArSSqRE3IJf6AR8zjElF7Jwo+Enub5Mixj7KbFMmluPdeKQItn8Y pEVMqeyy1E43PjYRDqpG7dG56KhyblyScvz85u8AUc+7Imx4CvbOpF6gxwxhgCNt Say7nZvFfZb0WASuHThD1mmTdqtSY8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=EbSPGtPcYC374eZQHH9Ett4HtbP+EliULfmONuM01DFjWqrbTGQkHSnOlftw sfbhI3zkJ4Q8JWgIlvYvt8JDXNfPE/2V4a87moCAOY/Vje/l7p44lPhRJ bwW1vFQA4y3VRbgz+UCirHHz17iEi0vYC8wUQqZUfAyEPe/AWwxPmg=; X-MDAV-Processed: mail.consulintel.es, Tue, 11 Apr 2017 17:11:42 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 11 Apr 2017 17:11:41 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406320.msg for ; Tue, 11 Apr 2017 17:11:41 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170411:md50005406320::34tIEZuspYT/QBdd:00003eD8 X-Return-Path: prvs=1274da9a4c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 11 Apr 2017 17:11:39 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: LISP support for draft-ietf-v6ops-rfc7084-bis-00 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:11:45 -0000 Hi all, I got a comment about including support for LISP in order to allow IPv4 acc= ess with an IPv6-only-WAN. Even if I=E2=80=99ve got a couple of links of providers that actually use i= t, I believe is not something that is happening in the market, and seems to= be tied to a specific vendor. I=E2=80=99m not personally fan of including that support in the document, h= owever I will like to heard some more opinions on that from the WG. I plan to publish a new version (-01) in 1-2 days, maximum, so I will like = to heard opinions about that, and in general for the actual version of the = document. Regards, Jordi =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Apr 11 08:48: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 DE74312EAB8 for ; Tue, 11 Apr 2017 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwUmcDISvipt for ; Tue, 11 Apr 2017 08:48:39 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7877612EADF for ; Tue, 11 Apr 2017 08:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491925717; x=1492530517; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=olopnlaoSeMV85xaPm1SRIHTy m22l0RveGj7qZ4BvLc=; b=nncOUg6kwBxV3HaAazN/PZhcvtrJDOLNXYXlTkJAQ 5WEjXlEFdW6505SLN5huVLlpCrK+aKdD2j0l24wGZKg0BKqZOuOkjVjgTSfy68yG MpJ8N+3IG8Qf0GEMSTmMo9KiSQ6eVfy8woPL9OaoFTYJTeG/7d/DS+Aw/BdtmE4u RQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=QJn/bjd2uhxe9PYzW5RBHruBv+0bhTT2J0UacQkZDVu+pv3tMcvLnAZFmeKS obzejEdw9aXrLUQwxQYd7OIF5VfYSNUQk91fzPj2dOKeTKLA4MVRJzV8c 6Krd9nVTB4vso+Uud5afcpeq533anW88daZoxHG2JhtkcRAZijVZ9Q=; X-MDAV-Processed: mail.consulintel.es, Tue, 11 Apr 2017 17:48:37 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 11 Apr 2017 17:48:35 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406364.msg for ; Tue, 11 Apr 2017 17:48:35 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170411:md50005406364::z8P+k8H7Zd0LPPxR:00005UXD X-Return-Path: prvs=1274da9a4c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 11 Apr 2017 17:48:32 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4B8D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <830DC02A-27B1-44BD-ABA3-712BDD14BA28@consulintel.es> <787AE7BB302AE849A7480A190F8B933009E4BB22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <61B3DBD5-CB04-42CC-AF8F-E629E8E44F9B@consulintel.es> <787AE7BB302AE849A7480A190F8B933009E4BBE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4BBE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:48:42 -0000 I see your point, but then, if we follow the text in RFC7618: Applicability Statement The solution allows multiple hosts to be simultaneously allocated the same IP address. As the IP address is no longer a unique identifier for a host, this solution is only suitable for specific architectures based on the Address plus Port model (A+P) [RFC6346]. Specifically, this document presents a solution that applies to [RFC7596] and certain configurations of [RFC7597] (e.g., Embedded Address bit (EA-bit) length set to 0). It seems a discrepancy not asking for DHCP 4o6 as well in MAP-E. Should either that be clarified in RFC7618, and meanwhile we should include= (in RFC7084-bis) for MAP-E support as MAY for both DHCP 4o6 and RFC7618. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: martes, 11 de abril de 2017, 16:56 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00= .txt Re-, =20 Listing RFC7618 for MAP-E is odd if DHCPv4 over DHCPv6 is not required = for MAP-E.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET > MARTINEZ > Envoy=C3=A9 : mardi 11 avril 2017 16:42 > =C3=80 : v6ops@ietf.org > Objet : Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-= bis- > 00.txt >=20 > Hi Mohamed, >=20 > In-line >=20 > Saludos, > Jordi >=20 >=20 > -----Mensaje original----- > De: > Responder a: > Fecha: martes, 11 de abril de 2017, 16:21 > Para: "jordi.palet@consulintel.es" , > "v6ops@ietf.org" > Asunto: RE: [v6ops] New Version Notification for draft-v6ops-rfc7084-= bis- > 00.txt >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI = PALET > > MARTINEZ > > Envoy=C3=A9 : mardi 11 avril 2017 15:38 > > =C3=80 : v6ops@ietf.org > > Objet : Re: [v6ops] New Version Notification for draft-v6ops- > rfc7084-bis- > > 00.txt > > > > Hi all, > > > > Thanks all for the inputs. > > > > Responding on this to Mohamed, Masanobu and Mikael. > > > > Fully agree. I=E2=80=99m editing a new version, which will remo= ve the DHCP > 4o6 for > > MAP E/T >=20 > [Med] OK, thank you. I guess it was also removed for DS-Lite and > XLAT. >=20 > and only keep it as a must for lw4o6. >=20 > [Jordi] Yes, *only* keeping it for lw4o6 >=20 > > > > Masanobu, I think it should be a must, to conform with RFC7596, > where is > > already a MUST. > > > > Mohamed, Dyn-Shared-v4Alloc is already RFC7618. In RFC7596, it = is a > MAY, > > and seems to be applicable to both lw4o6 and MAP-E. Do you have= an > opinion > > about if we should make more explicit it, by including as MAY > support for > > RFC7618 for both (lw4o6 and MAP-E) ? >=20 > [Med] A simple approach is to follow the requirements as worded i= n > RFC7596 and RFC7597, i.e.,: > * no mention of RFC7618 for MAP-E > * use the same wording as in RFC7596 for lw4o6: MAY. >=20 > [Jordi] I=E2=80=99m also considering using MAY for MAP-E, as it seems= that, > according to RFC7618 applicability statement it is used in certain > configurations of MAP-E. >=20 > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: > > Responder a: > > Fecha: martes, 11 de abril de 2017, 11:39 > > Para: Mikael Abrahamsson > > CC: "jordi.palet@consulintel.es" , > > "v6ops@ietf.org" > > Asunto: RE: [v6ops] New Version Notification for draft-v6ops- > rfc7084-bis- > > 00.txt > > > > Re-, > > > > I think we are in agreement, Mikael. > > > > Actually, the only RFC that cites DHCPv4 over DHCPv6 is RFC= 7596. > So, > > at most that item may be listed for lw4o6 but be removed from o= ther > > sections. > > > > Note that for RFC7596, it says the following: > > > > " If stateful IPv4 configuration or > > ^^ > > additional IPv4 configuration information is required, D= HCP > 4o6 > > [RFC7341] MUST be used." > > > > And > > > > In addition to the DHCPv6-based mechanism described in > Section 5.1, > > several other IPv4 provisioning protocols have been > suggested. > > These > > protocols MAY be implemented. These alternatives includ= e: > > o DHCPv4 over DHCPv6: [RFC7341] describes implementing > DHCPv4 > > messages over an IPv6-only service provider's network= . > This > > enables leasing of IPv4 addresses and makes DHCPv4 op= tions > > available to the DHCPv4-over-DHCPv6 client. An lwB4 = MAY > > implement > > > > ^^^^^^^^^^^^^^^^^^^^^^ > > [RFC7341] and [Dyn-Shared-v4Alloc] to retrieve a shar= ed > IPv4 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > address with a set of ports. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > > Envoy=C3=A9 : mardi 11 avril 2017 09:29 > > > =C3=80 : BOUCADAIR Mohamed IMT/OLN > > > Cc : jordi.palet@consulintel.es; v6ops@ietf.org > > > Objet : Re: [v6ops] New Version Notification for draft-v6= ops- > > rfc7084-bis- > > > 00.txt > > > > > > On Tue, 11 Apr 2017, mohamed.boucadair@orange.com wrote: > > > > > > > [Med] DHCPv4-over-DHCPv6 is not a required for many of = the > > techniques > > > > listed in this draft. I suggest to delete it from the t= ext. > > > > > > Hm, we still need to keep it for the mechanisms that actu= ally > need > > this, > > > like lw4o6. > > > > > > I understand if it's removed for the ones that do not nee= d it. > > > > > > -- > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privi= leged > or > > confidential. The information is intended to be for the use of = the > > individual(s) named above. If you are not the intended recipien= t be > aware > > that any disclosure, copying, distribution or use of the conten= ts of > this > > information, including attached files, is prohibited. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be a= ware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Apr 11 09:23: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 3FC3C12EAEF for ; Tue, 11 Apr 2017 09:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FqJSjE545ucd for ; Tue, 11 Apr 2017 09:23:19 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 4172E12EAF2 for ; Tue, 11 Apr 2017 09:23:19 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l28so1464002wre.0 for ; Tue, 11 Apr 2017 09:23:19 -0700 (PDT) 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=TOw7Akxs8c3V97bX8fVB7+Xv+eAkkvb+SFKcQKmVrzo=; b=hUDbCTIXtoIYBDzIcbwd1pcPjNLphA3pEnjHx6rDnkbdXI7CnOZV9klCiDCh50F+wC VcmSwzxWtr7vDMNCjckA+LEtvws0iu5t+Rm8Bv7UdPKadJNPrgMue3MgEVjBJbXvFSLw q6mmeOq4uMZ8qXuuwVFO8nW/B92pf5Pj7Tc/ZyhvlLdigoLEtayEDB1I16C4tD2Rk+GD bBED8CQzfn8ifYLpx/7mKEq3OrwdOvBBqQAfMptjei1h70+bXdGyPUqDsCrCjBT/0Gjt 8j6Dszz9rZW0wwFqpRX4H1VBjQ6m5iZFL7jn/bdlc156ue8ld3OFLOftvuvhgZzGryQ6 jghQ== 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=TOw7Akxs8c3V97bX8fVB7+Xv+eAkkvb+SFKcQKmVrzo=; b=T5XSL+2ZZbmAUCm/VBujpVELV7MbCBfbYnQm+O3bmc6sJvNY5Dbg493m6wSWg5dPeV W4Xpd4fZ3MdMU9AmvSmC4urVgAS4ZOt3LRVK6Rd6wnLmDdsmvN9NOwMiMyLe2J1IRj1H F/5gD/I8Y9BtQQYOJsRmIwbtkGfc8dmej+HX8s4mizHOvYrplBj31o6wHpd0W5FfrcD1 ZVtIyvj0edEdKFnPuV7yGeMsMhbLqDwhdMUV+6/J7Q1eSw68NAmZXpC1GYtfJrLnjYXi HZLpCVoSQoBhjwJmmCROkSpLdXs71oTOuqWCgZDc5tQL5imum2bFaBY0wXoCp26Nj5/c k4Ow== X-Gm-Message-State: AFeK/H1JKWizugYFoBYVxKSs86jL2D/iLRODx7QALHKwy4yUA6sxanAruVH/y3EapJK03g== X-Received: by 10.223.166.108 with SMTP id k99mr28861668wrc.139.1491927797550; Tue, 11 Apr 2017 09:23:17 -0700 (PDT) Received: from 202.66.20.149.in-addr.arpa (202.66.20.149.in-addr.arpa. [149.20.66.202]) by smtp.gmail.com with ESMTPSA id m90sm3048633wmi.34.2017.04.11.09.23.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 09:23:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Tue, 11 Apr 2017 09:23:17 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 16:23:21 -0000 Speaking as a participant. I would suggest that any requirements found in the document be = *required* by at least one commercial network, preferably several. = Vendors and enthusiasts like to stuff requirements documents with their = favorite features, and in the products they make they can certainly = include them. But for everyone else, and for the networks that don't use = them, they are simply cost and a source of bugs. On Apr 11, 2017, at 8:11 AM, JORDI PALET MARTINEZ = wrote: > Hi all, >=20 > I got a comment about including support for LISP in order to allow = IPv4 access with an IPv6-only-WAN. >=20 > Even if I=E2=80=99ve got a couple of links of providers that actually = use it, I believe is not something that is happening in the market, and = seems to be tied to a specific vendor. >=20 > I=E2=80=99m not personally fan of including that support in the = document, however I will like to heard some more opinions on that from = the WG. >=20 > I plan to publish a new version (-01) in 1-2 days, maximum, so I will = like to heard opinions about that, and in general for the actual version = of the document. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 11 11:24: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 96DB712EBC7 for ; Tue, 11 Apr 2017 11:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, URIBL_BLOCKED=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 Hrl5NL412ZfB for ; Tue, 11 Apr 2017 11:24:40 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0113.outbound.protection.outlook.com [104.47.34.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3919D12EB9D for ; Tue, 11 Apr 2017 11:23:27 -0700 (PDT) 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=5uFmlyCvZ0Ei89lCnyjzcnKF9kMaEzb0J0SYk1OfSM8=; b=S/Xf32L/HEmFQUoPvrCSuDA0HMqjFyQmitzuHq00VJXMXMtYEaaZXs/XneqQEmtPInaG2CS97rrVGmxaLCPyKa2FQbaLL9aynu1ZY7qjmWvEoCeekpIlT/nGkHL6ZwDPPYExRx0q6i/Vbh5tSzhfuvdKUS/UMt2Eyxrccgua8ss= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Tue, 11 Apr 2017 18:23:26 +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.1034.009; Tue, 11 Apr 2017 18:23:26 +0000 From: Ron Bonica To: IPv6 Ops WG , Warren Kumari Thread-Topic: WGLC: draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 Thread-Index: AdKc0InL4psoNWVHTMWydOXElaK6IgWH+1Hw Date: Tue, 11 Apr 2017 18:23:25 +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: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 7:PEm3HvINVcF7i0qWNzrlB6z0GOPgw+bF/wtrpaamn9MIfG+cFxYmxUJuk9Bmu79RhaWPqmFUE+9bePZrodu7K+xf6MyGzUsBL3xO8TdhqJkTKM93774skoUJJ7hRmAjrWf5vHFSapAn0OjLiqJGhviNpEm8bI0DPrBZ9oYbtww1lhT8T3nbPL8mMQhhuhiamLbxu8ArbOEN4gSyt1y8gBrPXu791ltuf400RjAGSgs3h51Ila5zkdqwVlLqr6WRHJm/GeAeOkQRpOP91/ptVphwpfH2Z6FWu+Gz+34kJ6vIBmNKbBIlIzMknyecRKqOIFpG5x+rD8YLrOyhHLDP3DQ== x-ms-office365-filtering-correlation-id: 652f8d02-712a-4abf-312c-08d48107d856 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR0501MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39450400003)(39850400002)(39860400002)(39840400002)(13464003)(377454003)(305945005)(74316002)(77096006)(7736002)(3280700002)(2900100001)(53936002)(3660700001)(6506006)(38730400002)(6436002)(6306002)(99286003)(2906002)(33656002)(86362001)(3846002)(102836003)(6246003)(9686003)(55016002)(6116002)(5660300001)(122556002)(53546009)(7696004)(66066001)(25786009)(189998001)(8936002)(230783001)(2950100002)(76176999)(50986999)(54356999)(229853002)(8676002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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 Apr 2017 18:23:25.8352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052 Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:24:43 -0000 Folks, The message concludes the WG Last Call for draft-ietf-v6ops-unique-ipv6-pre= fix-per-host-02. We have had a good discussion on the mailing list and I be= lieve that all issues have been adequately addressed. Ron, Fred and Lee > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ron Bonica > Sent: Tuesday, March 14, 2017 10:41 AM > To: IPv6 Ops WG > Subject: [v6ops] WGLC: draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 >=20 > Folks, >=20 > This message initiates a Working Group Last Call (WGLC) for draft-ietf-v6= ops- > unique-ipv6-prefix-per-host-02. Since IETF is approaching, we will let th= e last > call run a little longer than usual. >=20 > Please submit comments to the list by April 11, 2017. >=20 > = Lee, Fred and Ron >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 11 11:34: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 ADE5D12EBD0; Tue, 11 Apr 2017 11:34:04 -0700 (PDT) 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, 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=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 Q-NQnYIe3iT0; Tue, 11 Apr 2017 11:34:03 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 9BF3D12EBCC; Tue, 11 Apr 2017 11:33:59 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id t189so7653845wmt.1; Tue, 11 Apr 2017 11:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:reply-to:mime-version:subject:date :message-id:cc:to; bh=nbBuLMOKaLGFurN9vK15tbYy2/NgVYCDirY87I//PVg=; b=eLVoRZBKqwNhA659ewgVlS/YAxunt2CEFCoYRMIYUGCA873prvNGSRbMVR77bZUQvl i5SGGdYWJ/Bx9U5ee79xblpYi1YqpX/HWnghHsrWw7BEU22MRb8XkP2d+JVblVRGTDsu 0v+GQDqY+GQgVAlu4040q2HFVtFxxvZJERcY7BjIQFOG9CWbA6QkYwH5S9/pSj4R1OZM 31GdVni1kOK+fDhio9MhvpnPl7Fs/Bdi90Jz2YK8zQWOTrouXhDpVLgNDGCrQSJl7feZ ppXy3APA3JgNtVj1ski43+OmmLGjTzVWaLi1mlG0w6Ij2tChfnGOwY/GPJtrrnJSDpIZ 9brQ== 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:reply-to :mime-version:subject:date:message-id:cc:to; bh=nbBuLMOKaLGFurN9vK15tbYy2/NgVYCDirY87I//PVg=; b=l1BRWKBQPLlHqvRhE0DoDclktFI1k3J3toeDRYKbhAE5D7RPCbiuUuySOlgAi8SllA qi28yKa/9GjDz+bdkevBR+d3T9FraMtcYzEhn35UMx15zUZyFy7XxatZV7I4E20S7bFN JxLJtQcLy1brp4z5CY+3XWwlFODYuf8ii+ghUGoJuzFoPN6ZisbLrqpRvCp1sQu+CBhu HijlsV/VyNCmv9vUU+M00Q3DRsgHmM9EzADO5hYaE5vXRS1YS0fssc0TBEPdfYdpqaAf t5tkFvdAD4CH3qryD/oXWBBYLhvCma72TyWe0360uhTefu92ODXAhKmumLtNgL1uUXFJ Nbgw== X-Gm-Message-State: AN3rC/6JP1iW4wREYJZceFrHRmXoplnvsPIPFLHEK43arr3456+30YvPTWMJ5x/9waY2Xg== X-Received: by 10.28.68.6 with SMTP id r6mr2593407wma.7.1491935638129; Tue, 11 Apr 2017 11:33:58 -0700 (PDT) Received: from 209.66.20.149.in-addr.arpa (209.66.20.149.in-addr.arpa. [149.20.66.209]) by smtp.gmail.com with ESMTPSA id v7sm22420131wrd.0.2017.04.11.11.33.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 11:33:57 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: IPv6 Operations Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Apr 2017 11:33:54 -0700 Message-Id: <6D1DEB90-C956-4740-B54E-384927527D6B@gmail.com> Cc: draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] WGLC for draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:34:05 -0000 This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-v6ops-v4v6-xlat-prefix. If you = have not read it, please do so now. You may send nits to the author, but = substantive discussion should go to the list. Note that we have one comment from Jordi, who considers it ready to go, = and my sense of the list discussion prior to adoption was that the = working group is OK with simply doing this. I will close the call on 25 April.= From nobody Tue Apr 11 22:57: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 A996F1287A0 for ; Tue, 11 Apr 2017 22:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 M9LDOnMc263A for ; Tue, 11 Apr 2017 22:57:33 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EE9127B31 for ; Tue, 11 Apr 2017 22:57:32 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 165B6C0669; Wed, 12 Apr 2017 07:57:31 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id D8C0A120059; Wed, 12 Apr 2017 07:57:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 07:57:30 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSstsgOmTC+LATkUyUWiapb2SKg6HBOsOg Date: Wed, 12 Apr 2017 05:57:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4C117@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4B8D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <830DC02A-27B1-44BD-ABA3-712BDD14BA28@consulintel.es> <787AE7BB302AE849A7480A190F8B933009E4BB22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <61B3DBD5-CB04-42CC-AF8F-E629E8E44F9B@consulintel.es> <787AE7BB302AE849A7480A190F8B933009E4BBE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 05:57:36 -0000 SGkgSm9yZGksIA0KDQpUaGVyZSBpcyBubyBuZWVkIHRvIG92ZXItc3BlY2lmeSBmb3IgTUFQLUUs IGhlcmUuIFRoZSB1c2Ugb2YgdGhlIERIQ1B2NiBvcHRpb24gdG8gcHJvdmlzaW9uIHRoZSBDRSBp cyBzdWZmaWNpZW50Lg0KDQpSRkM3MDg0LWJpcyBzaG91bGQgbm90IHJlcXVpcmUgbW9yZSB0aGFu IHdoYXQgd2FzIHJlY29yZGVkIGluIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGVhY2ggbWVjaGFuaXNt LiBUaGFuayB5b3UuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgSk9SREkgUEFMRVQNCj4gTUFSVElORVoNCj4gRW52b3nDqcKgOiBtYXJkaSAxMSBh dnJpbCAyMDE3IDE3OjQ5DQo+IMOAwqA6IHY2b3BzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBb djZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdjZvcHMtcmZjNzA4NC1i aXMtDQo+IDAwLnR4dA0KPiANCj4gSSBzZWUgeW91ciBwb2ludCwgYnV0IHRoZW4sIGlmIHdlIGZv bGxvdyB0aGUgdGV4dCBpbiBSRkM3NjE4Og0KPiANCj4gQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQN Cj4gDQo+ICAgIFRoZSBzb2x1dGlvbiBhbGxvd3MgbXVsdGlwbGUgaG9zdHMgdG8gYmUgc2ltdWx0 YW5lb3VzbHkgYWxsb2NhdGVkIHRoZQ0KPiAgICBzYW1lIElQIGFkZHJlc3MuICBBcyB0aGUgSVAg YWRkcmVzcyBpcyBubyBsb25nZXIgYSB1bmlxdWUgaWRlbnRpZmllcg0KPiAgICBmb3IgYSBob3N0 LCB0aGlzIHNvbHV0aW9uIGlzIG9ubHkgc3VpdGFibGUgZm9yIHNwZWNpZmljIGFyY2hpdGVjdHVy ZXMNCj4gICAgYmFzZWQgb24gdGhlIEFkZHJlc3MgcGx1cyBQb3J0IG1vZGVsIChBK1ApIFtSRkM2 MzQ2XS4gIFNwZWNpZmljYWxseSwNCj4gICAgdGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIHNvbHV0 aW9uIHRoYXQgYXBwbGllcyB0byBbUkZDNzU5Nl0gYW5kDQo+ICAgIGNlcnRhaW4gY29uZmlndXJh dGlvbnMgb2YgW1JGQzc1OTddIChlLmcuLCBFbWJlZGRlZCBBZGRyZXNzIGJpdA0KPiAgICAoRUEt Yml0KSBsZW5ndGggc2V0IHRvIDApLg0KPiANCj4gSXQgc2VlbXMgYSBkaXNjcmVwYW5jeSBub3Qg YXNraW5nIGZvciBESENQIDRvNiBhcyB3ZWxsIGluIE1BUC1FLg0KPiANCj4gU2hvdWxkIGVpdGhl ciB0aGF0IGJlIGNsYXJpZmllZCBpbiBSRkM3NjE4LCBhbmQgbWVhbndoaWxlIHdlIHNob3VsZA0K PiBpbmNsdWRlIChpbiBSRkM3MDg0LWJpcykgZm9yIE1BUC1FIHN1cHBvcnQgYXMgTUFZIGZvciBi b3RoIERIQ1AgNG82IGFuZA0KPiBSRkM3NjE4Lg0KPiANCj4gUmVnYXJkcywNCj4gSm9yZGkNCj4g DQo+IA0KPiAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiBEZTogPG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+DQo+IFJlc3BvbmRlciBhOiA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4NCj4gRmVjaGE6IG1hcnRlcywgMTEgZGUgYWJyaWwgZGUgMjAxNywgMTY6NTYNCj4gUGFy YTogImpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzIiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwu ZXM+LA0KPiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4NCj4gQXN1bnRvOiBSRTog W3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXY2b3BzLXJmYzcwODQt YmlzLQ0KPiAwMC50eHQNCj4gDQo+ICAgICBSZS0sDQo+IA0KPiAgICAgTGlzdGluZyBSRkM3NjE4 IGZvciBNQVAtRSBpcyBvZGQgaWYgREhDUHY0IG92ZXIgREhDUHY2IGlzIG5vdCByZXF1aXJlZA0K PiBmb3IgTUFQLUUuDQo+IA0KPiAgICAgQ2hlZXJzLA0KPiAgICAgTWVkDQo+IA0KPiAgICAgPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gICAgID4gRGUgOiB2Nm9wcyBbbWFpbHRvOnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSk9SREkgUEFMRVQNCj4gICAgID4g TUFSVElORVoNCj4gICAgID4gRW52b3nDqSA6IG1hcmRpIDExIGF2cmlsIDIwMTcgMTY6NDINCj4g ICAgID4gw4AgOiB2Nm9wc0BpZXRmLm9yZw0KPiAgICAgPiBPYmpldCA6IFJlOiBbdjZvcHNdIE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdjZvcHMtDQo+IHJmYzcwODQtYmlzLQ0K PiAgICAgPiAwMC50eHQNCj4gICAgID4NCj4gICAgID4gSGkgTW9oYW1lZCwNCj4gICAgID4NCj4g ICAgID4gSW4tbGluZQ0KPiAgICAgPg0KPiAgICAgPiBTYWx1ZG9zLA0KPiAgICAgPiBKb3JkaQ0K PiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiAg ICAgPiBEZTogPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ICAgICA+IFJlc3BvbmRl ciBhOiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gICAgID4gRmVjaGE6IG1hcnRl cywgMTEgZGUgYWJyaWwgZGUgMjAxNywgMTY6MjENCj4gICAgID4gUGFyYTogImpvcmRpLnBhbGV0 QGNvbnN1bGludGVsLmVzIiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+LA0KPiAgICAgPiAi djZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4NCj4gICAgID4gQXN1bnRvOiBSRTogW3Y2 b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXY2b3BzLQ0KPiByZmM3MDg0 LWJpcy0NCj4gICAgID4gMDAudHh0DQo+ICAgICA+DQo+ICAgICA+ICAgICBSZS0sDQo+ICAgICA+ DQo+ICAgICA+ICAgICBQbGVhc2Ugc2VlIGlubGluZS4NCj4gICAgID4NCj4gICAgID4gICAgIENo ZWVycywNCj4gICAgID4gICAgIE1lZA0KPiAgICAgPg0KPiAgICAgPiAgICAgPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gICAgID4gICAgID4gRGUgOiB2Nm9wcyBbbWFpbHRvOnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSk9SREkNCj4gUEFMRVQNCj4gICAgID4g ICAgID4gTUFSVElORVoNCj4gICAgID4gICAgID4gRW52b3nDqSA6IG1hcmRpIDExIGF2cmlsIDIw MTcgMTU6MzgNCj4gICAgID4gICAgID4gw4AgOiB2Nm9wc0BpZXRmLm9yZw0KPiAgICAgPiAgICAg PiBPYmpldCA6IFJlOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt djZvcHMtDQo+ICAgICA+IHJmYzcwODQtYmlzLQ0KPiAgICAgPiAgICAgPiAwMC50eHQNCj4gICAg ID4gICAgID4NCj4gICAgID4gICAgID4gSGkgYWxsLA0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAg ICAgPiBUaGFua3MgYWxsIGZvciB0aGUgaW5wdXRzLg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAg ICAgPiBSZXNwb25kaW5nIG9uIHRoaXMgdG8gTW9oYW1lZCwgTWFzYW5vYnUgYW5kIE1pa2FlbC4N Cj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gRnVsbHkgYWdyZWUuIEnigJltIGVkaXRpbmcg YSBuZXcgdmVyc2lvbiwgd2hpY2ggd2lsbCByZW1vdmUgdGhlDQo+IERIQ1ANCj4gICAgID4gNG82 IGZvcg0KPiAgICAgPiAgICAgPiBNQVAgRS9UDQo+ICAgICA+DQo+ICAgICA+ICAgICBbTWVkXSBP SywgdGhhbmsgeW91LiAgSSBndWVzcyBpdCB3YXMgYWxzbyByZW1vdmVkIGZvciBEUy1MaXRlDQo+ IGFuZA0KPiAgICAgPiBYTEFULg0KPiAgICAgPg0KPiAgICAgPiAgICAgIGFuZCBvbmx5IGtlZXAg aXQgYXMgYSBtdXN0IGZvciBsdzRvNi4NCj4gICAgID4NCj4gICAgID4gW0pvcmRpXSBZZXMsICpv bmx5KiBrZWVwaW5nIGl0IGZvciBsdzRvNg0KPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAg PiAgICAgPiBNYXNhbm9idSwgSSB0aGluayBpdCBzaG91bGQgYmUgYSBtdXN0LCB0byBjb25mb3Jt IHdpdGgNCj4gUkZDNzU5NiwNCj4gICAgID4gd2hlcmUgaXMNCj4gICAgID4gICAgID4gYWxyZWFk eSBhIE1VU1QuDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+IE1vaGFtZWQsIER5bi1TaGFy ZWQtdjRBbGxvYyBpcyBhbHJlYWR5IFJGQzc2MTguIEluIFJGQzc1OTYsIGl0DQo+IGlzIGENCj4g ICAgID4gTUFZLA0KPiAgICAgPiAgICAgPiBhbmQgc2VlbXMgdG8gYmUgYXBwbGljYWJsZSB0byBi b3RoIGx3NG82IGFuZCBNQVAtRS4gRG8geW91DQo+IGhhdmUgYW4NCj4gICAgID4gb3Bpbmlvbg0K PiAgICAgPiAgICAgPiBhYm91dCBpZiB3ZSBzaG91bGQgbWFrZSBtb3JlIGV4cGxpY2l0IGl0LCBi eSBpbmNsdWRpbmcgYXMgTUFZDQo+ICAgICA+IHN1cHBvcnQgZm9yDQo+ICAgICA+ICAgICA+IFJG Qzc2MTggZm9yIGJvdGggKGx3NG82IGFuZCBNQVAtRSkgPw0KPiAgICAgPg0KPiAgICAgPiAgICAg W01lZF0gQSBzaW1wbGUgYXBwcm9hY2ggaXMgdG8gZm9sbG93IHRoZSByZXF1aXJlbWVudHMgYXMg d29yZGVkDQo+IGluDQo+ICAgICA+IFJGQzc1OTYgYW5kIFJGQzc1OTcsIGkuZS4sOg0KPiAgICAg PiAgICAgKiBubyBtZW50aW9uIG9mIFJGQzc2MTggZm9yIE1BUC1FDQo+ICAgICA+ICAgICAqIHVz ZSB0aGUgc2FtZSB3b3JkaW5nIGFzIGluIFJGQzc1OTYgZm9yIGx3NG82OiBNQVkuDQo+ICAgICA+ DQo+ICAgICA+IFtKb3JkaV0gSeKAmW0gYWxzbyBjb25zaWRlcmluZyB1c2luZyBNQVkgZm9yIE1B UC1FLCBhcyBpdCBzZWVtcyB0aGF0LA0KPiAgICAgPiBhY2NvcmRpbmcgdG8gUkZDNzYxOCBhcHBs aWNhYmlsaXR5IHN0YXRlbWVudCBpdCBpcyB1c2VkIGluIGNlcnRhaW4NCj4gICAgID4gY29uZmln dXJhdGlvbnMgb2YgTUFQLUUuDQo+ICAgICA+DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ IFJlZ2FyZHMsDQo+ICAgICA+ICAgICA+IEpvcmRpDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAg ICA+DQo+ICAgICA+ICAgICA+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+ICAgICA+ICAg ICA+IERlOiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gICAgID4gICAgID4gUmVz cG9uZGVyIGE6IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiAgICAgPiAgICAgPiBG ZWNoYTogbWFydGVzLCAxMSBkZSBhYnJpbCBkZSAyMDE3LCAxMTozOQ0KPiAgICAgPiAgICAgPiBQ YXJhOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U+DQo+ICAgICA+ICAgICA+ IENDOiAiam9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXMiIDxqb3JkaS5wYWxldEBjb25zdWxpbnRl bC5lcz4sDQo+ICAgICA+ICAgICA+ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPg0K PiAgICAgPiAgICAgPiBBc3VudG86IFJFOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtdjZvcHMtDQo+ICAgICA+IHJmYzcwODQtYmlzLQ0KPiAgICAgPiAgICAgPiAw MC50eHQNCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAgIFJlLSwNCj4gICAgID4gICAg ID4NCj4gICAgID4gICAgID4gICAgIEkgdGhpbmsgd2UgYXJlIGluIGFncmVlbWVudCwgTWlrYWVs Lg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgQWN0dWFsbHksIHRoZSBvbmx5IFJG QyB0aGF0IGNpdGVzIERIQ1B2NCBvdmVyIERIQ1B2NiBpcw0KPiBSRkM3NTk2Lg0KPiAgICAgPiBT bywNCj4gICAgID4gICAgID4gYXQgbW9zdCB0aGF0IGl0ZW0gbWF5IGJlIGxpc3RlZCBmb3IgbHc0 bzYgYnV0IGJlIHJlbW92ZWQgZnJvbQ0KPiBvdGhlcg0KPiAgICAgPiAgICAgPiBzZWN0aW9ucy4N Cj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAgIE5vdGUgdGhhdCBmb3IgUkZDNzU5Niwg aXQgc2F5cyB0aGUgZm9sbG93aW5nOg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAg IiBJZiBzdGF0ZWZ1bCBJUHY0IGNvbmZpZ3VyYXRpb24gb3INCj4gICAgID4gICAgID4gICAgICAg Xl4NCj4gICAgID4gICAgID4gICAgICAgIGFkZGl0aW9uYWwgSVB2NCBjb25maWd1cmF0aW9uIGlu Zm9ybWF0aW9uIGlzIHJlcXVpcmVkLA0KPiBESENQDQo+ICAgICA+IDRvNg0KPiAgICAgPiAgICAg PiAgICAgICAgW1JGQzczNDFdIE1VU1QgYmUgdXNlZC4iDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ ICAgICA+ICAgICBBbmQNCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAgICAgIEluIGFk ZGl0aW9uIHRvIHRoZSBESENQdjYtYmFzZWQgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbg0KPiAgICAg PiBTZWN0aW9uIDUuMSwNCj4gICAgID4gICAgID4gICAgICAgIHNldmVyYWwgb3RoZXIgSVB2NCBw cm92aXNpb25pbmcgcHJvdG9jb2xzIGhhdmUgYmVlbg0KPiAgICAgPiBzdWdnZXN0ZWQuDQo+ICAg ICA+ICAgICA+IFRoZXNlDQo+ICAgICA+ICAgICA+ICAgICAgICBwcm90b2NvbHMgTUFZIGJlIGlt cGxlbWVudGVkLiAgVGhlc2UgYWx0ZXJuYXRpdmVzDQo+IGluY2x1ZGU6DQo+ICAgICA+ICAgICA+ ICAgICAgICBvICBESENQdjQgb3ZlciBESENQdjY6IFtSRkM3MzQxXSBkZXNjcmliZXMgaW1wbGVt ZW50aW5nDQo+ICAgICA+IERIQ1B2NA0KPiAgICAgPiAgICAgPiAgICAgICAgICAgbWVzc2FnZXMg b3ZlciBhbiBJUHY2LW9ubHkgc2VydmljZSBwcm92aWRlcidzDQo+IG5ldHdvcmsuDQo+ICAgICA+ IFRoaXMNCj4gICAgID4gICAgID4gICAgICAgICAgIGVuYWJsZXMgbGVhc2luZyBvZiBJUHY0IGFk ZHJlc3NlcyBhbmQgbWFrZXMgREhDUHY0DQo+IG9wdGlvbnMNCj4gICAgID4gICAgID4gICAgICAg ICAgIGF2YWlsYWJsZSB0byB0aGUgREhDUHY0LW92ZXItREhDUHY2IGNsaWVudC4gIEFuIGx3QjQN Cj4gTUFZDQo+ICAgICA+ICAgICA+IGltcGxlbWVudA0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAg ICAgPiBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ICAgICA+ICAgICA+ICAgICAgICAgICBbUkZD NzM0MV0gYW5kIFtEeW4tU2hhcmVkLXY0QWxsb2NdIHRvIHJldHJpZXZlIGENCj4gc2hhcmVkDQo+ ICAgICA+IElQdjQNCj4gICAgID4gICAgID4gICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl4NCj4gICAgID4gICAgID4gICAgICAgICAgIGFkZHJlc3Mgd2l0aCBhIHNl dCBvZiBwb3J0cy4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAgIENoZWVycywNCj4g ICAgID4gICAgID4gICAgIE1lZA0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gICAgID4gICAgID4gICAgID4gRGUgOiBNaWth ZWwgQWJyYWhhbXNzb24gW21haWx0bzpzd21pa2VAc3dtLnBwLnNlXQ0KPiAgICAgPiAgICAgPiAg ICAgPiBFbnZvecOpIDogbWFyZGkgMTEgYXZyaWwgMjAxNyAwOToyOQ0KPiAgICAgPiAgICAgPiAg ICAgPiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gICAgID4gICAgID4gICAgID4g Q2MgOiBqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lczsgdjZvcHNAaWV0Zi5vcmcNCj4gICAgID4g ICAgID4gICAgID4gT2JqZXQgOiBSZTogW3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LQ0KPiB2Nm9wcy0NCj4gICAgID4gICAgID4gcmZjNzA4NC1iaXMtDQo+ICAgICA+ ICAgICA+ICAgICA+IDAwLnR4dA0KPiAgICAgPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAg ICAgPiBPbiBUdWUsIDExIEFwciAyMDE3LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdy b3RlOg0KPiAgICAgPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgPiA+IFtNZWRdIERI Q1B2NC1vdmVyLURIQ1B2NiBpcyBub3QgYSByZXF1aXJlZCBmb3IgbWFueSBvZg0KPiB0aGUNCj4g ICAgID4gICAgID4gdGVjaG5pcXVlcw0KPiAgICAgPiAgICAgPiAgICAgPiA+IGxpc3RlZCBpbiB0 aGlzIGRyYWZ0LiBJIHN1Z2dlc3QgdG8gZGVsZXRlIGl0IGZyb20gdGhlDQo+IHRleHQuDQo+ICAg ICA+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ICAgICA+IEhtLCB3ZSBzdGlsbCBuZWVkIHRv IGtlZXAgaXQgZm9yIHRoZSBtZWNoYW5pc21zIHRoYXQNCj4gYWN0dWFsbHkNCj4gICAgID4gbmVl ZA0KPiAgICAgPiAgICAgPiB0aGlzLA0KPiAgICAgPiAgICAgPiAgICAgPiBsaWtlIGx3NG82Lg0K PiAgICAgPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgPiBJIHVuZGVyc3RhbmQgaWYg aXQncyByZW1vdmVkIGZvciB0aGUgb25lcyB0aGF0IGRvIG5vdA0KPiBuZWVkIGl0Lg0KPiAgICAg PiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgPiAtLQ0KPiAgICAgPiAgICAgPiAgICAg PiBNaWthZWwgQWJyYWhhbXNzb24gICAgZW1haWw6IHN3bWlrZUBzd20ucHAuc2UNCj4gICAgID4g ICAgID4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4NCj4gICAg ID4gICAgID4NCj4gICAgID4gICAgID4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KPiAgICAgPiAgICAgPiBJUHY0IGlzIG92ZXINCj4gICAgID4gICAgID4g QXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+ICAgICA+ICAgICA+IGh0dHA6 Ly93d3cuY29uc3VsaW50ZWwuZXMNCj4gICAgID4gICAgID4gVGhlIElQdjYgQ29tcGFueQ0KPiAg ICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlu cyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUNCj4gcHJpdmlsZWdlZA0KPiAgICAgPiBvcg0KPiAg ICAgPiAgICAgPiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBi ZSBmb3IgdGhlIHVzZSBvZg0KPiB0aGUNCj4gICAgID4gICAgID4gaW5kaXZpZHVhbChzKSBuYW1l ZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+IHJlY2lwaWVudCBiZQ0KPiAg ICAgPiBhd2FyZQ0KPiAgICAgPiAgICAgPiB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBk aXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZQ0KPiBjb250ZW50cyBvZg0KPiAgICAgPiB0aGlzDQo+ ICAgICA+ICAgICA+IGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHBy b2hpYml0ZWQuDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+DQo+ ICAgICA+ICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ICAgICA+ICAgICA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiAgICAgPiAgICAgPiB2Nm9w c0BpZXRmLm9yZw0KPiAgICAgPiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gICAgID4g SVB2NCBpcyBvdmVyDQo+ICAgICA+IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQg Pw0KPiAgICAgPiBodHRwOi8vd3d3LmNvbnN1bGludGVsLmVzDQo+ICAgICA+IFRoZSBJUHY2IENv bXBhbnkNCj4gICAgID4NCj4gICAgID4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMg aW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQNCj4gb3INCj4gICAgID4gY29uZmlk ZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2Yg dGhlDQo+ICAgICA+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgYmUNCj4gYXdhcmUNCj4gICAgID4gdGhhdCBhbnkgZGlzY2xv c3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YNCj4g dGhpcw0KPiAgICAgPiBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBw cm9oaWJpdGVkLg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgPiB2Nm9wcyBtYWls aW5nIGxpc3QNCj4gICAgID4gdjZvcHNAaWV0Zi5vcmcNCj4gICAgID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4gDQo+IA0KPiANCj4gKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiBJUHY0IGlzIG92ZXINCj4g QXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+IGh0dHA6Ly93d3cuY29uc3Vs aW50ZWwuZXMNCj4gVGhlIElQdjYgQ29tcGFueQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3Nh Z2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29u ZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ug b2YgdGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUNCj4gdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWlu ZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcw0KPiBpbmZvcm1h dGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KPiANCj4gDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2 Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Wed Apr 12 02:34: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 42A4B1242EA for ; Wed, 12 Apr 2017 02:34:50 -0700 (PDT) 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=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 o1LHZX1tpqss for ; Wed, 12 Apr 2017 02:34:48 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D866E12EB08 for ; Wed, 12 Apr 2017 02:34:47 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 12 Apr 2017 09:34:47 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 525ADD788B; Wed, 12 Apr 2017 02:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=iE51PB1jXf8bLrltKBipIFgT2+A=; b= EVopxkpB3g/RfTZpD4jTGbFTUWNVCB38Qr2CcP5mQnjTvMH8OhdI8Jev9kjo0bNN hqebW5r2tzwimEd3gYGAy3639ASStWyoap8+n7n8dbjrGXpgD8bt/PNB8HWIH6nn rL3P+GGoMtw45Na5XKuJxRhbTcfSw/s3I0av0Feqmfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=clOP5jImbhcmbrE2NdniTOd 7snfY4fG3yiSyDr4lx74AyiwQrsuI0dL9rDhb0bvEMJETuZd9YXvfQVK+M+jAEV4 kGf+yfCPil4txCFq3bIROo3zNONUQoMlYqqXvGeqjt4PQheJqOtFDPPDsHaZkbDO MT1Lc+sZeS6zzq9qamKY= 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 1EDC8D788A; Wed, 12 Apr 2017 02:34:47 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D758BA903910; Wed, 12 Apr 2017 11:34:45 +0200 (CEST) From: otroan@employees.org Message-Id: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_CEA46EA1-677D-441D-9055-7029D0E7B658"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 11:34:44 +0200 In-Reply-To: Cc: v6ops@ietf.org To: jordi.palet@consulintel.es References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 09:34:50 -0000 --Apple-Mail=_CEA46EA1-677D-441D-9055-7029D0E7B658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jordi, The standardisation of the "transitioning off IPv4 mechanisms" is a = prime example of IETF failure. You are proposing to carry that failure forward and require all CE = implementations to implement _all_ the mechanisms in existence? That is not providing "value add" to the community. If I remember correctly that list is now: RFC2473, GRE, L2TP, LISP, = MAP-E, MAP-T, 4RD, 464XLAT, Public 4over6, LW46, Dynamic LW46, ... Best regards, Ole > On 11 Apr 2017, at 17:11, JORDI PALET MARTINEZ = wrote: >=20 > Hi all, >=20 > I got a comment about including support for LISP in order to allow = IPv4 access with an IPv6-only-WAN. >=20 > Even if I=E2=80=99ve got a couple of links of providers that actually = use it, I believe is not something that is happening in the market, and = seems to be tied to a specific vendor. >=20 > I=E2=80=99m not personally fan of including that support in the = document, however I will like to heard some more opinions on that from = the WG. >=20 > I plan to publish a new version (-01) in 1-2 days, maximum, so I will = like to heard opinions about that, and in general for the actual version = of the document. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_CEA46EA1-677D-441D-9055-7029D0E7B658 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY7fS0AAoJEL7aWKiYQt92t5oP/j+ALfklqpcC0E8aa/lJkE37 uewCfOznmzt//kGXBTFljg543cVxe1nlYq0lhgTBGW43GQV2rBLnyHBmBGuN5qmC fRe2R2dFWJiAobjCepzJa894Kcnq2xCZfM6hSFWlTZED/mSSnG2+GDPHtq0Oowhd 9lP/tGtZG6hvl57q/n7YfJJrFBHxgcEDIHCxrRjJvFx/X+Hqi92DFnCjGOXaFGIk UCuSBiqmru+jMFZmPG6PsDiZ0KoMFzYaVaNBjGqGvch+DmnO/EWG6+G1I3GHHiMM jl5F0hbp+M0echPaJRRPESAt+he7OyhW5+kkUeFshipPILAZ8cRepjPI1NxuRCYX yTnwxh4gr0MhtkuhIXTQZBh+z6FeI4GgMN0aY119cbV7IujMceHIyLWi7OTNpYc7 RglnQ/UF3rQh6zFTcxC41Wz/Rf0ksFXdFFS9sQOE6SJehts45NmKaRFPncMQD7AD R0jkYjMtxURlnQQTHy0BhkQAp4j5av3YpMQJOl0kOYWbPd66btzCk0zJUutVuCt0 PTHrCUB1l+m+dGh1m6nQG91CifJbwqD3y+7nWwxppHjBh883yXw3o4ulppzU4iKA J0O0wgWPMgNdy4b3Sil7XpUw7ZgASqd/dblTzjLxoW26XjYbhWBrIcmtlqDYAd4G 1gWUlcDzlEeqguWl7ofP =HkXR -----END PGP SIGNATURE----- --Apple-Mail=_CEA46EA1-677D-441D-9055-7029D0E7B658-- From nobody Wed Apr 12 02:44: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 76CFE1314FF for ; Wed, 12 Apr 2017 02:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyj2lJhAiAP8 for ; Wed, 12 Apr 2017 02:44:54 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF7A1314FD for ; Wed, 12 Apr 2017 02:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491990290; x=1492595090; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=Y0EOoDjZ2F611LDWuNyJHe3gR RkbKcNMiyWKtgXGv6A=; b=Gcek7mw4NZyE4gMGkA6pjOBr2ZarEyLRVLmarJ7m7 mD7tpu2BU80e3pARe9C/g1PpCotyAD2nWnAGS8VpgTmNhLf8so6OzxSh8sHfWgj6 FJXLJZel5HPiWa9Vh12Bqxrk3mHXrIqOrsKttS9Cn1E4peIl/REnQtWzglYnAv4t cI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=uAZf5w2w8kk3RKSEkRB4rEEjpAwsP6X3Y4qzcRLXvOvT6EkDFNL2WeNaP+Rw BqF17sMcf2KiL5eaHf2M5CSfu4BRMUt7aEWsl40memkuLGR3OgHt5HSA3 6R0nX8qBIPSwq3X9RC+yM77cR36VNC8tymCoHdcunYTHGkR4JIxAYI=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 11:44:50 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 11:44:49 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406904.msg for ; Wed, 12 Apr 2017 11:44:47 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005406904::ub7LA8P37gmPQu4b:000035qd X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 11:44:46 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> In-Reply-To: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 09:44:56 -0000 Hi Ole, No, sorry, I guess you misunderstood my email. I=E2=80=99m NOT in favor of including an unlimited number of mechanisms, an= d I think we must focus in those that have a real traction. I=E2=80=99m NOT= in favor of including LISP. However, the document is a WG document, so is not just my decision, but the= WG, so I must ask the WG opinions before =E2=80=9Crejecting=E2=80=9D LISP.= That was my question. I think we need to have a balance: 1) Main goal, support of IPv6-only access but allow IPv4 to keep working in= the customer=E2=80=99s LANs. 2) Allow the support of =E2=80=9Colder=E2=80=9D IPv6-in-IPv4 (basically 6rd= ) as it was in the previous version of the document, but moved to MAY. Depl= oyments that today have IPv4-only access, can start deploying IPv6 (in IPv4= if they need it), but use the same CE for when they can move to IPv6-only = access. 3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed), ba= sed on market relevance and understanding that most of them don=E2=80=99t t= ake additional code in the CPE, because most of this code is basically the = same. So, to make it short, unless there is a =E2=80=9Cmagic=E2=80=9D mechanism t= hat I=E2=80=99m not aware of, and the WG decides to include it, my intend i= s no longer include anything new in the document. And if that =E2=80=9Cmagi= c=E2=80=9D mechanism exists, then we could delete all the others. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 11:34 Para: CC: Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Jordi, =20 The standardisation of the "transitioning off IPv4 mechanisms" is a pri= me example of IETF failure. You are proposing to carry that failure forward and require all CE impl= ementations to implement _all_ the mechanisms in existence? =20 That is not providing "value add" to the community. =20 If I remember correctly that list is now: RFC2473, GRE, L2TP, LISP, MAP= -E, MAP-T, 4RD, 464XLAT, Public 4over6, LW46, Dynamic LW46, ... =20 Best regards, Ole =20 > On 11 Apr 2017, at 17:11, JORDI PALET MARTINEZ wrote: >=20 > Hi all, >=20 > I got a comment about including support for LISP in order to allow IP= v4 access with an IPv6-only-WAN. >=20 > Even if I=E2=80=99ve got a couple of links of providers that actually= use it, I believe is not something that is happening in the market, and se= ems to be tied to a specific vendor. >=20 > I=E2=80=99m not personally fan of including that support in the docum= ent, however I will like to heard some more opinions on that from the WG. >=20 > I plan to publish a new version (-01) in 1-2 days, maximum, so I will= like to heard opinions about that, and in general for the actual version o= f the document. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 03:56: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 E7E0A131605 for ; Wed, 12 Apr 2017 03:56:44 -0700 (PDT) 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=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 pDmgVGbOnLxp for ; Wed, 12 Apr 2017 03:56:43 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 4E38F1314B3 for ; Wed, 12 Apr 2017 03:56:43 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 12 Apr 2017 10:56:42 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 9E5F7D788B; Wed, 12 Apr 2017 03:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=OC1IwHHetXhvWPM2maKAlXDAqOw=; b= glgGcQchMJ7TOsnsrzmZwOSwdz2jBbddw/TCTLNVCQEBw+KZtiNQhc1qL/fVs81G 6E3gTiaf9B0lmk86geJjhpDB38n4YQMZgdtsqJ0ct8mSMJ6SvuTeEEDRUlQAi7w7 5asJOCCK4pnFajiRfuxL1ddP8x93H1YEopVusZb3I/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=BmOriqvb570tHh/r/WLYPl0 QeylxLBRASza91fI4g2VfUZwlJR4MrDdwzEwPRd883uXehC7i+N86FgTsNWUCPpg 2LIzBv8MQrUgh1ysx2M2RM96GXJ6KtaTnS2ktARHhQn5OLUx659diIcJyO0uo1hV SGO3TK0ceMwJ+WsN6T7I= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 265DED788A; Wed, 12 Apr 2017 03:56:42 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7AF2BA913D4C; Wed, 12 Apr 2017 12:56:40 +0200 (CEST) From: otroan@employees.org Message-Id: <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_545806E5-93F5-4D60-90D7-02A7CD63648B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 12:56:39 +0200 In-Reply-To: <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> Cc: v6ops@ietf.org To: jordi.palet@consulintel.es References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:56:45 -0000 --Apple-Mail=_545806E5-93F5-4D60-90D7-02A7CD63648B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jordi, > I=E2=80=99m NOT in favor of including an unlimited number of = mechanisms, and I think we must focus in those that have a real = traction. I=E2=80=99m NOT in favor of including LISP. >=20 > However, the document is a WG document, so is not just my decision, = but the WG, so I must ask the WG opinions before =E2=80=9Crejecting=E2=80=9D= LISP. That was my question. >=20 > I think we need to have a balance: > 1) Main goal, support of IPv6-only access but allow IPv4 to keep = working in the customer=E2=80=99s LANs. > 2) Allow the support of =E2=80=9Colder=E2=80=9D IPv6-in-IPv4 = (basically 6rd) as it was in the previous version of the document, but = moved to MAY. Deployments that today have IPv4-only access, can start = deploying IPv6 (in IPv4 if they need it), but use the same CE for when = they can move to IPv6-only access. Which is a bit ironic with regards to 6RD which is one of the few = mechanisms with real deployment, as in millions and millions of users. >3) Support a subset of IPv4-in-IPv6 (from all those that IETF = designed), based on market relevance and understanding that most of them = don=E2=80=99t take additional code in the CPE, because most of this code = is basically the same. That statement is not quite true. The various mechanisms while largely = being built out of the same parts, require quite a bit of glue, testing = and additional support for configuration. If you think the conflict = around hosts/network DNS recursive resolver configuration is hard, then = this is a n-square problem. For implementation complexity just compare MAP-T and MAP-E/LW46 in: https://git.fd.io/vpp/tree/src/vnet/map > So, to make it short, unless there is a =E2=80=9Cmagic=E2=80=9D = mechanism that I=E2=80=99m not aware of, and the WG decides to include = it, my intend is no longer include anything new in the document. And if = that =E2=80=9Cmagic=E2=80=9D mechanism exists, then we could delete all = the others. The magic is in us having the balls to make a choice. And pick one = mandatory to implement mechanism. And only one. Cheers, Ole --Apple-Mail=_545806E5-93F5-4D60-90D7-02A7CD63648B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY7gfoAAoJEL7aWKiYQt92XyIQALZ5CuO5mmBQhosQ0ijQ+MVj /t3WBgHupeeQiDmvqfXE4/1fnmbTXsZjD0nat1OYrEIVIhBiNUqlUmwOugc3B5OU ORuq5IKvHyKWHAWuQMoY+koWWX42Azgg/Is4mqHJiEr9BKrOfxwzhtM6aKS3GSJE XGePiiWI43/StS2+jHvxoRjwVjj5upsJZSAIefw6qc+sMf3eptqkMpkgj3AbnMVk B4znJ907IPY8Si4eZ2js+bi/kabQ30qVr4fohSkacjlUnMJpcJASTtOsT5UJZ/9X 3LriPEGxwYsinLPV4s06BC6i3lenuSWMs36L8LDKb1D9bK49PYpsRqmC8dsFxNM4 jXJbaoZBFlJsm5SK9OnAEPDxWPNkkoZGFar1OPaP5aD4uKBu8cDtMZQSO8Fdobrt BhsBwnaxoPun+f0+ic+AIvOea78RMdtU5WqdkEe1CdLlUPn97xK/8MI0W5azzTHf n8fTJdD8Tpm1MtVRxubqCwoqXGjjd3kQlp5NVGLoAAXnb60P02PW+kNBqayPbRH5 Oha92iy35xlZetKRJGSCu7aDOm6CIcOK/xQmiHo+fm93/Vsly5bBODDUVa0ZYq81 HhQnGrkkfkitWJf7rHet4xE1cQ83PBgGqKygqCdNBjL2W54vAiX5IYPDLxxFyYwK WgGxvR8QKWrKiW1ZuUFS =aR3k -----END PGP SIGNATURE----- --Apple-Mail=_545806E5-93F5-4D60-90D7-02A7CD63648B-- From nobody Wed Apr 12 04:30: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 DA876131660 for ; Wed, 12 Apr 2017 04:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mOmeV0BvntK3 for ; Wed, 12 Apr 2017 04:30:36 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2869813166A for ; Wed, 12 Apr 2017 04:30:36 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 565BD40734; Wed, 12 Apr 2017 13:30:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 29E6A1A005F; Wed, 12 Apr 2017 13:30:34 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 13:30:33 +0200 From: To: "otroan@employees.org" , "jordi.palet@consulintel.es" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSs3uD0Lrj7FW0mUG8wxo2iykVW6HBlHng Date: Wed, 12 Apr 2017 11:30:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> In-Reply-To: <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 11:30:38 -0000 SGkgT2xlLCANCg0KSSB0ZW5kIHRvIGFncmVlIHdpdGggeW91IGJ1dCB3aXRoIGEgc2xpZ2h0bHkg ZGlmZmVyZW50IHByb3Bvc2FsOiAgcGljayBPTkUgbWFuZGF0b3J5IHN0YXRlZnVsIG1lY2hhbmlz bSAoRFMtTGl0ZSkgYW5kIE9ORSBtYW5kYXRvcnkgQStQIG1lY2hhbmlzbSAoTUFQLUUpLiANCg0K RldJVywgdGhlIGZvbGxvd2luZyB0YWJsZXMgcmVjYXAgdGhlIHJlcXVpcmVkIGZ1bmN0aW9uYWxp dHkgdG8gYmUgc3VwcG9ydGVkIGJ5IHRoZSBDUEUgZm9yIERTLUxpdGUsIGx3NG92ZXI2LCBhbmQg TUFQLUUgKyByZXF1aXJlZCBwcm92aXNpb25pbmcgaW5mb3JtYXRpb24gZm9yIGVhY2ggb2YgdGhl bS4NCg0KICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8ICAgRnVuY3Rpb25hbCB8ICBJUHY0LWluLUlQdjYg IHwgUG9ydC1yZXN0cmljdGVkIHwgUG9ydC1yZXN0cmljdGVkIHwNCiAgIHwgICAgICBFbGVtZW50 IHwgICAgIHR1bm5lbCAgICAgfCAgICAgICBJUHY0ICAgICAgfCAgICAgIE5BVDQ0ICAgICAgfA0K ICAgfCAgICAgICAgICAgICAgfCAgICBlbmRwb2ludCAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICAgICAgICAgIEI0IHwgICAg ICBZZXMgICAgICAgfCAgICAgICBObyAgICAgICAgfCAgICAgICBObyAgICAgICAgfA0KICAgfCAg ICAgICAgIGx3QjQgfCAgICAgIFllcyAgICAgICB8ICAgICAgIFllcyAgICAgICB8ICAgICAgIFll cyAgICAgICB8DQogICB8ICAgICBNQVAtRSBDRSB8ICAgICAgWWVzICAgICAgIHwgICAgICAgWWVz ICAgICAgIHwgICAgICAgWWVzICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgICAgICAg ICAgICAgICAgICAgICBUYWJsZSB4OiBTdXBwb3J0ZWQgRmVhdHVyZXMNCg0KICAgICAgICAgKy0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICAgICAgICB8ICAgIE1vZGUgfCBQcm92aXNpb25pbmcgSW5mb3JtYXRpb24gICAgICAgICAgICAg ICAgICAgIHwNCiAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgfCBEUy1MaXRlIHwgUmVtb3RlIElQdjQtaW4t SVB2NiBUdW5uZWwgRW5kcG9pbnQgQWRkcmVzcyB8DQogICAgICAgICB8ICAgTHc0bzYgfCBSZW1v dGUgSVB2NC1pbi1JUHY2IFR1bm5lbCBFbmRwb2ludCBBZGRyZXNzIHwNCiAgICAgICAgIHwgICAg ICAgICB8IElQdjQgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgICAgfCAgICAgICAgIHwgUG9ydCBTZXQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgICB8ICAgTUFQLUUgfCBNYXBwaW5nIFJ1bGVzICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgIHwgICAgICAgICB8IE1BUCBEb21haW4gUGFyYW1l dGVycyAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAg ICAgICAgIFRhYmxlIHg6IFByb3Zpc2lvbmluZyBJbmZvcm1hdGlvbg0KQ2hlZXJzLA0KTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IHY2b3BzIFttYWlsdG86djZv cHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPiBvdHJvYW5AZW1wbG95ZWVzLm9y Zw0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDEyIGF2cmlsIDIwMTcgMTI6NTcNCj4gw4DCoDogam9y ZGkucGFsZXRAY29uc3VsaW50ZWwuZXMNCj4gQ2PCoDogdjZvcHNAaWV0Zi5vcmcNCj4gT2JqZXTC oDogUmU6IFt2Nm9wc10gTElTUCBzdXBwb3J0IGZvciBkcmFmdC1pZXRmLXY2b3BzLXJmYzcwODQt YmlzLTAwDQo+IA0KPiBKb3JkaSwNCj4gDQo+ID4gSeKAmW0gTk9UIGluIGZhdm9yIG9mIGluY2x1 ZGluZyBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mIG1lY2hhbmlzbXMsIGFuZCBJDQo+IHRoaW5rIHdl IG11c3QgZm9jdXMgaW4gdGhvc2UgdGhhdCBoYXZlIGEgcmVhbCB0cmFjdGlvbi4gSeKAmW0gTk9U IGluIGZhdm9yDQo+IG9mIGluY2x1ZGluZyBMSVNQLg0KPiA+DQo+ID4gSG93ZXZlciwgdGhlIGRv Y3VtZW50IGlzIGEgV0cgZG9jdW1lbnQsIHNvIGlzIG5vdCBqdXN0IG15IGRlY2lzaW9uLCBidXQN Cj4gdGhlIFdHLCBzbyBJIG11c3QgYXNrIHRoZSBXRyBvcGluaW9ucyBiZWZvcmUg4oCccmVqZWN0 aW5n4oCdIExJU1AuIFRoYXQgd2FzIG15DQo+IHF1ZXN0aW9uLg0KPiA+DQo+ID4gSSB0aGluayB3 ZSBuZWVkIHRvIGhhdmUgYSBiYWxhbmNlOg0KPiA+IDEpIE1haW4gZ29hbCwgc3VwcG9ydCBvZiBJ UHY2LW9ubHkgYWNjZXNzIGJ1dCBhbGxvdyBJUHY0IHRvIGtlZXAgd29ya2luZw0KPiBpbiB0aGUg Y3VzdG9tZXLigJlzIExBTnMuDQo+ID4gMikgQWxsb3cgdGhlIHN1cHBvcnQgb2Yg4oCcb2xkZXLi gJ0gSVB2Ni1pbi1JUHY0IChiYXNpY2FsbHkgNnJkKSBhcyBpdCB3YXMNCj4gaW4gdGhlIHByZXZp b3VzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBidXQgbW92ZWQgdG8gTUFZLiBEZXBsb3ltZW50 cw0KPiB0aGF0IHRvZGF5IGhhdmUgSVB2NC1vbmx5IGFjY2VzcywgY2FuIHN0YXJ0IGRlcGxveWlu ZyBJUHY2IChpbiBJUHY0IGlmDQo+IHRoZXkgbmVlZCBpdCksIGJ1dCB1c2UgdGhlIHNhbWUgQ0Ug Zm9yIHdoZW4gdGhleSBjYW4gbW92ZSB0byBJUHY2LW9ubHkNCj4gYWNjZXNzLg0KPiANCj4gV2hp Y2ggaXMgYSBiaXQgaXJvbmljIHdpdGggcmVnYXJkcyB0byA2UkQgd2hpY2ggaXMgb25lIG9mIHRo ZSBmZXcNCj4gbWVjaGFuaXNtcyB3aXRoIHJlYWwgZGVwbG95bWVudCwgYXMgaW4gbWlsbGlvbnMg YW5kIG1pbGxpb25zIG9mIHVzZXJzLg0KPiANCj4gPjMpIFN1cHBvcnQgYSBzdWJzZXQgb2YgSVB2 NC1pbi1JUHY2IChmcm9tIGFsbCB0aG9zZSB0aGF0IElFVEYgZGVzaWduZWQpLA0KPiBiYXNlZCBv biBtYXJrZXQgcmVsZXZhbmNlIGFuZCB1bmRlcnN0YW5kaW5nIHRoYXQgbW9zdCBvZiB0aGVtIGRv buKAmXQgdGFrZQ0KPiBhZGRpdGlvbmFsIGNvZGUgaW4gdGhlIENQRSwgYmVjYXVzZSBtb3N0IG9m IHRoaXMgY29kZSBpcyBiYXNpY2FsbHkgdGhlDQo+IHNhbWUuDQo+IA0KPiBUaGF0IHN0YXRlbWVu dCBpcyBub3QgcXVpdGUgdHJ1ZS4gVGhlIHZhcmlvdXMgbWVjaGFuaXNtcyB3aGlsZSBsYXJnZWx5 DQo+IGJlaW5nIGJ1aWx0IG91dCBvZiB0aGUgc2FtZSBwYXJ0cywgcmVxdWlyZSBxdWl0ZSBhIGJp dCBvZiBnbHVlLCB0ZXN0aW5nDQo+IGFuZCBhZGRpdGlvbmFsIHN1cHBvcnQgZm9yIGNvbmZpZ3Vy YXRpb24uIElmIHlvdSB0aGluayB0aGUgY29uZmxpY3QgYXJvdW5kDQo+IGhvc3RzL25ldHdvcmsg RE5TIHJlY3Vyc2l2ZSByZXNvbHZlciBjb25maWd1cmF0aW9uIGlzIGhhcmQsIHRoZW4gdGhpcyBp cyBhDQo+IG4tc3F1YXJlIHByb2JsZW0uDQo+IA0KPiBGb3IgaW1wbGVtZW50YXRpb24gY29tcGxl eGl0eSBqdXN0IGNvbXBhcmUgTUFQLVQgYW5kIE1BUC1FL0xXNDYgaW46DQo+IGh0dHBzOi8vZ2l0 LmZkLmlvL3ZwcC90cmVlL3NyYy92bmV0L21hcA0KPiANCj4gPiBTbywgdG8gbWFrZSBpdCBzaG9y dCwgdW5sZXNzIHRoZXJlIGlzIGEg4oCcbWFnaWPigJ0gbWVjaGFuaXNtIHRoYXQgSeKAmW0gbm90 DQo+IGF3YXJlIG9mLCBhbmQgdGhlIFdHIGRlY2lkZXMgdG8gaW5jbHVkZSBpdCwgbXkgaW50ZW5k IGlzIG5vIGxvbmdlciBpbmNsdWRlDQo+IGFueXRoaW5nIG5ldyBpbiB0aGUgZG9jdW1lbnQuIEFu ZCBpZiB0aGF0IOKAnG1hZ2lj4oCdIG1lY2hhbmlzbSBleGlzdHMsIHRoZW4NCj4gd2UgY291bGQg ZGVsZXRlIGFsbCB0aGUgb3RoZXJzLg0KPiANCj4gVGhlIG1hZ2ljIGlzIGluIHVzIGhhdmluZyB0 aGUgYmFsbHMgdG8gbWFrZSBhIGNob2ljZS4gQW5kIHBpY2sgb25lDQo+IG1hbmRhdG9yeSB0byBp bXBsZW1lbnQgbWVjaGFuaXNtLiBBbmQgb25seSBvbmUuDQo+IA0KPiBDaGVlcnMsDQo+IE9sZQ0K From nobody Wed Apr 12 05:47: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 839B412945F for ; Wed, 12 Apr 2017 05:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 3Bgh8QUsJkP7 for ; Wed, 12 Apr 2017 05:47:40 -0700 (PDT) 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 3247B126C2F for ; Wed, 12 Apr 2017 05:47:40 -0700 (PDT) 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 v3CCjHfn038311; Wed, 12 Apr 2017 08:47:31 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 29sjnrmrrg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 08:47:31 -0400 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 v3CClUDu012527; Wed, 12 Apr 2017 08:47:30 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3CClM4P012341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 08:47:24 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 12:47:11 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 08:47:11 -0400 From: "STARK, BARBARA H" To: "otroan@employees.org" , "jordi.palet@consulintel.es" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgP//1q0g Date: Wed, 12 Apr 2017 12:47:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB19475@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> In-Reply-To: <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.164.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_09:, , 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-1702020001 definitions=main-1704120106 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:47:41 -0000 PiBXaGljaCBpcyBhIGJpdCBpcm9uaWMgd2l0aCByZWdhcmRzIHRvIDZSRCB3aGljaCBpcyBvbmUg b2YgdGhlIGZldyBtZWNoYW5pc21zDQo+IHdpdGggcmVhbCBkZXBsb3ltZW50LCBhcyBpbiBtaWxs aW9ucyBhbmQgbWlsbGlvbnMgb2YgdXNlcnMuDQoNClRoZSByZWFzb24gSSd2ZSBzYWlkIEkgaGF2 ZSBubyBwcm9ibGVtIHdpdGggYmFja2luZyBvZmYgNnJkIGluIHRoaXMgZG9jdW1lbnQgaXMgYmVj YXVzZSBJIHNlZSB0aGlzIGRvY3VtZW50IGFzIHByaW1hcmlseSBkcml2aW5nIHJldGFpbCBkZXZp Y2VzLiBUaGUgb25seSBzdWNjZXNzZnVsIGRlcGxveW1lbnRzIEknbSBhd2FyZSBvZiByZWx5IG9u IElTUC1wcm9jdXJlZCwgc3VwcGxpZWQsIGFuZCBtYW5hZ2VkIGRldmljZXMuIE5vIGNoYW5nZSB0 byA2cmQgcmVxdWlyZW1lbnRzIGlzIGhhcHBlbmluZyBpbiBCQkYgVFItMTI0Lg0KDQpJIGhhdmUg c2VyaW91cyBkb3VidHMgdGhhdCBhbnkgdHJhbnNpdGlvbiBtZWNoYW5pc20gY2FuIGJlIHN1Y2Nl c3NmdWwgaWYgdGhlIGN1c3RvbWVyIG11c3QgdGFrZSBhbnkgYWN0aW9uLCB3aGF0c29ldmVyLCB0 byBzcGVjaWZpY2FsbHkgZW5hYmxlIGl0Lg0KDQpXaGljaCBtZWFucyBJIHRoaW5rIGR1YWwgc3Rh Y2sgaXMgdGhlIG9ubHkgc2NlbmFyaW8gaXQgaXMgcmVhc29uYWJsZSB0byByZXF1aXJlIGluIHJl dGFpbCByb3V0ZXJzLiBBbGwgcmV0YWlsIHJvdXRlciBpbXBsZW1lbnRhdGlvbnMgSSd2ZSBzZWVu IG9mIHRyYW5zaXRpb24gbWVjaGFuaXNtcyByZXF1aXJlIHVzZXJzIHRvICgxKSBoYXZlIHB1cnBv c2VmdWxseSBzb3VnaHQgb3V0IGEgcm91dGVyIHRoYXQgc3VwcG9ydHMgSVB2NiwgKDIpIGtub3cg dGhleSBuZWVkIGEgcm91dGVyIHRoYXQgc3VwcG9ydHMgYSBzcGVjaWZpYyB0cmFuc2l0aW9uIHRl Y2hub2xvZ3ksICgzKSBoYXZlIGNhcmVmdWxseSByZXNlYXJjaGVkIHNwZWNpZmljYWxseSB3aGlj aCByb3V0ZXJzIHN1cHBvcnQgdGhhdCBwYXJ0aWN1bGFyIHRyYW5zaXRpb24gdGVjaG5vbG9neSAo YmVjYXVzZSBpdCB3b24ndCBiZSBsaXN0ZWQgb24gdGhlIHBhY2thZ2luZyksIGFuZCAoNCkgZW5h YmxlIHRoZSB0cmFuc2l0aW9uIHRlY2hub2xvZ3kuDQoNCkJlY2F1c2UgdGhpcyBjdXN0b21lciBi ZWhhdmlvciBpcyBzbyB1bmxpa2VseSwgaXQncyBpcnJlbGV2YW50IHdoZXRoZXIgb3Igbm90IGEg cmV0YWlsIHJvdXRlciBzdXBwb3J0cyA2cmQuIA0KSW4gZmFjdCwgYW55IHRyYW5zaXRpb24gdGVj aG5vbG9neSB0aGF0IGRvZXMgbm90IHNoaXAgZW5hYmxlZCwgc2ltdWx0YW5lb3VzIHdpdGggZHVh bCBzdGFjaywgaXMgaXJyZWxldmFudCBpbiByZXRhaWwgZGV2aWNlcy4NCkJhcmJhcmENCg== From nobody Wed Apr 12 05:53: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 8730D129C3F for ; Wed, 12 Apr 2017 05:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 6A1R9zMTLImg for ; Wed, 12 Apr 2017 05:53:14 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2E9E1129B6F for ; Wed, 12 Apr 2017 05:53:14 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3CCjHCY033544; Wed, 12 Apr 2017 08:53:05 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 29sjmx50tx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 08:53:05 -0400 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 v3CCr4sj019305; Wed, 12 Apr 2017 08:53:04 -0400 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 v3CCqxfW019235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 08:52:59 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 12:52:46 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 08:52:45 -0400 From: "STARK, BARBARA H" To: "mohamed.boucadair@orange.com" , "otroan@employees.org" , "jordi.palet@consulintel.es" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgIAACXcA///SZzA= Date: Wed, 12 Apr 2017 12:52:45 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.164.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_09:, , 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-1702020001 definitions=main-1704120106 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:53:15 -0000 PiBJIHRlbmQgdG8gYWdyZWUgd2l0aCB5b3UgYnV0IHdpdGggYSBzbGlnaHRseSBkaWZmZXJlbnQg cHJvcG9zYWw6ICBwaWNrIE9ORQ0KPiBtYW5kYXRvcnkgc3RhdGVmdWwgbWVjaGFuaXNtIChEUy1M aXRlKSBhbmQgT05FIG1hbmRhdG9yeSBBK1ANCj4gbWVjaGFuaXNtIChNQVAtRSkuDQoNCkJlY2F1 c2UgUkZDIDcwODQgaXMgYWxzbyB1c2VkIGFzIGEgbWFuZGF0b3J5IHJlZmVyZW5jZSBpbiBCQkYg VFItMTI0ICh1c2VkIGJ5IHRlbGNvIElTUHMgdG8gaGVscCB3aXRoIENFIHJvdXRlciBSRlBzKSwg YW5kIG1vc3QgSVNQcyBoYXZlIG5vIGludGVyZXN0IGluIHJlcXVpcmluZyBjYXBhYmlsaXRpZXMg dGhhdCBhcmUgbm90IHVzZWZ1bCB0byBvciByZWxldmFudCBpbiB0aGVpciBkZXBsb3ltZW50LCB0 aGVyZSBNVVNUIE5PVCBiZSBhbnkgbWFuZGF0b3J5IHRyYW5zaXRpb24gbWVjaGFuaXNtcyBpbmNs dWRlZCBpbiBhIDcwODQtYmlzLg0KQmFyYmFyYQ0K From nobody Wed Apr 12 06:03: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 B603D12945B for ; Wed, 12 Apr 2017 06:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=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 w9bjkRr3N45C for ; Wed, 12 Apr 2017 06:03:45 -0700 (PDT) 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 7E10B1316BE for ; Wed, 12 Apr 2017 06:03:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 205CBA2; Wed, 12 Apr 2017 15:03:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492002223; bh=gNNL+TWFdG74v/N6XA75W8NkLGIKnBLVhGVzLIxJ4BE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BR9FQ8uC83fsJMw15lDH4cH6LzdlwxinqFmrBf9eg3LpjJjWLonNVyiljX/zIpr3h azh1l6ey7KBzGtSyDR8AyYDyaWsmG2Zer9gKrI7ZeoXPpVv7/goJBL9sdcGodKK0HU GIrZP5q+D2iIKP0InhgPvLzGbQJPCf/+iJgiF+u4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1D2D388; Wed, 12 Apr 2017 15:03:43 +0200 (CEST) Date: Wed, 12 Apr 2017 15:03:43 +0200 (CEST) From: Mikael Abrahamsson To: "STARK, BARBARA H" cc: "v6ops@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB19475@GAALPA1MSGUSRBF.ITServices.sbc.com> Message-ID: References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <2D09D61DDFA73D4C884805CC7865E6114DB19475@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:03:48 -0000 On Wed, 12 Apr 2017, STARK, BARBARA H wrote: > In fact, any transition technology that does not ship enabled, simultaneous with dual stack, is irrelevant in retail devices. I know of ISPs who send DHCP option 212 to (some) customers. Their IPv6 enablement rate seems to hover around 1%. So there seems to be devices out there that support 6RD out of the box, but they're such a small minority that I agree that this IPv6 "rollout" can't be counted as "successful". My view on 7084 is that it's a "laundry list", which ISPs can use to assist them in successfully procuring residential gateways. So I find it useful that it contains lots of stuff, but then perhaps the title shouldn't be "basic requirements" anymore, but perhaps something else. Oles point on it becoming quite extensive is valid. Perhaps we should re-focus it to be a document that says "if you want to support X, do REQ1-REQ9". I still think it's good input to both people procuring gateways, and people implementing gateways. Not all have the resources to create that 5000+ lines of requirements whenever they procure a new gateway, or large enough that they would get any attention from vendors even if they had such a list. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 12 06:12: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 EDE60129B15 for ; Wed, 12 Apr 2017 06:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 UhZCqTkEcnKc for ; Wed, 12 Apr 2017 06:12:34 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE69129B0A for ; Wed, 12 Apr 2017 06:12:33 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 017E7180396; Wed, 12 Apr 2017 15:12:32 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id C031E20073; Wed, 12 Apr 2017 15:12:31 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 15:12:31 +0200 From: To: "STARK, BARBARA H" , "otroan@employees.org" , "jordi.palet@consulintel.es" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgIAACXcA///SZzCAAAaJUA== Date: Wed, 12 Apr 2017 13:12:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4C4D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:12:36 -0000 SGkgQmFyYmFyYSwgDQoNCldvdWxkbid0IGp1c3QgYmUgZmluZSBmb3IgdGhvc2UgSVNQcyBub3Qg aW50ZXJlc3RlZCBpbiB0cmFuc2l0aW9uIG1lY2hhbmlzbXMgdG8gY29udGludWUgcmVmZXJyaW5n IHRvIFJGQzcwODQ/DQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiBTVEFSSywgQkFSQkFSQSBIIFttYWlsdG86YnM3NjUyQGF0dC5jb21dDQo+ IEVudm95w6nCoDogbWVyY3JlZGkgMTIgYXZyaWwgMjAxNyAxNDo1Mw0KPiDDgMKgOiBCT1VDQURB SVIgTW9oYW1lZCBJTVQvT0xOOyBvdHJvYW5AZW1wbG95ZWVzLm9yZzsNCj4gam9yZGkucGFsZXRA Y29uc3VsaW50ZWwuZXMNCj4gQ2PCoDogdjZvcHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUkU6IFt2 Nm9wc10gTElTUCBzdXBwb3J0IGZvciBkcmFmdC1pZXRmLXY2b3BzLXJmYzcwODQtYmlzLTAwDQo+ IA0KPiA+IEkgdGVuZCB0byBhZ3JlZSB3aXRoIHlvdSBidXQgd2l0aCBhIHNsaWdodGx5IGRpZmZl cmVudCBwcm9wb3NhbDogIHBpY2sNCj4gT05FDQo+ID4gbWFuZGF0b3J5IHN0YXRlZnVsIG1lY2hh bmlzbSAoRFMtTGl0ZSkgYW5kIE9ORSBtYW5kYXRvcnkgQStQDQo+ID4gbWVjaGFuaXNtIChNQVAt RSkuDQo+IA0KPiBCZWNhdXNlIFJGQyA3MDg0IGlzIGFsc28gdXNlZCBhcyBhIG1hbmRhdG9yeSBy ZWZlcmVuY2UgaW4gQkJGIFRSLTEyNCAodXNlZA0KPiBieSB0ZWxjbyBJU1BzIHRvIGhlbHAgd2l0 aCBDRSByb3V0ZXIgUkZQcyksIGFuZCBtb3N0IElTUHMgaGF2ZSBubyBpbnRlcmVzdA0KPiBpbiBy ZXF1aXJpbmcgY2FwYWJpbGl0aWVzIHRoYXQgYXJlIG5vdCB1c2VmdWwgdG8gb3IgcmVsZXZhbnQg aW4gdGhlaXINCj4gZGVwbG95bWVudCwgdGhlcmUgTVVTVCBOT1QgYmUgYW55IG1hbmRhdG9yeSB0 cmFuc2l0aW9uIG1lY2hhbmlzbXMgaW5jbHVkZWQNCj4gaW4gYSA3MDg0LWJpcy4NCj4gQmFyYmFy YQ0K From nobody Wed Apr 12 06:14: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 843C5129B1A for ; Wed, 12 Apr 2017 06:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 MyHnykNSZk1j for ; Wed, 12 Apr 2017 06:14:39 -0700 (PDT) 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 EAE72129B15 for ; Wed, 12 Apr 2017 06:14:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1cyI6U-0000ErC; Wed, 12 Apr 2017 15:14:34 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <2D09D61DDFA73D4C884805CC7865E6114DB19475@GAALPA1MSGUSRBF.ITServices.sbc.com> In-reply-to: Your message of "Wed, 12 Apr 2017 12:47:11 +0000 ." <2D09D61DDFA73D4C884805CC7865E6114DB19475@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 12 Apr 2017 15:14:33 +0200 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:14:41 -0000 >Because this customer behavior is so unlikely, it's irrelevant whether or not >a retail router supports 6rd. >In fact, any transition technology that does not ship enabled, simultaneous wi >th dual stack, is irrelevant in retail devices. I have a strong preference for dual stack, so in that sense I don't particularly care about transtition mechanisms, but that said... Since for ever, I have been able to buy retail routers that support an insane number of ways to configure ADSL or VDSL. For ADSL you need at least VPI and VCI, and encapsulation mode. For VDSL you often need to configure the VLAN number and whether to use PPPoE or not. In addition you may have to configure user name and password for PPP variations. Surprisingly, despite the fact that consumers are utterly incapable of configuring those parameters, these routers can be easily bought retail. Some vendors are cheating though. Some of them spell out the parameters for different ISPs in the manual. Others go even further and have a configuration wizzard where you just select your ISP. Note that in some cases, the ISP supplied device doesn't do what you want. Then it is good if there are retail devices that support your ISP's choice of protocols. So for me it is weird to say that just because all relevant ISPs provide a 6rd capable router, there is no need for that protocol in a retail device. Retail devices should support protocols popular in the region where the device is sold. Here, one ISP refuses to provide bridge mode in the cable modem when IPv6 is enabled because not all (or too few) retail routers support the transitioning technology they are using. From nobody Wed Apr 12 06:16: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 E5023129B0A for ; Wed, 12 Apr 2017 06:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 u3KmiSssUrk6 for ; Wed, 12 Apr 2017 06:15:59 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 84069129B16 for ; Wed, 12 Apr 2017 06:15:58 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3CDFSbJ021407; Wed, 12 Apr 2017 09:15:50 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 29s8dnqgkh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 09:15:50 -0400 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 v3CDFm79021977; Wed, 12 Apr 2017 09:15:49 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3CDFiiH021957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 09:15:45 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 13:15:21 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 09:15:21 -0400 From: "STARK, BARBARA H" To: "mohamed.boucadair@orange.com" , "otroan@employees.org" , "jordi.palet@consulintel.es" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgIAACXcA///SZzCAAAaJUIAAAKzA Date: Wed, 12 Apr 2017 13:15:21 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB19559@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933009E4C4D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4C4D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.164.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_09:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704120111 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:16:01 -0000 PiBXb3VsZG4ndCBqdXN0IGJlIGZpbmUgZm9yIHRob3NlIElTUHMgbm90IGludGVyZXN0ZWQgaW4g dHJhbnNpdGlvbiBtZWNoYW5pc21zDQo+IHRvIGNvbnRpbnVlIHJlZmVycmluZyB0byBSRkM3MDg0 Pw0KDQpDdXJyZW50bHksIHRoZSBkcmFmdCBpcyB3cml0dGVuIGFzIGEgLWJpcyB0byBSRkZDIDcw ODQsIHdpdGggdGhlIGludGVudCB0byBvYnNvbGV0ZSBSRkMgNzA4NCB3aGVuIGl0IGlzIHB1Ymxp c2hlZC4NCklmIHRoaXMgaXMgZG9uZSwgdGhlbiwgbm8sIGNvbnRpbnVlZCByZWZlcmVuY2luZyBv ZiBSRkMgNzA4NCB3b3VsZCBub3QgYmUgYXBwcm9wcmlhdGUuDQoNCklmIGEgZGlmZmVyZW50IGFw cHJvYWNoIGlzIHRha2VuIHRoYXQgbGVhdmVzIFJGQyA3MDg0IGFsb25lLCBJIHdvdWxkIGFncmVl Lg0KQmFyYmFyYQ0K From nobody Wed Apr 12 06:50: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 60EFD1294C0 for ; Wed, 12 Apr 2017 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 CMoWC_l4zlt9 for ; Wed, 12 Apr 2017 06:50:30 -0700 (PDT) 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 C2C5B1294B5 for ; Wed, 12 Apr 2017 06:50:29 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id j9so11922036ywj.3 for ; Wed, 12 Apr 2017 06:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fv3QtNJ8Fug5Boa5ZogWeYVd9nSrP49vXCBqGahxKPQ=; b=AHPqe0KYO0Nc9s6LjR9p0J65mqugRk/FP5FjlQDty/tYgzb1cCP0qqCjSoLpwTchse WGqW/LrSEk6bpwEnfp9h1IG3fcu4uF5iyL/CYkTBLnd0Tyo27rVtgbdlSpdk2+/ZnwsS FYaAd+RrVaCLJfV5NThIp1mLdiKIAVKvgULGrLgHPa/e0XfQYSrgECc76XSCQ2YJPpY6 xBOgC0euxFxSxVs+hz9Tsi+tIDG2j6232MlqwK8twQJu9noo4e/5d9r2HX1UwTx//aN2 OBMRMan9r09f5x2quaMuyfH/X1GOk2bZ36kE4WTb0JOQNpIUOSpQHedqmd0C50XsibC+ f+Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fv3QtNJ8Fug5Boa5ZogWeYVd9nSrP49vXCBqGahxKPQ=; b=HYqf+R/L13Ee1wvk5/i5nGHWhy/B9zm32uJPSmh8SzKFVelU575Em9scyNA5FkGqQR 765++QQeuejbD7o6aN8hFMdpHXF/v8KbhUUuRUDDi9aO0EOj0VcVSWGIDmfXa99IUcPq /OoNXKVbXTTyn5xWaiar7r9LAT8buxA6vu2YpF1NcWO0SZyQgE5316eKZzzoSoq3j7c6 Wf4UxM54jkXNJ1VVPt9DlkmSwbhLWsSn5D+gPTgbulnY+6Ag/O22PuuyxdPhGqgxiIaJ tQJ0DAZv9pA+nf1FS7D82hfS1gmg9BkckcUgcR2n8KgKWqOlMsOOdEZc3Xy2ch+lzwDQ IttQ== X-Gm-Message-State: AN3rC/6NjbuQOFjGVsQgsPXZer//eRbe/l70FoppwBtWUW4sBrx1BpdCGBHT9HAnR2lwMdS6GX5COtUMTIZxtg== X-Received: by 10.129.53.199 with SMTP id c190mr8694896ywa.80.1492005029002; Wed, 12 Apr 2017 06:50:29 -0700 (PDT) MIME-Version: 1.0 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> In-Reply-To: <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> From: Ca By Date: Wed, 12 Apr 2017 13:50:17 +0000 Message-ID: To: jordi.palet@consulintel.es, otroan@employees.org Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary=001a11421778c1c3db054cf87d23 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:50:32 -0000 --001a11421778c1c3db054cf87d23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole On Wed, Apr 12, 2017 at 3:56 AM wrote: > Jordi, > > > I=E2=80=99m NOT in favor of including an unlimited number of mechanisms= , and I > think we must focus in those that have a real traction. I=E2=80=99m NOT i= n favor of > including LISP. > > > > However, the document is a WG document, so is not just my decision, but > the WG, so I must ask the WG opinions before =E2=80=9Crejecting=E2=80=9D = LISP. That was my > question. > > > > I think we need to have a balance: > > 1) Main goal, support of IPv6-only access but allow IPv4 to keep workin= g > in the customer=E2=80=99s LANs. > > 2) Allow the support of =E2=80=9Colder=E2=80=9D IPv6-in-IPv4 (basically= 6rd) as it was > in the previous version of the document, but moved to MAY. Deployments th= at > today have IPv4-only access, can start deploying IPv6 (in IPv4 if they ne= ed > it), but use the same CE for when they can move to IPv6-only access. > > Which is a bit ironic with regards to 6RD which is one of the few > mechanisms with real deployment, as in millions and millions of users. > > >3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed), > based on market relevance and understanding that most of them don=E2=80= =99t take > additional code in the CPE, because most of this code is basically the sa= me. > > That statement is not quite true. The various mechanisms while largely > being built out of the same parts, require quite a bit of glue, testing a= nd > additional support for configuration. If you think the conflict around > hosts/network DNS recursive resolver configuration is hard, then this is = a > n-square problem. > > For implementation complexity just compare MAP-T and MAP-E/LW46 in: > https://git.fd.io/vpp/tree/src/vnet/map Has there yet been a substantial (millions of subs) deployment of any of those listed ? I would not say your metric of subjective complexity is relevant to the current hundreds of millions of subs on v6 or v6-only. I think map-t may have had some recent deployment at Jio, but it is not clear to me how much they have used map-t vs DS ... or their v6 numbers in mobile vs landline. > > > So, to make it short, unless there is a =E2=80=9Cmagic=E2=80=9D mechani= sm that I=E2=80=99m not > aware of, and the WG decides to include it, my intend is no longer includ= e > anything new in the document. And if that =E2=80=9Cmagic=E2=80=9D mechani= sm exists, then we > could delete all the others. > > The magic is in us having the balls to make a choice. And pick one > mandatory to implement mechanism. And only one. > Disagree. This idea of a standard is neither true for ipv4 networks or ipv6 networks. You make standards for interop and design validation, not picking a universal solution. Neither have seen one magic choice in routing protocols, L2 encap, security strategy, v4-v6 transition.... Softwire WG already has seen this approach fail both the working group and industry several times. Softwire's approach failed me and my deployment. Coin flips don't convince anyone of anything aside from your standards being arbitrary and not driven by practical deployments. CB Ps. LISP remains in search of a problem it solves, and has, afaik, not been used to push ipv6 forward in the real world. > Cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11421778c1c3db054cf87d23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ole

On We= d, Apr 12, 2017 at 3:56 AM <otro= an@employees.org> wrote:
Jor= di,

> I=E2=80=99m NOT in favor of including an unlimited number of mechanism= s, and I think we must focus in those that have a real traction. I=E2=80=99= m NOT in favor of including LISP.
>
> However, the document is a WG document, so is not just my decision, bu= t the WG, so I must ask the WG opinions before =E2=80=9Crejecting=E2=80=9D = LISP. That was my question.
>
> I think we need to have a balance:
> 1) Main goal, support of IPv6-only access but allow IPv4 to keep worki= ng in the customer=E2=80=99s LANs.
> 2) Allow the support of =E2=80=9Colder=E2=80=9D IPv6-in-IPv4 (basicall= y 6rd) as it was in the previous version of the document, but moved to MAY.= Deployments that today have IPv4-only access, can start deploying IPv6 (in= IPv4 if they need it), but use the same CE for when they can move to IPv6-= only access.

Which is a bit ironic with regards to 6RD which is one of the few mechanism= s with real deployment, as in millions and millions of users.

>3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed)= , based on market relevance and understanding that most of them don=E2=80= =99t take additional code in the CPE, because most of this code is basicall= y the same.

That statement is not quite true. The various mechanisms while largely bein= g built out of the same parts, require quite a bit of glue, testing and add= itional support for configuration. If you think the conflict around hosts/n= etwork DNS recursive resolver configuration is hard, then this is a n-squar= e problem.

For implementation complexity just compare MAP-T and MAP-E/LW46 in:
https://git.fd.io/vpp/tree/src/vnet/map





> So, to make it short, unless there is a =E2=80=9Cmagic=E2=80=9D mechan= ism that I=E2=80=99m not aware of, and the WG decides to include it, my int= end is no longer include anything new in the document. And if that =E2=80= =9Cmagic=E2=80=9D mechanism exists, then we could delete all the others.
The magic is in us having the balls to make a choice. And pick one mandator= y to implement mechanism. And only one.

Disagree. This idea of a standard is neith= er true for ipv4 networks or ipv6 networks. You make standards for interop = and design validation, not
picking a universal solution.=C2=A0 Ne= ither have seen one magic choice in routing protocols, L2 encap, security s= trategy, v4-v6 transition....

Softwire WG already = has seen this approach fail both the working group and industry several tim= es.=C2=A0 Softwire's approach failed me and my deployment.=C2=A0
<= div>
Coin flips don't convince anyone of anything aside f= rom your standards being arbitrary and not driven by practical deployments.= =C2=A0

CB

Ps. LISP remain= s in search of a problem it solves, and has, afaik, not been used to push i= pv6 forward in the real world.=C2=A0


Cheers,
Ole
_______________________________________________
v6ops mailing list
v6o= ps@ietf.org
https://www.ietf.org/mailman/listinfo= /v6ops
--001a11421778c1c3db054cf87d23-- From nobody Wed Apr 12 07:05: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 A81F3129B4D for ; Wed, 12 Apr 2017 07:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6dqHboy1uUE for ; Wed, 12 Apr 2017 07:05:34 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B9B1294C7 for ; Wed, 12 Apr 2017 07:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492005931; x=1492610731; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=qj7RRTtDp7mZlrTxBebDSKSEn taKGDo9nYvcOPPQPko=; b=SpnIkmrhWafp9ZaQIdBHbUTwL6Cw/x0PW0D6kzRzC xEAp5oP2GsAVcRE1COseUDCf1jrOtEz9TxlICMN9WGq0mC+y3I5CJ5qZmysNj+Sr BpNbNwpHfXVJEOpooYDNYlT+x52hVJulfrdb1T4oIGldZBjinipz284py1lm1Amv 3U= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=V1e5A1dNOOuzIecWqxknT/8cKZLc9jjVLc0yNntEGueGOmbVwheq838EFUmh RTFD1TNDj1vd2wXeaNBl9ZAtohT4R73fYiK9MZzFQwMXrW6BhlS/9O3wL NIv4ieX86s9NdkGfHaYqLvPHfuPkjhpJIHweBNLw/KUy1Ho5kjIa+g=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 16:05:31 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 16:05:30 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407094.msg for ; Wed, 12 Apr 2017 16:05:30 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407094::tQ0EzPB6E/9LGmoB:00002SD+ X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 16:05:27 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 14:05:37 -0000 Fully agree with Cameron view, and furthermore =E2=80=A6 if we need to choo= se one mechanism because how many millions of devices already use it, and t= his demonstrates the success, clearly 464XLAT has more TENS OF MILLIONS of = users than DS-LITE + 6RD + MAP E + MAP T, altogether, and of course it mean= s a single ISP having both wired and cellular networks, can have a single w= ay to deploy IPv6 instead of two. Regards, Jordi =20 -----Mensaje original----- De: Ca By Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 15:50 Para: , CC: Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 =20 Ole =20 On Wed, Apr 12, 2017 at 3:56 AM wrote: =20 =20 Jordi, =20 > I=E2=80=99m NOT in favor of including an unlimited number of mechanis= ms, and I think we must focus in those that have a real traction. I=E2=80= =99m NOT in favor of including LISP. > > However, the document is a WG document, so is not just my decision, b= ut the WG, so I must ask the WG opinions before =E2=80=9Crejecting=E2=80=9D= LISP. That was my question. > > I think we need to have a balance: > 1) Main goal, support of IPv6-only access but allow IPv4 to keep work= ing in the customer=E2=80=99s LANs. > 2) Allow the support of =E2=80=9Colder=E2=80=9D IPv6-in-IPv4 (basical= ly 6rd) as it was in the previous version of the document, but moved to MAY= . Deployments that today have IPv4-only access, can start deploying IPv6 (i= n IPv4 if they need it), but use the same CE for when they can move to IPv6= -only access. =20 Which is a bit ironic with regards to 6RD which is one of the few mecha= nisms with real deployment, as in millions and millions of users. =20 >3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed= ), based on market relevance and understanding that most of them don=E2=80= =99t take additional code in the CPE, because most of this code is basicall= y the same. =20 That statement is not quite true. The various mechanisms while largely = being built out of the same parts, require quite a bit of glue, testing and= additional support for configuration. If you think the conflict around hos= ts/network DNS recursive resolver configuration is hard, then this is a n-s= quare problem. =20 For implementation complexity just compare MAP-T and MAP-E/LW46 in: https://git.fd.io/vpp/tree/src/vnet/map =20 =20 Has there yet been a substantial (millions of subs) deployment of any o= f those listed ? I would not say your metric of subjective complexity is r= elevant to the current hundreds of millions of subs on v6 or v6-only.=20 =20 I think map-t may have had some recent deployment at Jio, but it is not= clear to me how much they have used map-t vs DS ... or their v6 numbers in= mobile vs landline.=20 =20 =20 =20 > So, to make it short, unless there is a =E2=80=9Cmagic=E2=80=9D mecha= nism that I=E2=80=99m not aware of, and the WG decides to include it, my in= tend is no longer include anything new in the document. And if that =E2=80= =9Cmagic=E2=80=9D mechanism exists, then we could delete all the others. =20 The magic is in us having the balls to make a choice. And pick one mand= atory to implement mechanism. And only one. =20 =20 =20 Disagree. This idea of a standard is neither true for ipv4 networks or = ipv6 networks. You make standards for interop and design validation, not picking a universal solution. Neither have seen one magic choice in ro= uting protocols, L2 encap, security strategy, v4-v6 transition.... =20 Softwire WG already has seen this approach fail both the working group = and industry several times. Softwire's approach failed me and my deploymen= t.=20 =20 Coin flips don't convince anyone of anything aside from your standards = being arbitrary and not driven by practical deployments.=20 =20 CB =20 Ps. LISP remains in search of a problem it solves, and has, afaik, not = been used to push ipv6 forward in the real world.=20 =20 =20 =20 Cheers, Ole _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 07:21: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 6D7DD12948A for ; Wed, 12 Apr 2017 07:21:22 -0700 (PDT) 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=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 HgU9qzR6noWu for ; Wed, 12 Apr 2017 07:21:20 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D7ED6126CF9 for ; Wed, 12 Apr 2017 07:21:20 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 12 Apr 2017 14:21:20 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BC239D788A; Wed, 12 Apr 2017 07:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=bJA5oudupNxCfHb9+5CLpiOcwws=; b= eifmTYF/1mj6kibHK1kqsVIl8m2XtK5yVb3QjcG1INXJ3pbDQR+pUFbFqdLHEagk tdISxYkq0fLjBktG3Bt0MMPQqhWpSdaNMYAYwpXGM7BtTFR8R2jeaQ8Ye7K8QyNL Gyf2TTKJemZyOsvEAkH11t4jAwYidbwnRv2b596ka2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=V7YB7vMGVIWsia7mF0End0o ad3GtlZYaYDxEN7O0lM42ZZfpiMO45gfkdmHvNf92wbSEO2QE3odl7mcjkXWMW18 3QRw72FvSMyX/q2wIf3PnyUH+qe3pVCqpYi5OrrXqDpqwbgFL1aJ38IDumQ9RRrT lBMaJbq/fEaLCm/847Uw= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 90ED5D788E; Wed, 12 Apr 2017 07:21:19 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 03C59A94ABB6; Wed, 12 Apr 2017 16:21:17 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_90FEF204-6C5E-461B-BCD9-4CC12C4A9BD7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 16:21:16 +0200 In-Reply-To: Cc: jordi.palet@consulintel.es, v6ops@ietf.org To: Ca By References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 14:21:22 -0000 --Apple-Mail=_90FEF204-6C5E-461B-BCD9-4CC12C4A9BD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > That statement is not quite true. The various mechanisms while largely = being built out of the same parts, require quite a bit of glue, testing = and additional support for configuration. If you think the conflict = around hosts/network DNS recursive resolver configuration is hard, then = this is a n-square problem. >=20 > For implementation complexity just compare MAP-T and MAP-E/LW46 in: > https://git.fd.io/vpp/tree/src/vnet/map >=20 > Has there yet been a substantial (millions of subs) deployment of any = of those listed ? I would not say your metric of subjective complexity = is relevant to the current hundreds of millions of subs on v6 or = v6-only. >=20 > I think map-t may have had some recent deployment at Jio, but it is = not clear to me how much they have used map-t vs DS ... or their v6 = numbers in mobile vs landline. Given that none of these mechanisms are interoperable. And that it is = difficult to build an ISP provisioning system that can deal with an = arbitrary CPE, and that it is hard to build a CPE that can deal with an = ISP offering an arbitrary mechanism. The conclusion really has to be the = same as Barbara has for the IPv6 over IPV6 mechanisms... and it follows = that there is nothing to gain by adding a list of these mechanisms in a = 7084bis document. Ole --Apple-Mail=_90FEF204-6C5E-461B-BCD9-4CC12C4A9BD7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY7jfdAAoJEL7aWKiYQt92KtYP/1KpWtZWj6RoH8X8NSiqHoiZ b8CV+aRHRupl9uj9J6xwiJ2Rles4N4QpCY2GB4hFE0uJtAppbLhQiGpLk4zoMMLU MI4s8/bevs2Vqjke3VQ56H5deuRLLyfbcg4nMd2rM1SMu1lg08cb42zY3KMd+oLU K8XrS6PqTYUsZdZLYxuqm5TcSireFdixBVOIxZh4+xHwey8OxZU7K2MQxyXlYjh5 g8Nug/982MXucLlipuWiPM+tmx3bGL/JdTV3PpFwYUlG8uhWUkTzkXe3VWNjKiU2 7i1df7HwUEOsQuOohcop8vfhwU/fQ47lS6DiFAFeLTOOVa0DaN0oRWE6AUPYd24W eUHDkShn6+C2+Tgbfv0m+Ynk1tmmExGmOtL2IqZfObFKI3CaoFBlJgYkCmno1yPc 7r8b36/5cbueQNeKrZj3zSyFm4vAxBe0PB6Rf8NvUuQZl2dXL5N3CItX36Ovj9bC cRWeLU5IsM+JujH8HJ4gF/vvWC0Paa3ycBwR7NXcsWmTc0LAuRhQHSPKR3NQXI5H hilf+oLHHj8xyitdLcHlTHSBvZin3n9FLB2havrWEcOaIEgi+rXknJt9wovi3lXQ qIxpbI9uoTE0mU3IV8hywYbY8FKGAEo2ltLhwV0FirK5ptjAa/rmxKxbmTW0DYB9 aAlzygbMeCpaV+kVK7uN =DnAp -----END PGP SIGNATURE----- --Apple-Mail=_90FEF204-6C5E-461B-BCD9-4CC12C4A9BD7-- From nobody Wed Apr 12 08:08: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 8F7741316CC for ; Wed, 12 Apr 2017 08:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADe33oBS2mXR for ; Wed, 12 Apr 2017 08:08:44 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A813129B4C for ; Wed, 12 Apr 2017 08:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492009715; x=1492614515; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=liKZUNgUtIDJhMHRbq1aS7CQ5 JyXGzBm9h9Y7ec8HUM=; b=LED31G1RiCy2S2B1xmOfcLBrstBA1s9PmQh6gw6iS 34AZ9kFse7HB8UkF01Xm6FBevHs4eOy8dTRFW9yGgvWIVMJGvaNf67iq7TMvAUU+ SMLfUDjcUj0S7Zpi0XRtVaPp/w9EnngaGNehSWDePzWWWDl6CYMAC5rdBy2IkO+Q 9Q= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=MtBSxmm3Cho4fnfBjykTY/nBIEx2Xo6d3rz5CbUeXA0hHsPURRzhwBufOfJF q7NjgIMJ/DETaVye2WSLbRI5XCUC/NZWfW9QR9jGAUPCdT9qrv/vSUWJ/ iHtSKxs6+w3QpzPUuQeD5yymXg0uLcO11QaW8KbxzObN/PlfJ+qMks=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 17:08:35 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 17:08:35 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407211.msg for ; Wed, 12 Apr 2017 17:08:35 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407211::fUNQuA2/7l/BbaQZ:00002JJb X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 17:08:32 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 15:08:51 -0000 Hi Barbara, Maybe I was not so clear in my explanation. I=E2=80=99m not trying to =E2=80=9Cconvert=E2=80=9D this document into some= thing related to 3GPP. However, I think what is being done there is relevant if it can be uses her= e as well. What I=E2=80=99m saying is that it makes sense to have a single transition = mechanism (if it is possible, and actually IT IS with 464XLAT) in both kind= of networks. Moreover, we need to understand that broadband deployment (residential and = SMEs) in the next few years will also have 3 scenarios in order to understa= nd the CE needs: 1) 1 or more concurrent wireline links (same or different ISPs) 2) 1 or more concurrent LTE links where wireline is not possible (same or d= ifferent ISPs) 3) A mix of 2 or more concurrent wireline + LTE links (same or different IS= Ps). In my opinion, considering this, again it makes a lot of sense to share a t= ransition mechanism that can do both in the same CPE, instead of a differen= t one for each link. If we agree on this perspective of what is going to happen, and we agree th= at clearly the IPv6 deployment in 3GPP is driven by 464XLAT, there is no su= rprise on what I=E2=80=99m saying. Despite that, I think and it has been said by real operators in this list a= few months ago, they actually use RFC7048 for their RFQs to vendors, and t= hey need support of not just 6rd and DS-lite as we have today. Some of them= mention specifically lw4o6, 464XLAT and MAP. This is why I=E2=80=99ve included them and personally I=E2=80=99ve no inten= d to include anything else, as I already mention. I was just asking in case= I have not enough information if LISP needs to be considered, in case has = more traction that what I knew. Now I guess the answer is NO. Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 16:32 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 > Fully agree with Cameron view, and furthermore =E2=80=A6 if we need t= o choose one > mechanism because how many millions of devices already use it, and th= is > demonstrates the success, clearly 464XLAT has more TENS OF MILLIONS o= f > users than DS-LITE + 6RD + MAP E + MAP T, altogether, and of course i= t > means a single ISP having both wired and cellular networks, can have = a single > way to deploy IPv6 instead of two. =20 RFC 7084 has nothing to do with cellular (3GPP) networks. 3GPP deployme= nts are not relevant to this discussion. 3GPP and wireline deployments are = not currently converged, with the 3GPP RAN and IP core networks being disti= nct from the wireline IP access networks (wireline is used as backhaul for = the 3GPP networks at layers 1 and 2, but not for IP). What makes sense for = a 3GPP deployment may or may not make sense for a wireline deployment -- es= pecially considering the lack of extensive IA_PD support in deployed 3GPP n= etworks. =20 If some ISP with wireline and wireless has interest in converging their= wireline IPv6 deployment with their wireless, in the very near future (usi= ng network elements that are already being trialed or have been deployed), = it would indeed be nice for them to speak up. Personally, I have no interna= l requests from my company to drive such IPv6 convergence. =20 So please don't use statistics related to 3GPP deployments in an argume= nt for wireline CE routers. And please don't try to bloat the CE router wit= h everything needed to support attachment to a 3GPP network. =20 In the wireline deployments I'm aware of, the only ones reaching into t= he millions have used dual stack, 6rd, or (possibly) DS-Lite. And of these = 3, the only one that I believe should ever be considered mandatory for all = CE routers is dual stack. Barbara =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 08:26: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 047EC129C5D for ; Wed, 12 Apr 2017 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 ORX0JAnx3c-3 for ; Wed, 12 Apr 2017 08:26:13 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 6C93A129516 for ; Wed, 12 Apr 2017 08:26:12 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3CEOuih030351; Wed, 12 Apr 2017 10:32:53 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 29sneha2g3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 10:32:53 -0400 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 v3CEWpHL014204; Wed, 12 Apr 2017 10:32:52 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3CEWhdW014010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 10:32:44 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 14:32:34 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 10:32:33 -0400 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgIAAMIOAgAAEPYD//76fsA== Date: Wed, 12 Apr 2017 14:32:33 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> In-Reply-To: <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.164.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_11:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704120120 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 15:26:15 -0000 PiBGdWxseSBhZ3JlZSB3aXRoIENhbWVyb24gdmlldywgYW5kIGZ1cnRoZXJtb3JlIOKApiBpZiB3 ZSBuZWVkIHRvIGNob29zZSBvbmUNCj4gbWVjaGFuaXNtIGJlY2F1c2UgaG93IG1hbnkgbWlsbGlv bnMgb2YgZGV2aWNlcyBhbHJlYWR5IHVzZSBpdCwgYW5kIHRoaXMNCj4gZGVtb25zdHJhdGVzIHRo ZSBzdWNjZXNzLCBjbGVhcmx5IDQ2NFhMQVQgaGFzIG1vcmUgVEVOUyBPRiBNSUxMSU9OUyBvZg0K PiB1c2VycyB0aGFuIERTLUxJVEUgKyA2UkQgKyBNQVAgRSArIE1BUCBULCBhbHRvZ2V0aGVyLCBh bmQgb2YgY291cnNlIGl0DQo+IG1lYW5zIGEgc2luZ2xlIElTUCBoYXZpbmcgYm90aCB3aXJlZCBh bmQgY2VsbHVsYXIgbmV0d29ya3MsIGNhbiBoYXZlIGEgc2luZ2xlDQo+IHdheSB0byBkZXBsb3kg SVB2NiBpbnN0ZWFkIG9mIHR3by4NCg0KUkZDIDcwODQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBj ZWxsdWxhciAoM0dQUCkgbmV0d29ya3MuIDNHUFAgZGVwbG95bWVudHMgYXJlIG5vdCByZWxldmFu dCB0byB0aGlzIGRpc2N1c3Npb24uIDNHUFAgYW5kIHdpcmVsaW5lIGRlcGxveW1lbnRzIGFyZSBu b3QgY3VycmVudGx5IGNvbnZlcmdlZCwgd2l0aCB0aGUgM0dQUCBSQU4gYW5kIElQIGNvcmUgbmV0 d29ya3MgYmVpbmcgZGlzdGluY3QgZnJvbSB0aGUgd2lyZWxpbmUgSVAgYWNjZXNzIG5ldHdvcmtz ICh3aXJlbGluZSBpcyB1c2VkIGFzIGJhY2toYXVsIGZvciB0aGUgM0dQUCBuZXR3b3JrcyBhdCBs YXllcnMgMSBhbmQgMiwgYnV0IG5vdCBmb3IgSVApLiBXaGF0IG1ha2VzIHNlbnNlIGZvciBhIDNH UFAgZGVwbG95bWVudCBtYXkgb3IgbWF5IG5vdCBtYWtlIHNlbnNlIGZvciBhIHdpcmVsaW5lIGRl cGxveW1lbnQgLS0gZXNwZWNpYWxseSBjb25zaWRlcmluZyB0aGUgbGFjayBvZiBleHRlbnNpdmUg SUFfUEQgc3VwcG9ydCBpbiBkZXBsb3llZCAzR1BQIG5ldHdvcmtzLg0KDQpJZiBzb21lIElTUCB3 aXRoIHdpcmVsaW5lIGFuZCB3aXJlbGVzcyBoYXMgaW50ZXJlc3QgaW4gY29udmVyZ2luZyB0aGVp ciB3aXJlbGluZSBJUHY2IGRlcGxveW1lbnQgd2l0aCB0aGVpciB3aXJlbGVzcywgaW4gdGhlIHZl cnkgbmVhciBmdXR1cmUgKHVzaW5nIG5ldHdvcmsgZWxlbWVudHMgdGhhdCBhcmUgYWxyZWFkeSBi ZWluZyB0cmlhbGVkIG9yIGhhdmUgYmVlbiBkZXBsb3llZCksIGl0IHdvdWxkIGluZGVlZCBiZSBu aWNlIGZvciB0aGVtIHRvIHNwZWFrIHVwLiBQZXJzb25hbGx5LCBJIGhhdmUgbm8gaW50ZXJuYWwg cmVxdWVzdHMgZnJvbSBteSBjb21wYW55IHRvIGRyaXZlIHN1Y2ggSVB2NiBjb252ZXJnZW5jZS4N Cg0KU28gcGxlYXNlIGRvbid0IHVzZSBzdGF0aXN0aWNzIHJlbGF0ZWQgdG8gM0dQUCBkZXBsb3lt ZW50cyBpbiBhbiBhcmd1bWVudCBmb3Igd2lyZWxpbmUgQ0Ugcm91dGVycy4gQW5kIHBsZWFzZSBk b24ndCB0cnkgdG8gYmxvYXQgdGhlIENFIHJvdXRlciB3aXRoIGV2ZXJ5dGhpbmcgbmVlZGVkIHRv IHN1cHBvcnQgYXR0YWNobWVudCB0byBhIDNHUFAgbmV0d29yay4NCg0KSW4gdGhlIHdpcmVsaW5l IGRlcGxveW1lbnRzIEknbSBhd2FyZSBvZiwgdGhlIG9ubHkgb25lcyByZWFjaGluZyBpbnRvIHRo ZSBtaWxsaW9ucyBoYXZlIHVzZWQgZHVhbCBzdGFjaywgNnJkLCBvciAocG9zc2libHkpIERTLUxp dGUuIEFuZCBvZiB0aGVzZSAzLCB0aGUgb25seSBvbmUgdGhhdCBJIGJlbGlldmUgc2hvdWxkIGV2 ZXIgYmUgY29uc2lkZXJlZCBtYW5kYXRvcnkgZm9yIGFsbCBDRSByb3V0ZXJzIGlzIGR1YWwgc3Rh Y2suDQpCYXJiYXJhDQo= From nobody Wed Apr 12 08:27: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 06B01129C47 for ; Wed, 12 Apr 2017 08:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRkbsxtTGTPr for ; Wed, 12 Apr 2017 08:27:19 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEECD129C68 for ; Wed, 12 Apr 2017 08:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492010833; x=1492615633; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=60Z2dT7DN+kI/ffvlloiYbyHV rjBqjNs2N8te5YJwv0=; b=XtBqWY2I12KidFpUnI+4mNvSwlC66JrJma+Jnmxp7 2Hvp6p65a9M+/AdrEt3quvAZQ/cpGcwxrPbmNQ6O/nMniccEaIbvj2IQSM7tPrjj L3COnXKLHYWb/OUAxD1qaXfYxO86+JablcSmvhd9iLwQqo//5rW7943bBiw3hGzj mU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=PajZVwGzlnHcwhawMKYnvTLGL44ETva5nJ66xuOUhAz9G7REOmZIXLR5kff8 rY87yuwJH00tKdroK8h3tOP6Y8hCy+pJvdJaafetadB+f09xfSJJeVlyk ZTYDRR46+ShNLGTcn/4jTtbTwv3Z3JP9CVUzfnZFVhyRjiyEquXdGg=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 17:27:13 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 17:27:13 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407222.msg for ; Wed, 12 Apr 2017 17:27:13 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407222::SETUdOn8kuR/YIpB:0000KPmH X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 17:27:09 +0200 From: JORDI PALET MARTINEZ To: , Ca By CC: Message-ID: Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 15:27:21 -0000 Hi Ole, > I think map-t may have had some recent deployment at Jio, but it is not c= lear to me how much they have used map-t vs DS ... or their v6 numbers in m= obile vs landline. =20 Given that none of these mechanisms are interoperable. And that it is d= ifficult to build an ISP provisioning system that can deal with an arbitrar= y CPE, and that it is hard to build a CPE that can deal with an ISP offerin= g an arbitrary mechanism. The conclusion really has to be the same as Barba= ra has for the IPv6 over IPV6 mechanisms... and it follows that there is no= thing to gain by adding a list of these mechanisms in a 7084bis document. [Jordi] I don=E2=80=99t agree. Several service providers have said so in th= e list. Some of them are big ones (I recall DT), other smaller and medium o= nes. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 08:51:59 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1BE1294FA; Wed, 12 Apr 2017 08:51:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149201230991.15796.10423245600175984626@ietfa.amsl.com> Date: Wed, 12 Apr 2017 08:51:49 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 15:51:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-rfc7084-bis-01.txt Pages : 29 Date : 2017-04-12 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers several transition technologies, as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. The document obsoletes RFC 7084. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc7084-bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 12 09:00: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 350F413174F for ; Wed, 12 Apr 2017 09:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZp_4qsSnL0i for ; Wed, 12 Apr 2017 08:59:59 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F53C131766 for ; Wed, 12 Apr 2017 08:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492012796; x=1492617596; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=DObBbIYJwzEc/Y7CDongV+1CX 9aEg7/koslhWB1rdDs=; b=ULC35xdvImCoCR2HDWVgJNIEINsWWcP9X1rQufQMn MId3nyoMGOX6KZlAX3ZzYtlA2qREditS4B+i2XHNT95zUX2xFHBQA5n9s9O9+EIz +xycvujD8OBUw6MHfDIrf3FPPgOd7yChzYbrFveDTX5yjailCpUqAnG1QK0OcNwz Z0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ICoGelBMo7f2dghwk7Uo6qdoIKHlytUvJ3GavDGWmpTCvKE7s4N8rikIfGV8 deU2pZMB/bCrjDyJuE+9T4fRAZvjaDwuimfdXI0spJ9m2d4UsKJZAFXox GU/9JoIsWRxc12wtoOOcm8IHXIH+nIQBLOfqQofq4e9n6a6H9Revn0=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 17:59:56 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 17:59:55 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407264.msg for ; Wed, 12 Apr 2017 17:59:55 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407264::RW+6B1cvE6pYAYO4:00003aMW X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 17:59:54 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt References: <149201230991.15796.10423245600175984626@ietfa.amsl.com> In-Reply-To: <149201230991.15796.10423245600175984626@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 16:00:01 -0000 Hi all, As indicated a couple of days ago, I=E2=80=99ve posted a new version. https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis It contains a new Annex at the end of the document, reflecting the changes = from -00, which basically are what has been discussed in the list the last = few days: 1. LW4O6-5 changed to port-restricted to conform with [RFC7596]. 2. MAPE-3 changed to port-restricted to conform with [RFC7597]. 3. MAPT-3 changed to port-restricted to conform with [RFC7599]. 4. [RFC7341] removed from 464XLAT, DS-LITE, MAP-E and MAP-T requirements. 5. [RFC5625] removed from 464XLAT, and included as general LAN requirement. 6. [RFC7618] included as MAY for lw4o6. Hopefully now that we have some =E2=80=9Cheat=E2=80=9D in the discussion, t= his version will facilitate interested folks to read over. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 17:51 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations of the IETF. =20 Title : Basic Requirements for IPv6 Customer Edge Rou= ters Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-rfc7084-bis-01.txt Pages : 29 Date : 2017-04-12 =20 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers several transition technologies, as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-onl= y or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. The document obsoletes RFC 7084. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-01 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc7084-bis-01 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 09:07: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 DB476131739 for ; Wed, 12 Apr 2017 09:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 jdN1MWwz5Ux7 for ; Wed, 12 Apr 2017 09:07:48 -0700 (PDT) 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 5BCCD1292AE for ; Wed, 12 Apr 2017 09:07:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BB2AEA2; Wed, 12 Apr 2017 18:07:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492013259; bh=wLRyTdqQ35be+CVj+ZgN6a3gUcNgGb+H3rZwmfG9eYM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2ASvEKJZaP16LpxnqJzDQ0bSsyzCib8WeOfDjga0iXUKDUSsTlpYr18hkvByIAYri 630+3ed9bdRE9CSLJpM5TZtER+YIPVKA28SdkSLliaYnBXQ5Jv7ftrR7UxAGH5iPRZ CE+xdkScqXW1+0rsale2Kt6MHy+IW95eagS+nRv4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B85EF88; Wed, 12 Apr 2017 18:07:39 +0200 (CEST) Date: Wed, 12 Apr 2017 18:07:39 +0200 (CEST) From: Mikael Abrahamsson To: "STARK, BARBARA H" cc: "v6ops@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> Message-ID: References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 16:07:51 -0000 On Wed, 12 Apr 2017, STARK, BARBARA H wrote: > In the wireline deployments I'm aware of, the only ones reaching into > the millions have used dual stack, 6rd, or (possibly) DS-Lite. And of > these 3, the only one that I believe should ever be considered mandatory > for all CE routers is dual stack. https://stats.labs.apnic.net/ipv6/DE I have been told that KABELDEUTSCHLAND and other DOCSIS providers in Germany use ds.lite. Considering the "samples" numbers, I'd say DS.lite is in the million+ in Germany alone. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 12 10:10: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 F409B12EB06 for ; Wed, 12 Apr 2017 10:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 BCA3uHFuePdD for ; Wed, 12 Apr 2017 10:10:43 -0700 (PDT) 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 15D7512EB02 for ; Wed, 12 Apr 2017 10:10:43 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id g2so6528097pge.2 for ; Wed, 12 Apr 2017 10:10:43 -0700 (PDT) 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=vy9B1Bc6BYN08Gbv2RIVi99E7Xz4dDRABthZO5zj+K0=; b=oxoGt/24hs8T9Mdk9u5d4y9Cs+gIMCXiDo1EuRHR7W+qVWXAbyKTPiJ9R08NkrOfED 1r1Owti8POwvuGuD0fEzH0bOXY69BoxA1PqChnmyvtcgXvXHjtov8Hu7L0FqbuFCA5R9 lnPunf1MEzvKADlPEzGVc/Bf/yKPz8phQ62u8ZxD8lHkA3EnRCieSwYZBCEiXsmNkS9e dxZX0ontcmJZY/S90gmHlTIQuLRIwAuC+/CttO0ZnEcxIUG6927uKbGWQT9ac/DHD4N3 +7v/wYO0ftENwIoHHLM0IlybiZqqv6ovVyCEfPOJZ9MivncghhQPNLDB43L5qmVQHLev LpIw== 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=vy9B1Bc6BYN08Gbv2RIVi99E7Xz4dDRABthZO5zj+K0=; b=cVhe/2GuhYfv3LulVKUNLMP8cfza3NG0jf19nNHjhm6E/Sue/3qSvADtqaPAAurX0f kXDE3t2oC0BMNYtaQWdLL/V0oiaZSHT30+1yJdst5YxWeS4jloiWKdTB0T/Rkq2Bfibr YMyh64aCJpYo0X8I+FJtoP/quqGLVLIytXc4fwlYkdDy89uaioBgYxwevk5GxVbZKGjQ UDXLVYsScXQpiL/IHRnErrgXfKXWxZrDnuwoV3uTQMxh7li6RR14DGHWM/Npy6Nuv0sO b4pv2k387lnzyj7VmNsRh6ugzI5fvWZsoBHRcD14xP66UPUdv25GPN/OT6g306j2SP4I PtFA== X-Gm-Message-State: AFeK/H2sLYjR0UXD+ZcHT2zmCpOUV2xH2bP6foQh4JM3qGpeT4ICsR8RdOcLDFko2Sahng== X-Received: by 10.98.19.12 with SMTP id b12mr67770509pfj.21.1492017042635; Wed, 12 Apr 2017 10:10:42 -0700 (PDT) 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 z21sm15903316pfk.95.2017.04.12.10.10.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 10:10:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4C4D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 12 Apr 2017 10:10:40 -0700 Cc: "STARK, BARBARA H" , "otroan@employees.org" , JORDI PALET MARTINEZ , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5542863A-9BA7-48A6-B114-52E13EA89380@gmail.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933009E4C4D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:10:45 -0000 > On Apr 12, 2017, at 6:12 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Barbara,=20 >=20 > Wouldn't just be fine for those ISPs not interested in transition = mechanisms to continue referring to RFC7084? The tricky bit tends to be in how we label the update. If it "obsoletes" = or "updates" 7084, we mean that any reference to 7084 becomes a = reference to the new thing, or 7084 plus the new thing. We would need to = clearly label it so that a procurement could reference 7084 without it, = or reference 7084 and the new thing separately. > Cheers, > Med >=20 >> -----Message d'origine----- >> De : STARK, BARBARA H [mailto:bs7652@att.com] >> Envoy=C3=A9 : mercredi 12 avril 2017 14:53 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; otroan@employees.org; >> jordi.palet@consulintel.es >> Cc : v6ops@ietf.org >> Objet : RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 >>=20 >>> I tend to agree with you but with a slightly different proposal: = pick >> ONE >>> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P >>> mechanism (MAP-E). >>=20 >> Because RFC 7084 is also used as a mandatory reference in BBF TR-124 = (used >> by telco ISPs to help with CE router RFPs), and most ISPs have no = interest >> in requiring capabilities that are not useful to or relevant in their >> deployment, there MUST NOT be any mandatory transition mechanisms = included >> in a 7084-bis. >> Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 12 10:22: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 6580212956A for ; Wed, 12 Apr 2017 10:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 lvxoOvlfpW5E for ; Wed, 12 Apr 2017 10:22:17 -0700 (PDT) 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 7181012953D for ; Wed, 12 Apr 2017 10:22:17 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id s16so16794137pfs.0 for ; Wed, 12 Apr 2017 10:22:17 -0700 (PDT) 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=1EhkpRKy1cfdeDCWOsYniYyo5ElE9ZWzrXqOnOx1pok=; b=CYJU8o7woUt3MovG8Gb4+DSzkF4NzqJ1kahlQnUsOWBRdzZu3Q8xfNH3C1hXU6q+YI bMRo5klkbCxzL417Hj39D7FEZcCs3KESIIKfBCGIozPHK/IzFNbo+GDVeK5LwwA36k7O HGNMKBLOLMGDczMB+5mh3S/tObyV53I6NptXrQb3B+zAh+Ck0oQTWRDgFSowT4SmOXR0 /Cyd5bH4CSoodxFG2avCoiSqawgRV6ZPcnScYheEi50zdNiyJNSQih2/PGrggbo48Hl5 SvIZ2m3murrhr+Q6ZEcsxgoBki1EFAmkQMAuxCQjVEpkEn/39b36KLZ8U7q4h2X7yrFm XQHw== 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=1EhkpRKy1cfdeDCWOsYniYyo5ElE9ZWzrXqOnOx1pok=; b=mb91SKADIuIcCsijEGt6rSSclyWLtDnLBW77SZm7P6bQZdjKxf+Y7ZOPEI1j+UC75g giyEKAkXJvV+hSjSpqDgK9GPuHDBQkeJx7Spr7ENEzuG4pL8Ma5gZXxPeilxYBQfz4cU vqyrrdlkUxB/X8sxaJVcbTYSFXglEknG6RH0kqrHiqkAwAPPcBTFAQQxAwo8VjHquEwd XCt2ly7Tfv9dJlCvxUGoXT08PFMpehCJrTpAah+alt7O+Ony0T4ucGj5S92kHfDtOLDn mKHibIi8NeuyqqYj8zGfS1mAxp3garG5q/iOdNJkqhve6pWQqrnRXsEwaBXPl2khWIoN VkoQ== X-Gm-Message-State: AFeK/H3ym5ZEaSkVlWRLG0eZlKguRTI+AeFm5PMvS0JmApWCS/DTL+AGstpqfmS8YhuDag== X-Received: by 10.99.247.69 with SMTP id f5mr70975030pgk.63.1492017737074; Wed, 12 Apr 2017 10:22:17 -0700 (PDT) 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 x21sm37677260pfa.71.2017.04.12.10.22.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 10:22:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 12 Apr 2017 10:22:14 -0700 Cc: JORDI PALET MARTINEZ , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" , "mohamed.boucadair@orange.com" , "otroan@employees.org" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:22:19 -0000 > On Apr 12, 2017, at 5:52 AM, STARK, BARBARA H wrote: >=20 >> I tend to agree with you but with a slightly different proposal: = pick ONE >> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P >> mechanism (MAP-E). >=20 > Because RFC 7084 is also used as a mandatory reference in BBF TR-124 = (used by telco ISPs to help with CE router RFPs), and most ISPs have no = interest in requiring capabilities that are not useful to or relevant in = their deployment, there MUST NOT be any mandatory transition mechanisms = included in a 7084-bis. No hats I'm not sure I would go so far as your respective statements, but I = agree that we don't want a laundry list of mechanisms that mostly make = equipment more expensive, harder to use, and harder to sell. It's kind = of pointless. It seems to me that if a network wants to use a given = transition technology, it should specify that to its vendor(s) in the = RFP/RFQ. A data point of interest: = https://ccdcoe.org/multimedia/hedgehog-fog-creating-and-detecting-ipv6-tra= nsition-mechanism-based-information.html is being flagged in the media = as a reason to not deploy IPv6 - transition technologies that use = tunnels apparently bypass intrusion detection technologies. I would = argue that the point is flawed; put the tunnel intrusion detection = technology between the tunnel endpoints and the user, problem solved. = One issue there might be with the IDS itself - if it only looks at IPv4, = it's not going to detect much in IPv6. But in general, I tend to think that a better recommendation would be to = walk through our list of technologies and obsolete them - like we did = with 6to4. > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 12 10:31: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 55FDF129BF5 for ; Wed, 12 Apr 2017 10:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKjGM_4dQ-zI for ; Wed, 12 Apr 2017 10:31:50 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08A812EB0C for ; Wed, 12 Apr 2017 10:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492018298; x=1492623098; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=AOqOi/QOL0yvo8uYHuOkOGglo sqSo3tZNiIIK/Hrnc4=; b=pLmuLYgskfU5gIEyQJhiCvcVWpCN+OzxavDm8iDLa k1FvVby396+t7o/0b3ZMlp95KfV4MarwyCYdhsiBcVkeBqCow8O4uqSqybk5Y3lW pLqpZdR5Ew/E3KGa8eksaoXlXIsHNCWsDfqYPN4/TNHDirbPBpKmLLh8h6fAe5ew k0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=lSKzIAhCe6QTCgC25JUi66gRAu9f6yjKOLjUwLAvw6LcRHnH2jTbKAaTd9xX 8541H73RbiYBrVOGnmdHcabYEv5qamSyobUcxgnwkbexsb1O+RxCj5EU2 UBwMrTCEksIbNncW37cEwIa5QBUn5P7dmSfT9IsPMe+HLAVNREHpBg=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 19:31:38 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 19:31:37 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407343.msg for ; Wed, 12 Apr 2017 19:31:37 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407343::5JHmDN0DHsPjsKJ8:0000B7tA X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 19:31:33 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <3ED0FE6F-1C6C-4A66-BC02-5F80943FD411@consulintel.es> Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933009E4C4D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5542863A-9BA7-48A6-B114-52E13EA89380@gmail.com> In-Reply-To: <5542863A-9BA7-48A6-B114-52E13EA89380@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:31:53 -0000 I=E2=80=99m not sure to understand the problem here. The transition mechanism in this document aren=E2=80=99t a =E2=80=9CMUST=E2= =80=9D (same in the actual RFC7084), so if an ISP is using this document as= a reference for an RFQ, and don=E2=80=99t need the transition mechanism, n= othing change. If the ISP want to ask in the RFQ the transition mechanism t= hey should reference to the RFC and add a MUST for those technologies that = he is going to use for the deployment, or even say something generic such a= s =E2=80=9Call the transition mechanism in this RFC MUST be supported if yo= u intend to be our provider, in addition to =E2=80=A6. (specific vendor req= uirements here)=E2=80=9D. Obsoleting and updating, will in any case have a reference such as =E2=80= =9Cthis document has been obsoleted or updated by =E2=80=A6=E2=80=9D, eithe= r in the header or in the document itself? I think it makes more sense obsoleting if we still have the same view of = =E2=80=9Cdoing updated=E2=80=9D to the current text, instead of working in = two documents as I asked in my presentation (slide 8) in Chicago. Just to r= emind it, the alternative was: - Downgrade actual RFC7084 so it doesn=E2=80=99t include any transition mec= hanism and have a new document with the transition mechanisms. We could also add some more detailed text over-explaining that the main sco= pe of the document is IPv6-only, and the transition mechanisms as there onl= y for the initial phase of the IPv6 deployment while there is still a need = to support access to IPv4-only devices/apps in the LAN or in the =E2=80=9Cr= emote-IPv4-only=E2=80=9D Internet. I think it is already clear in the actua= l text but we can =E2=80=9Cstress=E2=80=9D it a bit more =E2=80=A6 Regards, Jordi =20 -----Mensaje original----- De: Fred Baker Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 19:10 Para: CC: "STARK, BARBARA H" , "otroan@employees.org" , JORDI PALET MARTINEZ , "v6ops@ietf= .org" Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 =20 > On Apr 12, 2017, at 6:12 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Barbara,=20 >=20 > Wouldn't just be fine for those ISPs not interested in transition mec= hanisms to continue referring to RFC7084? =20 The tricky bit tends to be in how we label the update. If it "obsoletes= " or "updates" 7084, we mean that any reference to 7084 becomes a reference= to the new thing, or 7084 plus the new thing. We would need to clearly lab= el it so that a procurement could reference 7084 without it, or reference 7= 084 and the new thing separately. =20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : STARK, BARBARA H [mailto:bs7652@att.com] >> Envoy=C3=A9 : mercredi 12 avril 2017 14:53 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; otroan@employees.org; >> jordi.palet@consulintel.es >> Cc : v6ops@ietf.org >> Objet : RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 >>=20 >>> I tend to agree with you but with a slightly different proposal: p= ick >> ONE >>> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P >>> mechanism (MAP-E). >>=20 >> Because RFC 7084 is also used as a mandatory reference in BBF TR-124= (used >> by telco ISPs to help with CE router RFPs), and most ISPs have no in= terest >> in requiring capabilities that are not useful to or relevant in thei= r >> deployment, there MUST NOT be any mandatory transition mechanisms in= cluded >> in a 7084-bis. >> Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 10:44: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 D5A0212EB23 for ; Wed, 12 Apr 2017 10:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK-xj-JU-hgN for ; Wed, 12 Apr 2017 10:44:11 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB69712EB21 for ; Wed, 12 Apr 2017 10:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492019049; x=1492623849; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=yEu7LVNog0GowoWQkVpTETjbg QIN2r45RPjFnCx+soA=; b=RizqsNzXH/pUWDgVK6RiYHoT7a1bQktqCfDbD1o7/ gbXH5uhxN4KMn3glWpRYlGT4NrCHTOC2skFEQfC971n9aV9YNTdnq8OoU4qZbKE5 QrCjR3gu4gYwTrlIakrOODtzY1Xc/F7T5rL8NYOWqS8fKv3Z7da4sopJmlrBTDfl Xk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=WBUTY636BAoviJncOs4ncqELe29TGgv1dc67Wv0tMvUQEDxJ+B+SG/AMBhKg 1khElBBbEDw6K5Bhh8NOqDb8fqb8336q3RPbS4+FAJczBw1HM01YZ1/gU hZktYoZQdD15YE9cnIECd/s4QXMmObmya/mXeGABBjeaOBLsL2SQBY=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 19:44:09 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 19:44:08 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407350.msg for ; Wed, 12 Apr 2017 19:44:07 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407350::xZXa5442MtMJcIJN:00001WfY X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 19:44:03 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <6DA0D96E-247C-4A95-906B-AD6EB3275938@consulintel.es> Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:44:13 -0000 > On Apr 12, 2017, at 5:52 AM, STARK, BARBARA H wrote: >=20 >> I tend to agree with you but with a slightly different proposal: pi= ck ONE >> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P >> mechanism (MAP-E). >=20 > Because RFC 7084 is also used as a mandatory reference in BBF TR-124 = (used by telco ISPs to help with CE router RFPs), and most ISPs have no int= erest in requiring capabilities that are not useful to or relevant in their= deployment, there MUST NOT be any mandatory transition mechanisms included= in a 7084-bis. =20 No hats =20 I'm not sure I would go so far as your respective statements, but I agr= ee that we don't want a laundry list of mechanisms that mostly make equipme= nt more expensive, harder to use, and harder to sell. It's kind of pointles= s. It seems to me that if a network wants to use a given transition technol= ogy, it=20 [Jordi] I disagree here. Adding the actual transition mechanism (all them) = in the v-01 of the document (submitted today) means 0,15% of extra flash me= mory (slide 4 in my Chicago presentation) in the average =E2=80=9Cvery low = cost=E2=80=9D CE today available in the market (8 Mbytes flash, leaving sti= ll about 2.5-3 Mbytes for future upgrades). I=E2=80=99ve done this analysis= based on OpenWRT and several products in the market that use this or simil= ar Linux-based implementations, which I think is probably 80% of the market= today, and going up. More and more product now start using 16 Mbytes flash= . There is no need for more CPU power or more RAM. In fact, there were 3 = =E2=80=9Cmajor well-know=E2=80=9D vendors in the meeting room and didn=E2= =80=99t said that I=E2=80=99m wrong on this. May be if they are reading, th= ey could confirm. should specify that to its vendor(s) in the RFP/RFQ. [Jordi] The point here is what I=E2=80=99ve indicated several times. Vendor= s are telling ISPs that they don=E2=80=99t support a given transition mecha= nism such as lw4o6, 464XLAT or MAP, because they=E2=80=99re aren=E2=80=99t = in the RFC7084. Smaller ISPs have even a worst situation because they can= =E2=80=99t do RFQs as their quantity is too small, so they just go to retai= l. This has been confirmed in the list by several folks. =20 A data point of interest: https://ccdcoe.org/multimedia/hedgehog-fog-cr= eating-and-detecting-ipv6-transition-mechanism-based-information.html is be= ing flagged in the media as a reason to not deploy IPv6 - transition techno= logies that use tunnels apparently bypass intrusion detection technologies.= I would argue that the point is flawed; put the tunnel intrusion detection= technology between the tunnel endpoints and the user, problem solved. One = issue there might be with the IDS itself - if it only looks at IPv4, it's n= ot going to detect much in IPv6. =20 But in general, I tend to think that a better recommendation would be t= o walk through our list of technologies and obsolete them - like we did wit= h 6to4. =20 > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 10:45: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 3836312EB25 for ; Wed, 12 Apr 2017 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 J7YrPSHWb8GD for ; Wed, 12 Apr 2017 10:45:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 C110212960D for ; Wed, 12 Apr 2017 10:45:29 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v3CHZ52Y025248; Wed, 12 Apr 2017 13:45:22 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 29sr34f0vh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 13:45:21 -0400 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 v3CHjKOk003537; Wed, 12 Apr 2017 13:45:20 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3CHjBFB003422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 13:45:13 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 17:44:58 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 13:44:57 -0400 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgIAAMIOAgAAEPYD//76fsIAAUwEA///ZnIA= Date: Wed, 12 Apr 2017 17:44:56 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.164.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_13:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704120144 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:45:31 -0000 PiBXaGF0IEnigJltIHNheWluZyBpcyB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgYSBzaW5n bGUgdHJhbnNpdGlvbiBtZWNoYW5pc20NCj4gKGlmIGl0IGlzIHBvc3NpYmxlLCBhbmQgYWN0dWFs bHkgSVQgSVMgd2l0aCA0NjRYTEFUKSBpbiBib3RoIGtpbmQgb2YgbmV0d29ya3MuDQoNCjQ2NFhM QVQgaXMgbm90IHVzZWZ1bCB0byBtZS4gSXQgaXMgbm90IHVzZWQgaW4gYW55IG9mIHRoZSBuZXR3 b3JrcyBvZiBteSBlbXBsb3llci4gVGhlcmVmb3JlLCBpdCB3aWxsIG5vdCBiZSByZXF1ZXN0ZWQg aW4gYW55IFJGUCB0aGF0IEkgaGVscCBhdXRob3IsIG5vciB3aWxsIGl0IGJlIHJlcXVpcmVkIChN VVNUKSBieSBhbnkgZG9jdW1lbnQgcmVmZXJlbmNlZCBieSBhbiBSRlAgdGhhdCBJIGhlbHAgYXV0 aG9yLiBJZiBpdCBtYWdpY2FsbHkgYXBwZWFycyBpbiBDRSByb3V0ZXJzIHdpdGhvdXQgZ2V0dGlu ZyBpbiBteSB3YXksIHRoZW4gSSB3b24ndCBtaW5kIGl0IGJlaW5nIHRoZXJlLg0KDQotLS0tLS0t LSBzbmlwIC0tLS0tLS0tLS0tDQoNCj4gRGVzcGl0ZSB0aGF0LCBJIHRoaW5rIGFuZCBpdCBoYXMg YmVlbiBzYWlkIGJ5IHJlYWwgb3BlcmF0b3JzIGluIHRoaXMgbGlzdCBhIGZldw0KPiBtb250aHMg YWdvLCB0aGV5IGFjdHVhbGx5IHVzZSBSRkM3MDQ4IGZvciB0aGVpciBSRlFzIHRvIHZlbmRvcnMs IGFuZCB0aGV5DQo+IG5lZWQgc3VwcG9ydCBvZiBub3QganVzdCA2cmQgYW5kIERTLWxpdGUgYXMg d2UgaGF2ZSB0b2RheS4gU29tZSBvZiB0aGVtDQo+IG1lbnRpb24gc3BlY2lmaWNhbGx5IGx3NG82 LCA0NjRYTEFUIGFuZCBNQVAuDQoNClJGQyA3MDg0IGlzIGEgbWFuZGF0b3J5IHJlcXVpcmVtZW50 IG9mIEJCRiBUUi0xMjQsIHdoaWNoIG15IGNvbXBhbnkgdXNlcyBmb3IgaXRzIFJGUHMuIFNpbmNl IG15IFJGUHMgd2lsbCBub3QgZXZlciByZXF1aXJlIChNVVNUKSA0NjRYTEFULCBpZiA3MDg0LWJp cyB3ZXJlIHRvIG1ha2UgaXQgYSBNVVNUIHJlcXVpcmVtZW50LCB0aGVuIDcwODQtYmlzIHdvdWxk IGJlIHVzZWxlc3MgdG8gbWUgYXMgYSByZWZlcmVuY2UgYW5kIEkgd291bGQgaGF2ZSB0byBlbnN1 cmUgNzA4NC1iaXMgd2FzIG5vdCBhIHJlcXVpcmVtZW50IGluIFRSLTEyNC4gQW5kIGFzIHNvbWVv bmUgd2hvJ3Mgd3JpdHRlbiBhIGxvdCBvZiBDRSByb3V0ZXIgUkZQcywgSSBrbm93IGZvciBhIGZh Y3QgdGhhdCBpdCBpcyBub3QgYXQgYWxsIGRpZmZpY3VsdCB0byBzYXkgIlJlcTE6IERvIGFsbCBt YW5kYXRvcnkgcmVxdWlyZW1lbnRzIG9mIFJGQyA3MDg0LWJpcy4iICJSZXEyOiBEbyA0NjRYTEFU IGFzIGRlc2NyaWJlZCBpbiBSRkMgNzA4NC1iaXMuIg0KDQpUbyBiZSBjbGVhcjogSSBkbyBub3Qg b2JqZWN0IHRvIHRoZSBjdXJyZW50IGxhbmd1YWdlIG9mICJTSE9VTEQiIGZvciA0NjRYTEFULiBJ IG9iamVjdCB0byB0aGUgcHJvcG9zYWwgdGhhdCBpdCBiZWNvbWUgIk1VU1QiLg0KV2hpbGUgSSdt IGF0IGl0LCBJIGFsc28gb2JqZWN0IHRvIHRoZSBjdXJyZW50IGxhbmd1YWdlIHRoYXQgIklmIDZy ZCBpcyBpbXBsZW1lbnRlZCwgNmluNCBNVVNUIGJlIHN1cHBvcnRlZCBhcyB3ZWxsLiIgIFRoaXMg c3RhdGVtZW50IHdpbGwgbWFrZSB0aGUgZG9jdW1lbnQgdXNlbGVzcyBmb3IgbWUgYXMgYSBSRlAg cmVmZXJlbmNlIChkaXJlY3RseSBvciBpbmRpcmVjdGx5KSwgYmVjYXVzZSBJIHdpbGwgbm90IGJl IHJlcXVpcmluZyA2aW40IGluIG15IENFIHJvdXRlcnMuDQoNCklmIHlvdSB3YW50IElFVEYgdG8g cHJvZHVjZSBhIENFIHJvdXRlciBwcm9maWxlIHRoYXQgaXMganVzdCBpbnRlbmRlZCB0byBiZSB1 c2VmdWwgZm9yIHNvbWUgb3BlcmF0b3JzLCBwbGVhc2UgZG9uJ3QgY2FsbCBpdCA3MDg0LWJpcyBv ciBoYXZlIGl0IG9ic29sZXRlIDcwODQuIE1ha2UgaXQgc29tZXRoaW5nIGVsc2UgKG5vdCA3MDg0 LWJpcykuIEEgNzA4NC1iaXMgdGhhdCBtYW5kYXRlcyAoTVVTVCkgYW55IHBhcnRpY3VsYXIgdHJh bnNpdGlvbiB0ZWNobm9sb2d5IG90aGVyIHRoYW4gdGhlIG9uZSBkZXBsb3llZCBpbiBteSBuZXR3 b3JrIGlzIHVuYWNjZXB0YWJsZSB0byBtZS4gQW5kIHRoYXQgaW5jbHVkZXMgbWFuZGF0aW5nIGEg dGVjaG5vbG9neSBub3QgZGVwbG95ZWQgaW4gbXkgbmV0d29yaywganVzdCBiZWNhdXNlIGl0IGlt cGxlbWVudHMgb25lIHRoYXQgaXMgZGVwbG95ZWQuDQoNCkZvciB0aGlzIGRvY3VtZW50IHRvIGJl IGEgdHJ1ZSByZXBsYWNlbWVudCBvZiBSRkMgNzA4NCwgaXQgTVVTVCBOT1QgaW50cm9kdWNlIGFu eSAiTVVTVCIgcmVxdWlyZW1lbnRzIHRoYXQgYW4gb3BlcmF0b3IgY3VycmVudGx5IHVzaW5nIFJG QyA3MDg0IChkaXJlY3RseSBvciBpbmRpcmVjdGx5KSBkb2VzIG5vdCB3YW50IGluIHRoZWlyIENF IHJvdXRlci4NCjcwODQtYmlzIE1VU1QgTk9UIGludGVyZmVyZSB3aXRoLCBwbGFjZSB1bmR1ZSBi dXJkZW4gb24sIG9yIGFkZCBjb3N0IHRvIGV4aXN0aW5nIGRlcGxveW1lbnRzIGFuZCB0aGUgQ0Ug cm91dGVycyB1c2VkIGluIHRob3NlIGV4aXN0aW5nIGRlcGxveW1lbnRzLg0KQmFyYmFyYQ0K From nobody Wed Apr 12 10:52: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 7C0E412EB28 for ; Wed, 12 Apr 2017 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mbh8bs8aRazU for ; Wed, 12 Apr 2017 10:52:49 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE3F1296C6 for ; Wed, 12 Apr 2017 10:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492019563; x=1492624363; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=9NM0waNhecNt+iPYfpSUkACSI 9mr1AjpDu/ieAmUK9c=; b=NvVIvj60gJshvduhOfmBtq6wH+Lx3bYVZEwhoMHJ3 diinFI9fqpE3DFh4Pe6nPR8YNgjcru/PTviUQPI4/tRS3UUWCI7G+lzDrV156Jyd ZOQyTf9kXEpWsxudN/DvdCK17TtK70bg5jAh+dqHkRYfB0/aGvQT69ChcPUAQ81G jc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dE7C2wHJiJS7Lyid6xWFJ70Wgep7Y8Sgd/SPtD6PPPcvxUbWw9ODXxcM1LWB QIEa+iHMJyZqejTAeEhLl8fQifxBoN6SMUNLMuhI2FO4RAR0IWf038dS+ wonkvM7eGtkbJvxsQfFeBVXJk524+zu9TfkWt/MXgxUN9AzwoAwdPw=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 19:52:43 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 19:52:43 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407360.msg for ; Wed, 12 Apr 2017 19:52:43 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407360::k30+8P40J4uT/+6A:0000AVYE X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 19:52:38 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:52:52 -0000 Hi Barbara, Thanks a lot for the explanation. I see your point clearer now. I=E2=80=99ve never intended (once I made the first question on this in the = list and got some inputs, before the first individual ID version), to use M= UST. I used MUST for the 6in4 if 6rd is available, because when you have 6rd sup= port in any router, you can just select 6rd and configure a 6in4 and it wor= ks, but many ISPs don=E2=80=99t even realize it because they can=E2=80=99t = see =E2=80=9Ca menu=E2=80=9D (if using the GUI, just an example), 6in4. So,= my intent was to make it more =E2=80=9Cobvious=E2=80=9D. If you feel that using the work MUST =E2=80=9Cbreaks=E2=80=9D it, I will fi= nd an alternative way to explain it and keep using MAY in this case. Ii think we will be in-sync with that change, unless you spot anything else= in the current version =E2=80=A6 of course happy to heard about that! Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 19:44 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 > What I=E2=80=99m saying is that it makes sense to have a single trans= ition mechanism > (if it is possible, and actually IT IS with 464XLAT) in both kind of = networks. =20 464XLAT is not useful to me. It is not used in any of the networks of m= y employer. Therefore, it will not be requested in any RFP that I help auth= or, nor will it be required (MUST) by any document referenced by an RFP tha= t I help author. If it magically appears in CE routers without getting in m= y way, then I won't mind it being there. =20 -------- snip ----------- =20 > Despite that, I think and it has been said by real operators in this = list a few > months ago, they actually use RFC7048 for their RFQs to vendors, and = they > need support of not just 6rd and DS-lite as we have today. Some of th= em > mention specifically lw4o6, 464XLAT and MAP. =20 RFC 7084 is a mandatory requirement of BBF TR-124, which my company use= s for its RFPs. Since my RFPs will not ever require (MUST) 464XLAT, if 7084= -bis were to make it a MUST requirement, then 7084-bis would be useless to = me as a reference and I would have to ensure 7084-bis was not a requirement= in TR-124. And as someone who's written a lot of CE router RFPs, I know fo= r a fact that it is not at all difficult to say "Req1: Do all mandatory req= uirements of RFC 7084-bis." "Req2: Do 464XLAT as described in RFC 7084-bis.= " =20 To be clear: I do not object to the current language of "SHOULD" for 46= 4XLAT. I object to the proposal that it become "MUST". While I'm at it, I also object to the current language that "If 6rd is = implemented, 6in4 MUST be supported as well." This statement will make the= document useless for me as a RFP reference (directly or indirectly), becau= se I will not be requiring 6in4 in my CE routers. =20 If you want IETF to produce a CE router profile that is just intended t= o be useful for some operators, please don't call it 7084-bis or have it ob= solete 7084. Make it something else (not 7084-bis). A 7084-bis that mandate= s (MUST) any particular transition technology other than the one deployed i= n my network is unacceptable to me. And that includes mandating a technolog= y not deployed in my network, just because it implements one that is deploy= ed. =20 For this document to be a true replacement of RFC 7084, it MUST NOT int= roduce any "MUST" requirements that an operator currently using RFC 7084 (d= irectly or indirectly) does not want in their CE router. 7084-bis MUST NOT interfere with, place undue burden on, or add cost to= existing deployments and the CE routers used in those existing deployments= . Barbara =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 11:02: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 2B6D6129A90 for ; Wed, 12 Apr 2017 11:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyOc5ouRxRNo for ; Wed, 12 Apr 2017 11:02:49 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E9B12EB2E for ; Wed, 12 Apr 2017 11:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492020166; x=1492624966; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=HgbZ3oiljUslPh/rHFbhiwMU1 /6cvTjmG+17Nwau/9g=; b=Xj93TJhWPgjPjfDQDFbBvYCZQiqWv0ArN/KoVk8ig K6YctQjE+SsS69NGk9w+LhJHpQih3x5IyO8hKNV9yR+gEH8IoK4zYd44RqUM32AT 2/MTQRljgfPcYfpfnO/giitJd3BZ8o5FM9fi0u2i4UC3kohut/LFzjzOoWo/uS4L wQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dmYyLmQv5216BPKnefAu+2t8IXs4OvHjYnGJYvaeRdqYL4YBAnimqb8lNAFJ xBJ8Id4zqX/ODvPwZZgvOwjZIPP6yvRbU1CH7APQi7ixY5zO+fwRbf6wQ u33oMm9OjofBitrOjS73iTaIOPaWqQpnvyc8YMytSyy/7B+Kc1Y15M=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 20:02:46 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 20:02:45 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407370.msg for ; Wed, 12 Apr 2017 20:02:44 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407370::S6CfQYJ1XSu+r+6O:0000Lv3k X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 20:02:41 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:02:51 -0000 May be this will make it: Actual text: The CE router MAY support 6in4 functionality. If 6rd is implemented, 6in4 MUST be supported as well. New text: The CE router MAY support 6in4 functionality. If 6rd is implemented, 6in4 is already supported as well, as the underlying protocol/technology=20 is the same, being the only difference, having the mention of =E2=80=9C6in4= =E2=80=9D=20 in the GUI/CLI (just an example) if it is being configured manually, or even stating that in the relevant documentation. In other words,=20 no additional code is required for the support of 6in4 when 6rd is already = supported Saludos, Jordi =20 -----Mensaje original----- De: v6ops en nombre de JORDI PALET MARTINEZ Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 19:52 Para: "v6ops@ietf.org" Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Hi Barbara, =20 Thanks a lot for the explanation. I see your point clearer now. =20 I=E2=80=99ve never intended (once I made the first question on this in = the list and got some inputs, before the first individual ID version), to u= se MUST. =20 I used MUST for the 6in4 if 6rd is available, because when you have 6rd= support in any router, you can just select 6rd and configure a 6in4 and it= works, but many ISPs don=E2=80=99t even realize it because they can=E2=80= =99t see =E2=80=9Ca menu=E2=80=9D (if using the GUI, just an example), 6in4= . So, my intent was to make it more =E2=80=9Cobvious=E2=80=9D. =20 If you feel that using the work MUST =E2=80=9Cbreaks=E2=80=9D it, I wil= l find an alternative way to explain it and keep using MAY in this case. =20 Ii think we will be in-sync with that change, unless you spot anything = else in the current version =E2=80=A6 of course happy to heard about that! =20 Regards, Jordi =20 =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 19:44 Para: "jordi.palet@consulintel.es" , "v6ops= @ietf.org" Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 =20 > What I=E2=80=99m saying is that it makes sense to have a single t= ransition mechanism > (if it is possible, and actually IT IS with 464XLAT) in both kind= of networks. =20 464XLAT is not useful to me. It is not used in any of the networks = of my employer. Therefore, it will not be requested in any RFP that I help = author, nor will it be required (MUST) by any document referenced by an RFP= that I help author. If it magically appears in CE routers without getting = in my way, then I won't mind it being there. =20 -------- snip ----------- =20 > Despite that, I think and it has been said by real operators in t= his list a few > months ago, they actually use RFC7048 for their RFQs to vendors, = and they > need support of not just 6rd and DS-lite as we have today. Some o= f them > mention specifically lw4o6, 464XLAT and MAP. =20 RFC 7084 is a mandatory requirement of BBF TR-124, which my company= uses for its RFPs. Since my RFPs will not ever require (MUST) 464XLAT, if = 7084-bis were to make it a MUST requirement, then 7084-bis would be useless= to me as a reference and I would have to ensure 7084-bis was not a require= ment in TR-124. And as someone who's written a lot of CE router RFPs, I kno= w for a fact that it is not at all difficult to say "Req1: Do all mandatory= requirements of RFC 7084-bis." "Req2: Do 464XLAT as described in RFC 7084-= bis." =20 To be clear: I do not object to the current language of "SHOULD" fo= r 464XLAT. I object to the proposal that it become "MUST". While I'm at it, I also object to the current language that "If 6rd= is implemented, 6in4 MUST be supported as well." This statement will make= the document useless for me as a RFP reference (directly or indirectly), b= ecause I will not be requiring 6in4 in my CE routers. =20 If you want IETF to produce a CE router profile that is just intend= ed to be useful for some operators, please don't call it 7084-bis or have i= t obsolete 7084. Make it something else (not 7084-bis). A 7084-bis that man= dates (MUST) any particular transition technology other than the one deploy= ed in my network is unacceptable to me. And that includes mandating a techn= ology not deployed in my network, just because it implements one that is de= ployed. =20 For this document to be a true replacement of RFC 7084, it MUST NOT= introduce any "MUST" requirements that an operator currently using RFC 708= 4 (directly or indirectly) does not want in their CE router. 7084-bis MUST NOT interfere with, place undue burden on, or add cos= t to existing deployments and the CE routers used in those existing deploym= ents. Barbara =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 11: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 D006B12EB31 for ; Wed, 12 Apr 2017 11:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ZeIktmpPX8uE for ; Wed, 12 Apr 2017 11:24:45 -0700 (PDT) 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 DBEE312EB28 for ; Wed, 12 Apr 2017 11:24:44 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id g2so18439027pge.3 for ; Wed, 12 Apr 2017 11:24:44 -0700 (PDT) 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=Q+HqBitcKurj3SOYBndETvW2g0sc7qJ764XhH1QXaZc=; b=iHOupFrUU53CRTx0JsJUdehnDb7kTWq4ft6spATHi0q434QpsBM26NPXScyyMxUFRY BocF6EtaVwSLWOV2suGCBOGjOGDE6b79zam/JNSUkqI2xt5DafYl2BnPw6gSDZnFUZUa YvfGkzh7TuQHxKYuAfbD/TGZKHCQ3qFCeV5gjnHs3dmI6p0efvGPJBs1NuK8OXdDmBqR GzcdVuzdP57hYjhF6xDdZGeKFvYf9sgw/kRmVgbqObW8SA7dplVIPnH4KFvrHzfBREuA 1ijOHyJkEOAKjbTUGR6sM7GtIsGt9uqIXUCLHH2ADv7vkv4L0jEqvmZ1FwkVu6fETimT UQ3g== 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=Q+HqBitcKurj3SOYBndETvW2g0sc7qJ764XhH1QXaZc=; b=k4R5aNs4wNqn16IU+sHBMXxivecnI7z4l6OZnfIrY3uFI3vA1lp/RIQNAsBJC+HPrG 1Ia1ER+wHG0Wa3xf93DOA8uyz9ilqAAp94HZC54Szta4ZJveJGA5YxJL93EN+RAN90AL MzhFWKGXcRLbQr8vvrnGHznCb0nxkyLvokmRztiHrNvsYTCwKoAVRODLG84JzQBYjAEB YIoovud0O7KAKEtXao7K0224/RgPAUjaJ5zQ5X0+Um53+DQt3P7bo+EYRTMDLOrXnXBr ix0xZum7KoVPvM+yqMEpboP9xvvvzsg/40biS8n8odn1WwOhvW8KYU7XFEFKDCUe/7It K5iA== X-Gm-Message-State: AFeK/H3hGdEYjwzDGDtFXOAx5n325hWC3Ml4ZzslgPOQOo9oHBYJV/PWGfTM0o5NW5ihmw== X-Received: by 10.99.175.7 with SMTP id w7mr69484825pge.170.1492021484408; Wed, 12 Apr 2017 11:24:44 -0700 (PDT) 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 b77sm3970301pfe.39.2017.04.12.11.24.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 11:24:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <6DA0D96E-247C-4A95-906B-AD6EB3275938@consulintel.es> Date: Wed, 12 Apr 2017 11:24:41 -0700 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4EB3C46D-7F2A-4BE1-A30C-C816D6026184@gmail.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <6DA0D96E-247C-4A95-906B-AD6EB3275938@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:24:47 -0000 > On Apr 12, 2017, at 10:44 AM, JORDI PALET MARTINEZ = wrote: >=20 > [Jordi] I disagree here. Adding the actual transition mechanism (all = them) in the v-01 of the document (submitted today) means 0,15% of extra = flash memory=20 no hats Perhaps true. It also means that the vendor (open source is a vendor, = from this perspective) allocates human resources, which cost money, to = write and maintain the software. The software has some probability of = bugs per volume of code, which means that there is a quantifiable = security risk. Now, any business calculates its costs and potential = upside benefits, and figures out how to make money (even open source = developers do, believe me). Asking them to spend money with little real = opportunity to gain saddles them with a cost and a risk with little = upside. It's not the volume and price of the flash; it's the support = costs. If the vendor is looking at 7084 for guidance and saying there is no = market for a given technology, it's because the operators in this = working group collectively said there was no market in their networks. = In the end it isn't about an RFC, it's about a market. No market, no = money, no product. It's that simple. If I'm hearing anything in this discussion, it's that the end game isn't = found in having all of the transition technologies in product. It's to = be found in native deployment that doesn't need the transition = technologies. You might find these two links interesting. One is from the IPv4 Market = Group, and makes prognostications on the value of an IPv4 address; the = other is a public presentation by Swisscom about the traffic = measurements in its network. In both cases, they are asking when they = expect IPv6 usage, whether in traffic or in users, to exceed IPv4, and = as a result when the need for dual stack deployment starts to wind down. = Both, by different avenues, pick 2019 as the turning point, and Swisscom = suggests that by 2024 it might not have enough IPv4 traffic in its = network to justify having IPv4 enabled - even in an overlay. The issue of transition mechanisms has to do with networks being = predominantly IPv4 and having to reach them using IPv6. Both are saying = that there is a light at the end of that particular tunnel, and it's not = an oncoming train. http://ipv4marketgroup.com/q42016-update/ = http://www.ipv6conference.ch/wp-content/uploads/2015/06/B10-Swisscom-Statu= s_Roadmap_and_Outlook_IPv6.pdf= From nobody Wed Apr 12 11:52: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 6575812EB3E for ; Wed, 12 Apr 2017 11:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpKzKIA3fcTj for ; Wed, 12 Apr 2017 11:52:47 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0F412955F for ; Wed, 12 Apr 2017 11:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492023163; x=1492627963; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=Hi+3czE1dOc9sTG3gLF7Xk1QB gFCw288QMIE3wOZAqM=; b=b5xT61cRj+TGxU3lNJwzYpZmzvhkEaURuoxuaDXEl ETvXRc5heLgKiWCbJ7KoNQMSqRPn+aNvl2/BCvx1mOkmuKLomolByiZCSzJ4m1/v i2TTv6wh4Yd/hohBXUjjwVrICWEYD3gn+fL3gRygaMvBQSSJvyc0ONU2v7Lb3nBC ko= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=lH5+xg79aIehlhORenU6Z1JGpq+znp2n44UjWPQXwQ6P4RNN051LkvTk+G7+ opXvuv5xP06fP0e6iFtyjfh0h/rO5rHkgzG4nA/0ygfghqZQWYuV02yMC ZoEyZzgfodHur5hwaeCMUnXKjL7V/baZvm5Sg6ajRzQtlNFlWJNd4M=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 20:52:43 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 20:52:41 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407396.msg for ; Wed, 12 Apr 2017 20:52:41 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407396::oxzdMHb/snD2H6UF:00001Pjp X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 20:52:37 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <6DA0D96E-247C-4A95-906B-AD6EB3275938@consulintel.es> <4EB3C46D-7F2A-4BE1-A30C-C816D6026184@gmail.com> In-Reply-To: <4EB3C46D-7F2A-4BE1-A30C-C816D6026184@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:52:50 -0000 > On Apr 12, 2017, at 10:44 AM, JORDI PALET MARTINEZ wrote: >=20 > [Jordi] I disagree here. Adding the actual transition mechanism (all = them) in the v-01 of the document (submitted today) means 0,15% of extra fl= ash memory=20 =20 no hats =20 Perhaps true. It also means that the vendor (open source is a vendor, f= rom this perspective) allocates human resources, which cost money, to write= and maintain the software. The software has some probability of bugs per v= olume of code, which means that there is a quantifiable security risk. Now,= any business calculates its costs and potential upside benefits, and figur= es out how to make money (even open source developers do, believe me). Aski= ng them to spend money with little real opportunity to gain saddles them wi= th a cost and a risk with little upside. It's not the volume and price of t= he flash; it's the support costs. [Jordi] Not really that much cost: - Code is available in source, actually there are several implementations. - Vendor can choose one source, integrate it with his own code (being linux= should not be more than a couple of hours). - Code has been tested already, so yes, still some =E2=80=9Cintegration tes= ting=E2=80=9D, again should not be a big issue. - Yes, more code more bugs, but if it is Linux, it is somehow =E2=80=9Cself= -maintained=E2=80=9D from the =E2=80=9Csource=E2=80=9D. =E2=87=92 What I know from several vendors of those CPEs that I=E2=80=99ve = talked to, is that they basically take the code of OpenWRT (or others), and= personalize the drivers for different chipsets and the GUI. So, adding som= ething that is already done by the community is not the problem at all. =20 If the vendor is looking at 7084 for guidance and saying there is no ma= rket for a given technology, it's because the operators in this working gro= up collectively said there was no market in their networks. In the end it i= sn't about an RFC, it's about a market. No market, no money, no product. It= 's that simple. [Jordi] I think is working in both ways. Vendors look at RFC7084 and integr= ate their boxes. ISPs talk to vendors and use the RFC7084 to push vendors. = But if vendors don=E2=80=99t have a push for a specific technology, because= ISPs get an =E2=80=9Cinitial=E2=80=9D =E2=80=9Cisn=E2=80=99t in the RFC708= 4=E2=80=9D, then it never gets done. Also, once a couple of =E2=80=9Cbig=E2= =80=9D retail (which are the same as ISP CE, but sometime OEM branded) vend= ors have support for the =E2=80=9Cnew=E2=80=9D transition mechs, the others= need to do the same, just a matter of competition. Right now, there are 2-= 3 vendors, but they are expensive and they don=E2=80=99t even consider orde= rs for 10.000 units or are too expensive for many markets. I tried it with = several of them =E2=80=A6 working for customers. Also, I understand that mo= st of the vendors could update the actual products in the market with new f= irmware, but they don=E2=80=99t do that, because it is better to sell new p= roducts to the same ISPs =E2=80=A6 That=E2=80=99s why I=E2=80=99ve been for= ced to use in several trials OpenWRT, and also a couple of ISPs actually us= ing it for commercial deployment, reflashing existing =E2=80=9Cretail=E2=80= =9D products. =20 If I'm hearing anything in this discussion, it's that the end game isn'= t found in having all of the transition technologies in product. It's to be= found in native deployment that doesn't need the transition technologies. [Jordi] Fully agree, but today you can=E2=80=99t tell any ISP that you=E2= =80=99re going to deliver IPv6 only CPEs, because customers will not need t= o access any IPv4 resource in remote Internet or even in their own local ne= tworks. Any ISP trying to sell =E2=80=9CIPv6-only in the LAN and in the WAN= =E2=80=9D services, will lose 99% of his customers. =20 You might find these two links interesting. One is from the IPv4 Market= Group, and makes prognostications on the value of an IPv4 address; the oth= er is a public presentation by Swisscom about the traffic measurements in i= ts network. In both cases, they are asking when they expect IPv6 usage, whe= ther in traffic or in users, to exceed IPv4, and as a result when the need = for dual stack deployment starts to wind down. Both, by different avenues, = pick 2019 as the turning point, and Swisscom suggests that by 2024 it might= not have enough IPv4 traffic in its network to justify having IPv4 enabled= - even in an overlay. =20 The issue of transition mechanisms has to do with networks being predom= inantly IPv4 and having to reach them using IPv6. Both are saying that ther= e is a light at the end of that particular tunnel, and it's not an oncoming= train. =20 http://ipv4marketgroup.com/q42016-update/ http://www.ipv6conference.ch/wp-content/uploads/2015/06/B10-Swisscom-St= atus_Roadmap_and_Outlook_IPv6.pdf =20 [Jordi] I already knew the 2nd one, however is a bit older (mid-2015) so I = believe the picture changed a lot, and there is much more IPv6 traffic and = I=E2=80=99m even more optimistic that it will be predomintanly-IPv6 sooner = than any expectation, but still customers will not throw away their local I= Pv4-only devices (cameras, smartTVs, etc.), and there will be at least 4-5 = more years with a considerable amount of IPv4-only sites. Probably 2020-21 = it may be possible to start considering disabling IPv4 traffic (in my opini= on) but still think that the support of IPv4-only local devices may take a = longer time. How you convince folks to buy a new smartTV in 4-5 years, that= they have purchased today (at least in Spain they still come w/o IPv6 supp= ort), unless the vendor upgrades the firmware? What about all kind of devic= es (IP cameras, wifi doorbell, cleaning robot, etc.), that today come with = IPv4-only ? I think we may see LAN-IPv4 traffic for a longer period, unfort= unately, and this is the reason the CPE must support it and some of those = =E2=80=9Ctraffic-flows=E2=80=9D may require access to IPv4 remote sites (cl= oud services they are based on). ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 11:55: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 EA58C12EB3F for ; Wed, 12 Apr 2017 11:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 0YaRoc9MPLWz for ; Wed, 12 Apr 2017 11:55:24 -0700 (PDT) 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 90A9812EB39 for ; Wed, 12 Apr 2017 11:55:24 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3CIj7rw029712; Wed, 12 Apr 2017 14:55:17 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 29sqhex53v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 14:55:17 -0400 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 v3CItFCt005434; Wed, 12 Apr 2017 14:55:16 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3CIt9dQ005384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 14:55:10 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 18:54:59 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 14:54:58 -0400 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgIAAMIOAgAAEPYD//76fsIAAUwEA///ZnICAAFQ9AIAAAs+A///H2XA= Date: Wed, 12 Apr 2017 18:54:58 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB19E7B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.164.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_14:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704120154 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:55:26 -0000 DQo+IE1heSBiZSB0aGlzIHdpbGwgbWFrZSBpdDoNCj4gDQo+IEFjdHVhbCB0ZXh0Og0KPiBUaGUg Q0Ugcm91dGVyIE1BWSBzdXBwb3J0IDZpbjQgZnVuY3Rpb25hbGl0eS4gIElmIDZyZCBpcyBpbXBs ZW1lbnRlZCwNCj4gNmluNCBNVVNUIGJlIHN1cHBvcnRlZCBhcyB3ZWxsLg0KPiANCj4gDQo+IE5l dyB0ZXh0Og0KPiBUaGUgQ0Ugcm91dGVyIE1BWSBzdXBwb3J0IDZpbjQgZnVuY3Rpb25hbGl0eS4g IElmIDZyZCBpcyBpbXBsZW1lbnRlZCwNCj4gNmluNCBpcyBhbHJlYWR5IHN1cHBvcnRlZCBhcyB3 ZWxsLCBhcyB0aGUgdW5kZXJseWluZyBwcm90b2NvbC90ZWNobm9sb2d5IGlzDQo+IHRoZSBzYW1l LCBiZWluZyB0aGUgb25seSBkaWZmZXJlbmNlLCBoYXZpbmcgdGhlIG1lbnRpb24gb2Yg4oCcNmlu NOKAnQ0KPiBpbiB0aGUgR1VJL0NMSSAoanVzdCBhbiBleGFtcGxlKSBpZiBpdCBpcyBiZWluZyBj b25maWd1cmVkIG1hbnVhbGx5LCBvciBldmVuDQo+IHN0YXRpbmcgdGhhdCBpbiB0aGUgcmVsZXZh bnQgZG9jdW1lbnRhdGlvbi4gSW4gb3RoZXIgd29yZHMsIG5vIGFkZGl0aW9uYWwNCj4gY29kZSBp cyByZXF1aXJlZCBmb3IgdGhlIHN1cHBvcnQgb2YgNmluNCB3aGVuIDZyZCBpcyBhbHJlYWR5IHN1 cHBvcnRlZA0KDQpOby4gDQpJJ20gZmluZSBzdWdnZXN0aW5nIHRoYXQgUkZDIDU1NjkgTUFZIGJl IHN1cHBvcnRlZC4gDQpUaGlzIFJGQyBpcyBjb21tb25seSByZWZlcnJlZCB0byBhcyAiNnJkIi4g QW55b25lIHdobyB3YW50cyB0byBoYXZlIFJGQyA1NTY5IGZ1bmN0aW9uYWxpdHkgcmVmZXJyZWQg dG8gYnkgYW5vdGhlciBuYW1lIGluIHRoZWlyIEdVSSBvciBvdGhlciB1c2VyIGludGVyZmFjZSBp cyBmcmVlIHRvIGRvIHNvLiBVSSBuYW1pbmcsIGNoYXJhY3RlciBzZXQsIGFuZCBsYW5ndWFnZSBh cmUgbm90IGluIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNClJGQyA1NTY5IGRvZXMgbm90IHJl ZmVyZW5jZSBSRkMgNDIxMy4gSXQgaGFzIG5vIGRlcGVuZGVuY3kgb24gUkZDIDQyMTMgYW5kIGlz IG5vdCB0aGUgc2FtZSBhcyBSRkMgNDIxMy4gVGhlc2UgYXJlIDIgZGlzdGluY3QgYW5kIHNlcGFy YXRlIFJGQ3MuDQpJIHdpbGwgbm90IHN1cHBvcnQgYW55IGxpbmthZ2Ugb2YgdGhlc2UgMiBSRkNz IGluIGEgNzA4NC1iaXMuDQpUaGlzIHdvdWxkIGltcGFjdCBteSBjb21wYW55IGFuZCB0aGUgcmVx dWlyZW1lbnRzIHdlIHVzZSBpbiBDRSByb3V0ZXIgcHJvY3VyZW1lbnQgZGlyZWN0bHkgKG1ha2lu ZyBpdCBpbXBvc3NpYmxlIGZvciB1cyB0byB1c2UgNzA4NC1iaXMgYXMgYSByZWZlcmVuY2UgZGly ZWN0bHkgb3IgdGhyb3VnaCBCQkYgVFItMTI0KS4NCg0KSWYgdGhlcmUncyBzb21lb25lIHdobyB3 YW50cyBSRkMgNDIxMywgbGV0IHRoZW0ganVzdGlmeSBpdCB3aXRob3V0IHRyeWluZyB0byBhZGQg ZXhwZW5zZSBhbmQgY29tcGxleGl0eSB0byBteSBDRSByb3V0ZXJzLg0KQmFyYmFyYQ0K From nobody Wed Apr 12 12:02: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 A8680127843 for ; Wed, 12 Apr 2017 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCqnvoJCf9nb for ; Wed, 12 Apr 2017 12:02:49 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA3212EBA0 for ; Wed, 12 Apr 2017 12:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492023707; x=1492628507; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=ClszbwibB5xA+HnPDSTKkK1cc Ia7ngxGs7r34Jh4qUg=; b=kqMeIY3vQRuABMM5HYYVT8lZA+NWBN32TO0lu0csv UglSf5bq+0/cZL5qnyDxy4pmaOBI/+pZLBgyPIUiIrE8x2S2DCy72YcUPDGlQOe/ qrOMMt25zac70u9PFNrmpih2/jzEayBBFvYhBGsdDtUGuLvJRmxU161/ih7Pk3+Z Dw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ZI9km+ZD8LvKEtcRGyX5Tc95Rtz42idVv15koMWf7Odgf5Bi+wcJoo+MVEPY KHq+ebtDV1KYGkeLO4R7XFNeCNeJ4BZRAHQYdI35puadAaGjWlbTjPGLp waci1oOgHH8Am58+MERpWzq9bUd3SX19jKhJn9wFvstdnf/U5tjMac=; X-MDAV-Processed: mail.consulintel.es, Wed, 12 Apr 2017 21:01:47 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 12 Apr 2017 21:01:47 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407407.msg for ; Wed, 12 Apr 2017 21:01:47 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170412:md50005407407::bT3ClCl2xVs855hP:00001eY5 X-Return-Path: prvs=127550c264=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 12 Apr 2017 21:01:46 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <562F273A-4B90-43D9-82E9-5FC2DD437261@consulintel.es> Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19E7B@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB19E7B@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:02:50 -0000 Hi Barbara, RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is referr= ing to RFC2893 (6in4, protocol 41), which has been updated by RFC4213. We are talking about the same. If you have a 6to4 router at home, you can just try. Create a HE tunnel bro= ker, and input manually the parameters even if your router only shows a 6rd= in the GUI. It works. Believe me. Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 20:54 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 =20 > May be this will make it: >=20 > Actual text: > The CE router MAY support 6in4 functionality. If 6rd is implemented, > 6in4 MUST be supported as well. >=20 >=20 > New text: > The CE router MAY support 6in4 functionality. If 6rd is implemented, > 6in4 is already supported as well, as the underlying protocol/technol= ogy is > the same, being the only difference, having the mention of =E2=80=9C6= in4=E2=80=9D > in the GUI/CLI (just an example) if it is being configured manually, = or even > stating that in the relevant documentation. In other words, no additi= onal > code is required for the support of 6in4 when 6rd is already supporte= d =20 No.=20 I'm fine suggesting that RFC 5569 MAY be supported.=20 This RFC is commonly referred to as "6rd". Anyone who wants to have RFC= 5569 functionality referred to by another name in their GUI or other user = interface is free to do so. UI naming, character set, and language are not = in scope of this document. =20 RFC 5569 does not reference RFC 4213. It has no dependency on RFC 4213 = and is not the same as RFC 4213. These are 2 distinct and separate RFCs. I will not support any linkage of these 2 RFCs in a 7084-bis. This would impact my company and the requirements we use in CE router p= rocurement directly (making it impossible for us to use 7084-bis as a refer= ence directly or through BBF TR-124). =20 If there's someone who wants RFC 4213, let them justify it without tryi= ng to add expense and complexity to my CE routers. Barbara =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 12 12:23: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 7C8D4129571 for ; Wed, 12 Apr 2017 12:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 1zhRqLpfeFLT for ; Wed, 12 Apr 2017 12:23:20 -0700 (PDT) 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 25802126557 for ; Wed, 12 Apr 2017 12:23:20 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id o126so18041009pfb.3 for ; Wed, 12 Apr 2017 12:23:20 -0700 (PDT) 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=7eOwZ2dyVLdIHoTGNfwTQHoDM+CuWy8jx6JNSTEPgIM=; b=Qjxl8uyNJjWYqiQjTxSdlaN7j1gUlFiu7klGbRpB5ft/jZvYQ30vwGezgvqKZpcYIu SE3jyiXaBmJ1AQBJau7+5hfFSEKbqzy57/T/H5wrqfxnz/xQXHqMZcqgNCa3/72ZX+nz Nks+kzl7fiLK96d3GmXOdEHypJk3bNY2Uc3CQvTedyDn9TOjbkAXDBcv9gTqxBeZrtFV ye8qce1c6XiO0cVo0ZRETMwT18Y4t2xSQ/JkHFCrTpwRRdjAhprreTC5DC6tloS1TdQ0 q4i110jAy/Z3JQecuLbnCXzTfbAk0FIU7VkEruH4rn6aDEEyEFBg7wKU7/beEQURYbdk qXxQ== 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=7eOwZ2dyVLdIHoTGNfwTQHoDM+CuWy8jx6JNSTEPgIM=; b=oocDZEDLQYAyT9cDAFwpx8txa81Zi4ptmeWWGqN4QpbZWKoy6eYpDBP/lCAo9BS5Il Z6p1ZMO4gJM8chPYpXUPuJHEMlP0pCgvvrsu3YLckYmvQKckvb44oEyPalHAJObk2jEP yu2DJMHMpzoWMyEHotz2QsqjT4B9AjU+JsUnkdaZVC7SPIoZbkETAyNJNjUkjzECbYFB mwh2vXnCG+uj+1DfLneASH5Tp1iAzyBBzVH8GUZjkviMsbVfmg6ZiWHQc+68zi1Bal18 lOZkhkkaCt/nBAlI8Rju4FcmLvdAtaI2EDzkhUT94FsPfzWIMDdP1nrSD4u9O5CTIJSp ZSfA== X-Gm-Message-State: AN3rC/4nkH4EM8CIZjwfXL8xrjFb1Mbit3WFVQDWFMN/3DBsXa24NB52CjMm1llxDo1a1g== X-Received: by 10.84.254.4 with SMTP id b4mr9299250plm.64.1492024999805; Wed, 12 Apr 2017 12:23:19 -0700 (PDT) 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 s21sm38223189pgg.65.2017.04.12.12.23.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 12:23:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB19E7B@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 12 Apr 2017 12:23:17 -0700 Cc: JORDI PALET MARTINEZ , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19E7B@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:23:21 -0000 > On Apr 12, 2017, at 11:54 AM, STARK, BARBARA H wrote: >=20 > If there's someone who wants RFC 4213, let them justify it without = trying to add expense and complexity to my CE routers. Aka "dual stack" and "Configured tunneling of IPv6 over IPv4", in the = words of the RFC. https://tools.ietf.org/html/rfc4213 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. = Nordmark, R. Gilligan. October 2005. (Format: TXT=3D58575 bytes) (Obsoletes RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4213) I think you will find dual stack pretty widely supported. SIXXS depended = on the ability to configure tunnels through their tunnel broker, and = HE's tunnel broker continues to. I suspect you will find IPv6/IPv4 = tunnels supported on a variety of routers. I also suspect that your = IPv6-capable residential customers won't need them. For them, RFC 4213 = =3D=3D Dual Stack. If I were to whine about tunnels, it would be about the routing and = security issues. RFCs 6169, 6324, 7059, a recent CCDCOE article, and so = on.= From nobody Wed Apr 12 13:34: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 8AC9F129564 for ; Wed, 12 Apr 2017 13:34:08 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 CbdsVHbkZe9Z for ; Wed, 12 Apr 2017 13:34:07 -0700 (PDT) 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 7853312EB38 for ; Wed, 12 Apr 2017 13:34:04 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id o126so18745582pfb.3 for ; Wed, 12 Apr 2017 13:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=MklIcxZI3SKbkSRtVLX3soaXhfQaYWTHi1lBKq0lZCo=; b=V6TJiJP41SUY2cuxtklyACh3MS+/OEtIGuNal91u5lGahwXQYxuStcCbyJaqDe9ZP+ YOF0XIUXJzSLiT1R42CZN3hkDTROYLG70bK8+Hst1uiRs4ocoqv8IUBp1QWudP6WtNdd Mg/fjTjWS25bLxtafvlb1GGLj2H4LLd/CIkV5HbsuAjlxD5ETWtQJOHIIPA10yrZSyUo gPuefPgE0HMIoJloRBLMo45HATbE2zzy1XIEUsPembifWDvmAbqkTJi32i4X0OLD5Y2C 3NWEo7TBLIlc6XC1/IIS7U+GTD8L+RX5Qmg+qPUnIeRIjnvuNvjW32R7tb5Yxuyimf9Y sznw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=MklIcxZI3SKbkSRtVLX3soaXhfQaYWTHi1lBKq0lZCo=; b=dvMyg0NO59OUwvmBSyZd2r6dusN6/srDKxRbNO2xnY/CpyiSAIlosFElNTVVb79C74 76bubaj6DRev5mUEJ1ZrGtj6NcDswhQ7dTAocw9+hIoSEeRBNYBS2tNjF2xX7qBNGzNz fQ63xKFsXcZ6bAaAAvNTb6fFn6v8yJ4+FC9suwnKbHZG+MUYm+Og1CguagVM6jWF/Cg/ iGg/AYrkwa0g+OFWBv1A2GX71LjipRlVW2VMGTofPfhBJDzwgOQKZezsMbFYnuwizVmp 4YwVDgkLovLu2ViE6/i3+mvHY7xmw946eo7Jhcd05AO6OblXHvOoAJRUdJVKRTNTioUT 5ypw== X-Gm-Message-State: AFeK/H0g8t95ZRgNr2Y6UlzwgZpnoKZ5rGKCYG4+W+CVN6A8jaould5Sze8rBjVNbi4/zaKo X-Received: by 10.98.1.213 with SMTP id 204mr69487280pfb.51.1492029243761; Wed, 12 Apr 2017 13:34:03 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id e76sm38096510pfk.75.2017.04.12.13.34.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 13:34:03 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_89C2D7F1-ABD2-4907-90B2-537C4E3E0135" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 12 Apr 2017 11:50:36 -0700 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "v6ops@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:34:09 -0000 --Apple-Mail=_89C2D7F1-ABD2-4907-90B2-537C4E3E0135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 12, 2017, at 10:22, Fred Baker wrote: >=20 > A data point of interest: = https://ccdcoe.org/multimedia/hedgehog-fog-creating-and-detecting-ipv6-tra= nsition-mechanism-based-information.html = is being flagged in the media = as a reason to not deploy IPv6 - transition technologies that use = tunnels apparently bypass intrusion detection technologies. After seeing Fig 3. on p. 6 of that paper, I don=E2=80=99t think I can = offer a sensible response to such arguments in any form other than a = sarcastic quip embedded in an image macro. --james woodyatt > --Apple-Mail=_89C2D7F1-ABD2-4907-90B2-537C4E3E0135 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 12, 2017, at 10:22, Fred Baker <fredbaker.ietf@gmail.com> wrote:

A data point of interest: https://ccdcoe.org/multimedia/hedgehog-fog-creating-and-detecti= ng-ipv6-transition-mechanism-based-information.html is being flagged in the = media as a reason to not deploy IPv6 - transition technologies that use = tunnels apparently bypass intrusion detection = technologies.

After seeing Fig 3. on p. 6 of that = paper, I don=E2=80=99t think I can offer a sensible response to such = arguments in any form other than a sarcastic quip embedded in an image = macro.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_89C2D7F1-ABD2-4907-90B2-537C4E3E0135-- From nobody Wed Apr 12 13:39: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 C7657129A9D for ; Wed, 12 Apr 2017 13:39:13 -0700 (PDT) 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=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 3vnKz_SqALPp for ; Wed, 12 Apr 2017 13:39:12 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 70B85129ABD for ; Wed, 12 Apr 2017 13:39:12 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 12 Apr 2017 20:39:12 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id DFB4DD788B; Wed, 12 Apr 2017 13:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=k9vS81axmMYPMZvEK8rvvwzLMSY=; b= YNAWRfPrEEcXRmrAK+e/jKnGKOqrUM8BP9DjpVML2GaIA5nWx/7nfq7HRZAB+JnQ FqswtqWaYqFaXsYa5w9OpvqPCuNjcYNBNqfR20RhfA+RLedmHCGTjHDP3ddtT66G 7iXY9+qA1/GaDHkYDH/eQYH8P08OgoBJAlZzH4cRCi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=mdfoFE1YD4mwlzy0ffTtpCO jOIZkv2n68SPKPxv8HpOg0eRghqVZuVTmTBx4io2Zz+c65n8yCmD2XWr2WVJLDjv GNOp1cEohZyfEPh1OfteJjim+PSN77EkuH7nr9rMIqIglYVsihUqCShv5H+lf56+ bYgrK3vjqgCZbGwhz42w= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 ABAA0D788D; Wed, 12 Apr 2017 13:39:11 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 29AAFA9A0F3D; Wed, 12 Apr 2017 22:39:10 +0200 (CEST) From: otroan@employees.org Message-Id: <9608510E-79BC-44A5-8D91-F665B72765F5@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A323EC8C-F5A8-4442-B0E0-43AA8A08234C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 22:39:08 +0200 In-Reply-To: <562F273A-4B90-43D9-82E9-5FC2DD437261@consulintel.es> Cc: "v6ops@ietf.org" To: jordi.palet@consulintel.es References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19E7B@GAALPA1MSGUSRBF.ITServices.sbc.com> <562F273A-4B90-43D9-82E9-5FC2DD437261@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:39:14 -0000 --Apple-Mail=_A323EC8C-F5A8-4442-B0E0-43AA8A08234C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jordi, > If you have a 6to4 router at home, you can just try. Create a HE = tunnel broker, and input manually the parameters even if your router = only shows a 6rd in the GUI. It works. Believe me. This is the IETF. There are other implementations than Linux. If there wasn't you didn't need a standard. Cheers, Ole --Apple-Mail=_A323EC8C-F5A8-4442-B0E0-43AA8A08234C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY7pBsAAoJEL7aWKiYQt92l8wP/ixdx45IAqd/5ZFxvUsOp3nd jwEtH6rNwRFyuVSWTIQaNldFF0ppV4JdXUbQ25Ii3+ASYS1hB7thLKNVlgtfh+PJ 38GvJOau4c7FPwZKedCJb1TBNdUxY1ZDZazp4z2QpJnFdg6wLgVW0DeM0432NwtU cwK6Hn7zETk/xgYbfgQyuOf7Mx1fi0Rwo+uJVwjuGfOi6JQzXafabMH0odI5+wdd GIZFXvi/O7YvVRyrIf4GWk4cnvb36bE/RngcNH+a2gtRqy4CVGW75uyFFTXO1CcV o4sqi6JJWAg1OQ2ZVspGMshzYC4P0eQCh3dV8Rqo3aZxs7TRJ0T0t9SFt2Vl3ueR KpjXWCM02wenc0y+QndvulUei6fn5QAYUWU21GQwTjSzyn3PiEox8wmvx9uf0jWg uAxyDBVzebH8393fUJyaUzK5WINmHJlG7SUNzmKYpFKDkE1nLBI2oWpPI7kjSSfT 0xgdmhYchxtsRs37e/uYc+Eb7sxwI2+muBF7T/bwAmgBnmnscBVyVRCLDx/gNYks zjuONGjXEOCgVRXxQDCvg56QAkTXu/iHMiav3kAFpHOsVgxTvaMKOPtV2EyKsTaA BJMeHu2fd21g6I+AyMikWL+DdiLxMoiHERE6HjoGAHuLD7KSKUQ9Ns4+UFeb3EVn dzwTEwpkRlv0ieyhed4/ =JLPG -----END PGP SIGNATURE----- --Apple-Mail=_A323EC8C-F5A8-4442-B0E0-43AA8A08234C-- From nobody Wed Apr 12 14:28: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 4892812EB50 for ; Wed, 12 Apr 2017 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 D5ODddbOGZiR for ; Wed, 12 Apr 2017 14:28:45 -0700 (PDT) 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 E8FA3120227 for ; Wed, 12 Apr 2017 14:28:44 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3CJFRwu034313; Wed, 12 Apr 2017 15:21:06 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 29st16th4p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 15:21:05 -0400 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 v3CJL4Lr009950; Wed, 12 Apr 2017 15:21:05 -0400 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 v3CJL1dl009903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 15:21:01 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 19:20:41 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 15:20:41 -0400 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgIAAMIOAgAAEPYD//76fsIAAUwEA///ZnICAAFQ9AIAAAs+A///H2XAACRUwAAAIFQoQ Date: Wed, 12 Apr 2017 19:20:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB19F62@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19E7B@GAALPA1MSGUSRBF.ITServices.sbc.com> <562F273A-4B90-43D9-82E9-5FC2DD437261@consulintel.es> In-Reply-To: <562F273A-4B90-43D9-82E9-5FC2DD437261@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.164.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_15:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704120157 Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:28:46 -0000 DQo+IFJGQzU1NjkgKDZyZCkgaXMgcmVmZXJyaW5nIHRvIDZ0bzQgZW5jYXBzdWxhdGlvbiAoUkZD MzA2NSksIHdoaWNoIGlzIHJlZmVycmluZw0KPiB0byBSRkMyODkzICg2aW40LCBwcm90b2NvbCA0 MSksIHdoaWNoIGhhcyBiZWVuIHVwZGF0ZWQgYnkgUkZDNDIxMy4NCj4gDQo+IFdlIGFyZSB0YWxr aW5nIGFib3V0IHRoZSBzYW1lLg0KPiANCj4gSWYgeW91IGhhdmUgYSA2dG80IHJvdXRlciBhdCBo b21lLCB5b3UgY2FuIGp1c3QgdHJ5LiBDcmVhdGUgYSBIRSB0dW5uZWwNCj4gYnJva2VyLCBhbmQg aW5wdXQgbWFudWFsbHkgdGhlIHBhcmFtZXRlcnMgZXZlbiBpZiB5b3VyIHJvdXRlciBvbmx5IHNo b3dzIGENCj4gNnJkIGluIHRoZSBHVUkuIEl0IHdvcmtzLiBCZWxpZXZlIG1lLg0KDQpXaGF0IEkg dGhpbmsgSSBoZWFyIHlvdSBzYXlpbmcgaXM6DQpJZiBhIENFIHJvdXRlciBpbXBsZW1lbnRzIFJG QyA1NTY5LCB0aGVuIHRoZSBhY2Nlc3MgbmV0d29yayBjYW4gdXNlIHRoZSBDRSByb3V0ZXIncyBS RkMgNTU2OSBmdW5jdGlvbmFsaXR5IHRvIGRlbGl2ZXIgYSBSRkMgNDIxMyB0dW5uZWwuDQoNCklm IHRoaXMgaXMgY29ycmVjdCwgdGhlbiB3aGF0IEknbSBzYXlpbmcgaXMgSSB3aWxsIG5vdCBzdXBw b3J0IGEgcmVxdWlyZW1lbnQgdGhhdCBkaWN0YXRlcyBJIGFuZCBteSBDRSByb3V0ZXIgdmVuZG9y cyAod2hvIGltcGxlbWVudCA2cmQpIE1VU1QgbG9vayBhdCBvciByZWFkICBvciBzY291ciBSRkMg NDIxMyB0byBzZWUgaWYgdGhlcmUgaXMgc29tZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50IHRoYXQg UkZDIDQyMTMgaW50cm9kdWNlcywgYmVjYXVzZSB0aGV5IGFyZSBub3cgcmVxdWlyZWQgdG8gYmUg Y29tcGxpYW50IHdpdGggaXQuIFRoZSByZWZlcmVuY2UgdG8gUkZDIDU1NjkgU0hBTEwgYmUgc3Vm ZmljaWVudCB0byBkaXJlY3QgaW1wbGVtZW50YXRpb24gb2YgdGhlIGZ1bmN0aW9uYWxpdHksIHdp dGggbm8gcmVmZXJlbmNlIHRvIFJGQyA0MjEzLg0KVUkgcmVxdWlyZW1lbnRzIGFyZSBvdXQgb2Yg c2NvcGUuDQpCYXJiYXJhDQo= From nobody Wed Apr 12 15:54:33 2017 Return-Path: <7riw77@gmail.com> 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 945E712EB69 for ; Wed, 12 Apr 2017 15:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 Kpydj35H4Rke for ; Wed, 12 Apr 2017 15:54:18 -0700 (PDT) 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 669D4127A91 for ; Wed, 12 Apr 2017 15:54:17 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id v207so3144247ywc.2 for ; Wed, 12 Apr 2017 15:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=49Ln639qmJOmz/8LqE7UtqED2HpE4LS74xr8bZ4hRKM=; b=USpB2ZmayJlCMysdhfNn+a3OK/XNwpDjjaOqSF83WnN7/pkBIJ+O2NTtvN6x9ElSe5 PczhSJgqLedm7Bp7NlN5Odis08Vi793DFbXmFC6YN5LHNCuKzTqP6LZ9QH0kNF5bzUL3 3Iqf2cFuXdInVN6u5wJzK6PfAK6zQLAol5gw8/x8whuagCr9F6upOISep8CmaASwRpt0 uvSpVJeUyN91LplevbxynhxGurL0MbEjZp2kin1zzIaAkwwR6LS2jQoIrz8YGlLL5lca I+V3dH5tqodoH3ZlU2bJvmpWNkb/gu4BfFFVEKQvV7/0GwDsve5Fcp27x32iNLhV2QP4 WMAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=49Ln639qmJOmz/8LqE7UtqED2HpE4LS74xr8bZ4hRKM=; b=TfHGLgPmGNQzOTia1KqV2pAPj6YBUEc9//Rr0XqALwlmoXQJztSrn9YjXGk4Y4alpn H1qABltxOrQsF/r6jkydSNQUiXFheB80KnHR3KNLu3idhcsBfZroAWml8/R1gLOLxSKT +Mt8Br74Lh48rZmeO/4lxiSmhlCo3uZQVCsa5pDYxdPIP6HIHv5z97t6GuZCYPizhPXt yhKG44w51XyFtOFEPfWmIdCaPktHdHcsuetyoetArz0siOho5tjtRl1MMKn41Bkv0f8B 9m9eJF+M7SHmGR8YqwifzbG7oxLjFvg46sHI07unrPGQXR74KdC8qOLMAAcoxCaMLkqB 15pw== X-Gm-Message-State: AN3rC/4pqcjFpYGp2QNJ1OjCoecq3Vt14G7miSfikXXNZcZu4OG+YRU6 1cjU3yNkA9qa1A== X-Received: by 10.129.130.195 with SMTP id s186mr97858ywf.52.1492037656716; Wed, 12 Apr 2017 15:54:16 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id s4sm7847069ywj.47.2017.04.12.15.54.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 15:54:16 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Brian E Carpenter'" , "'IPv6 Operations'" References: <483cf623-3ac3-2a14-6864-05c8626864cb@gmail.com> In-Reply-To: <483cf623-3ac3-2a14-6864-05c8626864cb@gmail.com> Date: Wed, 12 Apr 2017 18:54:15 -0400 Message-ID: <032d01d2b3df$b6262dc0$22728940$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKNXGUZxyb1xaMO5fe0MGFXkpvciKBNBW1A Content-Language: en-us Archived-At: Subject: Re: [v6ops] Scope question about draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 22:54:20 -0000 > I see nothing, not even placeholders, in the draft about router = support for > on-link hosts, e.g. the requirements to generate RAs, PIOs, redirects = etc.=20 Are these covered in other drafts? I'm okay with adding them -- RAs and = redirects seem simple enough. If the WG ends up deciding to include = DHCPv6 as a must or should implement, it seems like PIOs would be = included there? > and > the ever popular topic of RDNSS. I'm staying out of this slugfest. When the WG reaches some sort of = consensus, I'm certain someone will tell me what should be in the draft. =F0=9F=98=8A /r=20 From nobody Thu Apr 13 00:49: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 461F312EC90 for ; Thu, 13 Apr 2017 00:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 TQAk5oVE1xL9 for ; Thu, 13 Apr 2017 00:49:21 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038E012EC89 for ; Thu, 13 Apr 2017 00:49:20 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 12CBAA06F0; Thu, 13 Apr 2017 09:49:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id C995F4007C; Thu, 13 Apr 2017 09:49:17 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 09:49:17 +0200 From: To: Fred Baker CC: "STARK, BARBARA H" , "otroan@employees.org" , JORDI PALET MARTINEZ , "v6ops@ietf.org" Thread-Topic: Obsolete or Update (RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00) Thread-Index: AdK0KnNhUJRDmuu/TGqgJtb891nMMg== Date: Thu, 13 Apr 2017 07:49:17 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 07:49:26 -0000 SGkgRnJlZCwgDQoNCkkgYWdyZWUuDQoNCklNTywgYXZvaWRpbmcgdG8gb2Jzb2xldGUgUkZDNzA4 NCBzZWVtcyB0aGUgcmlnaHQgYXBwcm9hY2ggdG8gZm9sbG93IGhlcmUuIA0KDQpDaGVlcnMsDQpN ZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRnJlZCBCYWtlciBb bWFpbHRvOmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAx MiBhdnJpbCAyMDE3IDE5OjExDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4g Q2PCoDogU1RBUkssIEJBUkJBUkEgSDsgb3Ryb2FuQGVtcGxveWVlcy5vcmc7IEpPUkRJIFBBTEVU IE1BUlRJTkVaOw0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW3Y2b3BzXSBMSVNQ IHN1cHBvcnQgZm9yIGRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4NC1iaXMtMDANCj4gDQo+IA0KPiA+ IE9uIEFwciAxMiwgMjAxNywgYXQgNjoxMiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSB3cm90ZToNCj4gPg0KPiA+IEhpIEJhcmJhcmEsDQo+ID4NCj4gPiBXb3VsZG4ndCBqdXN0IGJl IGZpbmUgZm9yIHRob3NlIElTUHMgbm90IGludGVyZXN0ZWQgaW4gdHJhbnNpdGlvbg0KPiBtZWNo YW5pc21zIHRvIGNvbnRpbnVlIHJlZmVycmluZyB0byBSRkM3MDg0Pw0KPiANCj4gVGhlIHRyaWNr eSBiaXQgdGVuZHMgdG8gYmUgaW4gaG93IHdlIGxhYmVsIHRoZSB1cGRhdGUuIElmIGl0ICJvYnNv bGV0ZXMiDQo+IG9yICJ1cGRhdGVzIiA3MDg0LCB3ZSBtZWFuIHRoYXQgYW55IHJlZmVyZW5jZSB0 byA3MDg0IGJlY29tZXMgYSByZWZlcmVuY2UNCj4gdG8gdGhlIG5ldyB0aGluZywgb3IgNzA4NCBw bHVzIHRoZSBuZXcgdGhpbmcuIFdlIHdvdWxkIG5lZWQgdG8gY2xlYXJseQ0KPiBsYWJlbCBpdCBz byB0aGF0IGEgcHJvY3VyZW1lbnQgY291bGQgcmVmZXJlbmNlIDcwODQgd2l0aG91dCBpdCwgb3IN Cj4gcmVmZXJlbmNlIDcwODQgYW5kIHRoZSBuZXcgdGhpbmcgc2VwYXJhdGVseS4NCj4gDQo+ID4g Q2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiA+PiBEZSA6IFNUQVJLLCBCQVJCQVJBIEggW21haWx0bzpiczc2NTJAYXR0LmNvbV0NCj4gPj4g RW52b3nDqSA6IG1lcmNyZWRpIDEyIGF2cmlsIDIwMTcgMTQ6NTMNCj4gPj4gw4AgOiBCT1VDQURB SVIgTW9oYW1lZCBJTVQvT0xOOyBvdHJvYW5AZW1wbG95ZWVzLm9yZzsNCj4gPj4gam9yZGkucGFs ZXRAY29uc3VsaW50ZWwuZXMNCj4gPj4gQ2MgOiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBPYmpldCA6 IFJFOiBbdjZvcHNdIExJU1Agc3VwcG9ydCBmb3IgZHJhZnQtaWV0Zi12Nm9wcy1yZmM3MDg0LWJp cy0wMA0KPiA+Pg0KPiA+Pj4gSSB0ZW5kIHRvIGFncmVlIHdpdGggeW91IGJ1dCB3aXRoIGEgc2xp Z2h0bHkgZGlmZmVyZW50IHByb3Bvc2FsOiAgcGljaw0KPiA+PiBPTkUNCj4gPj4+IG1hbmRhdG9y eSBzdGF0ZWZ1bCBtZWNoYW5pc20gKERTLUxpdGUpIGFuZCBPTkUgbWFuZGF0b3J5IEErUA0KPiA+ Pj4gbWVjaGFuaXNtIChNQVAtRSkuDQo+ID4+DQo+ID4+IEJlY2F1c2UgUkZDIDcwODQgaXMgYWxz byB1c2VkIGFzIGEgbWFuZGF0b3J5IHJlZmVyZW5jZSBpbiBCQkYgVFItMTI0DQo+ICh1c2VkDQo+ ID4+IGJ5IHRlbGNvIElTUHMgdG8gaGVscCB3aXRoIENFIHJvdXRlciBSRlBzKSwgYW5kIG1vc3Qg SVNQcyBoYXZlIG5vDQo+IGludGVyZXN0DQo+ID4+IGluIHJlcXVpcmluZyBjYXBhYmlsaXRpZXMg dGhhdCBhcmUgbm90IHVzZWZ1bCB0byBvciByZWxldmFudCBpbiB0aGVpcg0KPiA+PiBkZXBsb3lt ZW50LCB0aGVyZSBNVVNUIE5PVCBiZSBhbnkgbWFuZGF0b3J5IHRyYW5zaXRpb24gbWVjaGFuaXNt cw0KPiBpbmNsdWRlZA0KPiA+PiBpbiBhIDcwODQtYmlzLg0KPiA+PiBCYXJiYXJhDQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB2Nm9wcyBt YWlsaW5nIGxpc3QNCj4gPiB2Nm9wc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From nobody Thu Apr 13 01:03: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 4955E12F5DB for ; Thu, 13 Apr 2017 01:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 IIz8sfCTYd7g for ; Thu, 13 Apr 2017 01:03:24 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0C512EC98 for ; Thu, 13 Apr 2017 01:03:22 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id A371A4039A; Thu, 13 Apr 2017 10:03:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 761191A0086; Thu, 13 Apr 2017 10:03:20 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 10:03:19 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt Thread-Index: AQHSs6S89SDZewB5MEmsreyL0wr6+KHBwtUAgAEeo/A= Date: Thu, 13 Apr 2017 08:03:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4CDA8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149201230991.15796.10423245600175984626@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 08:03:26 -0000 SGkgSm9yZGksIA0KDQpUaGFuayB5b3UgZm9yIHRoaXMgdXBkYXRlLiANCg0KUHV0dGluZyBhc2lk ZSB0aGUgdXBkYXRlL29ic29sZXRlIGlzc3VlLCBiZWxvdyBzb21lIGNvbW1lbnRzOg0KDQoqIDQ2 NFhMQVQgaXMgZm9sbG93ZWQgYnkgbW9iaWxlIG9wZXJhdG9ycy4gSSBzdWdnZXN0IHRvIHJlbW92 ZSBpdCBmcm9tIHRoZSBkb2N1bWVudCBiZWNhdXNlIHRoZXJlIGFyZSBwbGVudHkgSVB2Ni1zcGVj aWZpYyBmZWF0dXJlcyB0aGF0IG5lZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IGEgd2lyZWxlc3MgQ1BF LiBUaGVyZSBpcyBubyByZWFzb24gdG8gZm9jdXMgb24gQ0xBVCB3aGlsZSBpZ25vcmluZyBvdGhl ciBzcGVjaWZpYyBJUHY2IHJlcXVpcmVtZW50cyBmb3IgY2VsbHVsYXIgZGV2aWNlcyAoc2VlIGZv ciBleGFtcGxlIFJGQzc4NDkpLiAgDQoNCiogSWYgeW91IHdvdWxkIGxpa2UgdG8gbWFpbnRhaW4g NnJkLzZpbjQsIHRoZW4geW91IG1heSBuZWVkIHRvIHN0cnVjdHVyZSB0aGUgdmFyaW91cyBtZWNo YW5pc21zLCBlLmcuLA0KDQpPTEQ6IA0KDQogICAgIDUuNC4gIFRyYW5zaXRpb24gVGVjaG5vbG9n aWVzIFN1cHBvcnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTUNCiAgICAgICA1LjQuMS4g IDQ2NFhMQVQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx NQ0KICAgICAgIDUuNC4yLiAgNmluNCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDE1DQogICAgICAgNS40LjMuICA2cmQgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcNCiAgICAgICA1LjQuNC4gIER1YWwt U3RhY2sgTGl0ZSAoRFMtTGl0ZSkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOA0KICAg ICAgIDUuNC41LiAgTGlnaHR3ZWlnaHQgNG92ZXI2IChsdzRvNikgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDE5DQogICAgICAgNS40LjYuICBNQVAtRSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTkNCiAgICAgICA1LjQuNy4gIE1BUC1UIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMA0KDQpORVc6DQoN CiAgICAgNS40LiAgSVB2NCBTZXJ2aWNlIENvbnRpbnVpdHkgb3ZlciBJUHY2IE5ldHdvcmtzIC4g LiAuIC4gLiAuIC4gLiAgMTUNCiAgICAgICA1LjQuMS4gIHh4eHggLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgICAgMTUNCiAgICAgICA1LjQueC4gIHh4eHgg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAuIC4gLiAuIC4gLiAuIC4gLiAgICAgMTgNCiAg ICAgICA1LjQueC4gIHh4eHh4eHh4eHggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICAgICAgMTkNCiAgICAgICA1LjQueC4gIHh4eHh4IC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMTkNCiAgICAgICA1LjQueC4gIHh4eHh4IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjAgDQogICAg IDUuNS4gIElQdjYgb3ZlciBJUHY0IE5ldHdvcmtzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4geHh4DQogICAgICAgNS54LnguICB4eHh4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgeHh4DQogICAgICAgNS54LnguICB4eHh4IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIHh4DQoNCkNoZWVy cywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSk9SREkgUEFMRVQN Cj4gTUFSVElORVoNCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAxMiBhdnJpbCAyMDE3IDE4OjAwDQo+ IMOAwqA6IHY2b3BzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4NC1iaXMtMDEudHh0DQo+IA0KPiBIaSBhbGwsDQo+IA0K PiBBcyBpbmRpY2F0ZWQgYSBjb3VwbGUgb2YgZGF5cyBhZ28sIEnigJl2ZSBwb3N0ZWQgYSBuZXcg dmVyc2lvbi4NCj4gDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdjZvcHMtcmZjNzA4NC1iaXMNCj4gDQo+IEl0IGNvbnRhaW5zIGEgbmV3IEFubmV4IGF0IHRo ZSBlbmQgb2YgdGhlIGRvY3VtZW50LCByZWZsZWN0aW5nIHRoZSBjaGFuZ2VzDQo+IGZyb20gLTAw LCB3aGljaCBiYXNpY2FsbHkgYXJlIHdoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBsaXN0 IHRoZSBsYXN0DQo+IGZldyBkYXlzOg0KPiANCj4gMS4gTFc0TzYtNSBjaGFuZ2VkIHRvIHBvcnQt cmVzdHJpY3RlZCB0byBjb25mb3JtIHdpdGggW1JGQzc1OTZdLg0KPiAyLiBNQVBFLTMgY2hhbmdl ZCB0byBwb3J0LXJlc3RyaWN0ZWQgdG8gY29uZm9ybSB3aXRoIFtSRkM3NTk3XS4NCj4gMy4gTUFQ VC0zIGNoYW5nZWQgdG8gcG9ydC1yZXN0cmljdGVkIHRvIGNvbmZvcm0gd2l0aCBbUkZDNzU5OV0u DQo+IDQuIFtSRkM3MzQxXSByZW1vdmVkIGZyb20gNDY0WExBVCwgRFMtTElURSwgTUFQLUUgYW5k IE1BUC1UIHJlcXVpcmVtZW50cy4NCj4gNS4gW1JGQzU2MjVdIHJlbW92ZWQgZnJvbSA0NjRYTEFU LCBhbmQgaW5jbHVkZWQgYXMgZ2VuZXJhbCBMQU4NCj4gcmVxdWlyZW1lbnQuDQo+IDYuIFtSRkM3 NjE4XSBpbmNsdWRlZCBhcyBNQVkgZm9yIGx3NG82Lg0KPiANCj4gSG9wZWZ1bGx5IG5vdyB0aGF0 IHdlIGhhdmUgc29tZSDigJxoZWF04oCdIGluIHRoZSBkaXNjdXNzaW9uLCB0aGlzIHZlcnNpb24N Cj4gd2lsbCBmYWNpbGl0YXRlIGludGVyZXN0ZWQgZm9sa3MgdG8gcmVhZCBvdmVyLg0KPiANCj4g UmVnYXJkcywNCj4gSm9yZGkNCj4gDQo+IA0KPiAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0K PiBEZTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IGVuIG5vbWJyZSBkZSA8aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPg0KPiBSZXNwb25kZXIgYTogPGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4NCj4gRmVjaGE6IG1pw6lyY29sZXMsIDEyIGRlIGFicmlsIGRlIDIwMTcsIDE3OjUxDQo+ IFBhcmE6IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+IENDOiA8djZvcHNAaWV0Zi5vcmc+DQo+ IEFzdW50bzogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXJmYzcwODQtYmlz LTAxLnR4dA0KPiANCj4gDQo+ICAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+ICAgICBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE9wZXJhdGlvbnMgb2YgdGhlIElF VEYuDQo+IA0KPiAgICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBCYXNpYyBSZXF1aXJlbWVu dHMgZm9yIElQdjYgQ3VzdG9tZXIgRWRnZQ0KPiBSb3V0ZXJzDQo+ICAgICAgICAgICAgIEF1dGhv ciAgICAgICAgICA6IEpvcmRpIFBhbGV0IE1hcnRpbmV6DQo+ICAgICAJRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi12Nm9wcy1yZmM3MDg0LWJpcy0wMS50eHQNCj4gICAgIAlQYWdlcyAgICAg ICAgICAgOiAyOQ0KPiAgICAgCURhdGUgICAgICAgICAgICA6IDIwMTctMDQtMTINCj4gDQo+ICAg ICBBYnN0cmFjdDoNCj4gICAgICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJlcXVpcmVtZW50 cyBmb3IgYW4gSVB2NiBDdXN0b21lciBFZGdlIChDRSkNCj4gICAgICAgIHJvdXRlci4gIFNwZWNp ZmljYWxseSwgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IGZvY3VzZXMNCj4g ICAgICAgIG9uIHRoZSBiYXNpYyBwcm92aXNpb25pbmcgb2YgYW4gSVB2NiBDRSByb3V0ZXIgYW5k IHRoZSBwcm92aXNpb25pbmcNCj4gICAgICAgIG9mIElQdjYgaG9zdHMgYXR0YWNoZWQgdG8gaXQu ICBUaGUgZG9jdW1lbnQgYWxzbyBjb3ZlcnMgc2V2ZXJhbA0KPiAgICAgICAgdHJhbnNpdGlvbiB0 ZWNobm9sb2dpZXMsIGFzIHJlcXVpcmVkIGluIGEgd29ybGQgd2hlcmUgSVB2NA0KPiBhZGRyZXNz ZXMNCj4gICAgICAgIGFyZSBubyBsb25nZXIgYXZhaWxhYmxlLCBzbyBob3N0cyBpbiB0aGUgY3Vz dG9tZXIgTEFOcyB3aXRoIElQdjQtDQo+IG9ubHkNCj4gICAgICAgIG9yIElQdjYtb25seSBhcHBs aWNhdGlvbnMgb3IgZGV2aWNlcywgcmVxdWlyaW5nIHRvIGNvbW11bmljYXRlIHdpdGgNCj4gICAg ICAgIElQdjQtb25seSBzZXJ2aWNlcyBhdCB0aGUgSW50ZXJuZXQsIGFyZSBhYmxlIHRvIGRvIHNv LiAgVGhlDQo+IGRvY3VtZW50DQo+ICAgICAgICBvYnNvbGV0ZXMgUkZDIDcwODQuDQo+IA0KPiAN Cj4gICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KPiAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9w cy1yZmM3MDg0LWJpcy8NCj4gDQo+ICAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6DQo+ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi12Nm9wcy1yZmM3MDg0LWJpcy0wMQ0KPiAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXJmYzcwODQtYmlzLTAxDQo+IA0KPiAgICAg QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4 NC1iaXMtMDENCj4gDQo+IA0KPiAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbg0KPiAgICAgdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCj4gDQo+ICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQo+ICAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KPiANCj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gICAgIHY2b3BzQGlldGYub3JnDQo+ ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0KPiBJUHY0IGlzIG92ZXINCj4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5l dCA/DQo+IGh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMNCj4gVGhlIElQdjYgQ29tcGFueQ0KPiAN Cj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5 IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50 ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQgYWJv dmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUNCj4gdGhh dCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29u dGVudHMgb2YgdGhpcw0KPiBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBp cyBwcm9oaWJpdGVkLg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Thu Apr 13 01:07: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 20DAA12F547 for ; Thu, 13 Apr 2017 01:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia1s2V7Y_FaH for ; Thu, 13 Apr 2017 01:07:48 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E244512F258 for ; Thu, 13 Apr 2017 01:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492070864; x=1492675664; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=Lzy5oizvfBMSt2Y4MyzuhfH5m q/eTlqeZ0ZTL8gDm8g=; b=U1N+unKsmOVdG33y2H0QzwXpFd2kcajSc7/4LdqYf zTrh1LB/iadria7rfbyK7nO+YH5QGGaKy9JEtVwjBKYLJoXoslXlkP4+yu6mfWT6 WUOQK0jdFySlGk6E5TmPYBCrevRpL9QOhYkzJ8is5j9lxF69BL/j0VFAoGjvz17c AU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=PLqM2aO/ASokXZvkDsuO1B4j1mMHXVhSRXW+qJ++z1/FK9U8+U6l37g38k/a EAiGZi892oIbjwyzNHVJzDEVSETen6OVP8g/CnCtaez4lNy6wwBdWCrTI r0X22dBoeH7Z2SmPmfXeduCDS4q4mDQMCtAsOz//rg4L6uFyeayPnA=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Apr 2017 10:07:44 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Apr 2017 10:07:44 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407683.msg for ; Thu, 13 Apr 2017 10:07:43 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170413:md50005407683::r7OUPKT+6MB0jWgu:00002y0P X-Return-Path: prvs=1276e13cdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 13 Apr 2017 10:07:43 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <053D09B3-877C-4B7F-BEC0-624E576D9B90@consulintel.es> Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19E7B@GAALPA1MSGUSRBF.ITServices.sbc.com> <562F273A-4B90-43D9-82E9-5FC2DD437261@consulintel.es> <9608510E-79BC-44A5-8D91-F665B72765F5@employees.org> In-Reply-To: <9608510E-79BC-44A5-8D91-F665B72765F5@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 08:07:50 -0000 Hi Ole, Actually, most of the times I=E2=80=99ve done this they were non-Linux boxe= s. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 22:39 Para: CC: "v6ops@ietf.org" Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Jordi, =20 > If you have a 6to4 router at home, you can just try. Create a HE tunn= el broker, and input manually the parameters even if your router only shows= a 6rd in the GUI. It works. Believe me. =20 This is the IETF. There are other implementations than Linux. If there wasn't you didn't need a standard. =20 Cheers, Ole =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 13 01:32: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 E0950128B8D for ; Thu, 13 Apr 2017 01:32:43 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pQFQARuZzfO1 for ; Thu, 13 Apr 2017 01:32:41 -0700 (PDT) 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 BEEDC12741D for ; Thu, 13 Apr 2017 01:32:41 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 63226A2; Thu, 13 Apr 2017 10:32:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492072359; bh=mq2NTPH5Mexix0GAM/5nGmVT2CX4jCzlyKqRv/ZTjXg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=tsj5skT26mCyktjWWiehELQCSRLCnAEwYOc2bSoE0ry4dem8UpClMVziaqJ0ryHmM LJrbZLy8BZveN22kRaxGiahmSzy/a4aXBoosMPnwfnGo4ppB+2TFjv3JJzpFMKN6a4 jiHt6b29kVDqL3QWpY1h8Xtel6XRZlU/EyWAOfsA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4B41188; Thu, 13 Apr 2017 10:32:39 +0200 (CEST) Date: Thu, 13 Apr 2017 10:32:39 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: "v6ops@ietf.org" In-Reply-To: Message-ID: References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.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-475143714-1492072359=:27978" Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 08:32:44 -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-475143714-1492072359=:27978 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 12 Apr 2017, JORDI PALET MARTINEZ wrote: > The CE router MAY support 6in4 functionality. If 6rd is implemented, > 6in4 is already supported as well, as the underlying protocol/technology > is the same, being the only difference, having the mention of “6in4†in > the GUI/CLI (just an example) if it is being configured manually, or > even stating that in the relevant documentation. In other words, no > additional code is required for the support of 6in4 when 6rd is already > supported In the original 6RD-2 requirement that talks about user configuration, for configuring 6in4 the UI would need to look slightly different, right? Depending on some choices in UI, some input methods of the parameters might not work with 6in4. So I guess your intention to include 6in4 could be done either as a new transition protocol with SHOULD, or it can add an additional MAY requirement in 6RD that the settings be compatible for configuring a generic 6in4 tunnel as well. The above text seems to be the latter? I think it would actually make more sense to create a "new" transition technology in there in that case. That would keep it clean the way I interpret Barbaras intention is? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-475143714-1492072359=:27978-- From nobody Thu Apr 13 02:05: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 D2BA813184A for ; Thu, 13 Apr 2017 02:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLaRrC1kLdC3 for ; Thu, 13 Apr 2017 02:05:18 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5685F131847 for ; Thu, 13 Apr 2017 02:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492074313; x=1492679113; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=+DuISaqC23Jaa766JBEa0Z6UI BvOan0FYBcs0L2oWis=; b=X5FUnMyV9c6zgzUasmpX6X3o9GM5vO69ewqnZOUtN 4lpB8mANPS8gsOioYkSWRGGq5pVjoZyQ9BeFM4JXoyDdEZMfA0yBOB/NUTdCKH1W oM4l2phDZ9vxWfe6gaAA5fK6CG0SSncuoN+p3/hahnxRqsSrvQkY5Cq+vBpaAj3t 5A= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=at/eh0za+6mVraJNDMQxBKPr00qy9IZ3PeBIFmBnuMvY/gDrvE0H8IkSGBen qtQLSpqOZebQQ8YoG0D4a/hmVWCTIs+AEz4JcgJh5saynlO5IO09gq5Wd 763StvsHZXN4SLsLWDW0WC0XxhQJhIw7KS+oGOrmWtPRENBhUp2FKI=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Apr 2017 11:05:13 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Apr 2017 11:05:12 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407725.msg for ; Thu, 13 Apr 2017 11:05:11 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170413:md50005407725::3sZ9uMlxQvxX3f2J:00002ioH X-Return-Path: prvs=1276e13cdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 13 Apr 2017 11:05:10 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <8F80DE9D-0677-4568-B211-9D79067BE22B@consulintel.es> Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:05:20 -0000 Hi Mikael, No, it is actually much easier than that. The text I proposes will go to th= e same section (6in4). So, it will be (for the sake of clarity): 5.4.2. 6in4 6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to manually configure IPv6 support via a service provider's IPv4 network infrastructure. The CE router MAY support 6in4 functionality. If 6rd is implemented, 6in4 is already supported as well, as the underlying protocol/technology is the same, being the only difference, having the mention of =E2=80=9C6= in4=E2=80=9D in the GUI/CLI (just an example) if it is being configured manually, or even stating that in the relevant documentation. In other words, no additional code is required for the support of 6in4 when 6rd is already supported. If 6in4 is supported, it MUST be implemented according to=20 [RFC4213]. The following CE Requirements also apply: =E2=80=A6 No code is required at all, and in any case, the target is MAY, same as we = have it right now also for 6rd. Let me explain. Let=E2=80=99s suppose you have *any* router or OS with 6rd support, never m= ind the configuration is done by means of DHCP or user-entered configuratio= n (as you said original 6RD-2, but also 6RD-1 and 6RD-3), and instead of a = 6RD relay, you provide the 6in4 tunnel-end-point, it just works. It is simple to understand, because both, 6in4, 6to4, and 6rd, actually do = exactly the same encapsulation/decapsulation (protocol-41), and exactly the= same routing thing. The difference is that in 6in4 is called a tunnel brok= er (or similar), in 6to4 is a 6to4 relay, etc. All the parameters in the UI= are the same. What it means from the perspective of the CE implementer: only a minor text= change in the UI. The UI today has a =E2=80=9Cmenu=E2=80=9D to allow 6RD-2= config, that says =E2=80=9C6rd=E2=80=9D. What I=E2=80=99m saying is it to = be changed to say =E2=80=9C6rd/6in4=E2=80=9D or alternatively, one option f= or =E2=80=9C6rd=E2=80=9D and another for =E2=80=9C6in4=E2=80=9D, but actual= ly both choices will bring to the same =E2=80=9Ccode=E2=80=9D. I believe Barbara is worried that if I keep it as a different than 6rd tran= sition mechanism (as it is actually in the current -01 version, see section= 5.4.2), because I=E2=80=99m referring to RFC4213, I=E2=80=99m =E2=80=9Cadd= ing=E2=80=9D more requirements behind that RFC. I=E2=80=99m actually readin= g all those documents and I believe she is wrong on that, but I will answer= that in a few minutes. I see no =E2=80=9Ctechnical=E2=80=9D difference in having it as part of the= 6rd text or as it is right now a separated one, which seems to me (I think= you agree on this, if I understood correctly) your email, clearer. Regards, Jordi =20 -----Mensaje original----- De: Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Responder a: Fecha: jueves, 13 de abril de 2017, 10:32 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 On Wed, 12 Apr 2017, JORDI PALET MARTINEZ wrote: =20 > The CE router MAY support 6in4 functionality. If 6rd is implemented,= =20 > 6in4 is already supported as well, as the underlying protocol/technol= ogy=20 > is the same, being the only difference, having the mention of =E2=80= =9C6in4=E2=80=9D in=20 > the GUI/CLI (just an example) if it is being configured manually, or= =20 > even stating that in the relevant documentation. In other words, no= =20 > additional code is required for the support of 6in4 when 6rd is alrea= dy=20 > supported =20 In the original 6RD-2 requirement that talks about user configuration, = for=20 configuring 6in4 the UI would need to look slightly different, right?= =20 Depending on some choices in UI, some input methods of the parameters= =20 might not work with 6in4. =20 So I guess your intention to include 6in4 could be done either as a new= =20 transition protocol with SHOULD, or it can add an additional MAY=20 requirement in 6RD that the settings be compatible for configuring a=20 generic 6in4 tunnel as well. The above text seems to be the latter? =20 I think it would actually make more sense to create a "new" transition= =20 technology in there in that case. That would keep it clean the way I=20 interpret Barbaras intention is? =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 13 02:22: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 D57EE12EBCC for ; Thu, 13 Apr 2017 02:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DpNYEosePgbI for ; Thu, 13 Apr 2017 02:22:50 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A142912EBF0 for ; Thu, 13 Apr 2017 02:22:50 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 13 Apr 2017 09:22:50 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id E9062D788D; Thu, 13 Apr 2017 02:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=rGaMsky59WaaxtvNDw4na5xp1dk=; b= ar4d3j9L2WMyaI/NP90kUTppoO1/M2BORchpQAIwianB8ASg4aKVxq7OryMdV6sn RmEOBnWZCnGNzZwbuF6UuifHJ1tsWzTzkURNMHuXRtmwVLmlJOHPAIwRg8vewcRF RfPtg9RY+iPQFqDUZR0AZb/nvXiNrOfKRhk9AfJbzCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=QUzzX5poQ24BX3bYdNJy2+N tZSRvlautoClUEaeiVAspKwRAYsQbia95KoCGk42tG9mklVn5isrCtGENbLZwWeS 93a/+jvbY1D88QXfMWaXT1HEHyko8dI2L+KHR+GeIJ5yu01JQ55j0a+NNDwfrkUZ UNdL/zBv0O98FlplH/FU= Received: from h.hanazo.no (77.16.76.254.tmi.telenormobil.no [77.16.76.254]) (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 E8DC3D788B; Thu, 13 Apr 2017 02:22:48 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A6866A9A3561; Thu, 13 Apr 2017 11:22:42 +0200 (CEST) From: otroan@employees.org Message-Id: <6772D740-0589-4B28-ACC2-252C6ACB8360@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F2744CBF-6446-4821-A93A-3CBA46FB037F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 11:22:41 +0200 In-Reply-To: <8F80DE9D-0677-4568-B211-9D79067BE22B@consulintel.es> Cc: "v6ops@ietf.org" To: jordi.palet@consulintel.es References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <8F80DE9D-0677-4568-B211-9D79067BE22B@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:22:53 -0000 --Apple-Mail=_F2744CBF-6446-4821-A93A-3CBA46FB037F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jordi, Where have you got the idea that an implementation of 6RD also supports = Configured tunnels? That is wrong. Ole > On 13 Apr 2017, at 11:05, JORDI PALET MARTINEZ = wrote: >=20 > Hi Mikael, >=20 > No, it is actually much easier than that. The text I proposes will go = to the same section (6in4). So, it will be (for the sake of clarity): >=20 > 5.4.2. 6in4 >=20 > 6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to > manually configure IPv6 support via a service provider's IPv4 = network > infrastructure. >=20 > The CE router MAY support 6in4 functionality. If 6rd is = implemented, > 6in4 is already supported as well, as the underlying = protocol/technology > is the same, being the only difference, having the mention of = =E2=80=9C6in4=E2=80=9D in > the GUI/CLI (just an example) if it is being configured manually, or > even stating that in the relevant documentation. In other words, no > additional code is required for the support of 6in4 when 6rd is = already > supported. If 6in4 is supported, it MUST be implemented according to > [RFC4213]. The following CE Requirements also apply: >=20 > =E2=80=A6 >=20 > No code is required at all, and in any case, the target is MAY, same = as we have it right now also for 6rd. Let me explain. >=20 > Let=E2=80=99s suppose you have *any* router or OS with 6rd support, = never mind the configuration is done by means of DHCP or user-entered = configuration (as you said original 6RD-2, but also 6RD-1 and 6RD-3), = and instead of a 6RD relay, you provide the 6in4 tunnel-end-point, it = just works. >=20 > It is simple to understand, because both, 6in4, 6to4, and 6rd, = actually do exactly the same encapsulation/decapsulation (protocol-41), = and exactly the same routing thing. The difference is that in 6in4 is = called a tunnel broker (or similar), in 6to4 is a 6to4 relay, etc. All = the parameters in the UI are the same. >=20 > What it means from the perspective of the CE implementer: only a minor = text change in the UI. The UI today has a =E2=80=9Cmenu=E2=80=9D to = allow 6RD-2 config, that says =E2=80=9C6rd=E2=80=9D. What I=E2=80=99m = saying is it to be changed to say =E2=80=9C6rd/6in4=E2=80=9D or = alternatively, one option for =E2=80=9C6rd=E2=80=9D and another for = =E2=80=9C6in4=E2=80=9D, but actually both choices will bring to the same = =E2=80=9Ccode=E2=80=9D. >=20 > I believe Barbara is worried that if I keep it as a different than 6rd = transition mechanism (as it is actually in the current -01 version, see = section 5.4.2), because I=E2=80=99m referring to RFC4213, I=E2=80=99m = =E2=80=9Cadding=E2=80=9D more requirements behind that RFC. I=E2=80=99m = actually reading all those documents and I believe she is wrong on that, = but I will answer that in a few minutes. >=20 > I see no =E2=80=9Ctechnical=E2=80=9D difference in having it as part = of the 6rd text or as it is right now a separated one, which seems to me = (I think you agree on this, if I understood correctly) your email, = clearer. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: Mikael Abrahamsson > Organizaci=C3=B3n: People's Front Against WWW > Responder a: > Fecha: jueves, 13 de abril de 2017, 10:32 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 >=20 > On Wed, 12 Apr 2017, JORDI PALET MARTINEZ wrote: >=20 >> The CE router MAY support 6in4 functionality. If 6rd is implemented, >> 6in4 is already supported as well, as the underlying = protocol/technology >> is the same, being the only difference, having the mention of = =E2=80=9C6in4=E2=80=9D in >> the GUI/CLI (just an example) if it is being configured manually, or >> even stating that in the relevant documentation. In other words, no >> additional code is required for the support of 6in4 when 6rd is = already >> supported >=20 > In the original 6RD-2 requirement that talks about user = configuration, for > configuring 6in4 the UI would need to look slightly different, = right? > Depending on some choices in UI, some input methods of the = parameters > might not work with 6in4. >=20 > So I guess your intention to include 6in4 could be done either as a = new > transition protocol with SHOULD, or it can add an additional MAY > requirement in 6RD that the settings be compatible for configuring = a > generic 6in4 tunnel as well. The above text seems to be the latter? >=20 > I think it would actually make more sense to create a "new" = transition > technology in there in that case. That would keep it clean the way = I > interpret Barbaras intention is? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_F2744CBF-6446-4821-A93A-3CBA46FB037F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY70NhAAoJEL7aWKiYQt929NAP/R+0BGzGwlihD+SemIkzpzT5 f/pjnzG8HFGwtLM7kRIYlbM1vbhqsvRaVtNZfOePgA8ni71RbKiAeHd4mC71vWvn 8qMD1VCDttB11MJn/QNJOLjE1bFOWXyY/Pf6JdK+rC0kBafnSJp6THLP2daKtDm2 YNHipewORlvD/jBx1h4b/RyWnCSNoHq6TIw2rDCeGK7EXusIXVoV6n5mR2Q+Fsmy 27Zb3H5le6AwczMQg7bKz23jLGpOPNL+fSUEOCYVlwQmNfY/hLqfpWDqYzHBiNKd lhLN0rC7S4VT23lEboadLMPXwaeh7Lu3RHLlaO3Ip28q+OYPR4KMrWt73wuq2US0 cwKDmACEyOWEkTxG9MVm0n/l9WSM3DBUN4ufxNqakzTkripEeesMRJPawU9/ZTMs WHmxmEBH4kVB+XJzYc220IZ1ikm2HVSGVm2Y5t3oCgpGQiRJ/wLxF9eoeL1E+eHV 6dYsbVxuGwZgUrWgsh6ELk7obzOYivzNqeBv3JQYE5q/TDGn6ADZ84e9+idc41Sg +kubDs4SvHN9PeMENcG7T/FEFz+SwFI+aFc1X1jkcMKW5gIIvG7i4QyCVOfNlae5 qQ/L6R30qGlpad+dQOg3M3jRAXUp/RhtrCpnLamLYVj7RWemNTvAwAb7FUWczIO7 H5QLCgpv4xLKouMqPr9P =DTv2 -----END PGP SIGNATURE----- --Apple-Mail=_F2744CBF-6446-4821-A93A-3CBA46FB037F-- From nobody Thu Apr 13 02:27: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 683B512EAE1 for ; Thu, 13 Apr 2017 02:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kPjO-QN3gmt for ; Thu, 13 Apr 2017 02:27:35 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B3D12EC25 for ; Thu, 13 Apr 2017 02:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492075648; x=1492680448; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=5tbZWYsrjLYo6JrBUBOg7M38Z tRZCeivd9BUtu1A4b0=; b=AV4ZDE4mBg9b5YbOa/YQ39QLmqMzp1YI+R3X5Iwd3 mOgLva+mhQrYeWkO6x02wJOVobi3WdFAi2dXuPecHL05GNYo5WEf25A18F2hy/Hh 7LckWdgWtHeo2HZbxww/Cc5sz2qAP30dKGFfBN+QD3K0JxAlBtmni5wcYqQcxwR5 K4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=f6fK2p9sw07AKp38vvFKosUAzAGuLYdXAsWzqpgPMIB+oUZ0Djywi5Oz/1eq ONHG7+/c788iNEVI0uWP4GSvoLqv1vhU0OWYUv0Jzxw1R3YBpUf4xFXJt fugbG1ucO4MIOYDwwUpixEDKYEiwpOqmLlSF0w3L8PDhM2sV/6a6Uw=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Apr 2017 11:27:28 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Apr 2017 11:27:27 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407740.msg for ; Thu, 13 Apr 2017 11:27:26 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170413:md50005407740::amg3ViHWnCwAYYet:00003e8d X-Return-Path: prvs=1276e13cdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 13 Apr 2017 11:27:23 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <0E84BD53-6022-4681-B8F8-7B64760D023A@consulintel.es> Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <8F80DE9D-0677-4568-B211-9D79067BE22B@consulintel.es> <6772D740-0589-4B28-ACC2-252C6ACB8360@employees.org> In-Reply-To: <6772D740-0589-4B28-ACC2-252C6ACB8360@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:27:37 -0000 Believe me, just try it. I=E2=80=99ve tried this with many CEs that had a =E2=80=9C6rd=E2=80=9D choi= ce and NO =E2=80=9C6in4=E2=80=9D. If you use the configured tunnel end-poin= t parameters to =E2=80=9Clie=E2=80=9D to the CE, it just works. And this is= normal if you look into the details of how 6to4, 6in4 configured tunnels a= nd 6rd work. They do the same, the difference is at the =E2=80=9Cprovider e= dge=E2=80=9D. The CE don=E2=80=99t =E2=80=9Csee=E2=80=9D any difference between them. In fact I=E2=80=99ve many customers using it, both residential and SMEs. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: jueves, 13 de abril de 2017, 11:22 Para: CC: "v6ops@ietf.org" Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Jordi, =20 Where have you got the idea that an implementation of 6RD also supports= Configured tunnels? That is wrong. =20 Ole =20 =20 > On 13 Apr 2017, at 11:05, JORDI PALET MARTINEZ wrote: >=20 > Hi Mikael, >=20 > No, it is actually much easier than that. The text I proposes will go= to the same section (6in4). So, it will be (for the sake of clarity): >=20 > 5.4.2. 6in4 >=20 > 6in4 [RFC4213] specifies a tunneling mechanism to allow end-users t= o > manually configure IPv6 support via a service provider's IPv4 netwo= rk > infrastructure. >=20 > The CE router MAY support 6in4 functionality. If 6rd is implemente= d, > 6in4 is already supported as well, as the underlying protocol/techn= ology > is the same, being the only difference, having the mention of =E2= =80=9C6in4=E2=80=9D in > the GUI/CLI (just an example) if it is being configured manually, o= r > even stating that in the relevant documentation. In other words, no > additional code is required for the support of 6in4 when 6rd is alr= eady > supported. If 6in4 is supported, it MUST be implemented according t= o > [RFC4213]. The following CE Requirements also apply: >=20 > =E2=80=A6 >=20 > No code is required at all, and in any case, the target is MAY, same = as we have it right now also for 6rd. Let me explain. >=20 > Let=E2=80=99s suppose you have *any* router or OS with 6rd support, n= ever mind the configuration is done by means of DHCP or user-entered config= uration (as you said original 6RD-2, but also 6RD-1 and 6RD-3), and instead= of a 6RD relay, you provide the 6in4 tunnel-end-point, it just works. >=20 > It is simple to understand, because both, 6in4, 6to4, and 6rd, actual= ly do exactly the same encapsulation/decapsulation (protocol-41), and exact= ly the same routing thing. The difference is that in 6in4 is called a tunne= l broker (or similar), in 6to4 is a 6to4 relay, etc. All the parameters in = the UI are the same. >=20 > What it means from the perspective of the CE implementer: only a mino= r text change in the UI. The UI today has a =E2=80=9Cmenu=E2=80=9D to allow= 6RD-2 config, that says =E2=80=9C6rd=E2=80=9D. What I=E2=80=99m saying is = it to be changed to say =E2=80=9C6rd/6in4=E2=80=9D or alternatively, one op= tion for =E2=80=9C6rd=E2=80=9D and another for =E2=80=9C6in4=E2=80=9D, but = actually both choices will bring to the same =E2=80=9Ccode=E2=80=9D. >=20 > I believe Barbara is worried that if I keep it as a different than 6r= d transition mechanism (as it is actually in the current -01 version, see s= ection 5.4.2), because I=E2=80=99m referring to RFC4213, I=E2=80=99m =E2=80= =9Cadding=E2=80=9D more requirements behind that RFC. I=E2=80=99m actually = reading all those documents and I believe she is wrong on that, but I will = answer that in a few minutes. >=20 > I see no =E2=80=9Ctechnical=E2=80=9D difference in having it as part = of the 6rd text or as it is right now a separated one, which seems to me (I= think you agree on this, if I understood correctly) your email, clearer. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: Mikael Abrahamsson > Organizaci=C3=B3n: People's Front Against WWW > Responder a: > Fecha: jueves, 13 de abril de 2017, 10:32 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 >=20 > On Wed, 12 Apr 2017, JORDI PALET MARTINEZ wrote: >=20 >> The CE router MAY support 6in4 functionality. If 6rd is implemented= , >> 6in4 is already supported as well, as the underlying protocol/techno= logy >> is the same, being the only difference, having the mention of =E2=80= =9C6in4=E2=80=9D in >> the GUI/CLI (just an example) if it is being configured manually, or >> even stating that in the relevant documentation. In other words, no >> additional code is required for the support of 6in4 when 6rd is alre= ady >> supported >=20 > In the original 6RD-2 requirement that talks about user configurat= ion, for > configuring 6in4 the UI would need to look slightly different, rig= ht? > Depending on some choices in UI, some input methods of the paramet= ers > might not work with 6in4. >=20 > So I guess your intention to include 6in4 could be done either as = a new > transition protocol with SHOULD, or it can add an additional MAY > requirement in 6RD that the settings be compatible for configuring= a > generic 6in4 tunnel as well. The above text seems to be the latter= ? >=20 > I think it would actually make more sense to create a "new" transi= tion > technology in there in that case. That would keep it clean the way= I > interpret Barbaras intention is? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 13 02:44: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 9B8A9131463 for ; Thu, 13 Apr 2017 02:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 cliQkwGxfa1q for ; Thu, 13 Apr 2017 02:44:21 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 595CF13145F for ; Thu, 13 Apr 2017 02:44:21 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 13 Apr 2017 09:44:21 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1D0F2D788D; Thu, 13 Apr 2017 02:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=bSplAD0g60zKzrVsg02kPKxPz54=; b= DwgmyOidaeyV1w+/ADyj7SFwuRhs2x8v7l0/14pXHgel4MDYQlMtIHBb2hHxo1uK h647+wuRrfJ2MscPSlcpNAEySYQ8KwuwpL4NwzpbV0xKzw1xg4vRqoqThSt4Z+p6 XAdxqZyQpge0/W7+AV+fiHzMNf+G0NsBxkTXFwyoVbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=fuXWzflLRSmcu7L84lsH9Dc mcH+h8aTJLmofHWdHpld7ACiRnuj+NVKXzS1Lj1vAZShwa5ra0xnZnyGgAesc9+e OJH/NkQ5v8cnqBBDJqmuJCmGYKhbZpqApfrALVJrYFqVID5W95pqlS7vDs6lqHPX XrDyCLCXrk2pmB69ruV0= Received: from h.hanazo.no (77.16.76.254.tmi.telenormobil.no [77.16.76.254]) (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 D3874D788A; Thu, 13 Apr 2017 02:44:20 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 027C4A9A7A31; Thu, 13 Apr 2017 11:44:15 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_46287733-CCB7-4F4C-B492-1C6CE6647BF1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 11:44:15 +0200 In-Reply-To: <0E84BD53-6022-4681-B8F8-7B64760D023A@consulintel.es> Cc: "v6ops@ietf.org" To: jordi.palet@consulintel.es References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <8F80DE9D-0677-4568-B211-9D79067BE22B@consulintel.es> <6772D740-0589-4B28-ACC2-252C6ACB8360@employees.org> <0E84BD53-6022-4681-B8F8-7B64760D023A@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:44:22 -0000 --Apple-Mail=_46287733-CCB7-4F4C-B492-1C6CE6647BF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jordi, > Believe me, just try it. Oh geez... You seem completely stuck with the implementations (Linux = based) that you have tried. > I=E2=80=99ve tried this with many CEs that had a =E2=80=9C6rd=E2=80=9D = choice and NO =E2=80=9C6in4=E2=80=9D. If you use the configured tunnel = end-point parameters to =E2=80=9Clie=E2=80=9D to the CE, it just works. = And this is normal if you look into the details of how 6to4, 6in4 = configured tunnels and 6rd work. They do the same, the difference is at = the =E2=80=9Cprovider edge=E2=80=9D. >=20 > The CE don=E2=80=99t =E2=80=9Csee=E2=80=9D any difference between = them. >=20 > In fact I=E2=80=99ve many customers using it, both residential and = SMEs. Take VPP for example. Does not behave like you think every = implementation does: https://git.fd.io/vpp/tree/src/plugins/sixrd Ole --Apple-Mail=_46287733-CCB7-4F4C-B492-1C6CE6647BF1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY70hvAAoJEL7aWKiYQt92QXUP/2IiZmNDDcoyVfm2tGzPZ649 xsK7t6MtXETtLZeN0fOGjW85LHIRnMFgv5BGZU9x3ELIiF+FF+vE43i0gAzcTfGq BD8dCned9SgzUPAzl1ZLSOoIsYaYd4uUVGgxRHEq15XemyHHRj+sxYz+D+A4oFr6 tOmCGq++pHbWrcjRxl3atI8PgrqNzDM5Chg3lPIoJC+HWCoqRP+kNpA5NrSkpRae Rt6B911fKQvSkPUtBRr5wSln8JHYQpQjgXb+2vXOelMzlCGYCwt33kjQvpSkny4e 86VR/cYxu/jJ0kJY7gx4k/0eOIy7voqm6rIAUhHrtXWOXhTbOPXNbseWUUhmzl0t wRDwv/B0vxI5xGvwdHywldogDErf+7qGaIU4JrX+thRAhpd6m/Z/fTvdhBC8q3kT eAmxlOjtACtARXkiI+BOZB85kCncQ6xREiCOMFNqF/GUhz4IizpLm+cgYKhaLFL5 VkzllrKPFvkKZZ/ihh76k3HERV+4IW6gaeY4yeNV4P+ETU4mx42YYff2h3/TyFNO 3bAKQqBKAoOKiGwUPFw35qU1aNQIaL0Fucb/EWXdSywj9petKDEnxe2gQ9Lc//YX bi7RQoQq0QYLrzsc49F3RVH7mkqannEVPSn5hVtJF8zVX2JZF8FfIcfz5fR3wyIw TJTNRX4kyO2n/P15YYig =z4rd -----END PGP SIGNATURE----- --Apple-Mail=_46287733-CCB7-4F4C-B492-1C6CE6647BF1-- From nobody Thu Apr 13 02:57: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 13A7E13149C for ; Thu, 13 Apr 2017 02:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP750ylpQkyx for ; Thu, 13 Apr 2017 02:57:55 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00ADC131464 for ; Thu, 13 Apr 2017 02:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492077469; x=1492682269; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=VediIu1sduPNerfrd7ZuZvwdr JSU4xSz9mFfiZ2td8g=; b=iCyqX719Aii1u2cdRXdf21AJk0t6GBC5P1F9Uxti6 3N7KprtPfh6Vs5SG2lw1rh3c9NsS0fGHdyFxZEAubd3PxFCUgPRd0DFkcl8XDP2C HIWXm3l65BNH/Fl6kEEoTL37S/M/zHB/rRaJaoBgA7FPEqQasR7kBJdB6ZLIRxrS yQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=JAzVDee5I4lCKDdPAS6GXYJtsNpXK5UeYnEYvgKmqQSe7YByHo1e6TFE9wfS a+pUzQqJ7k5y0dLmpPQHs8XLpxfiZfeJjY2kHqOybbqu5crZiEut7io/A 3MYdjLiN1dj11tykxFBOLw5flwI+ptusF6sXb9BKTJ3JOsB3QqyC8o=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Apr 2017 11:57:49 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Apr 2017 11:57:48 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407764.msg for ; Thu, 13 Apr 2017 11:57:48 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170413:md50005407764::w7Tc8kq3H7C6b0mr:00009nNt X-Return-Path: prvs=1276e13cdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 13 Apr 2017 11:57:47 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <8F80DE9D-0677-4568-B211-9D79067BE22B@consulintel.es> <6772D740-0589-4B28-ACC2-252C6ACB8360@employees.org> <0E84BD53-6022-4681-B8F8-7B64760D023A@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:57:57 -0000 No Ole, actually I don=E2=80=99t think I=E2=80=99ve tried it with Linux, ju= st with regular CEs, both from retail and provided by ISPs. There is no way the CE knows if the tunnel-end-point is a 6rd or a 6in4 or = a 6to4, and looking at your link it seems the same to me =E2=80=A6 may be y= ou can point exactly to what source line/section you think will =E2=80=9Cbr= eak it=E2=80=9D? Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: jueves, 13 de abril de 2017, 11:44 Para: CC: "v6ops@ietf.org" Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 Jordi, =20 > Believe me, just try it. =20 Oh geez... You seem completely stuck with the implementations (Linux ba= sed) that you have tried. =20 > I=E2=80=99ve tried this with many CEs that had a =E2=80=9C6rd=E2=80= =9D choice and NO =E2=80=9C6in4=E2=80=9D. If you use the configured tunnel = end-point parameters to =E2=80=9Clie=E2=80=9D to the CE, it just works. And= this is normal if you look into the details of how 6to4, 6in4 configured t= unnels and 6rd work. They do the same, the difference is at the =E2=80=9Cpr= ovider edge=E2=80=9D. >=20 > The CE don=E2=80=99t =E2=80=9Csee=E2=80=9D any difference between the= m. >=20 > In fact I=E2=80=99ve many customers using it, both residential and SM= Es. =20 Take VPP for example. Does not behave like you think every implementati= on does: https://git.fd.io/vpp/tree/src/plugins/sixrd =20 Ole =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 13 03:04: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 A980C1314A5 for ; Thu, 13 Apr 2017 03:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlVslYIwYDUr for ; Thu, 13 Apr 2017 03:04:47 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC23131487 for ; Thu, 13 Apr 2017 03:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492077885; x=1492682685; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=VOI76RQ50OAatPWFTSsfsGHCzwF8t5mrPhfI5dz2HEw=; b=Oj9UG4vn+juVo yDbo9ZcLJ76js7wh2tgyahMlrq1lYF6LEw5zPUH8LbaV8jksOqcguYou72xAQ6DD F4pmMMhDoqrqQFBc0AfTd1xHzp11Dgac4x48STdxgY/1w1K1peFhC/Fi8JOqbFQq qsoa1tPEBldLtzXTE+tWdguKsBe2AI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=tenpMJtmIvyTq/zhU+il4u8chUPzRDIy77VX8zADbLfw5HcHGoVyAUZlnqu/ yBQMKnp/+dBeuurzc27wWFvF7F385PaI+5zCZ925iHhzUotPsnd3UKahW r/grNP1OOesSc4r7LbqGRmHIz9T7neNHF7Y1pRzz85bM9zvmm0kWEM=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Apr 2017 12:04:45 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Apr 2017 12:04:44 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407776.msg for ; Thu, 13 Apr 2017 12:04:43 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170413:md50005407776::gSp1NgubijjH9Po0:00003WYh X-Return-Path: prvs=1276e13cdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 13 Apr 2017 12:04:40 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <20A9F884-38CF-47A1-86C9-99B52CD7A7B8@consulintel.es> Thread-Topic: draft-ietf-v6ops-rfc7084-bis-01 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] draft-ietf-v6ops-rfc7084-bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:04:50 -0000 (changed subject to focus in the actual version and discussion) Hi Barbara, I see your point and I understand it, but I=E2=80=99ve done the following t= o make sure that there is no discrepancy. 1) I=E2=80=99ve re-read with a lot of care RFC5569 (6rd), RFC3056 (6to4), R= FC2893 and RFC4213. 2) I=E2=80=99ve also searched for MAY, SHOULD, MUST, etc., and other =E2=80= =9Cpicky=E2=80=9D text in those documents. 3) I=E2=80=99ve concluded that there is nothing that any of those documents= is requiring that is not already part of the 6rd requirements. It will be nice if someone else can reassess that, so is not just me =E2=80= =A6 If that=E2=80=99s the case, and even more, considering that the complete se= ction is a MAY, I don=E2=80=99t see how this will conflict with your actual= RFQs, etc.? Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 21:20 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 =20 > RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is = referring > to RFC2893 (6in4, protocol 41), which has been updated by RFC4213. >=20 > We are talking about the same. >=20 > If you have a 6to4 router at home, you can just try. Create a HE tunn= el > broker, and input manually the parameters even if your router only sh= ows a > 6rd in the GUI. It works. Believe me. =20 What I think I hear you saying is: If a CE router implements RFC 5569, then the access network can use the= CE router's RFC 5569 functionality to deliver a RFC 4213 tunnel. =20 If this is correct, then what I'm saying is I will not support a requir= ement that dictates I and my CE router vendors (who implement 6rd) MUST loo= k at or read or scour RFC 4213 to see if there is some additional requirem= ent that RFC 4213 introduces, because they are now required to be compliant= with it. The reference to RFC 5569 SHALL be sufficient to direct implement= ation of the functionality, with no reference to RFC 4213. UI requirements are out of scope. Barbara =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 13 03:33: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 57F2B1314DD for ; Thu, 13 Apr 2017 03:33:44 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8YRxd9Th1Euc for ; Thu, 13 Apr 2017 03:33:40 -0700 (PDT) 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 941461314DB for ; Thu, 13 Apr 2017 03:33:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C5606A2; Thu, 13 Apr 2017 12:33:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492079617; bh=0SVUNucRwGu3zQlv2OUCGCft+345MHOACsk2qgfRxVU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UrMkpMFlriF3spqt+geMllx83Uz7+sp78DqrXDuXodEAla19inc8evjPphiIe+gyD UyI/zKKBsOpFk337i+08Ngu8Szuj78WnSmRQBMqRUfUIfKhTFyiEqsELzIubHV51Ly nRVgDysqRdnZ8smlTwceRmbQwBjA/qeC4Cd8/FrM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AD9F888; Thu, 13 Apr 2017 12:33:37 +0200 (CEST) Date: Thu, 13 Apr 2017 12:33:37 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: "v6ops@ietf.org" In-Reply-To: <8F80DE9D-0677-4568-B211-9D79067BE22B@consulintel.es> Message-ID: References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <8F80DE9D-0677-4568-B211-9D79067BE22B@consulintel.es> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:33:44 -0000 On Thu, 13 Apr 2017, JORDI PALET MARTINEZ wrote: > It is simple to understand, because both, 6in4, 6to4, and 6rd, actually > do exactly the same encapsulation/decapsulation (protocol-41), and > exactly the same routing thing. The difference is that in 6in4 is called > a tunnel broker (or similar), in 6to4 is a 6to4 relay, etc. All the > parameters in the UI are the same. Not necessarily. For 6to4, you basically don't need any user settable parameters. It's all well-known. For 6in4, you need delegated prefix, remote IPv4 relay address. For 6RD you need even more parameters, especially for the modes where you don't map everything into the full IPv4 32 bit space. So the UI designer need to take into account all these three, or the user will probably be confused. Yes, 6in4 and 6to4 are subsets of 6RD but they still require different code to do the UI and input validation correctly, compared to 6RD. My opinion is that your text should be changed to something like this to paint the minor difference in a more positive light? ---- The CE router MAY support 6in4 functionality. The main difference between 6in4 and 6rd is the parameters needed for configuration. The on-wire and forwarding plane is identical for both mechanisms. Thus, if the device supports either 6rd or 6in4, it's commonly a minor UI addition to support both. If 6in4 is supported, it MUST be implemented according to [RFC4213]. The following CE Requirements also apply: --- I am not really happy about above text, I'm sure someone can rewrite it even better. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Apr 13 03:35:29 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 596731314DD for ; Thu, 13 Apr 2017 03:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 M0EfLsEBWcr1 for ; Thu, 13 Apr 2017 03:35:26 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAC21314DC for ; Thu, 13 Apr 2017 03:35:26 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 13 Apr 2017 10:35:25 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 59C54D788F; Thu, 13 Apr 2017 03:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=7bgoSoN5Lowp+GsoGYT4RI3Ql50=; b= rhwUwuZQBGVj/RIeSy3LuQVbDMX54wLTqd18ODyATQxkbXiYd10MWyE865Sq2t6Z h7eQDDmgNd8LAZnHLP5X7ZfJXreJSfpgivprtpN8N+6AqI7yQtMirOyanD4mcq0z 6RWbh53poJ7sjqa2c7u4hcpV1mj8tHcSi3AYStkGtMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=qN2I1gL5iak4DpS+3ptyYE3 Lrl+4EqGm+qFgJeOZiCCMLARizZUYtImZYslvgCX96vhQ7UqGjm5wm62IXzq1zsd IfboFgXXH352Vi72ppjN50HvWz9LjS/zAV0rQAUns/xti348f7ARG2s9wRNnXNEG b2W0xPUT4nx839gFYZ8E= Received: from h.hanazo.no (77.16.76.254.tmi.telenormobil.no [77.16.76.254]) (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 1891FD788B; Thu, 13 Apr 2017 03:35:24 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 160B9A9A8C0D; Thu, 13 Apr 2017 12:35:19 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A17E25F0-6025-4C71-8FE8-746912834693"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 12:35:18 +0200 In-Reply-To: <20A9F884-38CF-47A1-86C9-99B52CD7A7B8@consulintel.es> Cc: "v6ops@ietf.org" To: jordi.palet@consulintel.es References: <20A9F884-38CF-47A1-86C9-99B52CD7A7B8@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-rfc7084-bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:35:28 -0000 --Apple-Mail=_A17E25F0-6025-4C71-8FE8-746912834693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jordi, > (changed subject to focus in the actual version and discussion) >=20 > Hi Barbara, >=20 > I see your point and I understand it, but I=E2=80=99ve done the = following to make sure that there is no discrepancy. >=20 > 1) I=E2=80=99ve re-read with a lot of care RFC5569 (6rd), RFC3056 = (6to4), RFC2893 and RFC4213. 6RD is specified in RFC5969. > 2) I=E2=80=99ve also searched for MAY, SHOULD, MUST, etc., and other = =E2=80=9Cpicky=E2=80=9D text in those documents. > 3) I=E2=80=99ve concluded that there is nothing that any of those = documents is requiring that is not already part of the 6rd requirements. >=20 > It will be nice if someone else can reassess that, so is not just me = =E2=80=A6 >=20 > If that=E2=80=99s the case, and even more, considering that the = complete section is a MAY, I don=E2=80=99t see how this will conflict = with your actual RFQs, etc.? It doesn't appear to me that anyone else but you want to include = configured tunnels. Cheers, Ole >=20 > -----Mensaje original----- > De: "STARK, BARBARA H" > Responder a: > Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 21:20 > Para: "jordi.palet@consulintel.es" , = "v6ops@ietf.org" > Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 >=20 >=20 >> RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is = referring >> to RFC2893 (6in4, protocol 41), which has been updated by RFC4213. >>=20 >> We are talking about the same. >>=20 >> If you have a 6to4 router at home, you can just try. Create a HE = tunnel >> broker, and input manually the parameters even if your router only = shows a >> 6rd in the GUI. It works. Believe me. >=20 > What I think I hear you saying is: > If a CE router implements RFC 5569, then the access network can use = the CE router's RFC 5569 functionality to deliver a RFC 4213 tunnel. >=20 > If this is correct, then what I'm saying is I will not support a = requirement that dictates I and my CE router vendors (who implement 6rd) = MUST look at or read or scour RFC 4213 to see if there is some = additional requirement that RFC 4213 introduces, because they are now = required to be compliant with it. The reference to RFC 5569 SHALL be = sufficient to direct implementation of the functionality, with no = reference to RFC 4213. > UI requirements are out of scope. > Barbara >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_A17E25F0-6025-4C71-8FE8-746912834693 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY71RmAAoJEL7aWKiYQt92jLkP/3EIyJg4/UrkOkQWfkSU53RL oeT5CTBgTfyh5Y7xVgWd/eh0jHk2zaiKrSFyRAh6JUZLFKEbHJDA25RXRPSkTynx H/imv/ilFiUB1AEcFFOHPeF3Q6MhHK21uR8qXwgmg2H3qqQILMdit/RGZjPACQbh 07Sy4gXrM+dLakHp3dV6qFkXAAxwdwSDvI6JzkL9hOob20L6M5/c+t5aak9KJHr+ 6r8E7NSQQYT20ZgzmzD9Y48OiLbM/Rcnwk/1DyaDvtqrpsszz1tXzbhp+WxRMSkL BHhfJMi3kCjbNnzk95gzeg8Y+8+ZKsKCGE67LzlDgU1c0OMLhybogqweqg0eih1M mqgiVvITuu5G9X9wq+Eqm2C3vwWPv3R7efqDE5fZG9Qemh5AhLYrz+R9dIjL/bHU UGkFYoBCN6POrXdDRT2A2E30fAG33KUec9aARZ67uphLT9rnNhLQEl8xC/RBl66O HamgZ219oQZReewmFIQ7X/gzcBioSIoIW6paMIbqvKLfuPMMuyzn1fglIXqzcfxs RYPva+dtVE/7Ig8/KjeG9HttDe+8x5KTIO79lxmySpUYYr7J+lcs9km25fCmwhjk KHor0hUX+mVJojIaWJoWHqfiP3OuTfH9MFNHFltdsxG/OMkECmF8XXP/mHNOdZbK em1X/wL8vvV6EGRzSlAq =UDhG -----END PGP SIGNATURE----- --Apple-Mail=_A17E25F0-6025-4C71-8FE8-746912834693-- From nobody Thu Apr 13 03:35: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 7B5E91314FD for ; Thu, 13 Apr 2017 03:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJszRa-iKT28 for ; Thu, 13 Apr 2017 03:35:48 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81211314EE for ; Thu, 13 Apr 2017 03:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492079737; x=1492684537; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=yCkTXhA1h+cD7nnJrd+xnqv3Y ApofRPht3lzcqk45oI=; b=q9N0oQ5xbC0ILWsTVYc//x1xd6hDcUbsiXjf/sZCo yEq9+Cw7louSvWhDFr1Hs25fpeBOyDnMvbZWmKFhrBkkwjmHX2wfK5m4uwtVJs6y Bm/dQEQMlE7Bgv3QjoiemDXJp5+GNmH672BziEjAHdjdv7D2s6Yiz3Bo/Rp4DkMA eM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=iqHtmfV0gFCOb8YJX1Z0vsARIshZz0PFAZbF0jKmogkSwCEuEC8ExHSXT3wY Y74S+BPtvo1d66URJo1ctuzd4SuZ3/JI8F5OLdlXroy2C4TbTXGBAVAoO ySylNY+fb8QuMHqTcnVwA7NuwNp8yZDlw1VPjizeLeoTdi86H93NOo=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Apr 2017 12:35:37 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Apr 2017 12:35:36 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407795.msg for ; Thu, 13 Apr 2017 12:35:36 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170413:md50005407795::0EoOq8zIKpQegOh9:00004chq X-Return-Path: prvs=1276e13cdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 13 Apr 2017 12:35:31 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: draft-ietf-v6ops-rfc7084-bis-01 References: <14D93EAB-485B-49D9-89A8-4746EB53839B@consulintel.es> In-Reply-To: <14D93EAB-485B-49D9-89A8-4746EB53839B@consulintel.es> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-rfc7084-bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:35:51 -0000 Forgot something to make it clearer ... Even if a reference to RFC5569 (6rd) as per Barbara comment, may be suffici= ent, 6RD is referencing to 6to4 which in turn is using an outdated referenc= e to 6in4. I think this is a *possible* path, however my suggestion of usin= g a direct reference to 6in4 is *only* for the sake of clarity and simplici= ty to anyone reading the document. *no* further requirements implied doing a =E2=80=9Cdirect=E2=80=9D referenc= e to the source of the encapsulation protocol (protocol 41). RFC7059 discusses all those mechanisms and may provide also some light. My = reading of that document, again, confirms that there is no difference from = the perspective of the CE perspective. The CE need to know the end point of= the tunnel, and the allocated prefix, same for all the 3 (6rd, 6to4, 6in4)= . Regards, Jordi =20 -----Mensaje original----- De: JORDI PALET MARTINEZ Fecha: jueves, 13 de abril de 2017, 12:04 Para: "v6ops@ietf.org" Asunto: draft-ietf-v6ops-rfc7084-bis-01 (changed subject to focus in the actual version and discussion) =20 Hi Barbara, =20 I see your point and I understand it, but I=E2=80=99ve done the followi= ng to make sure that there is no discrepancy. =20 1) I=E2=80=99ve re-read with a lot of care RFC5569 (6rd), RFC3056 (6to4= ), RFC2893 and RFC4213. 2) I=E2=80=99ve also searched for MAY, SHOULD, MUST, etc., and other = =E2=80=9Cpicky=E2=80=9D text in those documents. 3) I=E2=80=99ve concluded that there is nothing that any of those docum= ents is requiring that is not already part of the 6rd requirements. =20 It will be nice if someone else can reassess that, so is not just me = =E2=80=A6 =20 If that=E2=80=99s the case, and even more, considering that the complet= e section is a MAY, I don=E2=80=99t see how this will conflict with your ac= tual RFQs, etc.? =20 Regards, Jordi =20 =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 21:20 Para: "jordi.palet@consulintel.es" , "v6ops= @ietf.org" Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 =20 =20 > RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which= is referring > to RFC2893 (6in4, protocol 41), which has been updated by RFC4213= . >=20 > We are talking about the same. >=20 > If you have a 6to4 router at home, you can just try. Create a HE = tunnel > broker, and input manually the parameters even if your router onl= y shows a > 6rd in the GUI. It works. Believe me. =20 What I think I hear you saying is: If a CE router implements RFC 5569, then the access network can use= the CE router's RFC 5569 functionality to deliver a RFC 4213 tunnel. =20 If this is correct, then what I'm saying is I will not support a re= quirement that dictates I and my CE router vendors (who implement 6rd) MUST= look at or read or scour RFC 4213 to see if there is some additional requ= irement that RFC 4213 introduces, because they are now required to be compl= iant with it. The reference to RFC 5569 SHALL be sufficient to direct imple= mentation of the functionality, with no reference to RFC 4213. UI requirements are out of scope. Barbara =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 13 03:39: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 856681314CF for ; Thu, 13 Apr 2017 03:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 MrdvkK6w6DTw for ; Thu, 13 Apr 2017 03:39:22 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8068C1242EA for ; Thu, 13 Apr 2017 03:39:22 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 13 Apr 2017 10:39:22 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 3103FD788D; Thu, 13 Apr 2017 03:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=FFEy7Q5IwWF2G/kTXHF5CEK56Qs=; b= OSynAHoR7D2AaboMu9i5xn6OYUBRQGV9gR/487z66ygmai2+QJi8xiPWUf7+Kwr5 3qI1CIxVFjEnjChjcpkWnoMmNi5qs+fzjR31LkT2nTFuIfJ6e5BhAXruBfSEBqjn LFBXqzOJAxVz9xnYqM9YovEZ/7j9rxy/LQ+mlcvR5Co= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=L0WsEnEuTBPcMMJqo6e8VW4 EUzMf+CcUSO9zqcfzpZVX5cTs4pKqGgxXIqguGesi5gcrfN7BcKxuz6lKKbNbvQb p/RmC5VM5JpwiUe4qpv8DTtWiAghkE0AHAaCfLvTItDxKxBXi7iA09Sj4WQsaxn6 WqRTlAVKnTZbNtTX2jNk= Received: from h.hanazo.no (77.16.76.254.tmi.telenormobil.no [77.16.76.254]) (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 810F5D788A; Thu, 13 Apr 2017 03:39:21 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CC7CAA9A96AA; Thu, 13 Apr 2017 12:39:15 +0200 (CEST) From: otroan@employees.org Message-Id: <34BF2556-12F9-4E4C-9C16-132029E96BBE@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_C1541E8F-8096-4C88-A64E-7B8C7C07A1BA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 12:39:15 +0200 In-Reply-To: Cc: "v6ops@ietf.org" To: jordi.palet@consulintel.es References: <14D93EAB-485B-49D9-89A8-4746EB53839B@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-rfc7084-bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:39:25 -0000 --Apple-Mail=_C1541E8F-8096-4C88-A64E-7B8C7C07A1BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jordi, > Forgot something to make it clearer ... >=20 > Even if a reference to RFC5569 (6rd) as per Barbara comment, may be = sufficient, 6RD is referencing to 6to4 which in turn is using an = outdated reference to 6in4. I think this is a *possible* path, however = my suggestion of using a direct reference to 6in4 is *only* for the sake = of clarity and simplicity to anyone reading the document. >=20 > *no* further requirements implied doing a =E2=80=9Cdirect=E2=80=9D = reference to the source of the encapsulation protocol (protocol 41). >=20 > RFC7059 discusses all those mechanisms and may provide also some = light. My reading of that document, again, confirms that there is no = difference from the perspective of the CE perspective. The CE need to = know the end point of the tunnel, and the allocated prefix, same for all = the 3 (6rd, 6to4, 6in4). No. 6rd and 6to4 are mesh. 6in4 is p2p. 6in4 uses DHCPv6 PD like any other link layer. The IETF have defined no mechanism to provision 6in4 tunnels. I suggest you think through the deployment model of this before you = continue the argument. Cheers, Ole > -----Mensaje original----- > De: JORDI PALET MARTINEZ > Fecha: jueves, 13 de abril de 2017, 12:04 > Para: "v6ops@ietf.org" > Asunto: draft-ietf-v6ops-rfc7084-bis-01 >=20 > (changed subject to focus in the actual version and discussion) >=20 > Hi Barbara, >=20 > I see your point and I understand it, but I=E2=80=99ve done the = following to make sure that there is no discrepancy. >=20 > 1) I=E2=80=99ve re-read with a lot of care RFC5569 (6rd), RFC3056 = (6to4), RFC2893 and RFC4213. > 2) I=E2=80=99ve also searched for MAY, SHOULD, MUST, etc., and = other =E2=80=9Cpicky=E2=80=9D text in those documents. > 3) I=E2=80=99ve concluded that there is nothing that any of those = documents is requiring that is not already part of the 6rd requirements. >=20 > It will be nice if someone else can reassess that, so is not just = me =E2=80=A6 >=20 > If that=E2=80=99s the case, and even more, considering that the = complete section is a MAY, I don=E2=80=99t see how this will conflict = with your actual RFQs, etc.? >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: "STARK, BARBARA H" > Responder a: > Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 21:20 > Para: "jordi.palet@consulintel.es" , = "v6ops@ietf.org" > Asunto: RE: [v6ops] LISP support for = draft-ietf-v6ops-rfc7084-bis-00 >=20 >=20 >> RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is = referring >> to RFC2893 (6in4, protocol 41), which has been updated by RFC4213. >>=20 >> We are talking about the same. >>=20 >> If you have a 6to4 router at home, you can just try. Create a HE = tunnel >> broker, and input manually the parameters even if your router only = shows a >> 6rd in the GUI. It works. Believe me. >=20 > What I think I hear you saying is: > If a CE router implements RFC 5569, then the access network can = use the CE router's RFC 5569 functionality to deliver a RFC 4213 tunnel. >=20 > If this is correct, then what I'm saying is I will not support = a requirement that dictates I and my CE router vendors (who implement = 6rd) MUST look at or read or scour RFC 4213 to see if there is some = additional requirement that RFC 4213 introduces, because they are now = required to be compliant with it. The reference to RFC 5569 SHALL be = sufficient to direct implementation of the functionality, with no = reference to RFC 4213. > UI requirements are out of scope. > Barbara >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_C1541E8F-8096-4C88-A64E-7B8C7C07A1BA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY71VTAAoJEL7aWKiYQt929m4QAKjMWfW7vKsm36X90TH1XD7N aAazx51v9xArRHzovb2lch6CEuGbCQ7jw4LzGRboawywYG3heFqzTSyYxHJj0jsa TKWY4bQQSINaFeoFzN0/GEP3cWeQIgTAkhWDhgGMyF/ryCkvNAncBjolJcRiiSid WKsjtig54pEOm6iBDSxfHLOfe3JlZ6z50IEhwNvdnWUd/YnT2auRmpqReUQDbSgW Ga9jeze1TE3UFA2wCnXAZwWNMlm+0e/oHY2lHhfW+/3QR0KeAfBywHaMAAMBRM/y Zly/wkPZWwQhHJOE9kb7PL1KcOSQlxyzqdntHr9LGz+jnR0utT2Svg8K6i6lTw0S OKgAuHop6Lo/9mEmzmN37n9CbOWPIkECGt8mjv4pAsVIPPHCJTad7UPfmE6AZurq NEl2R9S/3yc10onHQc6ci1ZtKYaEPz/nabshShmpT34PF+y5H+e/wi3aFszj8QVr CbGjWsY9r+LuXSR+47F/B5GcBn9B6+OVeNTox9fVptwOnixdX62DK9XSeX3md93t ZS1mli9vzCZ4RobP4/wwYm277dEqbKdp8HRe6J9i9XdR8jTnXV+zC/LQ4AsfqBWc 0WdF8POUQ7wriKYdxYbes2Ha8BPml0parzttI6c+FsWP9nYokxL4W/Fpf3y+Vp5r dcPwWun4JCDfu/+KJqEu =4ncz -----END PGP SIGNATURE----- --Apple-Mail=_C1541E8F-8096-4C88-A64E-7B8C7C07A1BA-- From nobody Thu Apr 13 03:41: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 96D681314EB for ; Thu, 13 Apr 2017 03:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD_4GNitb69g for ; Thu, 13 Apr 2017 03:40:59 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804E21314D3 for ; Thu, 13 Apr 2017 03:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492080057; x=1492684857; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=zfVcLYeRoYBVutt0ivbqhgK+j ASuEXqLlD0yxUOKqxM=; b=hBCe9o1t9p7fbC62UD656l0ZW/nxffz6fMZ9WMBNe 1UBoVF5ZGki/4oB9h6sQn4ElWBT4m4TnMg1pz5fx9NirW2KT6OWt1bL3xLDGjZEE R71r60d59JPexT9gKmZnKfSiPmZgy9B03l5z0tuqTyUQ0Jg1Cjz1F+bYiSxohycs tw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=kGzM7wpsc++akFxogaryelWFhVVlIvkZnK2rl3PJ4pfYExszcCjhDYiqszvJ /22uu8AncwXd3Ac3AjUcFJ72MEKKU1d2U+wZgB6U2K0/T6qvO8IusCEC3 M4cI5AP1RdMzZ0BVT6CF7DhZhBgPtaXQEzQxbZMbqJxjx5KASZvPnE=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Apr 2017 12:40:57 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Apr 2017 12:40:56 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407800.msg for ; Thu, 13 Apr 2017 12:40:56 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170413:md50005407800::6tki+7kOmBd5dcYy:00004GoV X-Return-Path: prvs=1276e13cdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 13 Apr 2017 12:40:54 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <4885B5CF-72DA-4F58-BAD5-C9006EECEECE@consulintel.es> Thread-Topic: [v6ops] draft-ietf-v6ops-rfc7084-bis-01 References: <20A9F884-38CF-47A1-86C9-99B52CD7A7B8@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-rfc7084-bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:41:02 -0000 Yes, sorry, typo in my original email about this that carried over the foll= owing. I=E2=80=99ve been talking all the time about the RFC5969, not the in= formational version. Saludos, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: jueves, 13 de abril de 2017, 12:35 Para: CC: "v6ops@ietf.org" Asunto: Re: [v6ops] draft-ietf-v6ops-rfc7084-bis-01 Jordi, =20 > (changed subject to focus in the actual version and discussion) >=20 > Hi Barbara, >=20 > I see your point and I understand it, but I=E2=80=99ve done the follo= wing to make sure that there is no discrepancy. >=20 > 1) I=E2=80=99ve re-read with a lot of care RFC5569 (6rd), RFC3056 (6t= o4), RFC2893 and RFC4213. =20 6RD is specified in RFC5969. =20 > 2) I=E2=80=99ve also searched for MAY, SHOULD, MUST, etc., and other = =E2=80=9Cpicky=E2=80=9D text in those documents. > 3) I=E2=80=99ve concluded that there is nothing that any of those doc= uments is requiring that is not already part of the 6rd requirements. >=20 > It will be nice if someone else can reassess that, so is not just me = =E2=80=A6 >=20 > If that=E2=80=99s the case, and even more, considering that the compl= ete section is a MAY, I don=E2=80=99t see how this will conflict with your = actual RFQs, etc.? =20 It doesn't appear to me that anyone else but you want to include config= ured tunnels. =20 Cheers, Ole =20 >=20 > -----Mensaje original----- > De: "STARK, BARBARA H" > Responder a: > Fecha: mi=C3=A9rcoles, 12 de abril de 2017, 21:20 > Para: "jordi.palet@consulintel.es" , "v6o= ps@ietf.org" > Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 >=20 >=20 >> RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is= referring >> to RFC2893 (6in4, protocol 41), which has been updated by RFC4213. >>=20 >> We are talking about the same. >>=20 >> If you have a 6to4 router at home, you can just try. Create a HE tun= nel >> broker, and input manually the parameters even if your router only s= hows a >> 6rd in the GUI. It works. Believe me. >=20 > What I think I hear you saying is: > If a CE router implements RFC 5569, then the access network can us= e the CE router's RFC 5569 functionality to deliver a RFC 4213 tunnel. >=20 > If this is correct, then what I'm saying is I will not support a r= equirement that dictates I and my CE router vendors (who implement 6rd) MUS= T look at or read or scour RFC 4213 to see if there is some additional req= uirement that RFC 4213 introduces, because they are now required to be comp= liant with it. The reference to RFC 5569 SHALL be sufficient to direct impl= ementation of the functionality, with no reference to RFC 4213. > UI requirements are out of scope. > Barbara >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 13 04:00: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 24DDA1314FF for ; Thu, 13 Apr 2017 04:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shyteBG7Rj-5 for ; Thu, 13 Apr 2017 04:00:18 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAA413150B for ; Thu, 13 Apr 2017 04:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492081212; x=1492686012; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=UGbx8UFkCvbqa9L/QhpnI53MTuag7PgsxculVA5nnLA=; b=A/xMP6Et6Y9Qt ToVKNxfZB2kmasCguLoenY/DvkxMiFkOLNXU2qt15XK4yrufQgJOrjm9n/w9h341 ZeBt0tby4uaE7ZWX9KuKLdreDIS4tnutGp4XeTBa7A/+Tnvu7zTlvMEYvglHikuf tRs+/m40uhZbum3Y6nDyuJNOAAqNHo= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=gskl39TGopBmggsZpPOOLjo84bAwnX6zE6iQcSG+H1/WT1ETS2jlI5dEr66d fzcxI+tmUot/pPbXBcgVJw/Yeusj9Bpxz/xDmKkvDhZGIujQK5FTtThir z/kTx0vYRKbAKT+bLyecKcEyHFmSrs8mDCfh5i87s68AR8nRPLoY/s=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Apr 2017 13:00:12 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Apr 2017 13:00:12 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005407814.msg for ; Thu, 13 Apr 2017 13:00:12 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170413:md50005407814::kNnbFAZb7sWDZ8LO:000051J5 X-Return-Path: prvs=1276e13cdf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 13 Apr 2017 13:00:11 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <1F9D5401-211D-4DF1-9E1F-3F060F37209F@consulintel.es> Thread-Topic: draft-ietf-v6ops-rfc7084-bis-01 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] draft-ietf-v6ops-rfc7084-bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 11:00:20 -0000 Thanks Mikael, Just to make it clear, I=E2=80=99m not asking for 6to4 support, so let=E2= =80=99s forget it to avoid increasing the confusion. I think you got the point here. 6in4 is a subset of =E2=80=9C6rd=E2=80=9D r= equirements/parameters, that=E2=80=99s precisely why it works with 6rd code= . So, I think we fully agree on that? What about this (I=E2=80=99m also considering latest email from Ole): The CE router MAY support 6in4 functionality. 6in4 used for a manually configured tunnel requires a subset of the 6rd parameters (delegated pr= efix and remote IPv4 end-point). The on-wire and forwarding plane is identic= al for both mechanisms, however 6in4 doesn=E2=80=99t support mesh traffic = and requires manually provisioning. Thus, if the device supports either 6rd= or 6in4, it=E2=80=99s commonly a minor UI addition to support both. If 6in4 is s= upported, it MUST be implemented according to [RFC4213]. The following CE Requirements a= lso apply: Regards, Jordi =20 -----Mensaje original----- De: Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Responder a: Fecha: jueves, 13 de abril de 2017, 12:33 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 On Thu, 13 Apr 2017, JORDI PALET MARTINEZ wrote: =20 > It is simple to understand, because both, 6in4, 6to4, and 6rd, actual= ly=20 > do exactly the same encapsulation/decapsulation (protocol-41), and=20 > exactly the same routing thing. The difference is that in 6in4 is cal= led=20 > a tunnel broker (or similar), in 6to4 is a 6to4 relay, etc. All the= =20 > parameters in the UI are the same. =20 Not necessarily. For 6to4, you basically don't need any user settable= =20 parameters. It's all well-known. For 6in4, you need delegated prefix,= =20 remote IPv4 relay address. For 6RD you need even more parameters,=20 especially for the modes where you don't map everything into the full I= Pv4=20 32 bit space. =20 So the UI designer need to take into account all these three, or the us= er=20 will probably be confused. Yes, 6in4 and 6to4 are subsets of 6RD but th= ey=20 still require different code to do the UI and input validation correctl= y,=20 compared to 6RD. My opinion is that your text should be changed to=20 something like this to paint the minor difference in a more positive=20 light? =20 ---- =20 The CE router MAY support 6in4 functionality. The main difference betw= een=20 6in4 and 6rd is the parameters needed for configuration. The on-wire an= d=20 forwarding plane is identical for both mechanisms. Thus, if the device= =20 supports either 6rd or 6in4, it's commonly a minor UI addition to suppo= rt=20 both. If 6in4 is supported, it MUST be implemented according to=20 [RFC4213]. The following CE Requirements also apply: =20 --- =20 I am not really happy about above text, I'm sure someone can rewrite it= =20 even better. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 13 05:14: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 7853F131598 for ; Thu, 13 Apr 2017 05:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, URIBL_BLOCKED=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 LJU_xcUVU7Wf for ; Thu, 13 Apr 2017 05:14:35 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0138.outbound.protection.outlook.com [104.47.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527F413158E for ; Thu, 13 Apr 2017 05:14:33 -0700 (PDT) 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=sBYOR8h0qMVAJG3yn5mapj0GzvV0BLjIjrvobIGqJvs=; b=S2E3snCII/jpPwc5pbiBb7oHaCLfLoceBZbSStP7M9Fc4/oA2ws+KMSQOqgu2GxJV8sak1yGlErmAIRaNyoeVqou0oP5mqzzchOsQu87Wgjr3141hYviBPx+P3n9FOw58BdubvdrCkXmNHMNF91z3xLcWzfhFf/3VeGscncM5O0= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.156.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 13 Apr 2017 12:14:30 +0000 Message-ID: <06e301d2b44f$361c3500$4001a8c0@gateway.2wire.net> From: t.petch To: Fred Baker CC: IPv6 Operations References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 13 Apr 2017 12:57:04 +0100 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: [86.169.157.161] X-ClientProxiedBy: AM4PR05CA0034.eurprd05.prod.outlook.com (10.171.184.175) To AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.156.144) X-MS-Office365-Filtering-Correlation-Id: 02051617-3f36-4951-2dcb-08d48266a37a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2994; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 3:74lLovcRfU/9ybspDFkmHT88DbodNpCgMsmg18Eo3gb3p1ycQpihdFYqYaS1TGaMIwqtAZVK4eHeLZLzGS1XzChcgna4zDMShBJ9xPs0lwwIFf3uXEGyCi55MHfrmbC9dL3+M77iAr27UBokfLq1VrLSOPdLCVbosKpifwpeExCJzsykyiGUF/cK80VcVZd7vqQMohqxQl8CK+ZXY4WyD9tCs9rcdM4AF20rtbniXqtaAzVlN2289SZ0kEYaVU8TlkWwP1LT8n+YrN35QF4SXd9CGL+P5X5uPaKglV7pNdhadI870MY8TQpk3nllWejWvwvXk+vXAraEYZ5seR/Mnw==; 25:dkLc2jcNXDFITkXcR6hpVH32rC8YHzZ9m2h6QSInt8EBbvDBvvbvTyBe3hu+PST/haUw5cjfR7au8Sfu2CEjJZca2/BtLyHG4sjzrfNHJeGhCdXyOnRrESOweXvFXiUfoPK7ZCaue9Aibjva3wEnEKhbkDx7MSl0kIiyr9j3WLjzk7IrF+foNU5LhmeAuwcfEfiXf+WgO9/0R8LE/a7rhYVOatJJT1vAMysPt0wAJg/FUjX/cNZnkErXKy2+q7gop6IC9ygb086Vsy7hghsUbIOfFLFcL3BK1TYGZJ40FaY+MEO/lXZgSsdLlaVSQtpCZfHWGlcm/JIdmNol36ATmSxts56JQDC/LD9oQ+TH80gVGtGv2f49DFF+b9Fculb+A87/al9ozOmbNpNeV2LZAIO151xVt1RoQoDLH31G43+OKz4Z9/XjicgQLF5URPXSXqwFqAPgVqybPrsPuOtjls457YeTkn8fsvGJvVR2VfA= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 31:7aRt1JuwZy2urJ/NZ7TNiIsstja/QgpN9cLvYbd4jijJMUM4lUfNDtJsft9B1BNA7MW2FHRpDLVfLSApspEsLE3Ek3jH3QTBkeDwSzrMMH+Hhcj2S6aC6+1+LOqsXYewElQ8OWW9GepOi0T7lq/sFdyVxo0uTLIeXTPXs5yU1vM90KbmQNeJSas7BTrYpRrt3cBffoiI+qTPnhcLtLwyz9PG2G8OBH55H6XZhftyAAuqXXZrAfiYx0M3/CKEpYJm X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(97927398514766); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM5PR0701MB2994; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2994; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 4:Z1ZGfwy1bEG95rVF4iFglZHEoliGd8vZ36AhYAwFoQ30g5m3lSpdJJu3SoBuIdu3Bxh5YURzdo5feVOhhXBIavW6pO05yWDvzzMyM10wIC1gvdyQ7axvv9CppkRNS3qH/7o23WgLxj/wPwuQOoE5YCxx5KyTrfe9R/JuS0gvOjUb0v8wR++EmJWIXk3afybUyq+y4ttauK+fH6tO5SLA79Xl91hZw0FP95QFVFollcbq/nRAx9UAmfMcXEIybLmiqoGkc7054+Ix7owz2Yz+WhT1DqJrtjYoOmtZhUfdsUalPqDSaz14w5udySNpNghuO1GoaQsjQWo7xWsbC3YWTLVSlUUpVrwT8WqdT8lUtsShXv7ux2lrzBgMTQbnGZwWJWq60Qt3KM0j4oVtLptA5evpPI1yj7TS0mzBgqVxPs/WV/oxaenOrGiOYrF7JMaTobSgKNLpvCWqEF9JCQ3g9E9HcxcwN54BI2IAIlLI6Df8ODdNS+o6sudrz9VtQo30v5BNASAH6SCV+9fxHwVKFVkrExvxO1ywCkosq9qU9CsUH/aF+IUWvYJHd7yLpCRmLqymqi4vXYZ+6F0sjejDPpyheu52H71TsuOW/g+SXh9cgHqdAaVkjmqw6Sesm/C3sExl/fRcJngSX2iIBIbbZEYQEk0OTExKJcwlnNJ4/bIwHn0T3H9ajmdj+Vp9BXdz8nH0nVa1bf1ixmZ1P7nTfWCFzSpinJXN++rM/xN7QupWr9M949O2t3Al84QQd6oU X-Forefront-PRVS: 02760F0D1C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39850400002)(39840400002)(39410400002)(39400400002)(39860400002)(39450400003)(24454002)(377454003)(13464003)(6116002)(230700001)(3846002)(50226002)(8676002)(7736002)(44716002)(305945005)(81166006)(86362001)(33646002)(47776003)(42186005)(61296003)(66066001)(229853002)(44736005)(76176999)(6486002)(6306002)(9686003)(116806002)(2906002)(25786009)(53936002)(93886004)(6916009)(6496005)(50466002)(6666003)(23756003)(4720700003)(38730400002)(6246003)(110136004)(81686999)(5660300001)(50986999)(4326008)(81816999)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2994; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2994; 23:slSCZOJ71zojZsaac6XLZDaQ66iktl1dKoNMy?= =?iso-8859-1?Q?7N702lRXxwPfnOUoq+DTocFJQTLt1mc4C3ayni5xAXkY7FsVVdiC6VQzX0?= =?iso-8859-1?Q?RiyDJYSmfPCC1O5kRCZCn5eJbNTuyRSDkyipJdw3mVTowKPYBOx4cBgKVf?= =?iso-8859-1?Q?QfCaVChJOoCNcMUj4k3BhOzDAlo/B83tOnstMeBn1Aayfrr0UN+M+XRuvx?= =?iso-8859-1?Q?b5lDhkyqLs2PRLQtbZiwJigkH4ZFwJKSXBurquVjP7C85rZGGJ3WUV/+yV?= =?iso-8859-1?Q?cQN+z3w1BmAiMZb8gxTYOBQln5cYSSgwlbAtKi8W8criYrFb3DGYhl/EcH?= =?iso-8859-1?Q?OI+Rnb34QnxwcSRgiRx4LRG0z7RwGAd2eWZ8Fd1Jh/QMUQYM1Fi33qno3J?= =?iso-8859-1?Q?3n+GU+eLVXaPxdTnJQpc1rpBcrcafLOC2GwcCRmXR/Mj74uapgVmIP+dKt?= =?iso-8859-1?Q?xKR+BrJD7uCbRZA1yxDoJQKXRuzXzaF3RS8+2afSYtD39wm8EPsRbTaefA?= =?iso-8859-1?Q?d9ONkmX9xXUXcKTlyu3l/nBBak+eDKjWyfRQCbE/jdpBzNMpJbK9VHxsUq?= =?iso-8859-1?Q?ccY6CsvAmERMcndV22rQAPCp1P+1xBM7gTp5qZ5RYcPcSy9ouvV0fCfut+?= =?iso-8859-1?Q?aTiUl36RxpxcpfHM/E82LVX/SvO2rumGmSp8n/uPPzUgfoc1feAr/OzLpD?= =?iso-8859-1?Q?KRj8Mj+cU42HNM4TEnUemB9AP1B1xlH919CcBifJPIlh1dBjQ549ZuBk5n?= =?iso-8859-1?Q?B1kA/2svC4CsE+QFP+bmGbs1Yo/SpCjKi1FiqYGzH9cI4Sgus/dj1XUUE1?= =?iso-8859-1?Q?kc2K7aBlTFYaGCiS4w1vt6xeap/6hXBZR5eDXhWYe/YMPVkzdRUyrsvOx9?= =?iso-8859-1?Q?FASdRfm1qKTHgM3X9Es9fLLxvutDO8yvYpvjVSpnYJqsIhWr1HLb3eeyfk?= =?iso-8859-1?Q?3aXqmRk2b3yItYIY7UnHt5avk6tJs3U822I/CSdxH4soDxB2PRANcWESMm?= =?iso-8859-1?Q?+Ca8zd6ZnBBghMA09icj1tlHOhngWxkQdXCrzAfbA+Tlv7Fky9fD2FLCJY?= =?iso-8859-1?Q?LEo6pKgNHUxOk+uDTuBNoECXBJ8HNId4jE4J+F3TiwVlhUP033H/wvwbZ8?= =?iso-8859-1?Q?P1IxCYZTatStOaqOqzee5qFLM/A3/PnxrIcz5UjIEaeIADKPjKyWkSPlCF?= =?iso-8859-1?Q?sqsA2xK6fDM1wqxGOzsmvs1IcuXtOMlNJfNzt1nZZSCzIYTt0lZ8MF9zkQ?= =?iso-8859-1?Q?lEsiJrtW8v9CsMEohqCLRnK9Ilfk9uKyCumkmX+nGdZYDXtrK0js1q7seh?= =?iso-8859-1?Q?ONUYpgy76UTNt36SebUDsCGCU?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 6:u1MQMkWFLktPVLPq3XnMQ5hGION3Kh/vmHF92aT/6dOqNBg+E6D/vTB20w8vl215yD3VMwL7vEVHVgrtRAbTTN60+4FECDn1qblCQYVP8uyzOiPqPCMgSVhlifeMgyZ0SvyFVg06K3re95A2aqE2t5WMh6xQacqUvjUvsKXga1jUeM9RhuRi4kN43bP26i1tpOtyx937ezVKU7l5B14KP/sYPCoYjv/vWVd7r1iEVtHyLk/qtUnlkcSJ8X9UvUaXmlLPTJGSdAu5IuGXmCnel2VLVBZJmuN5KBUqmtuUDzsOHRKIqmjaZf97PUUZcBPu1O/1bISYI6yIGjvTjIS6sUno8Kx3BHnjaEGfnqcRrvDqairHP1KOa626OQtDDqAugQWJ6VKY88NAYEgSBm0zZHF/ez395h9jUmQ3cPsyN+lToVjI2DYIG8rFqwHwuVVoN5nEfGK+UKB8xTRnJlhQ7A==; 5:H7yTTN/qlnNH39RO+tfatxo5NFhO+RFxHUoh/5xiYlQLA/1I3FPCef3JuAczD5DshsdxC1ZhhcxDuKEyY0wW+zc1Fa0jMTR/TWeK3/y9yasuB03UbF4JOgeYBRPo4eVyy15lXcF7k4hswWB1Ds50WQ==; 24:4rE4c72KbDX9ZKFfESlmSk95BzAxd9/1pT/2dzRXOFZuAze6oPaBuO1rh1fdGo4EK1HFfJkKR5JchrPCVlGiFwa1QkFbKs7c9cdx1OdUQh8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 7:jSnSEvYQWOuIbviWCaTjtIAzukGNYHhKivA81hhoIntIRZCer36fW9WIMU6NL6Ho0ZDhU42oVQRdHot5/TRB9afkVTWGeS6dBAHPAVW1fgecTGEijxBoX5QlVFDoY94gE7Kz/jeBEkaz1VuOEcpoKlFmdKfXWqmruGfYRabDHvS1bOTIYsVqodFZ7q+qGpN2F35xaOBNwIA4min8pLSnQFPdebPSyBDOFanpbaRYAjsW2hypbIfZFY5NRK3j/vCTBqvFGGuHMnKYBw8yOQzHr7c3nVHCZlMwDyC4Z7/wZAnHpAmLTwp5IWc+QKV1JHJLj6QBglOXIFXDaDCZsHmeAw== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2017 12:14:30.4979 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2994 Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 12:14:37 -0000 Fred A week ago you asked for feedback and set the :Reply-To to V6ops chairs. I just got a bounce from my ESP saying that it had tried and failed 52 times to deliver the message, so your feedback may be incomplete. "Delivery has failed to these recipients or groups: V6ops Chairs (v6ops-chairs@tools.ietf.org) Your message couldn't be delivered. Despite repeated attempts to contact the recipient's email system it didn't respond." I can send the rest of the bounce if needed. Tom Petch ----- Original Message ----- From: "Fred Baker" To: "STARK, BARBARA H" Cc: "Fernando Gont" ; "IPv6 Operations" Sent: Friday, April 07, 2017 5:31 PM > > On Apr 7, 2017, at 8:08 AM, STARK, BARBARA H wrote: > > > > What I'm reading is that some enterprise operators want to use IETF to try to force Google to implement DHCPv6 client in Android. > > It is both inappropriate and ineffective to try to use IETF to bully a single company into doing what you want, just because it's what you want. > > For the record, I think there is also a subtext of bullying Microsoft into implementing RDNSS, and I think Sander's complaint about vendors trying to force their vision of the world has merit. Yes, there is an attempted forcing function here. It goes both ways. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Apr 13 10:17: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 D07F2129B1B for ; Thu, 13 Apr 2017 10:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 a7uwyaO0hi1U for ; Thu, 13 Apr 2017 10:17:26 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 342AD129B98 for ; Thu, 13 Apr 2017 10:17:26 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id i5so31277889pfc.2 for ; Thu, 13 Apr 2017 10:17:26 -0700 (PDT) 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=R0T/VIe48vOFWQYKPGrMhzk9UKxgFI9Z648kYnnhXmE=; b=tKhrCpbOKqkhv0IoO6ZDHmrt8As/89Cu3zcoS9aiXQBB+Glp2dixTtXK5RckMBNJR6 AHID0CFTtQhQHfoNWmRExGSv4j+kI1gBKoTmKJmraiYeP+8nAA/eoBwwWhQihkVW2H5O enFmCNowD+mWSELpj0B1Rs3VG9deP0K2OYS18WdQAWYxAEeHQYwlnt80qJkGR+z+rTwV hYICea1jIBiC1D2MKvKGdnyrava+h++3QMAcD2T6ty22WykFhWg/pmMxkECIfznAWjvH JfQDj0WTq/NKaFBUl0NRBGp43YmFF+FvL5Ge/WtZyJ62Tog3a6sG/TJ2kw3QWmksiz5n AUGA== 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=R0T/VIe48vOFWQYKPGrMhzk9UKxgFI9Z648kYnnhXmE=; b=R4BUDlLg9y3uP9xP4ztnvWOXevoTL5IErnj7c86qakXvviciLfk+n3GiFzOj7c31yp 1CahX/s0d+MLdo7qMmplbThro7QdIQh7I1QWBVrRlJLud/1AbqXOAc5hfYk/iqExcGcM DuKDo1IS3M+HiuQbCQOml+Y2BP/ntWaKS3G0jrf/JXeaocUDynjhThetsp4dSZnShVDr h+lbOPGl2YzDvBgB8rFmsVlb4MGmOKqeDa62xWgwupKKdzk0ek8zljDOw5L4+NR+0stX 7DuJ9OWRmuGnv83Xw9dTIgfc+zH36GvsHpgRiHkFWc3mPcV+Bb3rFmfpji8bURq2kwVn QxEw== X-Gm-Message-State: AN3rC/431IziwvkAQJKWsfZVnE8E7eEHxm+jf8N3pG8gFpHHjBWhHBSd PbGFSOfg927kUQ== X-Received: by 10.84.143.195 with SMTP id 61mr4780279plz.158.1492103845888; Thu, 13 Apr 2017 10:17:25 -0700 (PDT) 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 d2sm29339671pgf.46.2017.04.13.10.17.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 10:17:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker X-Priority: 3 In-Reply-To: <06e301d2b44f$361c3500$4001a8c0@gateway.2wire.net> Date: Thu, 13 Apr 2017 10:17:25 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: 7bit Message-Id: <0A8E00AF-A362-4D42-B72A-07A095BA1425@gmail.com> References: <1d62cc94-3f4f-0aef-f8c8-abfdc9f3685a@si6networks.com> <8B68BB24-05A2-455C-B61C-2B7678FEE9C1@steffann.nl> <2D09D61DDFA73D4C884805CC7865E6114DB16502@GAALPA1MSGUSRBF.ITServices.sbc.com> <06e301d2b44f$361c3500$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 17:17:29 -0000 Weird. The alias works when I use it... I'll send it to AMS. > On Apr 13, 2017, at 4:57 AM, t.petch wrote: > > Fred > > A week ago you asked for feedback and set the :Reply-To to V6ops chairs. > I just got a bounce from my ESP saying that it had tried and failed 52 > times to deliver the message, so your feedback may be incomplete. > > "Delivery has failed to these recipients or groups: > V6ops Chairs > (v6ops-chairs@tools.ietf.org) > Your message couldn't be delivered. Despite repeated attempts to contact > the recipient's email system it didn't respond." > > I can send the rest of the bounce if needed. > > Tom Petch > > ----- Original Message ----- > From: "Fred Baker" > To: "STARK, BARBARA H" > Cc: "Fernando Gont" ; "IPv6 Operations" > > Sent: Friday, April 07, 2017 5:31 PM > >>> On Apr 7, 2017, at 8:08 AM, STARK, BARBARA H wrote: >>> >>> What I'm reading is that some enterprise operators want to use IETF > to try to force Google to implement DHCPv6 client in Android. >>> It is both inappropriate and ineffective to try to use IETF to bully > a single company into doing what you want, just because it's what you > want. >> >> For the record, I think there is also a subtext of bullying Microsoft > into implementing RDNSS, and I think Sander's complaint about vendors > trying to force their vision of the world has merit. Yes, there is an > attempted forcing function here. It goes both ways. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Apr 13 10:39:09 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9347129B35; Thu, 13 Apr 2017 10:39:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: v6ops-chairs@ietf.org, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149210514779.15804.11448190653920016384.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 10:39:07 -0700 Archived-At: Subject: [v6ops] Spencer Dawkins' Yes on charter-ietf-v6ops-04-00: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 17:39:08 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-v6ops-04-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a Yes, but I'm not a Responsible AD Yes. The ballot tab says "ready w/o external review", but both questions are on the ballot itself. I wouldn't object to external review if other people thought it was important, but I'm happier if people in other SDOs assume we're already looking at deployment experience :D. The following is a nit, of course. The last sentence in "The global deployment of IPv6 is underway, creating an Internet consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and IPv6+translation networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks, ensuring addressing and connectivity for all IPv4 and IPv6 nodes. An important aspect of that has been the shutdown of IPv4 in some networks, which has resulted in innovations in network operation." took me three reads to parse. If you think it could be more clear, I might suggest replacing it with "An important aspect of IPv6 deployment has been the shutdown of IPv4 in some networks, and this shutdown has resulted in innovations in network operation". And, now that I think I understand what is being said, I wonder if "An important aspect of IPv6 deployment has been the shutdown of IPv4 in some networks, and issues and opportunities from these shutdowns have resulted in innovations in network operation", matching your new goal #3 (issues, opportunities, innovations) might be clearer. But Yes, please change the charter to do this work, however you describe it! From nobody Thu Apr 13 11:53: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 03CA41315A8; Thu, 13 Apr 2017 11:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 whdgCrDTYlJP; Thu, 13 Apr 2017 11:53:33 -0700 (PDT) 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 4A7F61315F1; Thu, 13 Apr 2017 11:53:33 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id g2so13018708pge.2; Thu, 13 Apr 2017 11:53:33 -0700 (PDT) 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=VupYpJL8SPSbALuX3ezqBQuKVmM0RYIpWdyjlR9Ua4c=; b=C34AkMKXPz5/sR89jh7RZdK3eHvm0x4dRA43h2ZPSlogsZyGkzrTRfZG/sfxl0Hzac ZUGmnTbZEvIiMpq5w3T/zRYC4MBcxrg7rmdj//LX2RCMIcESzJGg0KZABZ9RR/i4bbO0 SFx3DlO03rYMI7fNzwuHhIfEfNrNgAD84W+rXX9zVCVp4rokSILb1X+VtCZENuDJEE6D ir+Uo8yYKBSIQMayKIbVta9wdkS6pHap18uTHXnot2+lufnRSV+bjAJVue52G97Pz0aU eeht5l6LJzCg2IqOhg/a+uGsJ6yW5TkdUd7XDQuQ62RDgxXgOLja7W6SrF6KmJCduNyn mSow== 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=VupYpJL8SPSbALuX3ezqBQuKVmM0RYIpWdyjlR9Ua4c=; b=GR5kbzAS/qifFeyBnqapkoxcgT0SBJPON2b4+20sQ2AKcfKASsYIvtH+qarCX8tOiG GTvNJgkZdaHfJBTlW/XDYIjt1qMerLLcrpdPChAJfJ1l8zm57CWq3Rc5AKHCDYRNnDm5 lbkcZpDibV11rFwSUfz0MAfw2JHqoYNyx79TpvCB4ravChJhNqjS5Zti8mGV1jeGuk+/ yGvsgdgVGVVUmZkw3LQOdGZy9ctOaOHcu3NPA5LbMv50y+enx2EfCw2J603oXe+6N0Id HEmc3cbbLRVpJwxXdtdKXuzeeS+TUX2D0kMLJTCEuxMFsg6zdobyIVRs3Fffh3YpjZ98 OoZQ== X-Gm-Message-State: AN3rC/5R0CBFaq50+SvG+nNKb/QJYAOL+gTRcB12QMMrdKTYrp92ZHzm /6RJAXa7TRFxdA== X-Received: by 10.98.211.18 with SMTP id q18mr4056555pfg.97.1492109612949; Thu, 13 Apr 2017 11:53:32 -0700 (PDT) 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 73sm43892624pfj.31.2017.04.13.11.53.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 11:53:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <149210514779.15804.11448190653920016384.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 11:53:30 -0700 Cc: The IESG , V6ops Chairs , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149210514779.15804.11448190653920016384.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Spencer Dawkins' Yes on charter-ietf-v6ops-04-00: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 18:53:35 -0000 I'm OK with your final formulation. Do you need an updated file, or can = we simply assume that will be changed before posting? > On Apr 13, 2017, at 10:39 AM, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > charter-ietf-v6ops-04-00: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-v6ops/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'm a Yes, but I'm not a Responsible AD Yes.=20 >=20 > The ballot tab says "ready w/o external review", but both questions = are > on the ballot itself.=20 >=20 > I wouldn't object to external review if other people thought it was > important, but I'm happier if people in other SDOs assume we're = already > looking at deployment experience :D. >=20 > The following is a nit, of course. >=20 > The last sentence in=20 >=20 > "The global deployment of IPv6 is underway, creating an Internet > consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and > IPv6+translation networks and nodes. This deployment must be properly > handled to avoid the division of the Internet into separate IPv4 and > IPv6 networks, ensuring addressing and connectivity for all IPv4 and > IPv6 nodes. An important aspect of that has been the shutdown of IPv4 > in some networks, which has resulted in innovations in network > operation."=20 >=20 > took me three reads to parse. If you think it could be more clear, I > might suggest replacing it with >=20 > "An important aspect of IPv6 deployment has been the shutdown of IPv4 = in > some networks, and this shutdown has resulted in innovations in = network > operation". >=20 > And, now that I think I understand what is being said, I wonder if=20 >=20 > "An important aspect of IPv6 deployment has been the shutdown of IPv4 = in > some networks, and issues and opportunities from these shutdowns have > resulted in innovations in network operation", >=20 > matching your new goal #3 (issues, opportunities, innovations) might = be > clearer. >=20 > But Yes, please change the charter to do this work, however you = describe > it! >=20 >=20 From nobody Thu Apr 13 12:00: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 7895D131600 for ; Thu, 13 Apr 2017 11:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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=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 YgOG-1Ls-zVY for ; Thu, 13 Apr 2017 11:59:57 -0700 (PDT) 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 E18941315DB for ; Thu, 13 Apr 2017 11:59:56 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 72so26027798pge.2 for ; Thu, 13 Apr 2017 11:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=lWV4uckBSba0xG4zUIqmVGI/+xtQeOaP0Dhv07sFUXM=; b=P4bgycNHgn63H/7Uws2YmUhF3ep/XO2FwAUUtBPqsVvJi9PRZAxHV8jwmwu+Xf9s6D EK+i9CYQuuHQdic60n7u5+E71zm3Uc1yBLLzyag/7JN9fa/+glV76I8psgb6vZI4z7lz qzHpuEr98I9+4Vf0TrfIvvW78zP+QqyU1U3X6Q52xK8bb+usxtt8R5A+3H/FXf894i7y M4iZdC9CZTETSMMSrlnBGECr8V0CodcjndQM47M0+XzwUVkCYahkXeHXnZNFx+w2Sh8R kbv1OTnq94dnrwm9E7ZRZGnMuYf4AlwQNciJhvfGvo2bGNku5sip+Q5o4Rlmh72Bf+ZY 1qzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=lWV4uckBSba0xG4zUIqmVGI/+xtQeOaP0Dhv07sFUXM=; b=G+YLQf7gWIQaqJapSFVjrXmorntoLTryQBR9QlWsnBqjON8Kngu+/zNLwHNmoRTKBZ HxLlmT+JLLicWLh7ppX8xxVoz7kB7xaDV7NAnGroxOLkVEsikrVnFHOKNVDN3qt1Ap7G 4YjszP5OOY36c8c3Gq5Y3Wdn/zaSSKXf13QMFQvPQGXpBaFUo9eISaiwyOJVTh8wEzHg i9f3tFQZR2ID9hJSs37E8ihCtdqVJ4TJ63++6sgc2+x0/PN5Tz/e0hz1+Cpu0DqwHJ+H PLhScKhlnyBnIkuYAaeqbWncscspXcLUiNGLleVbYOBcskdb2HcawFTEM+FuS9NZBSmA fmbA== X-Gm-Message-State: AN3rC/4SW2XZUSHHN8MPUUV7WzHmBAxBl3CoUbczn0dLh4LpjMcaVjAu X8zR3YcVX0ukP9OQCS6qqA== X-Received: by 10.99.144.65 with SMTP id a62mr2758008pge.12.1492109996200; Thu, 13 Apr 2017 11:59:56 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id b77sm43949732pfl.2.2017.04.13.11.59.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 11:59:55 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_F9499472-6FFB-4FE8-8BFE-28F536643C89" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 11:59:58 -0700 References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: "v6ops@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 18:59:59 -0000 --Apple-Mail=_F9499472-6FFB-4FE8-8BFE-28F536643C89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 13, 2017, at 00:49, mohamed.boucadair@orange.com wrote: >=20 > IMO, avoiding to obsolete RFC7084 seems the right approach to follow = here.=20 I prefer to obsolete. My reasoning: while the various IPv6 service provisioning mechanisms and = IPv4 service transition mechanism available have changed and will = probably continue to change, the behavior of CE routers in the local = area interior routing domain is badly out of date and needs to be = revised to include the proposed standards developed in the HOMENET = working group. Also I=E2=80=99d like to declare that I=E2=80=99m in general agreement = with the spirit of what Barbara Stark wrote earlier on proposed = requirements on the wide-area link interface of the CE router can be = introduced in an acceptable revision of RFC 7084. She wrote: >> For this document to be a true replacement of RFC 7084, it MUST NOT = introduce any "MUST" requirements that an operator currently using RFC = 7084 (directly or indirectly) does not want in their CE router. >> 7084-bis MUST NOT interfere with, place undue burden on, or add cost = to existing deployments and the CE routers used in those existing = deployments.=20 Where I might be departing from her on this point (not sure) is that I = don=E2=80=99t believe it=E2=80=99s a good idea, or even really possible, = to publish RFC 7084-bis without adding some non-recurring costs to the = development of new CE routers that implement the more recent HOMENET = standards for the LAN interfaces in home networks. Maybe there are operators that don=E2=80=99t =E2=80=9Cwant=E2=80=9D = their CE routers to participate in the HNCP distributed consensus = protocol on the LAN interface. If there are such operators, then I think = it would help to surface their objections sooner rather than later. --james woodyatt > --Apple-Mail=_F9499472-6FFB-4FE8-8BFE-28F536643C89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 13, 2017, at 00:49, mohamed.boucadair@orange.com wrote:

IMO, avoiding to obsolete RFC7084 seems the = right approach to follow here.

I prefer to obsolete.

My reasoning: while the = various IPv6 service provisioning mechanisms and IPv4 service transition = mechanism available have changed and will probably continue to change, = the behavior of CE routers in the local area interior routing domain is = badly out of date and needs to be revised to include the proposed = standards developed in the HOMENET working group.
Also I=E2=80=99d like to declare that = I=E2=80=99m in general agreement with the spirit of what Barbara Stark = wrote earlier on proposed requirements on the wide-area link interface = of the CE router can be introduced in an acceptable revision of RFC = 7084. She wrote:

For = this document to be a true replacement of RFC 7084, it MUST NOT = introduce any "MUST" requirements that an operator currently using RFC = 7084 (directly or indirectly) does not want in their CE = router.
7084-bis MUST NOT interfere with, place = undue burden on, or add cost to existing deployments and the CE routers = used in those existing = deployments. 

Where I might be = departing from her on this point (not sure) is that I don=E2=80=99t = believe it=E2=80=99s a good idea, or even really possible, to publish = RFC 7084-bis without adding some non-recurring costs to the development = of new CE routers that implement the more recent HOMENET standards for = the LAN interfaces in home networks.

Maybe there are operators that don=E2=80=99= t =E2=80=9Cwant=E2=80=9D their CE routers to participate in the HNCP = distributed consensus protocol on the LAN interface. If there are such = operators, then I think it would help to surface their objections sooner = rather than later.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_F9499472-6FFB-4FE8-8BFE-28F536643C89-- From nobody Thu Apr 13 14:03: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 762E91200DF; Thu, 13 Apr 2017 14:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[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, 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 cgVIxD7QRsZB; Thu, 13 Apr 2017 14:03:08 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 E653B1243F3; Thu, 13 Apr 2017 14:03:06 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l189so29950052ywb.0; Thu, 13 Apr 2017 14:03:06 -0700 (PDT) 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=WPn5qUm1MNjVXsXUQAGRi5OS0GCz7l+nxOPTliceUh4=; b=UfKyWdeMOZFE7DEcexq7viwynHy8w4p9jOxSbZhNOMbI4ISWyvKNUfbsj9k748bP/+ M3hWEfwkoauMYCUZCu8JOSIz20dNQgc5WyXlX8VcGAWJJstfntD7e+EqiO4I+bWKhHne AtEWyNFbkdw5qEjmnni0MpaJPBeAcCu/3ob7L9iRR6AVLe7DSKSiT+JCAwH+GwGqXudN UamMB14oNOgg3PPKXwdFXp7deUVjzeFg86gLmIqABveAMjCuOvPeO3k01tRj5KNXZ+ZU d/2+PIzsAvKo3r8xiwq/Eas11v6SY3C3hpsYrxrqa5El3v7nPHgvTsjIS1/6v22TUIhq wPpQ== 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=WPn5qUm1MNjVXsXUQAGRi5OS0GCz7l+nxOPTliceUh4=; b=oVrjEoNt0/cdUwAnRYYhfLLlyEnXg3eNJeuf7GZJm+Hbn97CQoA9lm0+QHwtlaS2VF anSsZe96OzM2bxVh6zGURDFq3O8rdSfIemI1uo7Rzec+SnszPAIh4hE7qVijz+fBzcP0 ZQxnW6hfTsrjWl6S1/xcJe34OePzRuv6fD9b/CUjKtVGC4ZoaIYNCgKomopqmVBpeY0V WbCAebq1OgnAS8dt/B0ungbZevjDBjiEpVpyPMmNhh8ZRY/08YcKmvB/TVsXmHeYxsDl To8lZUKcYywVG8FrvtY/CH6W5ttG0ToHOFn82lGHlzGvu2BdCrLdLl+ru8Up0RLL+OVg KPrQ== X-Gm-Message-State: AN3rC/7NvIIB5lta81M7cSMsa0sjMh7fxvu0qEFhdK6SX9QIxQ2HOUu/ Jnif1Us3E1LQ+NxwjY4o2JMOtLCQDQ== X-Received: by 10.13.250.129 with SMTP id k123mr4191633ywf.276.1492117386184; Thu, 13 Apr 2017 14:03:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Thu, 13 Apr 2017 14:03:05 -0700 (PDT) Received: by 10.37.73.129 with HTTP; Thu, 13 Apr 2017 14:03:05 -0700 (PDT) In-Reply-To: References: <149210514779.15804.11448190653920016384.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Thu, 13 Apr 2017 16:03:05 -0500 Message-ID: To: Fred Baker Cc: iesg@ietf.org, v6ops list , V6ops Chairs Content-Type: multipart/alternative; boundary=94eb2c080a1cc49577054d12a65c Archived-At: Subject: Re: [v6ops] Spencer Dawkins' Yes on charter-ietf-v6ops-04-00: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 21:03:10 -0000 --94eb2c080a1cc49577054d12a65c Content-Type: text/plain; charset=UTF-8 Hi, Fred, On Apr 13, 2017 13:53, "Fred Baker" wrote: I'm OK with your final formulation. Do you need an updated file, or can we simply assume that will be changed before posting? I'll defer to the responsible AD. Warren, could you let Fred know what the right thing to do is? Thanks! > On Apr 13, 2017, at 10:39 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > > Spencer Dawkins has entered the following ballot position for > charter-ietf-v6ops-04-00: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-v6ops/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a Yes, but I'm not a Responsible AD Yes. > > The ballot tab says "ready w/o external review", but both questions are > on the ballot itself. > > I wouldn't object to external review if other people thought it was > important, but I'm happier if people in other SDOs assume we're already > looking at deployment experience :D. > > The following is a nit, of course. > > The last sentence in > > "The global deployment of IPv6 is underway, creating an Internet > consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and > IPv6+translation networks and nodes. This deployment must be properly > handled to avoid the division of the Internet into separate IPv4 and > IPv6 networks, ensuring addressing and connectivity for all IPv4 and > IPv6 nodes. An important aspect of that has been the shutdown of IPv4 > in some networks, which has resulted in innovations in network > operation." > > took me three reads to parse. If you think it could be more clear, I > might suggest replacing it with > > "An important aspect of IPv6 deployment has been the shutdown of IPv4 in > some networks, and this shutdown has resulted in innovations in network > operation". > > And, now that I think I understand what is being said, I wonder if > > "An important aspect of IPv6 deployment has been the shutdown of IPv4 in > some networks, and issues and opportunities from these shutdowns have > resulted in innovations in network operation", > > matching your new goal #3 (issues, opportunities, innovations) might be > clearer. > > But Yes, please change the charter to do this work, however you describe > it! > > --94eb2c080a1cc49577054d12a65c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Fred,

On Apr 13, 2017 13:53, "Fred Baker" <fredbaker.ietf@gmai= l.com> wrote:
I'm OK with your final formulation. Do you need an upda= ted file, or can we simply assume that will be changed before posting?

I&#= 39;ll defer to the responsible AD.

Warren, could you let Fred know what the right thing to do is?

Thanks!

> On Apr 13, = 2017, at 10:39 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> w= rote:
>
> Spencer Dawkins has entered the following ballot position for
> charter-ietf-v6ops-04-00: Yes
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/cha= rter-ietf-v6ops/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I'm a Yes, but I'm not a Responsible AD Yes.
>
> The ballot tab says "ready w/o external review", but both qu= estions are
> on the ballot itself.
>
> I wouldn't object to external review if other people thought it wa= s
> important, but I'm happier if people in other SDOs assume we'r= e already
> looking at deployment experience :D.
>
> The following is a nit, of course.
>
> The last sentence in
>
> "The global deployment of IPv6 is underway, creating an Internet<= br> > consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and
> IPv6+translation networks and nodes. This deployment must be properly<= br> > handled to avoid the division of the Internet into separate IPv4 and > IPv6 networks, ensuring addressing and connectivity for all IPv4 and > IPv6 nodes.=C2=A0 An important aspect of that has been the shutdown of= IPv4
> in some networks, which has resulted in innovations in network
> operation."
>
> took me three reads to parse. If you think it could be more clear, I > might suggest replacing it with
>
> "An important aspect of IPv6 deployment has been the shutdown of = IPv4 in
> some networks, and this shutdown has resulted in innovations in networ= k
> operation".
>
> And, now that I think I understand what is being said, I wonder if
>
> "An important aspect of IPv6 deployment has been the shutdown of = IPv4 in
> some networks, and issues and opportunities from these shutdowns have<= br> > resulted in innovations in network operation",
>
> matching your new goal #3 (issues, opportunities, innovations) might b= e
> clearer.
>
> But Yes, please change the charter to do this work, however you descri= be
> it!
>
>


--94eb2c080a1cc49577054d12a65c-- From nobody Thu Apr 13 15:29: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 394E4128616 for ; Thu, 13 Apr 2017 15:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 2hE_5udK_0hA for ; Thu, 13 Apr 2017 15:29:08 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 7B57B129A9C for ; Thu, 13 Apr 2017 15:29:07 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id v3so56326488qtd.3 for ; Thu, 13 Apr 2017 15:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yc1RqAduWdw8D/4L7shPPhO/GJzawQMK/l3KRv2Zw9E=; b=JSG6smbtO8rmO5xjMHr+6Tw3Uu2OlqoRnkC/ou+fii0nMWQMx9pfgC2RUmHWYJud5g s+/YQiiItzT4ZcDxVmkCuajcKlXAl2AESj/1h7ckngyUTf4tD3UdBOFHc5ZF+5otE7Qd adw+p1rD9lyXLqCd11WAWFxNGgJ+dIqyjbp7Wea1W57/NpRo4tzG0ZbA+WajWmWomuU5 CaAJYdcIHCr4LLtVh1J7TVyWGlT9U4LZvJhaHutFcvOGHUT8i4fCBF8j6hmGNNhPX4yD V2+JvC8FIbvxG0DBs5HCC5phYSIPFDfe0vAduj1xSfscFpma2ZwqDR9sIdBk8a1MjPrg khSA== 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=Yc1RqAduWdw8D/4L7shPPhO/GJzawQMK/l3KRv2Zw9E=; b=suFFT+uybfarIRhMEBlPwd0zaVZTFhpHpwGJ3h0zJIydebcx11MkSuVFHw0wrAew7b NHkE1yAW4I3ll8LxCpuWDOzlD+H6CHdnnScHGz1gQl40hk+BMMJ69zl2d442NDVhETmO kD7Mdir68CQpJ4GFUCPl/BwbqgNXcaATmYos1F9J2uL7Gsj7fh8Fa1bB+qNwPZZANDFH 36uNFl5e3uRr6UhuiOtALPjXFXtW1qB4VU86HZQa5sDf52jwhOP0bjXlXCCxAh0AQXdH kHk9AD/qz5FIekmtEq9flKgPRwPddMjVcRlNNLSpjTvfiLaarlYmAgF5DrZk+p+/mt/i 1DVg== X-Gm-Message-State: AN3rC/7dICfRiSdm4PCY3mq/iK3jyrx07uci2/IvbLpLigQR6dgb6bSh ZdgMU77YT11HLyaRY+V8BG579uXlVCIt X-Received: by 10.200.45.161 with SMTP id p30mr4675595qta.122.1492122546477; Thu, 13 Apr 2017 15:29:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.136 with HTTP; Thu, 13 Apr 2017 15:28:26 -0700 (PDT) In-Reply-To: References: <149210514779.15804.11448190653920016384.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Thu, 13 Apr 2017 18:28:26 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: Fred Baker , v6ops list , V6ops Chairs , The IESG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Spencer Dawkins' Yes on charter-ietf-v6ops-04-00: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 22:29:11 -0000 On Thu, Apr 13, 2017 at 5:03 PM, Spencer Dawkins at IETF wrote: > Hi, Fred, > > On Apr 13, 2017 13:53, "Fred Baker" wrote: > > I'm OK with your final formulation. Do you need an updated file, or can we > simply assume that will be changed before posting? > > > I'll defer to the responsible AD. > > Warren, could you let Fred know what the right thing to do is? I just edited the proposed charter with your addition. Thanks Spencer and Fred. W > > Thanks! > >> On Apr 13, 2017, at 10:39 AM, Spencer Dawkins >> wrote: >> >> Spencer Dawkins has entered the following ballot position for >> charter-ietf-v6ops-04-00: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-v6ops/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I'm a Yes, but I'm not a Responsible AD Yes. >> >> The ballot tab says "ready w/o external review", but both questions are >> on the ballot itself. >> >> I wouldn't object to external review if other people thought it was >> important, but I'm happier if people in other SDOs assume we're already >> looking at deployment experience :D. >> >> The following is a nit, of course. >> >> The last sentence in >> >> "The global deployment of IPv6 is underway, creating an Internet >> consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and >> IPv6+translation networks and nodes. This deployment must be properly >> handled to avoid the division of the Internet into separate IPv4 and >> IPv6 networks, ensuring addressing and connectivity for all IPv4 and >> IPv6 nodes. An important aspect of that has been the shutdown of IPv4 >> in some networks, which has resulted in innovations in network >> operation." >> >> took me three reads to parse. If you think it could be more clear, I >> might suggest replacing it with >> >> "An important aspect of IPv6 deployment has been the shutdown of IPv4 in >> some networks, and this shutdown has resulted in innovations in network >> operation". >> >> And, now that I think I understand what is being said, I wonder if >> >> "An important aspect of IPv6 deployment has been the shutdown of IPv4 in >> some networks, and issues and opportunities from these shutdowns have >> resulted in innovations in network operation", >> >> matching your new goal #3 (issues, opportunities, innovations) might be >> clearer. >> >> But Yes, please change the charter to do this work, however you describe >> it! >> >> > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Apr 13 16:02:18 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3135812EAD1; Thu, 13 Apr 2017 16:02:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: v6ops@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149212453015.27548.13210718340210615403@ietfa.amsl.com> Date: Thu, 13 Apr 2017 16:02:10 -0700 Archived-At: Subject: [v6ops] Genart last call review of draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 23:02:10 -0000 Reviewer: Joel Halpern Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-?? Reviewer: Joel Halpern Review Date: 2017-04-13 IETF LC End Date: None IESG Telechat date: Not scheduled for a telechat Summary: This document is almsot ready for publication as an RFC. Major issues: N/A Minor issues: The proposed status seems questionable. We as a community are not recommending that operators assign unique prefixes to hosts. This document is saying "if you want to do that, here is a way, using existing tools, to make that work." The document also recommends specific setting of other flags (the O flag in the RA, for example) that are not closely coupled to the particular topic. This looks like an ordinary Informational RFC. I would have no concern with this being published with that label. Nits/editorial comments: As per the nits checker, the document uses RFC 2119 terminology. The usage seems quite appropriate. The document should therefore cite RFC 2119. Also, as per the nits checker, the document references RFC 6106. It should reference RFC 8106. From nobody Thu Apr 13 17:44: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 D44FF127876 for ; Thu, 13 Apr 2017 17:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 yqWtjE4Sraco for ; Thu, 13 Apr 2017 17:44:37 -0700 (PDT) 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 80D90126CF6 for ; Thu, 13 Apr 2017 17:44:37 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3E0ZlnW021126; Thu, 13 Apr 2017 20:44:33 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 29tkdp0wsa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Apr 2017 20:44:32 -0400 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 v3E0iWxM004290; Thu, 13 Apr 2017 20:44:32 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3E0iPm0004246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Apr 2017 20:44:28 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 14 Apr 2017 00:44:08 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.98]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 20:44:07 -0400 From: "STARK, BARBARA H" To: james woodyatt , "v6ops@ietf.org" Thread-Topic: rfc7084-bis and homenet Thread-Index: AdK0uDYv4KQInu9eQJC3/nELhqFhTw== Date: Fri, 14 Apr 2017 00:44:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.156.127] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-13_21:, , 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-1702020001 definitions=main-1704140004 Archived-At: Subject: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 00:44:39 -0000 DQo+IFdoZXJlIEkgbWlnaHQgYmUgZGVwYXJ0aW5nIGZyb20gaGVyIG9uLi4uIFtub3QgaW50cm9k dWNpbmcgImJ1cmRlbnNvbWUiIHJlcXVpcmVtZW50c10gLi4uKG5vdCBzdXJlKSBpcyB0aGF0IEkg ZG9u4oCZdCANCj4gYmVsaWV2ZSBpdOKAmXMgYSBnb29kIGlkZWEsIG9yIGV2ZW4gcmVhbGx5IHBv c3NpYmxlLCB0byBwdWJsaXNoIFJGQyA3MDg0LWJpcyB3aXRob3V0IGFkZGluZyBzb21lIG5vbi1y ZWN1cnJpbmcgY29zdHMgdG8gDQo+IHRoZSBkZXZlbG9wbWVudCBvZiBuZXcgQ0Ugcm91dGVycyB0 aGF0IGltcGxlbWVudCB0aGUgbW9yZSByZWNlbnQgSE9NRU5FVCBzdGFuZGFyZHMgZm9yIHRoZSBM QU4gaW50ZXJmYWNlcyBpbiBob21lIG5ldHdvcmtzLg0KDQo+IE1heWJlIHRoZXJlIGFyZSBvcGVy YXRvcnMgdGhhdCBkb27igJl0IOKAnHdhbnTigJ0gdGhlaXIgQ0Ugcm91dGVycyB0byBwYXJ0aWNp cGF0ZSBpbiB0aGUgSE5DUCBkaXN0cmlidXRlZCANCj4gY29uc2Vuc3VzIHByb3RvY29sIG9uIHRo ZSBMQU4gaW50ZXJmYWNlLiBJZiB0aGVyZSBhcmUgc3VjaCBvcGVyYXRvcnMsIHRoZW4gSSB0aGlu ayBpdCB3b3VsZCBoZWxwIHRvIHN1cmZhY2UgDQo+IHRoZWlyIG9iamVjdGlvbnMgc29vbmVyIHJh dGhlciB0aGFuIGxhdGVyLg0KDQpXaGVyZSBJIHN0cnVnZ2xlIGlzIHRoZSBjaGlja2VuIGFuZCBl Z2cgdGhpbmcuIFRoaXMgb3BlcmF0b3IsIGF0IGxlYXN0LCBpc24ndCBzZWVpbmcgYSBzdHJvbmcg bmVlZCB0byBiZSBhIGRyaXZlciBvZiBob21lbmV0IHByb3RvY29scy4gQW5kIGl0J3Mgbm90IG1l LCBwZXJzb25hbGx5LiBJdCdzIHRoYXQgSSBjYW4ndCBmaWd1cmUgb3V0IGhvdyB0byBjb252aW5j ZSB0aGUgcGVvcGxlIHdobyBkbyBDRSByb3V0ZXIgcmVsZWFzZSBwbGFubmluZyBvciB3aG8gaXNz dWUgdGhlIFJGUHMuIEl0J3MgcG9zc2libGUgZm9yIGEgcm91dGVyIHZlbmRvciB0byBzYXkgdGhl eSBzZWUgYSBuZWVkLCBoYXZlIGRldmVsb3BlZCBpdCwgYW5kIHdpbGwganVzdCBpbmNsdWRlIGl0 LiBCdXQgSSBoYXZlbid0IHNlZW4gdGhlIHJvdXRlciB2ZW5kb3JzIHNheWluZyB0aGF0LiBJZiBu by1vbmUgd2hvIGlzIGluIGEgZGVjaXNpb24tbWFraW5nIGNhcGFjaXR5IGlzIGNvbnZpbmNlZCwg aXQgd2lsbCBub3QgaGFwcGVuLiBSRkNzIGxpa2UgdGhpcyBoYXZlIG1pbmltYWwgZWZmZWN0aXZl bmVzcy4NCg0KV2hhdCB3ZSBuZWVkIGlzIGEgY29udmluY2luZyBhcmd1bWVudCBhcyB0byB3aHkg YSBDRSByb3V0ZXIgd2lsbCBiZSBkZXNpcmVkIGJ5IHJlZ3VsYXIgcGVvcGxlIGlmIGl0IGhhcyB0 aGUgaG9tZW5ldCBzdHVmZi4NCg0KT25lIG9mIHRoZSBiaWdnZXN0IHByb2JsZW1zIEkgc2VlIHRo YXQgaG9tZW5ldCBzb2x1dGlvbnMgbWlnaHQgYmUgYWJsZSB0byBzb2x2ZSBmb3IgcmVndWxhciBw ZW9wbGUgKGFuZCBJIGRvbid0IHRoaW5rIGl0IGRvZXMgcXVpdGUgeWV0IGJ1dCBJIGNvdWxkIGJl IHdyb25nKSBpcyBoZWxwaW5nIGRpdnZ5IHVwIGEgc2luZ2xlIC82NCBhbW9uZyBtdWx0aXBsZSBy b3V0ZXJzLiBCdXQgdGhpcyB3b3VsZCBhbHNvIHJlcXVpcmUgdGhlIGFiaWxpdHkgdG8gc2VuZCBh IHN1YnNldCBvZiBhIC82NCBpbiBSQSBhbmQgaG9zdHMgZG8gYSBzdGF0ZWxlc3MgYXV0b2NvbmZp Z3VyYXRpb24gYWRkcmVzcyBhc3NpZ25tZW50IGJ1dCByZWNvZ25pemluZyB0aGF0IGl0IGRvZXNu J3QgaGF2ZSBhIC82NCB0byB1c2UgYW5kIGNhbid0IGRvIEVVSS02NCAoc28gaXQgaXNuJ3QgUkZD IDQ4NjIgU0xBQUMpLiBJZiB3ZSBjb3VsZCBmaWd1cmUgb3V0IGhvdyB0byBkbyB0aGlzIHdpdGhv dXQgYnJlYWtpbmcgZXhpc3Rpbmcgc3R1ZmYsIEkgdGhpbmsgSSBjb3VsZCBzZWxsIGl0LiBJIGtl ZXAgc2VlaW5nIHRob3NlIDNHUFAgZGVwbG95bWVudHMgd2l0aCBqdXN0IHRoZSBzaW5nbGUgLzY0 IGFuZCBob3cgc29tZSBJU1BzIGFyZSBzYXlpbmcgLzY0IHNlZW1zIGxpa2UgcGxlbnR5IGFuZCB0 aGluayBpdCB3b3VsZCBiZSB3b3J0aCBhIHRyeSB0byBkaXZ2eSBpdCB1cCByYXRoZXIgdGhhbiBy YWlsaW5nIGF0IHRob3NlIHN0dXBpZCBJU1BzICh3aGljaCBoYXNuJ3QgYmVlbiByZWFsIHN1Y2Nl c3NmdWwgdG8gZGF0ZSkuDQoNCjxXYXJuaW5nOiB0aGUgYWJvdmUgY29udGVudCB3YXMgd3JpdHRl biBhZnRlciB3b3JrIGFuZCBhZnRlciB3aW5lOyBpdCdzIGp1c3QgYSByYW5kb20gdGhvdWdodC4+ DQpCYXJiYXJhDQo= From nobody Thu Apr 13 18:33: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 E8CC9127909 for ; Thu, 13 Apr 2017 18:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 e9prJBWlhZpL for ; Thu, 13 Apr 2017 18:33:11 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 6B6C31242EA for ; Thu, 13 Apr 2017 18:33:11 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id n46so58234906qta.2 for ; Thu, 13 Apr 2017 18:33:11 -0700 (PDT) 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=eXTYKeqiWPK17eD2/HLz5uYS4HsVY+lx1SKFwoa7D/k=; b=CtlHF9LEmCQ96lxua4bacEtTrIeZNV6N3gI42951wzpSvQ/hI6H7OtS+Ip/jHmyjaR M2N/2FYZFhj00TtrUp13AgGpl2ZZU/aoBGaZDMpaEHxjg6v2RgLJCvB8/LCJPrYEQDzI etX3XZKyVt2MmV9qq3Czs5sVc9IkFR4jizRI4gwTo4Q68IxKuYbNcpXGbcrNk3jVd0F/ LJyS+LG6DvbmquhZMYRgCXkA6pS2/gRrA/Fd7b9vppnYaq47L0OXfoNrMmLCW34qnCYe QxAgdJ43eRo3oKyW8ihDWq3f51D02gCaX6viGzSYg+IhwkKZq5J2rASWf4Fy02JqpBKP zEgw== 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=eXTYKeqiWPK17eD2/HLz5uYS4HsVY+lx1SKFwoa7D/k=; b=DneUArUZR9Oou2g0/Goc5tr8OlEdRu0Cxe+jm+txDZ9tPJ9x/d76qTyUwgRMCUStjW Dd2TlvT7BLuuoFEts7GcPIe/hWVHpGXIsD5GhYsWEm64aVIZ3oPXHew6aAFIy2YXBIi3 JGcg+2ieM2Anb3WZrVFBxyYhI7wE617bTfkzWgcjRQ8ARKK5aEjWjwM8gFEpIb10bbyV 5JrVZg1J2AlHsrBp1PYzFSX20qwuJIl3hL/gCoauKq19WojusxVTd9PhKHUOoYvyH3PC 0FwriWqxXtGTODrXbKVSNEmNa36C3QUM95X5gSrYWSdbAGG4hBLsBlO+H4smeQ9kdCZy +QUg== X-Gm-Message-State: AN3rC/5haRkf8Q6XgczTyVYGi3GGMs0AGuNQRYn701+2o4DOMIaUTw6w Bd9g0YOannRnIA== X-Received: by 10.200.54.218 with SMTP id b26mr5915120qtc.8.1492133590654; Thu, 13 Apr 2017 18:33:10 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 16sm358687qkk.2.2017.04.13.18.33.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 18:33:09 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D12D65D1-183E-4E2C-B4E5-2A7EF3FDA263" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 21:33:08 -0400 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: james woodyatt , "v6ops@ietf.org" To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:33:13 -0000 --Apple-Mail=_D12D65D1-183E-4E2C-B4E5-2A7EF3FDA263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 13, 2017, at 8:44 PM, STARK, BARBARA H wrote: > One of the biggest problems I see that homenet solutions might be able = to solve for regular people (and I don't think it does quite yet but I = could be wrong) is helping divvy up a single /64 among multiple routers. It's entirely possible that if ISPs start handing out single /64s to = broadband customers, a market for this solution will arise. That would = be a tremendously bad outcome, however, and also risks triggering the = spread of the much simpler solution of just doing NAT. Consequently, I'm disinclined to make this a target use case. I think it's more likely that the homenet use case will be applicable to = high-end routers like the ones Google are starting to sell. I believe = that they are driving this market, and homenet would be a nice = deployment model. But not until we have it. --Apple-Mail=_D12D65D1-183E-4E2C-B4E5-2A7EF3FDA263 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 13, 2017, at 8:44 PM, STARK, BARBARA H <bs7652@att.com> = wrote:
One of the biggest = problems I see that homenet solutions might be able to solve for regular = people (and I don't think it does quite yet but I could be wrong) is = helping divvy up a single /64 among multiple = routers.

It's entirely possible that if ISPs start handing out single = /64s to broadband customers, a market for this solution will arise. =   That would be a tremendously bad outcome, however, and also risks = triggering the spread of the much simpler solution of just doing = NAT.

Consequently, I'm disinclined to make this a target use = case.

I think = it's more likely that the homenet use case will be applicable to = high-end routers like the ones Google are starting to sell.   I = believe that they are driving this market, and homenet would be a nice = deployment model.   But not until we have it.

= --Apple-Mail=_D12D65D1-183E-4E2C-B4E5-2A7EF3FDA263-- From nobody Thu Apr 13 18:40: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 B1D59127599 for ; Thu, 13 Apr 2017 18:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 QSxgMkOGPTGM for ; Thu, 13 Apr 2017 18:40:56 -0700 (PDT) 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 BB1F1127076 for ; Thu, 13 Apr 2017 18:40:56 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3E1ZAMi043679; Thu, 13 Apr 2017 21:40:46 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 29tkdp1wbf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Apr 2017 21:40:46 -0400 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 v3E1ej0g018056; Thu, 13 Apr 2017 21:40:45 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3E1efRC018018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Apr 2017 21:40:41 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 14 Apr 2017 01:40:30 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.98]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 21:40:30 -0400 From: "STARK, BARBARA H" To: Ted Lemon CC: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] rfc7084-bis and homenet Thread-Index: AdK0uDYv4KQInu9eQJC3/nELhqFhTwAKGLUAAAg37tA= Date: Fri, 14 Apr 2017 01:40:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB22108@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.156.127] Content-Type: text/plain; charset="iso-8859-1" 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-04-13_21:, , 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-1702020001 definitions=main-1704140010 Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:40:58 -0000 > I think it's more likely that the homenet use case will be applicable to = high-end routers=20 > like the ones Google are starting to sell. =A0 I believe that they are dr= iving this market, and=20 > homenet would be a nice deployment model. =A0 But not until we have it. This opinion gives me ammunition to push back against James W's proposal to= require HNCP in a 7084-bis. Barbara From nobody Thu Apr 13 19:18: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 8E4FB127097 for ; Thu, 13 Apr 2017 19:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 UxiI8cihc41w for ; Thu, 13 Apr 2017 19:18:17 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 06974126C7B for ; Thu, 13 Apr 2017 19:18:17 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id f133so61289361qke.2 for ; Thu, 13 Apr 2017 19:18:16 -0700 (PDT) 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=/5UsoIFX3GecABxIaNgN0Y8SWYx7OxzMIYnJhchcJOY=; b=AUP7LBOMt9Nej5mRI9lIjdtiq6hZ/4sbe9nzMiB414RuSsqRUHQccJa76eY8yk6ber 5rNMBwm1HiSrNPCr0eBJV/gAK6VTeyE+r2SqdzE/Us/TI0Al/No15b9rweb3hTO4Caa7 JOa5mfyobMKJl3msM1KJtv7gJHNQwiZTGaAhHi9zo/ZyQKkQP4CQcB+fEu0RLQzrjNpc VDDhrpGOgl7ilcw1DJxditlOsLTzfXEL1+gcFFrlcusWnD+YAIWSaNJcfAbkTopJXRbm DAyD/Y4+Ox7V5ZgY5QI80zHeTFm7X9dT/eOkohcENRQUykNknjm0NRa+Syz6MoalDk+q 80cQ== 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=/5UsoIFX3GecABxIaNgN0Y8SWYx7OxzMIYnJhchcJOY=; b=b3J7mNUv+tRXxXvvXQ5RSxf0Jod4eF66oB46LjTPhtfNOQzf8GmCMtulYyqwIpU3ao wLgHQdFE6DnRwsTrnxe8uTXq60tx9+T7nR+KjGgpgcecYxwRJZn9uaDGOAzpFOwBNjdl saR2E0EV7/AUtpGtdFuToFDGMSr8OEeuFG1EtQu5nZAShBPH1UhT3Tf6KDF6xpVXi0Gi eOdDayh4D+T1dtHCegcS0dmXi6xFqGddq0uuoNnn7nYeMy2ApODrIwUj8cHgbPG217Di zbH57YkrIgwqW5H88YCuCFSv5tQrbWJUUmu+nl8OAf0R+mDgVW3ud9Hb231WKGa3ykxS 3zMg== X-Gm-Message-State: AN3rC/6ZO8C1fq7PzaKzh/Ikvu2w54kdy1oarM/obr2tkCeE1hExmetD LREef5q/qkNS4Lc0Pm0= X-Received: by 10.55.102.193 with SMTP id a184mr4834742qkc.309.1492136296260; Thu, 13 Apr 2017 19:18:16 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r55sm416889qtr.16.2017.04.13.19.18.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 19:18:15 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_101E0E76-7CB2-46E0-9A0E-A2AEC6157344" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 22:18:14 -0400 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB22108@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: james woodyatt , "v6ops@ietf.org" To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB22108@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 02:18:18 -0000 --Apple-Mail=_101E0E76-7CB2-46E0-9A0E-A2AEC6157344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 13, 2017, at 9:40 PM, STARK, BARBARA H wrote: > This opinion gives me ammunition to push back against James W's = proposal to require HNCP in a 7084-bis. Personally I think that would be premature. I don't know what the = requirement would say. --Apple-Mail=_101E0E76-7CB2-46E0-9A0E-A2AEC6157344 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 13, 2017, at 9:40 PM, STARK, BARBARA H <bs7652@att.com> = wrote:
This opinion gives = me ammunition to push back against James W's proposal to require HNCP in = a 7084-bis.

Personally I think that would be premature. =   I don't know what the requirement would say.

= --Apple-Mail=_101E0E76-7CB2-46E0-9A0E-A2AEC6157344-- From nobody Thu Apr 13 19:42: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 959B4128A32 for ; Thu, 13 Apr 2017 19:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SJ4wODBRHbGW for ; Thu, 13 Apr 2017 19:42:12 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 D8BE9128ACA for ; Thu, 13 Apr 2017 19:42:11 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id l28so44945221wre.0 for ; Thu, 13 Apr 2017 19:42:11 -0700 (PDT) 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=VIY4bojjyNmFUhUB0k4D0RTS2f4DP8aFkVkBzNpn0nE=; b=sxnpaDEigs6aD1vFaHd4IG8oo5U7OucMWMnspitR4Oj/+E861Hg+CnXPwOwTEkPLJW FeDoNVLwNKwYKUoWObkxVMSvZtR5SCycyJKAH0xyp/HlYrCthTmqyr1SWpuyaUkqpiCH v6jUHWfMKlYJqVv5QF1WF+Vhb9FBEdDTGzOWFRUkYQKgTGkfCPeZLp4smccr5sO/vNol +rYG6tl1OmbM67XlAEWh2+mPOQ9/AvUy2lScgZdbLOk36hGmjU6Cps9g4cCn6yHv1Pww OEhqnQMz/LV+dJkEZFxgF27Jjc4jYDS2hMh5PtdulcZXxCMpuXZXACD7gdJBYYyiyM9d D6mQ== 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=VIY4bojjyNmFUhUB0k4D0RTS2f4DP8aFkVkBzNpn0nE=; b=nEHK96U5F/Zq9spjZCLxCJortiUdPBwR/CgfzfwbgQMVCBNTHUwL7Ik1knPYOA+Emv JWxjLnXEG4xwhwIfDpRfURngCdN8cUIHGKKdigSChY6T7gpxHgqhxKvmDrqlHa9DQirl jzKzJX3B0NTtY/C+OgjPowAi64D6F6jNWeaxOYXior6jAfC0bYovqnqOkzk0Th7dU8Vq HK1SDvJvDun1/NcMWopKaq64iJeeZxV1BL6cVad25/ZczBffNqMJXcpZ7gt0UEnRAPbk 1RC3mYrF1qYV/H8s5JBCYVa0NNp7NUPShEzkLrQx7Cu1uOfifCZnng1nH1AaQpk+Sav8 vQYA== X-Gm-Message-State: AN3rC/5AemhlloiC6h5T4nn0GEz4iK5bb3beUoYZK9HGY1rALLGYtMqi RI0hCaF9M8l97Q== X-Received: by 10.223.163.212 with SMTP id m20mr5253259wrb.29.1492137730445; Thu, 13 Apr 2017 19:42:10 -0700 (PDT) Received: from 229.66.20.149.in-addr.arpa (229.66.20.149.in-addr.arpa. [149.20.66.229]) by smtp.gmail.com with ESMTPSA id l186sm1010861wmd.17.2017.04.13.19.42.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 19:42:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 13 Apr 2017 19:42:06 -0700 Cc: james woodyatt , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 02:42:13 -0000 On Apr 13, 2017, at 5:44 PM, STARK, BARBARA H wrote: >=20 > One of the biggest problems I see that homenet solutions might be able = to solve for regular people (and I don't think it does quite yet but I = could be wrong) is helping divvy up a single /64 among multiple routers. = But this would also require the ability to send a subset of a /64 in RA = and hosts do a stateless autoconfiguration address assignment but = recognizing that it doesn't have a /64 to use and can't do EUI-64 (so it = isn't RFC 4862 SLAAC). If we could figure out how to do this without = breaking existing stuff, I think I could sell it. I keep seeing those = 3GPP deployments with just the single /64 and how some ISPs are saying = /64 seems like plenty and think it would be worth a try to divvy it up = rather than railing at those stupid ISPs (which hasn't been real = successful to date). A single /64 to a telephone that has a hot spot behind it is not too = hard. The telephone gets one of the 2^64 IIDs and is therefore in the = same subnet as the LAN. =46rom a routing perspective, it is the router = that gets a packet to the destination address in the hot spot. What you request is of course trivial if we can put a prefix longer than = /64 on a LAN, or if we can get a prefix shorter than /64 from the ISP. = Other ISPs that I have spoken with suggest that one gets pretty much = what one asks for - if you ask for a /64, that's what you get, if you = ask for a /63 you get a /60, and if you ask for a /59, you get a /56. A = prefix longer than a /64 will get disapproving commentary in v6ops or = 6man. What does allocating a prefix shorter than /64 to a subscriber get = in your favorite network?= From nobody Thu Apr 13 21:14: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 7D31D129407 for ; Thu, 13 Apr 2017 21:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 kG_I2AsSC110 for ; Thu, 13 Apr 2017 21:14:29 -0700 (PDT) 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 9ADA71286B1 for ; Thu, 13 Apr 2017 21:14:29 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 21so39204517pgg.1 for ; Thu, 13 Apr 2017 21:14:29 -0700 (PDT) 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=lHPIkLnkGchjyPHGU5h3PjE+aNIf/ngAmyO5dMhNils=; b=s6rmbSQkermkhYtczKE0jgqII45KVJ89nO+UMkgkEvbqDILaFhEyzYeYXErMieM9u2 yFPCsx+C9spZDAdf34avpc/Y4PT6GlhYFjVaIYs/5XEI6/uCGaVIya0bEw0GEZgjwCdR z4ZRo2LBGkvwzoP/1KhwUMY9frsK/YxD1xi95HSNGFP1Pj5eEXSwSCZ8jXkKdhfyANvE HIPQu+tJUOXJfabVEf+NZvG3H00fb1QEfCNE5GNPsuYSeui+j4osAGofwem0C62tm/C6 Zc+nsI2hUDYVEriszsxgK/v+w9AnzfThgVqqCN04kDKFcjbh9T2h3RSrXxUItgKMgxiP A+4A== 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=lHPIkLnkGchjyPHGU5h3PjE+aNIf/ngAmyO5dMhNils=; b=mCbJuTFqO5GO+fTC9helSBg7pcfszuChVzjfaDA+R5kUMAO+tqeiWp5JTB3PiMSYuc gtZNi8An6JZqpSmtzxKjnn2iEDrord0pHBeY9fVUv6d9sLihvLYPObT8DLnm6ESdzTAR QCRpOJOv1VIDyRXbOXIPO4dNGTF19aBBu5kTFX1jSp4SXkJQvBSxwOon6uwwc6QgqEwJ OyKCX5RLHaUkSNyVfiVvhnjZNxNzVMjIypUZd7mTG3jR0aO2gcxf6NhNpuukD6Y/Ao7C Q9/0+CLEu8mBzR9+eivCHW5XMdbXhwXD2WWTTSHCzOb9dLLf1wA8ErND226h152bZlnU w+ZA== X-Gm-Message-State: AN3rC/7nfmV12wmhE+Gjllp1pbLT4jwgpVuxm3LxN/qdTn7itBqb3Uqm Q0csULHU5u8oQw== X-Received: by 10.84.168.5 with SMTP id e5mr6354668plb.181.1492143269239; Thu, 13 Apr 2017 21:14:29 -0700 (PDT) Received: from ?IPv6:2406:e007:703c:1:28cc:dc4c:9703:6781? ([2406:e007:703c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c7sm779011pgn.24.2017.04.13.21.14.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 21:14:28 -0700 (PDT) To: "STARK, BARBARA H" , james woodyatt , "v6ops@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 14 Apr 2017 16:14:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 04:14:31 -0000 On 14/04/2017 12:44, STARK, BARBARA H wrote: >=20 >> Where I might be departing from her on... [not introducing "burdensome= " requirements] ...(not sure) is that I don=E2=80=99t=20 >> believe it=E2=80=99s a good idea, or even really possible, to publish = RFC 7084-bis without adding some non-recurring costs to=20 >> the development of new CE routers that implement the more recent HOMEN= ET standards for the LAN interfaces in home networks. >=20 >> Maybe there are operators that don=E2=80=99t =E2=80=9Cwant=E2=80=9D th= eir CE routers to participate in the HNCP distributed=20 >> consensus protocol on the LAN interface. If there are such operators, = then I think it would help to surface=20 >> their objections sooner rather than later. >=20 > Where I struggle is the chicken and egg thing. This operator, at least,= isn't seeing a strong need to be a driver of homenet protocols. And it's= not me, personally. It's that I can't figure out how to convince the peo= ple who do CE router release planning or who issue the RFPs. It's possibl= e for a router vendor to say they see a need, have developed it, and will= just include it. But I haven't seen the router vendors saying that. If n= o-one who is in a decision-making capacity is convinced, it will not happ= en. RFCs like this have minimal effectiveness. >=20 > What we need is a convincing argument as to why a CE router will be des= ired by regular people if it has the homenet stuff. If they desire to build a multi-router network in their home or small off= ice, it would be easiest if all their routers support homenet and one of = them happens to be connected as the CE. At some point in history, that ma= y become the common case, but I don't see it happening just yet. For 7084= bis, making homenet a MAY is realistic, with a hint that 7084bis-bis is l= ikely to make it a SHOULD. > One of the biggest problems I see that homenet solutions might be able = to solve for regular people (and I don't think it does quite yet but I co= uld be wrong) is helping divvy up a single /64 among multiple routers. Bu= t this would also require the ability to send a subset of a /64 in RA and= hosts do a stateless autoconfiguration address assignment but recognizin= g that it doesn't have a /64 to use and can't do EUI-64 (so it isn't RFC = 4862 SLAAC).=20 Being picky, it *is* RFC 4862 SLAAC; SLAAC is carefully defined without a= specific IID size. It *isn't* consistent with RFC 4291 unless the length is 64. See several = hundred messages about 4291bis... > If we could figure out how to do this without breaking existing stuff, = I think I could sell it. I keep seeing those 3GPP deployments with just t= he single /64 and how some ISPs are saying /64 seems like plenty and thin= k it would be worth a try to divvy it up rather than railing at those stu= pid ISPs (which hasn't been real successful to date). That isn't going to happen on the timescale of 7084bis, IMNSHO. For now, = ISPs need to get real and supply a /48 (we have about 15 trillion in stock) or /56 (we have almost 4 quadr= illion) for customers with subnets. I suspect the ISPs will shift on this= as the market evolves. Brian >=20 > > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri Apr 14 00:44: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 D7F5212420B for ; Fri, 14 Apr 2017 00:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QqJBHUjcXcK3 for ; Fri, 14 Apr 2017 00:44:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD5F120326 for ; Fri, 14 Apr 2017 00:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3295; q=dns/txt; s=iport; t=1492155841; x=1493365441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FA85qCG+rYkaoVEl/212AmKN+lrGUrZvfYxiqscXuAE=; b=nHDAW0UujvWa1bXW/8Sl2GEoW6G9GZ30YOuGNfMses8YwgtwWCgu7JRm p21n9fvABdldDQdHP19HSPwHIAPHUzlZ3CzEVUhkbnpJancxkBHB9I0Nj kOzt29zH/+Hl+gIM3oEQ9eTBYf/T1JNPIRdxxvKOvEqO7GvphL1RW898e 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQAnffBY/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQuNe5FblVyCDyELhXgCg3w/GAECAQEBAQEBAWsohRYBAQE?= =?us-ascii?q?CAQEBbAsFCwIBCEYnCyUCBA4FG4l0CA6rJYsTAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGAWGUYFdK4JshFaDNIIxBZ0WAZJjgX+PR4hpix8BHziBBVsVQREBhkl1iTs?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.37,197,1488844800"; d="scan'208";a="14855795" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2017 07:44:00 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3E7i0JU014812 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Apr 2017 07:44:00 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Apr 2017 02:44:00 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 14 Apr 2017 02:44:00 -0500 From: "Pascal Thubert (pthubert)" To: "STARK, BARBARA H" CC: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] rfc7084-bis and homenet Thread-Index: AQHStPLhMIT6Kt1PFki/lMP2iogHzA== Date: Fri, 14 Apr 2017 07:44:00 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 07:44:04 -0000 Hello Barbara: An alternate to subnetting the /64 could be to route to the host. That's wh= at we do in route-over IOT solutions, using RPL between the routers.=20 Networks with thousands of nodes are deployed like that around you, for ins= tance in smart metering industry. For home, using RPL would be consistent with the use of ANIMA and help buil= d a trustable network. It would also be consistent with RPL-based Home IOT. Note: when the host moves rapidly, support for RFC-6775-update can improve = the user experience by immediately signaling the freshest location. OTOH, I= f you subnet the /64, the host renumbers to the new subnet and loses its cu= rrent connections. Regards, Pascal > Le 14 avr. 2017 =E0 02:44, STARK, BARBARA H a =E9crit : >=20 >=20 >> Where I might be departing from her on... [not introducing "burdensome" = requirements] ...(not sure) is that I don=92t=20 >> believe it=92s a good idea, or even really possible, to publish RFC 7084= -bis without adding some non-recurring costs to=20 >> the development of new CE routers that implement the more recent HOMENET= standards for the LAN interfaces in home networks. >=20 >> Maybe there are operators that don=92t =93want=94 their CE routers to pa= rticipate in the HNCP distributed=20 >> consensus protocol on the LAN interface. If there are such operators, th= en I think it would help to surface=20 >> their objections sooner rather than later. >=20 > Where I struggle is the chicken and egg thing. This operator, at least, i= sn't seeing a strong need to be a driver of homenet protocols. And it's not= me, personally. It's that I can't figure out how to convince the people wh= o do CE router release planning or who issue the RFPs. It's possible for a = router vendor to say they see a need, have developed it, and will just incl= ude it. But I haven't seen the router vendors saying that. If no-one who is= in a decision-making capacity is convinced, it will not happen. RFCs like = this have minimal effectiveness. >=20 > What we need is a convincing argument as to why a CE router will be desir= ed by regular people if it has the homenet stuff. >=20 > One of the biggest problems I see that homenet solutions might be able to= solve for regular people (and I don't think it does quite yet but I could = be wrong) is helping divvy up a single /64 among multiple routers. But this= would also require the ability to send a subset of a /64 in RA and hosts d= o a stateless autoconfiguration address assignment but recognizing that it = doesn't have a /64 to use and can't do EUI-64 (so it isn't RFC 4862 SLAAC).= If we could figure out how to do this without breaking existing stuff, I t= hink I could sell it. I keep seeing those 3GPP deployments with just the si= ngle /64 and how some ISPs are saying /64 seems like plenty and think it wo= uld be worth a try to divvy it up rather than railing at those stupid ISPs = (which hasn't been real successful to date). >=20 > > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 14 06:43: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 E0409127071 for ; Fri, 14 Apr 2017 06:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 m2RKPg1AFGQU for ; Fri, 14 Apr 2017 06:43:45 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 4A15F12ECF5 for ; Fri, 14 Apr 2017 06:43:45 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3EDYxUX022362; Fri, 14 Apr 2017 09:43:42 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 29tq79cux7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Apr 2017 09:43:41 -0400 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 v3EDheut010709; Fri, 14 Apr 2017 09:43:40 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3EDhZNY010665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Apr 2017 09:43:38 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 14 Apr 2017 13:43:26 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.98]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Fri, 14 Apr 2017 09:43:26 -0400 From: "STARK, BARBARA H" To: Fred Baker CC: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] rfc7084-bis and homenet Thread-Index: AdK0uDYv4KQInu9eQJC3/nELhqFhTwAMgVEAAA1axSA= Date: Fri, 14 Apr 2017 13:43:26 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB248EE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> In-Reply-To: <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.153.211] 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-04-14_09:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704140118 Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 13:43:47 -0000 > Other ISPs that > I have spoken with suggest that one gets pretty much what one asks for - = if > you ask for a /64, that's what you get, if you ask for a /63 you get a /6= 0, and if > you ask for a /59, you get a /56. A prefix longer than a /64 will get > disapproving commentary in v6ops or 6man. What does allocating a prefix > shorter than /64 to a subscriber get in your favorite network? Please don't misconstrue what I said as "this is what AT&T wants". It's not about AT&T. AT&T hat way, way off. Consumer hat firmly in place. As a consumer and an individual, I see what options consumers are being pro= vided around the world. Many people are going to LTE for their broadband access (using a USB LTE ra= dio attached to one of those easy-to-get routers that has drivers for the U= SB device from their LTE provider). I'm not personally aware of any LTE pro= viders who are providing more than a /64. AFAIK, the 3GPP release that supp= orts IA_PD still hasn't been deployed. There are other ISPs that are supplying whatever prefixes they're supplying= .=20 Most consumers really don't care (not about IPv6, and certainly not about I= Pv6 prefix lengths). So the population of people who care is small.=20 Because of this, there are not strong market drivers to speed up developmen= t of IA_PD features in 3GPP releases and deploy them. There's not even a st= rong market driver to get equipment vendors to actually deliver GPON or VDS= L2 access equipment that properly (i.e., it actually works and doesn't have= bugs) supports IPv6 (which forces continued use of technologies like 6rd, = which do not allow for variation in provided prefix). For years now, there has been a dominant view in IETF that the correct appr= oach for consumers to take who want to have multiple routers (multiple /64 = prefixes) is to whine, complain, use empty threats, and beg to try to get a= bigger prefix. In order to force consumers to take this approach, this dom= inant view has successfully prevented consumers from getting tools that wou= ld allow them to maximize use of a /64, if they have one. Whining and beggi= ng is only effective if many people do it, and if consumers had tools to de= al with the problem on their own, they would stop whining and begging, whic= h would reduce pressure on ISPs, which would reduce pressure on vendors to = deliver working equipment to ISPs. Therefore, to ensure continued whining a= nd begging, it's very important to keep out of consumers' hands any tool th= at would allow them to make full use of the 2^64 addresses in a /64. As a consumer, I really don't like being used as a pawn by vocal people who= want to maximize their voice by forcing me to add mine to theirs. I just w= ant the tools that will let me easily use my 2^64 addresses the way I want.= =20 Barbara From nobody Fri Apr 14 09:54: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 CE87612946C for ; Fri, 14 Apr 2017 09:54:02 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 dCsg_jhLAvV0 for ; Fri, 14 Apr 2017 09:54:01 -0700 (PDT) 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 4F8191294EE for ; Fri, 14 Apr 2017 09:54:01 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id s16so42733936pfs.0 for ; Fri, 14 Apr 2017 09:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=mxWd98wE2Hh7U8t8YqgR5J0IHvYfMpXe8TteXCCzUDI=; b=vA3A+ZxpQoEyTjdJHBKYDQ/xS/1N5g29y8fu8QBfnTgQ2KETnGTWfENpZ6hAFgZm2Z /XfjhhW2E0d1Wi65DL58FpMn3oc3Xtc2Q56+mbqwEOHy+HS5wsvAKMMgf8uVdcLZ7Fy3 E/K5wNj5MGwRXs9ukKOnE1a2WtkVLqgwhba+PDdieqGZEsrxeCoG9Oxuj5IoWsw52+1W G1khrwzXlqr0eiqMUO9NHIYtqLez//FZ5RaEvsvqDCaVfaK0ZWrLM/+RP9UWciGxBfTB dN3SoOSPfYQ4dSamPpa+ZkjiBUpO8ehCHxsrxlXFlhIxgjKWIFhq0UVCrL0I86m7DjKl AnxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=mxWd98wE2Hh7U8t8YqgR5J0IHvYfMpXe8TteXCCzUDI=; b=IUodBCs+1KXdiYOHB6xWjcTqwBzNkHbBtc4HiKxll1XDjocddDVjNnoiY5ANvatBjl RgAez3Bkp5j5P2Vduwg8mRLlkks7i+xpjIKyT9+mm1nYlKaLKmEEbULFupkEb708Ozj+ HFisH4Ar8ohHhMTs2xhisrSTZXLhX2ci9Uh6m1/Qr9B0NRJKwZpPXYh9Aui5YNuIQdmQ REHEjALhJVQBYmX2n8Q01tjhO1YziK2yBxaopvGrRv3JDdGAAPa/bL1VCu8G+bBWHTw6 bTrH84GStaDgKf/rmR2ruN0CjVaE1p8n+3unPK+gokHNuUSjbAf4idqH+5EQCslGGcU1 lh3g== X-Gm-Message-State: AN3rC/5at9SqesBHrnQUJrB1GixYl2bCWJcOPyP2f+RUcMbYmbxvFWxV UigEJ7JGcMmvVKufR4hQlA== X-Received: by 10.98.159.131 with SMTP id v3mr7689434pfk.57.1492188840489; Fri, 14 Apr 2017 09:54:00 -0700 (PDT) Received: from ?IPv6:2001:5a8:4:2290:7cc9:361c:b9d7:cdfb? ([2001:5a8:4:2290:7cc9:361c:b9d7:cdfb]) by smtp.gmail.com with ESMTPSA id n24sm4265833pgc.43.2017.04.14.09.53.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 09:53:59 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_05573A09-3B20-4F68-B8AC-5DCE01AD9E29" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 09:53:58 -0700 References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> To: "v6ops@ietf.org" In-Reply-To: <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> Message-Id: <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:54:03 -0000 --Apple-Mail=_05573A09-3B20-4F68-B8AC-5DCE01AD9E29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 13, 2017, at 19:42, Fred Baker wrote: >=20 > Other ISPs that I have spoken with suggest that one gets pretty much = what one asks for [=E2=80=A6] This is, of course, a misrepresentation of how it actually works. = Here=E2=80=99s how it actually works: p1. There is no reason whatsoever to ask for a prefix longer than /48, = so everyone asks for a /48. p2. No service provider accepts the rationale for assigning every = subscriber a /48, so everyone gets a longer prefix. p3. Therefore, everyone gets the shortest prefix their service provider = is willing to assign them, which may be as long as a /64 regardless of = what is requested. One gets whatever the ISP decides, not what one asks for. And if you = don=E2=80=99t like your ISP, then you can petition your local telecom = regulatory agency to allow a competitor to operate in your market, = hopefully one that provides shorter prefixes. --james woodyatt > --Apple-Mail=_05573A09-3B20-4F68-B8AC-5DCE01AD9E29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 13, 2017, at 19:42, Fred Baker <fredbaker.ietf@gmail.com> wrote:

Other ISPs that I = have spoken with suggest that one gets pretty much what one asks for = [=E2=80=A6]

This is, of course, a misrepresentation = of how it actually works. Here=E2=80=99s how it actually = works:

p1. = There is no reason whatsoever to ask for a prefix longer than /48, so = everyone asks for a /48.

p2. No service provider accepts the rationale for assigning = every subscriber a /48, so everyone gets a longer prefix.

p3. Therefore, everyone = gets the shortest prefix their service provider is willing to assign = them, which may be as long as a /64 regardless of what is = requested.

One = gets whatever the ISP decides, not what one asks for. And if you don=E2=80= =99t like your ISP, then you can petition your local telecom regulatory = agency to allow a competitor to operate in your market, hopefully one = that provides shorter prefixes.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_05573A09-3B20-4F68-B8AC-5DCE01AD9E29-- From nobody Fri Apr 14 10:25: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 BCAD1129440 for ; Fri, 14 Apr 2017 10:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWUj0ZpMlqtP for ; Fri, 14 Apr 2017 10:25:12 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E051128CDC for ; Fri, 14 Apr 2017 10:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492190710; x=1492795510; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=2KoWv5OrUYlOe18UCMfUhzWTx GlWZV6+1gjFfg6ejJg=; b=kblGkZVYfHATC3/iQVW4b4qL/KkYTVDCPvEfrHTfF uoqf92pz2xDRZqxT3EwF2q7RNQW41wG/KVtCJGcSF73aJwxcijEvGNM+dayTm8mg A5vInjyhrF+tOgP5B/G5febxy62Cp/Peak115DpUeaMbsaQ5nigDYSMJ2nJkBg/K Lo= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=KN/s6J8TgHdgcAYeEmIFeEZOK7L4Lu6ZWerCNF94Y/z8wdZmDJXADuPKyEpo Rqm0aPN9gs/+qWfOlRw/Zop1TaFLc67+YeC018BPTf+ExU6YQULjM3QwW jYfGxuq8beQWBPhg6HnCms+S25A4lcQrQrh+Ddm/DMXZW8Bq3GlPMk=; X-MDAV-Processed: mail.consulintel.es, Fri, 14 Apr 2017 19:25:10 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 14 Apr 2017 19:25:10 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005408640.msg for ; Fri, 14 Apr 2017 19:25:10 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170414:md50005408640::V5p+I0A0k1bXvTpI:000003hj X-Return-Path: prvs=12776aa295=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Fri, 14 Apr 2017 19:25:09 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <20099E35-64AE-4A3D-9FFE-597CBA0158C5@consulintel.es> Thread-Topic: [v6ops] rfc7084-bis and homenet References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> In-Reply-To: <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 17:25:15 -0000 Fully agree with James. I=E2=80=99ve analyzed that thru a survey that I=E2=80=99ve already mention = in this list before. The latest slide set and video of the presentation at = RIPE is here: https://ripe73.ripe.net/archives/video/1242 One of the results that this survey shows, is that many (1/3) ISPs (99% in = wireline access technologies), provide only a /64 to the customers. Here is= the relevant data (slide 15): - 33% /64 mainly in LACNIC, some countries in APNIC - 35% /56 mainly ARIN/RIPE NCC - 22% /48 mainly =E2=80=9Cmore advanced=E2=80=9D countries (Australia, New = Zealand, Germany, Finland, Denmark, France, UK, China, Japan) - 10% provide =E2=80=9Cother=E2=80=9D lengths (including some /128) In my opinion, despite how much effort in IPv6 training has been done in LA= CNIC and APNIC, most of the ISPs still continue to see IPv6 as IPv4, and th= is is the main reason this happens, in addition to reasons related to wrong= ly understood sales/marketing rationales. We are also working at RIPE BCOP WG in a relevant document. Latest public v= ersion is here: https://www.ripe.net/ripe/mail/archives/bcop/2017-March/000159.html If we talk about the 3GPP context, there is a nice document, RFC7849, that,= if followed, could sort out the problem. In fact, a few ISPs and very few = vendors, are actually following it for broadband deployment with 3GPP. Unfortunately, this document was and independent submission, not sure to re= call correctly all the history details, but my opinion is that it will make= a lot of sense to reclassify it as a standard track. =E2=87=92 Question for the co-chairs and authors. It will be possible to do= so? Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de james woodyatt Responder a: Fecha: viernes, 14 de abril de 2017, 18:53 Para: "v6ops@ietf.org" Asunto: Re: [v6ops] rfc7084-bis and homenet On Apr 13, 2017, at 19:42, Fred Baker wrote: =20 =20 Other ISPs that I have spoken with suggest that one gets pretty much wh= at one asks for [=E2=80=A6] =20 =20 =20 =20 This is, of course, a misrepresentation of how it actually works. Here= =E2=80=99s how it actually works: =20 p1. There is no reason whatsoever to ask for a prefix longer than /48, = so everyone asks for a /48. =20 p2. No service provider accepts the rationale for assigning every subsc= riber a /48, so everyone gets a longer prefix. =20 p3. Therefore, everyone gets the shortest prefix their service provider= is willing to assign them, which may be as long as a /64 regardless of wha= t is requested. =20 One gets whatever the ISP decides, not what one asks for. And if you do= n=E2=80=99t like your ISP, then you can petition your local telecom regulat= ory agency to allow a competitor to operate in your market, hopefully one t= hat provides shorter prefixes. =20 --james woodyatt =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Fri Apr 14 10:55: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 4D86D1294F8 for ; Fri, 14 Apr 2017 10:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=umn.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 TruLiVr0tO3i for ; Fri, 14 Apr 2017 10:55:19 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 5AF661294D3 for ; Fri, 14 Apr 2017 10:55:18 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id BCB33965 for ; Fri, 14 Apr 2017 17:55:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2MA_HMXjmD5 for ; Fri, 14 Apr 2017 12:55:17 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 82FE442B for ; Fri, 14 Apr 2017 12:55:17 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id q26so18500785uaa.7 for ; Fri, 14 Apr 2017 10:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CeZZ6SsBYczmu8lozKeqNzNOlIduqUWFyNzBQKgM9Ls=; b=cN99zTLw49ZfLBnzDa1mMHwA/toejDC1bdISYKdYM/dfJPV80mTYU05XTmUDXBOZg1 bLSH/3yeSeV7xZxapRtTtH69VbwNoebnMekWVaN3qkapA8qdb/iB9HM9ciemT5HViOzA eKHq2Z8+4VZZliTLk3Kb7s5HkASxQWTJ+HPBN/G5iu469D2IoBrFE2wt0Rvv2nvuiNb8 48NUE66IVsmve0QL0Jd4VndPzJ0JF7znaj9U5JWKzOIDWZqYM04XyttNUdxuWkIZOgGL RfiBpHdnjIu4mXcVNYuTiTggNS8LBeio15c85J/9bckdGUNumXJHnJGfsD3419c970bL hpqw== 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=CeZZ6SsBYczmu8lozKeqNzNOlIduqUWFyNzBQKgM9Ls=; b=gkdabqbMl3n//z3GP58HZc9oz+KLIirHVQrtAM2BSyoMVhfHFtNj2Wte4vo9l5bjEF 8sy6uWWyK61WGN8sgrLnohceVo99zjYJR2DOjDNrxG6Yp0hAYMfywRa+xmp40YqfjRRq gd/VEn+/l2H9vHqJ/5KaBQ5MiCWiDqVw8TTRJAV/qObJFQQ8MTmijH6X5+apfM7qoCJh 0EapDIcURGpYVm+LXCp29qyaGR2GoGae/tbAwB8c06vqIEaZM3TRHzVnlGQ/JdmD1RJd porgkycY4e2ttmXhi6MekMQyi3Xz/A1LakLX8HBzMZJiMIbw3Ti8KixQQkl/4WkSFIv0 pOaw== X-Gm-Message-State: AN3rC/5sblq8ZBpxZ9LmqpMIkrGbkmhwIOqbyN9dZC85v73/Bwc5DqnA 9GK0PAkut+zBH6LYLi3zZiZs7ehwD9X8y+J4hYlTKgRyJB+XK1hlt87DaXuDHd+Any3iwl20OAE eql80zuiIO3Lra6Xz X-Received: by 10.31.108.212 with SMTP id j81mr4010676vki.96.1492192516931; Fri, 14 Apr 2017 10:55:16 -0700 (PDT) X-Received: by 10.31.108.212 with SMTP id j81mr4010667vki.96.1492192516759; Fri, 14 Apr 2017 10:55:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.69 with HTTP; Fri, 14 Apr 2017 10:55:16 -0700 (PDT) In-Reply-To: <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> From: David Farmer Date: Fri, 14 Apr 2017 12:55:16 -0500 Message-ID: To: james woodyatt Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a114790b4e5f25b054d2424b8 Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 17:55:21 -0000 --001a114790b4e5f25b054d2424b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 14, 2017 at 11:53 AM, james woodyatt wrote: > On Apr 13, 2017, at 19:42, Fred Baker wrote: > > > Other ISPs that I have spoken with suggest that one gets pretty much what > one asks for [=E2=80=A6] > > > This is, of course, a misrepresentation of how it actually works. Here=E2= =80=99s > how it actually works: > > p1. There is no reason whatsoever to ask for a prefix longer than /48, so > everyone asks for a /48. > I disagree there are plenty to reasons to not hand out /48s, even some valid ones, and perpetuating that myth that handing out /48s is the only way to go is not helpful. Now there should be no reason to not give out more than just one /64. A side note: at UMN we still have IPv4 /24s given out to departments over 25 years ago, before VLSM, and working with the departments to recover unused address space is much harder than pulling teeth. So internally, I want IPv6 isn't a good enough reason for us to allocate a /48 for a department, we will allocate as many /64 as they want and even a /56 if the ask for it. But I require some level of justification for a /48, like a plan to use at least a couple dozen or so /64s, because it will be a big pain to ever get them to change once we give a department a /48. > p2. No service provider accepts the rationale for assigning every > subscriber a /48, so everyone gets a longer prefix. > So, /48, /52, /56, and /60 are all reasonable options, for providers to hand out, this is essentally waht RFC 6177 says. > p3. Therefore, everyone gets the shortest prefix their service provider i= s > willing to assign them, which may be as long as a /64 regardless of what = is > requested. > > One gets whatever the ISP decides, not what one asks for. And if you don= =E2=80=99t > like your ISP, then you can petition your local telecom regulatory agency > to allow a competitor to operate in your market, hopefully one that > provides shorter prefixes. > Part of the reason for this is a number of the CE routers don't work right if you give them something more than a /64, ISPs don't want any breakage. This is basically the same reason you don't want to do DHCPv6 on Android, providers aren't any more unreasonable than you are, they just have a different point of view on the world. So if we really want to fix this rfc7084-bis needs a SHOULD support prefix delegation of any length between /48 and /64, and MUST support prefix delegations of /48, /52, /56, /60, and /64. > --james woodyatt > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114790b4e5f25b054d2424b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 14, 2017 at 11:53 AM, james woodyatt <= jhw@google.com><= /span> wrote:
On Apr 13, 2017, at 19:42, Fred Baker <fredbaker.ietf@gma= il.com> wrote:

Other ISPs that I have spoken with suggest that one gets pretty m= uch what one asks for [=E2=80=A6]

<= /div>
This is, of course, a misrepresentation of how it actually works.= Here=E2=80=99s how it actually works:

p1. There i= s no reason whatsoever to ask for a prefix longer than /48, so everyone ask= s for a /48.

I disagree there a= re plenty to reasons to not hand out /48s, even some valid ones, and perpet= uating that myth that handing out /48s is the only way to go is not helpful= .=C2=A0 Now there should be no reason to not give out more than just one /6= 4. =C2=A0

A side note: at UMN we still have IPv4 /= 24s given out to departments over 25 years ago, before VLSM, and working wi= th the departments to recover unused address space is much harder than pull= ing teeth.=C2=A0 So internally, I want IPv6 isn't a good enough reason = for us to allocate a /48 for a department, we will allocate as many /64 as = they want and even a /56 if the ask for it.=C2=A0 But I require some level = of justification for a /48, like a plan to use at least a couple dozen or s= o /64s, because it will be a big pain to ever get them to change once we gi= ve a department a /48. =C2=A0 =C2=A0
=C2=A0
= p2. No service provider accepts the rationale for assigning every subscribe= r a /48, so everyone gets a longer prefix.
So, /48, /52, /56, and /60 are all reasonable options, for prov= iders to hand out, this is essentally waht RFC 6177 says.
=C2=A0<= /div>
p3. Therefore, everyone gets the shortest prefix their= service provider is willing to assign them, which may be as long as a /64 = regardless of what is requested.

One gets whatever= the ISP decides, not what one asks for. And if you don=E2=80=99t like your= ISP, then you can petition your local telecom regulatory agency to allow a= competitor to operate in your market, hopefully one that provides shorter = prefixes.

Part of the reason fo= r this is a number of the CE routers don't work right if you give them = something more than a /64, ISPs don't want any breakage.=C2=A0 This is = basically the same reason you don't want to do DHCPv6 on Android, provi= ders aren't any more unreasonable than you are, they just have a differ= ent point of view on the world.

So if we really wa= nt to fix this=C2=A0rfc7084-bis needs a SHOULD support prefix delegation of= any length between /48 and /64, and MUST support prefix delegations of=C2= =A0/48, /52, /56, /60, and /64.=C2=A0
=C2=A0
--james woodyatt <jhw@google.com>
__________________________________= _____________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu<= br>Networking & Telecommunication Services
Office of Information Tec= hnology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a114790b4e5f25b054d2424b8-- From nobody Fri Apr 14 11:28:29 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 70F501294F6 for ; Fri, 14 Apr 2017 11:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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=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 hhU388QMzP_h for ; Fri, 14 Apr 2017 11:28:26 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 0CE96127B57 for ; Fri, 14 Apr 2017 11:28:26 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id 21so46485321pgg.1 for ; Fri, 14 Apr 2017 11:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=vXS6mX0fj+pY4Jv94McaLylIgnZWhMcXwPckzms9u1k=; b=T3nFW905XnzmKZ8K9bL5BUHKat8+cVDZJDR28j8BqfR9QBkKipTsWqZyuHpzlNdcMw HRjZhwoVOPGz2OazIXCinbywlGS9OvC6pANF5+A8JEKZkulWX50W+9IbnqoiIBtzZmC5 ilMvZ+IHQKlJS8MPVF1zPgsEn6rX3Q7JMrpvZlMQx9LTo9Uwg4l1F2M0zzxyUYYZ6Utp 2wtZtGB0kosG1li+G7Ji8wcX4tsxeB4Zmr6uhgqeXV434bMMqcW6LdLpE1IyBtQS3rsm /Yz6L9bzhAo3jCv0HMNWYu2PWbGWB67bfFvWU0bjPVml83X8Ru8xeEa4gnA5TjiokHlG kCuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=vXS6mX0fj+pY4Jv94McaLylIgnZWhMcXwPckzms9u1k=; b=bQsPxU5pjskxJHb3UZwDohegCMExSDO/O88LHFuaW06H6Z5IOK/6BdfEZtAV/WeawI uHUlHu7EHwZEWa+r0yLu4fbsmPb/fXiUrB/1lwfbJvcGzFxdG6UATPKzdB5GMap0D5Wm 8CxEpd/f9bDFUVynz6641XtAFZYHxn6inqV594R5lXqI227KBmd27xf8IqbSo4PzXG+a WRKYKI4qcVNa1fE8QVOLiVQlK/UZGq3ai9vXKtwMFPiVcdJgU6aYKE7ztvHN0PVX0dqs GJNoiOJn7x/3wmsxoU7sJEwiSH+elIV9Gwtk3hsAUBUhFLoAFedktSxuyG73ax30tcMN Q/EA== X-Gm-Message-State: AN3rC/5QL7+iyxjG9kVzL7eJnloYdFdG6c98l0LtklxcbGB4YnapMtBo qPNSo2ilVmSTPaqxF8V/+A== X-Received: by 10.84.238.141 with SMTP id v13mr10621370plk.13.1492194505367; Fri, 14 Apr 2017 11:28:25 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:6c8d:700d:566:3215? ([2620:0:10e7:10:6c8d:700d:566:3215]) by smtp.gmail.com with ESMTPSA id s10sm4525899pfe.28.2017.04.14.11.28.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 11:28:24 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_DFAD031E-E660-43C1-A967-53E318ACE7B0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 11:28:24 -0700 References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> To: "v6ops@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 18:28:27 -0000 --Apple-Mail=_DFAD031E-E660-43C1-A967-53E318ACE7B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 14, 2017, at 10:55, David Farmer wrote: > On Fri, Apr 14, 2017 at 11:53 AM, james woodyatt > wrote: > [=E2=80=A6] > p1. There is no reason whatsoever to ask for a prefix longer than /48, = so everyone asks for a /48. >=20 > I disagree there are plenty to reasons to not hand out /48s, even some = valid ones, and perpetuating that myth that handing out /48s is the only = way to go is not helpful. [=E2=80=A6] Unfair. I didn=E2=80=99t say there=E2=80=99s no reason for providers to = refuse some or all requests for /48s. I said there=E2=80=99s no reason = for a subscriber to ask for a prefix longer than a /48. As it happens, I personally find none of the architectural reasoning for = delegating prefixes longer than /48 to retail subscribers at all = convincing, but please be fair: I=E2=80=99m not disputing that other = people here make different value judgments than I do about whose = interests in the architecture of the Internet should be prioritized over = the interests of everyone else. --james woodyatt > --Apple-Mail=_DFAD031E-E660-43C1-A967-53E318ACE7B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 14, 2017, at 10:55, David Farmer <farmer@umn.edu> = wrote:
On Fri, Apr 14, 2017 at 11:53 AM, james woodyatt = <jhw@google.com> wrote:
[=E2=80=A6]
p1. There is no reason whatsoever to ask for a prefix = longer than /48, so everyone asks for a = /48.

I disagree there are plenty to reasons to not hand out /48s, = even some valid ones, and perpetuating that myth that handing out /48s = is the only way to go is not helpful. = [=E2=80=A6]

Unfair. I didn=E2=80=99t say there=E2=80=99s no = reason for providers to refuse some or all requests for /48s. I said = there=E2=80=99s no reason for a subscriber to ask for a prefix longer = than a /48.

As it happens, I = personally find none of the architectural reasoning for delegating = prefixes longer than /48 to retail subscribers at all convincing, but = please be fair: I=E2=80=99m not disputing that other people here make = different value judgments than I do about whose interests in the = architecture of the Internet should be prioritized over the interests of = everyone else.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_DFAD031E-E660-43C1-A967-53E318ACE7B0-- From nobody Fri Apr 14 12:43: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 CF09C1294D3 for ; Fri, 14 Apr 2017 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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=umn.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 dyeSjgY3xXsN for ; Fri, 14 Apr 2017 12:42:59 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 359A61242F7 for ; Fri, 14 Apr 2017 12:42:59 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 98805BFC for ; Fri, 14 Apr 2017 19:42:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68aSXRpILbE9 for ; Fri, 14 Apr 2017 14:42:58 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 6146CC19 for ; Fri, 14 Apr 2017 14:42:58 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id 75so10082825uak.19 for ; Fri, 14 Apr 2017 12:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=//bSScuV3NqPGDxkm13WVRZa6kNZig/hNvbbk2hDcuk=; b=Eo5sessaeVm8qzV8PN8knKEKChzRm6aD8JjqA4liGCUMpTU/hmpODUuBSfOIRr1LMz KHGuZ5xHVpm+BNr8olGs9jyceI5XdN5BSt95MDbgl8AuYFok8V0WLog1nDa5m5C5Ql02 hm4wPc92/avT8mColKWxk5LOSUNazoHHSO6wVVQrBeWgauCITrLd4bjib4D40U46peQv 1rqF+NdUgZ3RejH9PmdhrOAu8ZzhKmd/6LKV9AcT+FQflcWnrHThAu5qwNd6O6vcPZp6 TWj42SCYPXuAS75OlLEesWV5uGEToAindcAk5zVuBc8lNp4nwWlvHsVdsKHHXdJw0YXX QySg== 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=//bSScuV3NqPGDxkm13WVRZa6kNZig/hNvbbk2hDcuk=; b=aPVLVDVpCgM2ZkP81orutAxI2UMXB92SuVi8BAfareDFIIigwt82l9FyeYva9gCEYZ bTLczZ09PW6DUp61vGNj/kAAwNzbq9p5eE/2rEJDCeqwvL7hgm5LQe/qVQia2GDySG2T LdlKFvLrpMe7SYhVfjqwt00JeGb81p+Lei9nrh5AzcoESYPpdlM9VdHOS2sTLTY+vB0C Tb0Y/X0tVsrWOAF9MT+MWo8pOzvCoKbINmMysiaLsl7RvphRJNs1QkIzIQVixlW6+FRE lcUcuE9XfCVi+s6dacOSWSr9+5Yg/vKsQm1OuDheUOLGW7sB8hlwn+/081eKSBLoCwcp nrEA== X-Gm-Message-State: AN3rC/4wmi6aD5y87qHwkG80QAAjQwzUOmh8PfNvVI5gR4Xy0cCjuTR2 2J/QVAwbF7ChZ5yyvZ5WY1V+GsUo8zH/AX5Ick7UmPvp6MAffy3MDKp9H4h+2IRAmyv6bfM6f5/ HIxSaawIcHAAsEDeM X-Received: by 10.31.52.80 with SMTP id b77mr4092699vka.129.1492198977748; Fri, 14 Apr 2017 12:42:57 -0700 (PDT) X-Received: by 10.31.52.80 with SMTP id b77mr4092694vka.129.1492198977560; Fri, 14 Apr 2017 12:42:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.69 with HTTP; Fri, 14 Apr 2017 12:42:57 -0700 (PDT) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> From: David Farmer Date: Fri, 14 Apr 2017 14:42:57 -0500 Message-ID: To: james woodyatt Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a114315eefdf40c054d25a518 Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 19:43:01 -0000 --001a114315eefdf40c054d25a518 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 14, 2017 at 1:28 PM, james woodyatt wrote: > On Apr 14, 2017, at 10:55, David Farmer wrote: > > On Fri, Apr 14, 2017 at 11:53 AM, james woodyatt wrote: > >> [=E2=80=A6] >> p1. There is no reason whatsoever to ask for a prefix longer than /48, s= o >> everyone asks for a /48. >> > > I disagree there are plenty to reasons to not hand out /48s, even some > valid ones, and perpetuating that myth that handing out /48s is the only > way to go is not helpful. [=E2=80=A6] > > > Unfair. I didn=E2=80=99t say there=E2=80=99s no reason for providers to r= efuse some or all > requests for /48s. I said there=E2=80=99s no reason for a subscriber to a= sk for a > prefix longer than a /48. > Ok, maybe a little unfair, but still there are plenty of reasons for subscriber to ask for a prefix longer than a /48. First, most providers don't give out /48s. Second, must subscriber don't need or want more and a handful of /64s, in most cases a /60 or /56 would more than cover what the need, if they even know they want more than one /64 anyway. So, asking for something you don't really need and know most people won't give you anyway, doesn't seem very practical or realistic. As it happens, I personally find none of the architectural reasoning for > delegating prefixes longer than /48 to retail subscribers at all > convincing, but please be fair: I=E2=80=99m not disputing that other peop= le here > make different value judgments than I do about whose interests in the > architecture of the Internet should be prioritized over the interests of > everyone else. > I'd agree from an architectural perspective, there is no reason for site prefixes longer than a /48. However, there isn't an architectural imperative for /48s either, where as there is an architectural imperative to give any site that needs or even wants it, including residential sites, more than one /64. I think it's far more important to focus on this architectural imperative, than continually pointing out that architecturally every site can have /48. Pointing that out really only seems to be frustrating the attempt to achieve this architectural imperative, not helping it. Thanks --james woodyatt > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114315eefdf40c054d25a518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 14, 2017 at 1:28 PM, james woodyatt <<= a href=3D"mailto:jhw@google.com" target=3D"_blank">jhw@google.com> wrote:
On Apr 14, 2017, at 10:55, David Farmer <farmer@umn.edu> wrot= e:
On Fri, Apr 14, 2017 at 11:53 AM, james w= oodyatt <jhw@google.com> wrote:
[=E2=80=A6]<= /div>
p1. There is no reason whatsoever to ask for a prefix longer than= /48, so everyone asks for a /48.

I disagree there are plenty to reasons to not hand out /48s, even some v= alid ones, and perpetuating that myth that handing out /48s is the only way= to go is not helpful. [=E2=80=A6]

Unfair. I didn=E2=80=99t say there=E2=80=99s no reaso= n for providers to refuse some or all requests for /48s. I said there=E2=80= =99s no reason for a subscriber to ask for a prefix longer than a /48.

Ok, maybe a little unfair, bu= t still there are=C2=A0plenty of reasons for subscriber to ask for a prefix= longer than a /48.=C2=A0 First, most providers don't give out /48s.=C2= =A0 Second, must subscriber don't need or want more and a handful of /6= 4s, in most cases a /60 or /56 would more than cover what the need, if they= even know they want more than one /64 anyway.=C2=A0 So, asking for somethi= ng you don't really need and know most people won't give you anyway= , doesn't seem very practical or realistic. =C2=A0

=
As it happens, I personally find none of the architect= ural reasoning for delegating prefixes longer than /48 to retail subscriber= s at all convincing, but please be fair: I=E2=80=99m not disputing that oth= er people here make different value judgments than I do about whose interes= ts in the architecture of the Internet should be prioritized over the inter= ests of everyone else.

I&= #39;d agree from an architectural perspective,=C2=A0there is no reason for = site prefixes longer than a /48.=C2=A0 However, there isn't an architec= tural imperative for /48s either, where as there is an architectural impera= tive to give any site that needs or even wants it, including residential si= tes, more than one /64.

I think it's far more = important to focus on this architectural imperative, than continually point= ing out that architecturally every site can have /48. Pointing that out rea= lly only seems to be frustrating the attempt to achieve this architectural = imperative, not helping it.

Thanks

<= /div>
--james woodyatt <jhw@google.com>

-- <= br>
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &a= mp; Telecommunication Services
Office of Information Technology
Unive= rsity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
--001a114315eefdf40c054d25a518-- From nobody Fri Apr 14 13:27: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 9F32F129A97 for ; Fri, 14 Apr 2017 13:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 tgzGn6UbR0Ma for ; Fri, 14 Apr 2017 13:27:10 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD651129649 for ; Fri, 14 Apr 2017 13:27:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 54BD91A071 for ; Fri, 14 Apr 2017 20:27:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB248EE@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 14 Apr 2017 21:26:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB248EE@GAALPA1MSGUSRBF.ITServices.sbc.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 20:27:12 -0000 "STARK, BARBARA H" wrote: > As a consumer, I really don't like being used as a pawn by vocal = people who want to maximize their voice by forcing me to add mine to = theirs. I just want the tools that will let me easily use my 2^64 = addresses the way I want.=20 Just playing devils advocate here a bit .... Isn't that attitude part of the reason that we still talk about the = number of ISPs that don't even support IPv6 at all, and "everyone" = thinks there's no problem with IPv4 because "NAT fixes everything" ? Or put another way, if we give people tools to "make do" with a = substandard service from their ISP, then there's nothing whatsoever to = push delinquent ISPs towards fixing their offerings. And lets face it, = with NAT (and especially, carrier grade NAT), there'll be enough IPv4 = addresses to go round for ever - so why bother with IPv6 at all ;-) Yes that's very tongue in cheek. I've lost count of the number of times = I've thrown some ramblings on the fundamental brokenness of NAT into = various threads when someone's suggested that "NAT is a good thing". From nobody Fri Apr 14 14:02: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 22B19129498 for ; Fri, 14 Apr 2017 14:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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=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 XXlKuMjetz8G for ; Fri, 14 Apr 2017 14:01:59 -0700 (PDT) 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 5EF6612952C for ; Fri, 14 Apr 2017 14:01:58 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id s16so44564244pfs.0 for ; Fri, 14 Apr 2017 14:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=DYHmgZld7fOWNxv68kPFc3KNwRU8v5Z6zvVzFa94CIU=; b=VjglT3h6qR4DJnDEcamzTrcKWBQLYjYpMOeZJGTPqgTyZcI0sb5sDkEV6U3jEdAQZV P34NvHB6TEWl2HpfTf7PMrspTaAEMqaUZBnKuBczKkew/XDGIMC8sRLvlzj+LhSy6p8P 1gj/ei/zhSsbigiOykEWWJVBd9DK1bLTX05MtiNUU0gmPhfJJbmMFqWr9AAC2tp5DJA6 zROxcdHlQC6O5/54iIjd+Dbbk3wxe9hQ8/xIMNy7j/4SHSM/etgA5tvUwEVEqKSAxMti +Cip/6WrFyNBTVq0WC7vVxj5dFV/PvRvbWJ8GYtogflFnqM3qvABwYrIkNIBTc0fAJZ2 NyNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=DYHmgZld7fOWNxv68kPFc3KNwRU8v5Z6zvVzFa94CIU=; b=Ta0wb+ZUgp4Qj7GzQ60jEf4a9d/n4f4DhHd3miirQC+dzmmIig4qYEvjfC2gKktg1n piBR4pMpinGY4Mi4MTW8NaC4TD8HBk7znGs7ilkcmLHdbi5tMOr3JjoBdeL/ZA/Kemn5 ptOn7b6FYNJ4e+rQnSNsMDvhi4vj/8xzx/iJJzdEmnVNhHm36fX1Wi9qaKBG9zzIpFd7 +wKGDw21Vnc3y8fqvI3npK9fos186bRivCpiQ7JHpa9066S7UedwSvdUl9eR+VpTJxKK BKA1e2Io4ZT3lSGbLNgiCIN+FWsRtxCcOuKLyb9iWRh8YlEOItAgIitTeKPEpUhmwbNj aDsQ== X-Gm-Message-State: AN3rC/6fXShcaF4ulpQwOteFuM4tXmWXjwbncFWCIu+u4cPUT1yerwtV 409i53M2PU9M3Tci9gtnUQ== X-Received: by 10.99.170.2 with SMTP id e2mr9059404pgf.0.1492203717587; Fri, 14 Apr 2017 14:01:57 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:b07e:d927:9e4:7b7a? ([2620:0:10e7:10:b07e:d927:9e4:7b7a]) by smtp.gmail.com with ESMTPSA id n4sm4809607pfg.73.2017.04.14.14.01.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 14:01:56 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_7042C29D-0519-435B-9BED-2D43CACAB130" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 14:01:55 -0700 References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> To: IPv6 Operations In-Reply-To: Message-Id: <45DE75F9-75DF-487C-95A9-781944284CE2@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] rfc7084-bis and homenet X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:02:01 -0000 --Apple-Mail=_7042C29D-0519-435B-9BED-2D43CACAB130 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 14, 2017, at 12:42, David Farmer wrote: >=20 > [=E2=80=A6] I'd agree from an architectural perspective, there is no = reason for site prefixes longer than a /48. [=E2=80=A6] Again, not fair. I=E2=80=99m not making any such claim, and I don=E2=80=99= t want anyone to be mistaken about it. The claim I'm making is much more narrow: from an architectural = perspective, there is no reason for site prefixes to be *SHORTER* than = 48 bits. My claim is that every site from the smallest to the largest = can live its entire lifespan without ever renumbering if it is assigned = a stable prefix of any length up to 48 bits. Any more than 48 bits and = sites run the risk of being forced to renumber when they run out of = subnet identifier space, so the most suitable request for them to make = is for a stable /48 routing prefix. The *ONLY* reason to ask for a longer prefix is if the network will = grant as short a prefix as the site requests, then charges subscribers = progressively more based on the size of their subnet identifier. I do recognize there are often business reasons for forcing sites to use = a smaller subnet identifier number space, i.e. to force them to renumber = and pay a premium when they need to move to a routing prefix with larger = subnet identifiers. =46rom an architectural perspective, that serves the = interests of network owner-operators by the creation of an artificial = number scarcity, entirely for business purposes only, where numbers in = reality are under monstrous glut conditions so terrible that people = should actually be paid for consuming them. I simply disagree with those who believe that the Internet architecture = should serve the interests of service provider network owners over the = interests of Internet users. I also recognize this is unlikely ever to = be a popular viewpoint in the V6OPS working group. --james woodyatt > --Apple-Mail=_7042C29D-0519-435B-9BED-2D43CACAB130 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 14, 2017, at = 12:42, David Farmer <farmer@umn.edu> wrote:

[=E2=80=A6] I'd agree from an = architectural perspective, there is no reason for site prefixes = longer than a /48. [=E2=80=A6]

Again, not fair. I=E2=80=99m not making any such = claim, and I don=E2=80=99t want anyone to be mistaken about = it.

The claim I'm making is much = more narrow: from an architectural perspective, there is no reason for = site prefixes to be *SHORTER* than 48 bits. My claim is that every site = from the smallest to the largest can live its entire lifespan without = ever renumbering if it is assigned a stable prefix of any length up to = 48 bits. Any more than 48 bits and sites run the risk of being forced to = renumber when they run out of subnet identifier space, so the most = suitable request for them to make is for a stable /48 routing = prefix.

The *ONLY* reason to ask for = a longer prefix is if the network will grant as short a prefix as the = site requests, then charges subscribers progressively more based on the = size of their subnet identifier.

I = do recognize there are often business reasons for forcing sites to use a = smaller subnet identifier number space, i.e. to force them to renumber = and pay a premium when they need to move to a routing prefix with larger = subnet identifiers. =46rom an architectural perspective, that serves the = interests of network owner-operators by the creation of an artificial = number scarcity, entirely for business purposes only, where numbers in = reality are under monstrous glut conditions so terrible that people = should actually be paid for consuming them.

I simply disagree with those who = believe that the Internet architecture should serve the interests of = service provider network owners over the interests of Internet users. I = also recognize this is unlikely ever to be a popular viewpoint in the = V6OPS working group.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_7042C29D-0519-435B-9BED-2D43CACAB130-- From nobody Fri Apr 14 14:09: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 17BED12952C for ; Fri, 14 Apr 2017 14:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 lL89jFFmHTdv for ; Fri, 14 Apr 2017 14:09:42 -0700 (PDT) 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 00EA3129508 for ; Fri, 14 Apr 2017 14:09:41 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id 63so4787094pgh.0 for ; Fri, 14 Apr 2017 14:09:41 -0700 (PDT) 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=UIeknjlmf1XRlfKlSmD7TA+tu44lRRqYUSd6BAjCkyA=; b=Rl3sxktQveaPKMsqZgslPWo8F2blXYV1ZixFjfvz5b7nzc7kk8Oku6by/kXe/5uzaX 4rWueHDD6fE8Y0VbQCAS8gguT8d2i9mxkUi3Tc6YU2ibPYI9aBF+IkWICndrLOtvglMH QitN+lHMSsxuJu+uJY1HmAsJ2LxUKQwcvZ7mNxzAuUH2J1Js9pZRXPsIt45GK20dWroT IDk+rali8C8wWBN02E34QTCQJlMZ3xwViUz20EQFXsNFTuI4+I4xT75pTNwKMKrF3Qxj guaE2A6Bmd2U1q7bWo90BVM63e0QowlJcCbfbUMR/Q34q/hpqDpV/1/Va2i0k8S3wKGp 5HNQ== 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=UIeknjlmf1XRlfKlSmD7TA+tu44lRRqYUSd6BAjCkyA=; b=CwOtAPcEBRUERZjSBn3OUQ4eTTkS3QUXRgmHE7ob9v7e2XZ2x2HAEnl/iUMMLFNRQT oIoyGJfJqcwRBby+xydFDUgOi03OZS5bzXXDjrCd65opm7AzM1AivUD1YEbVKnj+CggI HXyFKW596lGUoveYI+NBksfxQ64jl0IrU9Rr5MP+S9ES/T+e81oLOYP/+XrSLxByzjyp kiDnDFfR2EQ3tWiOX+Sp/g9cJzBVhzXi5szSfwSKZPaUnioD9//aprboS9qPu2zUaI0M AjIEy9xlu317fcq3waDTACbX41lHD3JxukGpZ+w54xsNlbsQ8zed82bntyJ3jj3B27I/ BRIg== X-Gm-Message-State: AN3rC/5LhgEWB6upXCS5QWsdSEgNxqY8Zl3E4SyVI1/R5aBSBN84VpZj 0j90GaX7WBJ1/g== X-Received: by 10.99.9.66 with SMTP id 63mr9160809pgj.22.1492204181619; Fri, 14 Apr 2017 14:09:41 -0700 (PDT) Received: from ?IPv6:2406:e001:38c5:1:28cc:dc4c:9703:6781? ([2406:e001:38c5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s21sm4837647pgg.65.2017.04.14.14.09.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 14:09:40 -0700 (PDT) To: David Farmer , james woodyatt References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> Cc: "v6ops@ietf.org" From: Brian E Carpenter Organization: University of Auckland Message-ID: <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> Date: Sat, 15 Apr 2017 09:09:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:09:43 -0000 On 15/04/2017 05:55, David Farmer wrote: ... > So if we really want to fix this rfc7084-bis needs a SHOULD support prefix > delegation of any length between /48 and /64, and MUST support prefix > delegations of /48, /52, /56, /60, and /64. Why wouldn't we simply say "MUST support prefix delegation of any length between /48 and /64"? Even that is not what the IPv6 routing architecture requires, which is "MUST support prefix delegation of any length." Brian From nobody Fri Apr 14 14:40: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 7BAD51294C9 for ; Fri, 14 Apr 2017 14:40:55 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 DqV181XGBKif for ; Fri, 14 Apr 2017 14:40:53 -0700 (PDT) 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 3AFD11293FB for ; Fri, 14 Apr 2017 14:40:53 -0700 (PDT) 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 v3ELepnJ006602; Fri, 14 Apr 2017 14:40:52 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3ELem96006584 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 14 Apr 2017 14:40:48 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 14:40:47 -0700 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.1263.000; Fri, 14 Apr 2017 14:40:47 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson CC: IPv6 Ops WG Thread-Topic: draft-templin-v6ops-pdhost (RE: [v6ops] Review draft-templin-v6ops-pdhost-02) Thread-Index: AdK1Zp14af1SU8mFSNiat/Ah2etPvw== Date: Fri, 14 Apr 2017 21:40:47 +0000 Message-ID: <00631cf9e0484dcc92095bb79eab5223@XCH15-06-08.nw.nos.boeing.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] draft-templin-v6ops-pdhost (RE: Review draft-templin-v6ops-pdhost-02) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:40:55 -0000 Hi, I would like to get the ball rolling again on this discussion from back= in August 2016. This is concerning 'draft-templin-v6ops-pdhost', which I have recently brou= ght back from the "expired" state: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ See below for the discussion context. It includes proposed resolutions to c= omments that have not been incorporated into the document yet pending confirmations= . I believe this document provides timely information given the current trend o= f the v6ops discussions. Please send comments to the list. Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Tuesday, August 23, 2016 3:15 PM > To: Mikael Abrahamsson > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 >=20 > Hi Mikael, >=20 > Thank you for taking the time to review the document. Please see below > for follow-ups: >=20 > > -----Original Message----- > > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > Sent: Friday, August 19, 2016 2:54 AM > > To: Templin, Fred L > > Cc: IPv6 Ops WG > > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02 > > > > On Thu, 18 Aug 2016, Templin, Fred L wrote: > > > > > Hello, > > > > > > A new version of this draft is now available based on review comments= received. > > > The comments have greatly improved the document, which now also inclu= des > > > figures that clearly illustrate the concepts described: > > > > > > https://www.ietf.org/id/draft-templin-v6ops-pdhost-04.txt > > > > Re-reading as if I never read it before: > > > > 1. Intro > > > > " Hosts > > 'Hn' on a LAN interface subsequently receive addresses 'An' taken > > from 'P' via an address autoconfiguration service such as IPv6 > > Stateless Address Autoconfiguration (SLAAC) [RFC4862]." > > > > If A=3D1 is used, I'd avoid using the term "receive addresses". "alloca= te > > addresse(s) for themselves" or similar term is more appropriate to make > > sure the reader understands the distinction. >=20 > How does this sound as a rewrite: >=20 > "Hosts 'Hn' subsequently obtain one or more addresses 'An' for themselv= es > via an address autoconfiguration service such as IPv6 Stateless Addre= ss > Autoconfiguration (SLAAC) [RFC4862]." >=20 > > 4. > > > > "The node also configures a default > > route that points to a router on the WAN link." > > > > This sentence can in context confuse readers to believe that this defau= lt > > route is installed because of receiving a delegated prefix, when in fac= t > > this is done because the node received an RA. Right? >=20 > Default routes can be configured via manual config and/or from whatever > form of autoconfiguration is appropriate for the link - of which RA is ju= st > one example. But, maybe it would be best to simply remove this sentence > and remain silent on the subject of default routes? >=20 > > 5. MLD/DAD Implications > > > > This is confusing. The node still has a LL which it needs to perform > > MLD/DAD for on the WAN interface, correct? >=20 > No, it is the same for LL's if DupAddrDetectTransmits is 0 - no DAD/MLD. >=20 > > Wouldn't it be better to just > > recommend not to put the delegated prefix addresses on the WAN interfac= e > > at all, but exlusively use a virtual interface? On that virtual interfa= ce > > then MLD/DAD can be turned off. Otherwise the WAN interface needs to > > selectively support DAD/MLD for some addresses configured on it, and no= t > > for others. >=20 > The document is referring to the case where no DAD/MLD is needed for any > addresses assigned to the interface -including LL, GUA, etc. >=20 > > 6. > > > > Is the third paragraph really necessary? It describes no new > > functionality, the text seems to describe normal IPv6 operations. Seems= it > > would only confuse the reader? >=20 > I don't mind removing the paragraph. But, in that case, I would still wan= t > to cite I-D.templin-aerolink as an example link where this is useful. >=20 > > 7. > > > > This paragraph would be simpler if we just avoid configuring the PD bas= ed > > addresses on the WAN interface. > > > > Summary: > > > > I am sympathetic to hosts requesting PD and then using it to assign its= elf > > addresses. I just think it would be cleaner if the weak host model was > > recommended and that the PD based addresses would only be configured on= a > > virtual interface in case only the WAN interface exists. >=20 > Some hosts may need to see ip_forwarding set to '1' if the addresses > are assigned to a virtual interface (e.g., a loopback) instead of the > WAN interface. Also, the MTU of the virtual interface would need > to be somehow matched to the MTU of the WAN interface in order > for TCP to correctly set its initial MSS, and that may be cumbersome > in some cases. >=20 > So, in my experience it is cleaner to assign the addresses to the WAN > interface. I am currently doing this on Androids using AERO, and the > applications seem to like it. >=20 > > Also, calling it "WAN" interface is a bit confusing. What is a "WAN" > > interface on a host? I have no better suggestion for what to call it, W= AN > > is short and "sweet" and using other names might just cause more > > confusion. The draft outlines what it means by WAN interface (good that > > you added the drawings) so it should be ok. >=20 > OK. >=20 > > The draft is DHCPv6 heavy and SLAAC light when it comes to text, it see= ms > > to talk more about DHCPv6 functions and glosses over things that are > > configured because of RAs etc. For someone not familiar with IPv6, they > > might draw the wrong conclusions on how IPv6 works regarding RA/DHCP > > interaction and what causes what. Perhaps there should be some more > > pointers to this, and if the text is DHCP verbose, then I think it need= s > > to be equally verbose on SLAAC/RA. >=20 > DHCPv6 PD is cited only as an example in the first paragraph of Section 1= . > Any other prefix delegation method is also in-scope. Other methods > include manual configuration, and any other prefix delegation method > that may one day be specified. >=20 > If you have specific examples of where the text seems to be inferring > DHCPv6 PD, I would be happy to make the text more generic so that > it is clear that DHCPv6 PD is only an example. >=20 > Thanks - Fred > fred.l.templin@oboeing.com >=20 > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 14 15:05: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 7DC55129B08 for ; Fri, 14 Apr 2017 15:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVfkhn1j1vtt for ; Fri, 14 Apr 2017 15:05:01 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D313129B11 for ; Fri, 14 Apr 2017 15:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492207494; x=1492812294; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=oogWcAnPT0ZSSXI9m8FrNFKBX QGFnbFVKjXWGubf8zc=; b=RF5vqJtpIgFiQmhEJ9CBTHPr6IOoTEmk3Dmnr9Fvf xRYzNW6s5h3/yvy0JgXX/mKChPhjCkzXuMiBXMqwgZFnrwShqyyMc8BVb+qAt5ho 6OYyc54pj8m2CyP0pK65peOWhSOZKJqj/NKzmC2MmHFkzjjdvn2eI98DggOSjwWu x4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VvNgAtBTYU/qQWqkgW9qa7TcDs5IUHBIkm2e4r64aSz+ePvJbCBoYiyWsNG6 eKJiilTX59pnDR0vsIucQnVyKXdzQuEwSrWQvhoOc14xyQiYKx2wbr8fW IzFlWmRdpm89JHRMQehdW/babNbLnRLxqEfoBhhGHzWMASGsllVxCw=; X-MDAV-Processed: mail.consulintel.es, Sat, 15 Apr 2017 00:04:54 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 15 Apr 2017 00:04:53 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005408767.msg for ; Sat, 15 Apr 2017 00:04:53 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170414:md50005408767::+ShddVGuypE8zX2a:000071mP X-Return-Path: prvs=12776aa295=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sat, 15 Apr 2017 00:04:50 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <8AB31715-9F0C-4F9C-8D31-A38F646C7D26@consulintel.es> Thread-Topic: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> In-Reply-To: <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 22:05:05 -0000 If it was my personal decision, I=E2=80=99m will more on the side to =E2=80= =9Cforce=E2=80=9D to always provide /48 to everyone, and I don=E2=80=99t wa= nt to start here again the discussion about that. I really think those chan= ges from RFC3177 to RFC6177 did a huge damage to the way the ISPs understoo= d IPv6 and as a consequence, how they are deploying it and in many cases ma= king big mistakes. However, as editor of RFC7084-bis, I must have a more balanced view =E2=80= =A6 In the original document the relevant requirement for the WAN-side configur= ation is: W-4: The router MUST act as a requesting router for the purposes of DHCPv6 prefix delegation ([RFC3633]). And this has not been changed in the actual version. In this document, we are referring to each =E2=80=9Crelevant=E2=80=9D piece= of the multiple layers of the cake that makes the =E2=80=9Ccomplete cake= =E2=80=9D, but we aren=E2=80=99t entering in the discussion of changing the= =E2=80=9Cingredients and their quantities=E2=80=9D of each portion of that= cake, and I think we should keep it that way. What I mean here is that if we believe that RFC3633 MUST say something abou= t the length to be supported, then it is RFC3633 which need to be changed o= n that, not RFC7084-bis. Otherwise, we will be making a set of references t= o RFCs with lots of exceptions or restrictions to those RFCs, which make th= em totally different things. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: viernes, 14 de abril de 2017, 23:09 Para: David Farmer , james woodyatt CC: "v6ops@ietf.org" Asunto: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] On 15/04/2017 05:55, David Farmer wrote: ... > So if we really want to fix this rfc7084-bis needs a SHOULD support p= refix > delegation of any length between /48 and /64, and MUST support prefix > delegations of /48, /52, /56, /60, and /64. =20 Why wouldn't we simply say "MUST support prefix delegation of any length between /48 and /64"? =20 Even that is not what the IPv6 routing architecture requires, which is "MUST support prefix delegation of any length." =20 Brian =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Fri Apr 14 15:09: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 34973126DED for ; Fri, 14 Apr 2017 15:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=umn.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 iR7EFEZqKDpj for ; Fri, 14 Apr 2017 15:09:55 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 8A6D21243F3 for ; Fri, 14 Apr 2017 15:09:55 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 1D455A84 for ; Fri, 14 Apr 2017 22:09:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YVV_wjGrfNO for ; Fri, 14 Apr 2017 17:09:54 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id DEA8B794 for ; Fri, 14 Apr 2017 17:09:54 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id 20so20011863uag.14 for ; Fri, 14 Apr 2017 15:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7n03Ld51FsHEP0HmV2k9fxVjqfWtk6I3T/NJX6D+HbE=; b=N4GntgrfN1yffMeMuWbMfxDCXXISY41+F5mvqt9KX3ZHk5jrOAVzXLEJr0BFTpkS7D awFZ9hP2euYWsJn3nOS4HTkSIUhP/C7kSPRSqp8Ccy0uj64lbbt2WdX5jQWlHlfRWUvv ei3cdWMVDuhQ0ByaOIJQaswrJl6eCtblOgbrgB6fJjJPrQ2wEvY4B6sCYCqsBw/1AhdG EgdGe5JuCXqKpfvOGVfI/z3WbVldULW1U+J7zwHWEbke76yvVwxJP5FgyC6BHBO5Prn2 /Bz+S0EiXvzepLhtK3H+PortsV2RaHNMtefuCM/tsBWzcfm6Gm+/zPTCOGB0LcyORS7J wAZQ== 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=7n03Ld51FsHEP0HmV2k9fxVjqfWtk6I3T/NJX6D+HbE=; b=jcNPEC44ALPjf2vrWHzd/1LSfPJiK1OHxUvfwcEhgdAebY9cFJCC8A8rSHBSHl0FeG NDOeBQXv/BFEvGowBwJ5gEG6S85gYWArgVLDBfRQeMYEAUb60I4lJoYNL1LIvwVfDo5u NEYztBibEVVK2Lw2/uFUdYE0mI0jJUte05MpjRLNvSvK3AhtfB1aIGfHEZtPAeC3e0M1 lrP+GzsVoFk/Suc+UYnL/uYJrD7a4CyZ1Mbm+cjxeYrzU+r8sBSSPXntvNBlG9CdSqOF PsKihF92E5DEI6/vwEwfcy5X69aVVk8K97qkitHUgLYS81DnRTwWJAch2LBC4nk9wmaX e1eA== X-Gm-Message-State: AN3rC/6w9BqYa2BEtWkbOilGTtb0usLKPEQRvmrBQ5/7heuiXtD8DJD4 v30N9VWrP6bOvkfjgM0frddN7jcb8i5+fH/ONr8E5hC1Jb/qANhFQG7yaEA+6ajbLfXIT9ZKjH+ mnuLeetYX/xEaPOUX X-Received: by 10.176.90.143 with SMTP id w15mr5083952uae.12.1492207794382; Fri, 14 Apr 2017 15:09:54 -0700 (PDT) X-Received: by 10.176.90.143 with SMTP id w15mr5083948uae.12.1492207794226; Fri, 14 Apr 2017 15:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.69 with HTTP; Fri, 14 Apr 2017 15:09:53 -0700 (PDT) In-Reply-To: <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> From: David Farmer Date: Fri, 14 Apr 2017 17:09:53 -0500 Message-ID: To: Brian E Carpenter Cc: james woodyatt , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=f403045ee578819f64054d27b3c0 Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 22:09:57 -0000 --f403045ee578819f64054d27b3c0 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 14, 2017 at 4:09 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 15/04/2017 05:55, David Farmer wrote: > ... > > So if we really want to fix this rfc7084-bis needs a SHOULD support > prefix > > delegation of any length between /48 and /64, and MUST support prefix > > delegations of /48, /52, /56, /60, and /64. > > Why wouldn't we simply say "MUST support prefix delegation of any > length between /48 and /64"? > Because RFC 6177 recommends nibble alignment for DNS simplicity, but avoidance of bit math errors is an equally good reason. If for a consumer device someone wanted to limit the choices to only those 5 lengths, I'd be fine with that. A MUST for any prefix between /48 and /64 wouldn't allow such simplification for consumers. By explicitly calling out those 5, I'd hope they would actually get tested too. Also, I'm trying to limit the MUSTs to what think I will get deployed in the real world. In IPv4 there is a natural tendency to organize things based on decimal digits, in IPv6 there is a similar tendency to organize things that way. Nibble alignment should make things slightly easier for non-technical users, and help technical users make fewer mistakes. > Even that is not what the IPv6 routing architecture requires, which > is "MUST support prefix delegation of any length." > > Brian -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403045ee578819f64054d27b3c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Apr 14, 2017 at 4:09 PM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
On 15/04/2017 05:55, David Farmer wrote:
...
> So if we really want to fix this rfc7084-bis needs a SHOULD support pr= efix
> delegation of any length between /48 and /64, and MUST support prefix<= br> > delegations of /48, /52, /56, /60, and /64.

Why wouldn't we simply say "MUST support prefix delegation of any<= br> length between /48 and /64"?

Becau= se RFC 6177 recommends nibble alignment for DNS simplicity, but avoidance o= f bit math errors is an equally good reason.=C2=A0 If for a consumer device= someone wanted to limit the choices to only those 5 lengths, I'd be fi= ne with that.=C2=A0 A MUST for any prefix between /48 and /64 wouldn't = allow such simplification for consumers. By explicitly calling out those 5,= I'd hope they would actually get tested too.=C2=A0 Also, I'm tryin= g to limit the MUSTs to what think I will get deployed in the real world.= =C2=A0

In IPv4 there is a natural tendency to orga= nize things based on decimal digits, in IPv6 there is a similar tendency to= organize=C2=A0things that way.=C2=A0 Nibble alignment should make things s= lightly easier for non-technical users, and help technical users make fewer= mistakes. =C2=A0 =C2=A0
=C2=A0
Even that is not what the IPv6 routing architecture requires, which
is "MUST support prefix delegation of any length."

=C2=A0 =C2=A0Brian

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication ServicesOffice of Information Technology
University of Minnesota=C2=A0=C2=A0 <= br>2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045ee578819f64054d27b3c0-- From nobody Fri Apr 14 18: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 85891129B30 for ; Fri, 14 Apr 2017 18:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 M93MprNFurOf for ; Fri, 14 Apr 2017 18:22:57 -0700 (PDT) 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 09FCC129AB0 for ; Fri, 14 Apr 2017 18:22:57 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id s16so46113397pfs.0 for ; Fri, 14 Apr 2017 18:22:57 -0700 (PDT) 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=4Tz4Ucaewq/YgAjRaaW+tFGZu9q0WyeXh6eeHjhv6eo=; b=bDo68qHYt5ARpnKPBA62hhuUZ1u1E6AZEzMSRNhwsS8XiKcZJ5pt31kPIeFBY8kOPQ qpZdaYWxp6f7oPgVp/rclkYBeK0twu5/K8J/MPA6yDm64Bhs/ILaCewzmscgKX+y0J4e vzzdPFQjd0dqtrUQM8D8TJdO1Mq/o5m6ZcgtIDj+1HLI0VzhR0rJe0ZGrFvy6pA+kHph B+Wp+CHPgm6WgP57Qw7ZK/+f7MhVOmFX6j+GYfef195yCdNWnhauibtulBodngrV2+c7 UKqiWLpx3HOuB8bheZWilWEJv5B5a2PDXb09ZxEgGLkyJBRSk6XnvBeboa6WTgiyoUZR bmsA== 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=4Tz4Ucaewq/YgAjRaaW+tFGZu9q0WyeXh6eeHjhv6eo=; b=GMED5B4dHhgkrLqmri3k9ObmFsQN0toSXXdU3QRznkazFoVd8yPM3iRXQY7GoGK8a0 7fu/erbTJaaN8fN7XQBfm+J7V93CeIoMUgtKST5IXaX0mzGDfSmEmSTdWZWilyWlLTDJ 2PxgslclzYbl6F0PfdAxs0hAqfCLbIuQyxYGDPWWKEa99WTdyi6zFVwHEwBkNxiRYhrJ kwsB9Kkb20eF9hGMpTuWCVNYCKSi/JDt7bhXVh50HrKqoufUS1AHJvR8XsY+uDDMIniN fvFwVR3BGPMlKKkGlQ6bnVSe0ngwfIGxz8nReMFqbpUMCOC99JiaxWICPfHrWidvalwJ GHgA== X-Gm-Message-State: AN3rC/47+FEFixB6+XT5A52hxdyflOFIzmtg4290SpMXsnpD/nObfKQi yMwdsJODpHCC7w== X-Received: by 10.99.54.72 with SMTP id d69mr434854pga.24.1492219376626; Fri, 14 Apr 2017 18:22:56 -0700 (PDT) Received: from ?IPv6:2406:e001:38c5:1:28cc:dc4c:9703:6781? ([2406:e001:38c5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s68sm617727pfj.77.2017.04.14.18.22.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 18:22:56 -0700 (PDT) To: David Farmer References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> Cc: james woodyatt , "v6ops@ietf.org" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 15 Apr 2017 13:23:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 01:22:58 -0000 On 15/04/2017 10:09, David Farmer wrote: > On Fri, Apr 14, 2017 at 4:09 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 15/04/2017 05:55, David Farmer wrote: >> ... >>> So if we really want to fix this rfc7084-bis needs a SHOULD support >> prefix >>> delegation of any length between /48 and /64, and MUST support prefix >>> delegations of /48, /52, /56, /60, and /64. >> >> Why wouldn't we simply say "MUST support prefix delegation of any >> length between /48 and /64"? >> > > Because RFC 6177 recommends nibble alignment for DNS simplicity, but > avoidance of bit math errors is an equally good reason. 6177 is irrelevant IMNSHO. We're talking about best practice for router design, and that is surely full support of VLSM/CIDR. And is it really our job to advise people that binary arithmetic is hard? > If for a consumer > device someone wanted to limit the choices to only those 5 lengths, I'd be > fine with that. Well, elsewhere on this list there are operators calling for even removing /64 from our vocabulary. So the more I think about it, the more it seems to me that there is no reason to exempt a CE router from the most fundamental router requirement of all: handle any prefix length. Limiting it to /48.../64 may be practical for now, but in fact it's wrong. > A MUST for any prefix between /48 and /64 wouldn't allow > such simplification for consumers. By explicitly calling out those 5, I'd > hope they would actually get tested too. Also, I'm trying to limit the > MUSTs to what think I will get deployed in the real world. > > In IPv4 there is a natural tendency to organize things based on decimal > digits, in IPv6 there is a similar tendency to organize things that way. > Nibble alignment should make things slightly easier for non-technical > users, and help technical users make fewer mistakes. I agree, when humans are involved. So I'd prefer to see ISPs following the 6177 advice. But I don't think it's OK to build that into a hardware requirements spec. Thus: >> Even that is not what the IPv6 routing architecture requires, which >> is "MUST support prefix delegation of any length." Brian From nobody Fri Apr 14 18:25: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 2AA6D129B38 for ; Fri, 14 Apr 2017 18:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5HFbQYXWUCoI for ; Fri, 14 Apr 2017 18:25:27 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 C1518129B37 for ; Fri, 14 Apr 2017 18:25:27 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id i5so46083791pfc.2 for ; Fri, 14 Apr 2017 18:25:27 -0700 (PDT) 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=ddhonemrOgPoIUhQKlc2OrKzQNhhKjVAMVJVUpbstvg=; b=t7v1wI4XvQoecc6AhoyagqucpHI4b9T38mO1eYLZbSUo77ZUp2CJmuk3kAXEYZ3/eL JeGyqrYe/XAy8HG7mwECKinfDawuPG/jLxBaObP1150DJnnrO+EwOxAGAhyWCjvPBUOn w2Q0sOuhe1v5HtbirYlsc2cUINDWHvTXv09M8kkDltVAdN7b86gxaFVvAJkxE8w9tUsw 3HLVe77ehqlys3danBJegNA1SdSfk4XmOFC1ah48d7fQnNI3L+Efqxnz5esNthZOJ+n2 kEzicil21hQ6TFgnUF4vk29VVSTMEfm4Nni8iS67jI2HRH6i33DxKMJMLhmgukvpAGuk ZcLA== 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=ddhonemrOgPoIUhQKlc2OrKzQNhhKjVAMVJVUpbstvg=; b=R3bzF23pgHx1kNMapf6gh2VEK0NI5GqYzx9hmgdZTpECaW84T9ETt6Q1rm14Y6ulb0 O+yESwpNyE9LlTTLkBMiZH1jzJ3/Ga1fUxDXn9hn93O9HVd3rgBNb1hEjuewXf1NmSdj ySr+jXea1d3bQNtGUSopJ3/f5lybxXsIClLVMXUiVcGilDPYDkEvx/TEtH6DFoZAk7AY WOiO+ZMDJvNqi1ISDzXrOmaF76TADbxDsaqj0cxTNixOxX3WqHFaqwmUm/KI6uCbV3TR O6Iqv+lTWVQhedlbeEt2o6LaKtXneWAwiyJQsOcF48+Dykx30KCXb+W/9y4LiyJSgwxD ykgQ== X-Gm-Message-State: AN3rC/4+GgNzrHBEybX30/x3SG8RVsQ2UvmBvWJ4pXlfp5TzlfxNvfSy /aiOTQMw+D7VEPLo X-Received: by 10.84.129.131 with SMTP id b3mr556918plb.160.1492219527234; Fri, 14 Apr 2017 18:25:27 -0700 (PDT) Received: from ?IPv6:2406:e001:38c5:1:28cc:dc4c:9703:6781? ([2406:e001:38c5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h85sm1583003pfd.114.2017.04.14.18.25.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 18:25:26 -0700 (PDT) To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <8AB31715-9F0C-4F9C-8D31-A38F646C7D26@consulintel.es> From: Brian E Carpenter Organization: University of Auckland Message-ID: <64ec3035-751f-0eb5-0ccd-60beb6f1d909@gmail.com> Date: Sat, 15 Apr 2017 13:25:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8AB31715-9F0C-4F9C-8D31-A38F646C7D26@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 01:25:29 -0000 On 15/04/2017 10:04, JORDI PALET MARTINEZ wrote: > If it was my personal decision, I=E2=80=99m will more on the side to =E2= =80=9Cforce=E2=80=9D to always provide /48 to everyone, and I don=E2=80=99= t want to start here again the discussion about that. I really think thos= e changes from RFC3177 to RFC6177 did a huge damage to the way the ISPs u= nderstood IPv6 and as a consequence, how they are deploying it and in man= y cases making big mistakes. >=20 > However, as editor of RFC7084-bis, I must have a more balanced view =E2= =80=A6 >=20 > In the original document the relevant requirement for the WAN-side conf= iguration is: >=20 > W-4: The router MUST act as a requesting router for the purposes of > DHCPv6 prefix delegation ([RFC3633]). >=20 > And this has not been changed in the actual version. >=20 > In this document, we are referring to each =E2=80=9Crelevant=E2=80=9D p= iece of the multiple layers of the cake that makes the =E2=80=9Ccomplete = cake=E2=80=9D, but we aren=E2=80=99t entering in the discussion of changi= ng the =E2=80=9Cingredients and their quantities=E2=80=9D of each portion= of that cake, and I think we should keep it that way. >=20 > What I mean here is that if we believe that RFC3633 MUST say something = about the length to be supported, then it is RFC3633 which need to be cha= nged on that, not RFC7084-bis. Otherwise, we will be making a set of refe= rences to RFCs with lots of exceptions or restrictions to those RFCs, whi= ch make them totally different things. Exactly right. A router should never make assumptions about these things.= Brian >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Responder a: > Fecha: viernes, 14 de abril de 2017, 23:09 > Para: David Farmer , james woodyatt > CC: "v6ops@ietf.org" > Asunto: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] >=20 > On 15/04/2017 05:55, David Farmer wrote: > ... > > So if we really want to fix this rfc7084-bis needs a SHOULD suppo= rt prefix > > delegation of any length between /48 and /64, and MUST support pr= efix > > delegations of /48, /52, /56, /60, and /64. > =20 > Why wouldn't we simply say "MUST support prefix delegation of any > length between /48 and /64"? > =20 > Even that is not what the IPv6 routing architecture requires, which= > is "MUST support prefix delegation of any length." > =20 > Brian > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that= any disclosure, copying, distribution or use of the contents of this inf= ormation, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri Apr 14 18:37: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 80C4E127369 for ; Fri, 14 Apr 2017 18:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, HK_RANDOM_FROM=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=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 DGGYyW6qzP37 for ; Fri, 14 Apr 2017 18:37:51 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 ED78A129B36 for ; Fri, 14 Apr 2017 18:37:50 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id j127so37904676vkh.0 for ; Fri, 14 Apr 2017 18:37:50 -0700 (PDT) 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=/NCtQOHr7tVy+bm8eALpgfDb66Z122nJns8+Lusiik4=; b=FvK7VkS6gIUaiWSp/SWZigK45+iTj/SP4498cuCjDkRL0EF44cmVVRC7RInCSSnst2 W+w0qwcoqkeORSPr2TydvvSfOBNuMpuh8RBdmHEUTssf9+8wQL/7nfvkpd+1o8FpVpxj cbE3WLPm8va9QgEQ+wOctYSgSgjnpAClbbj0xmhjjh9jgBFtvm3bBRWLaUsxKdi9h4po mcSXLTftDtywdmRj4VcBnIUkkYZCgLK/VovBVyI2lxDHXk7hKcq/EkgIpSt8DzIGks8h dQHBvoakXbtuxHpuzcc64lAWlRDhWx6tCnb7QnZOnjn6yjMRzZPoAAPKMFSLS98TAGCB VfTA== 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=/NCtQOHr7tVy+bm8eALpgfDb66Z122nJns8+Lusiik4=; b=tS2OeLUeYVQ+l8RDv1nPRlvtleAuQJ+j5opXqVvt0HRKdEDjkeJ5/ZBYEI0LPwLjSg x/pqQKRMQHjmkC5Gb/qko9OHOZ6XteWDf3s9QazurcgEsOazScFSQ/WTTkxb1thApJmA GxO3lOVN2jhB46p9LABNHvvDl9hN4X1i1iicOGFSCfDUdDl0EJvqq4CdzHnleLMhJ20T 4DheRkd700jX3u8DVISQajrkkteR2KrDAl+MIJn5Yt65XyV743e5JYftTARwsBePg5tl Bot1GBtXLycGljt1QsJ+2yQgPB3xDYD42Ce5XMxDscWLrmS+16XTSz5OdNGhieOt+INa FV2Q== X-Gm-Message-State: AN3rC/7GM8f/5tVfVKj1JonpnzHmf3gi1khbaHLjEpDUSBasYQP3jP+L nudyre72p3Ofbfvu2P/EGq0cJcz7Xg== X-Received: by 10.31.15.82 with SMTP id 79mr4337666vkp.156.1492220270080; Fri, 14 Apr 2017 18:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Fri, 14 Apr 2017 18:37:19 -0700 (PDT) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> From: Mark Smith Date: Sat, 15 Apr 2017 11:37:19 +1000 Message-ID: To: David Farmer Cc: Brian E Carpenter , james woodyatt , "v6ops@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 01:37:52 -0000 On 15 April 2017 at 08:09, David Farmer wrote: > > On Fri, Apr 14, 2017 at 4:09 PM, Brian E Carpenter > wrote: >> >> On 15/04/2017 05:55, David Farmer wrote: >> ... >> > So if we really want to fix this rfc7084-bis needs a SHOULD support >> > prefix >> > delegation of any length between /48 and /64, and MUST support prefix >> > delegations of /48, /52, /56, /60, and /64. >> >> Why wouldn't we simply say "MUST support prefix delegation of any >> length between /48 and /64"? > > > Because RFC 6177 recommends nibble alignment for DNS simplicity, but > avoidance of bit math errors is an equally good reason. If for a consumer > device someone wanted to limit the choices to only those 5 lengths, I'd be > fine with that. A MUST for any prefix between /48 and /64 wouldn't allow > such simplification for consumers. The simplification should be that CPE consumers don't have to deal with prefix lengths at all. We need to both remember and stop expecting that home users are network nerds or are interested in being network nerds. In a residential environment, nobody should ever even see or have to deal with an IPv6 address. No typing them in, reading them out, cutting-and-pasting them into devices, or planning and implementing an addressing structure to number multiple subnets. (It should be possible do this ... after all, computers can successfully drive cars on public roads.) >By explicitly calling out those 5, I'd > hope they would actually get tested too. Also, I'm trying to limit the > MUSTs to what think I will get deployed in the real world. > MUSTs are minimums, and since developer time costs money, there is a strong incentive to only implement the minimum. This is particularly the case with price sensitive low end CPE. So by saying MUST support /48, /52, /56, /60, and /64, that's all that will be implemented in CPE, as they'll make the same judgement you have ("what think I will get deployed in the real world"). That means it would be best to then prohibit ISPs from providing anything else to best ensure fault free interoperability. So the most robust choices are: - nominate a defined set of prefix lengths, and prohibit ISPs from providing and CPEs from supporting anything else - require support for any prefix lengths and don't nominate any specific ones Asking for both will be worse than choosing one or the other. Regards, Mark. > In IPv4 there is a natural tendency to organize things based on decimal > digits, in IPv6 there is a similar tendency to organize things that way. > Nibble alignment should make things slightly easier for non-technical users, > and help technical users make fewer mistakes. > >> >> Even that is not what the IPv6 routing architecture requires, which >> is "MUST support prefix delegation of any length." >> >> Brian > > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sat Apr 15 02:46: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 320321241FC for ; Sat, 15 Apr 2017 02:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 S5sl_ou0w7jk for ; Sat, 15 Apr 2017 02:46:09 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5187C1205F0 for ; Sat, 15 Apr 2017 02:46:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 4385D1BC37 for ; Sat, 15 Apr 2017 09:46:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Sat, 15 Apr 2017 10:46:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 09:46:11 -0000 Mark Smith wrote: > In a residential environment, nobody should ever even see or have to > deal with an IPv6 address. No typing them in, reading them out, > cutting-and-pasting them into devices, or ... Checks out of window, no there's no porcine aerial display team = practicing above our house :-) > So the most robust choices are: >=20 > - nominate a defined set of prefix lengths, and prohibit ISPs from > providing and CPEs from supporting anything else >=20 > - require support for any prefix lengths and don't nominate any = specific ones >=20 > Asking for both will be worse than choosing one or the other. Surely the most robust option is to say that CPE routers MUST handle any = prefix length, and ISPs SHOULD only issue from a fixed set of lengths - = would that latter requirement be better specified in a BCP ? While I'm = not a developer, I;d have thought that unless you only support 48 and 64 = bit prefix lengths, then supporting any prefix length is no harder than = supporting a fixed set that doesn't align on full 16 bit boundaries. I still have memories of finding that a CPE router from a major brand = refused to accept a.b.c.0 as a valid IPv4 address, presumably because = they were stuck in "no-one has more than a /24" mentality. I think you = are right to assume that if the standards don't say "MUST" for the right = things, CPE vendors will do stupid things. From nobody Sat Apr 15 10:18: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 099B5129438 for ; Sat, 15 Apr 2017 10:18:47 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 TpyDgJmKcyii for ; Sat, 15 Apr 2017 10:18:45 -0700 (PDT) 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 D8131129432 for ; Sat, 15 Apr 2017 10:18:44 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id g60so14165593qtd.3 for ; Sat, 15 Apr 2017 10:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=q0+6kwqNB7/C5dk3Fe/qcnUz05qZ9wLjaWgt2p69umk=; b=WC1QgvddkXCfj4GkuFq8pQdbMSgiogM5wSaY3DaaXdbRFQZYBBiQVPowAXeXmQrHWJ NHqQzdsg1X1IVqRepXdZDEAT54LJMMVwgCE+jELGs/tV3ykN5ec+0yXS+ltyTGhDsBKl jR6UJYbm+59XY1SL+giv7RuRBbWAJyFKv9wuPQJxoCtsauDr46dQIMlXdGZVQ3qPH4wc I65GceEgxZItHIuQwVxKwi0aRpTUfWy0Uo1g+jvAJUukJ4g8LtcBSZgEAblrhuNofrJg V/5zug7Oho6OOLNstqQtBx6SarlTjiJ4DW6fVTd82N1ljBmOjERCtHTJcCsB3MZhKzD0 HrBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=q0+6kwqNB7/C5dk3Fe/qcnUz05qZ9wLjaWgt2p69umk=; b=azX9O6xUbvTQKaGRPRLHC1JgCx51n86ImRjmsqV+Gbvw1TK6FySqTuOlypBSCv3uZr wbwh116iqNTcTylmstQgC3KAfRUBiaKnGG1dlHUNjiPvi6Dku3e9cNAtdHheN8MfqA50 R05ajtIpJloQCLQsJmhrzzVbIGTBqFzooBLkATX+yshfT11B2xjwChJZWuSyC7N6XKTy eMRXNe2iGd5/Ryt1gzWrHCufDJXw/IcX2Gdx5+mR7C8AvecFjgyrmYM8SUAEvX8poYIm w994ddniyTK31ab7ja6EpGFKmODdTpqVdBlBjRLmy/c+pUJZD96hS028zKFJtsIjcD8x ekLw== X-Gm-Message-State: AN3rC/6OAtrjRJO/VLQAv3A3T7qsVcw/JCUbu8sM9AQJRJcULobd10Rb qdCSgMB4iG8B2CRNPxvaAhiLnFaUZ3//5YY= X-Received: by 10.200.51.70 with SMTP id u6mr2694224qta.122.1492276724025; Sat, 15 Apr 2017 10:18:44 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> In-Reply-To: <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> From: Warren Kumari Date: Sat, 15 Apr 2017 17:18:32 +0000 Message-ID: To: Simon Hobson , "v6ops@ietf.org Operations" Content-Type: multipart/alternative; boundary=001a113a40840ae4ea054d37c0fc Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 17:18:47 -0000 --001a113a40840ae4ea054d37c0fc Content-Type: text/plain; charset=UTF-8 Ok, so dumb user question here -- how on earth do I know what I can request? Do I just ask for a /48, and if that doesn't work, ask for a /64, and if that does, try for a /56, and if that doesn't work try for a /60? Nope, calling my ISP and asking isn't a good option, nor is reading the 4-color glossies... W On Sat, Apr 15, 2017 at 5:46 AM Simon Hobson wrote: > Mark Smith wrote: > > > In a residential environment, nobody should ever even see or have to > > deal with an IPv6 address. No typing them in, reading them out, > > cutting-and-pasting them into devices, or ... > > Checks out of window, no there's no porcine aerial display team practicing > above our house :-) > > > > So the most robust choices are: > > > > - nominate a defined set of prefix lengths, and prohibit ISPs from > > providing and CPEs from supporting anything else > > > > - require support for any prefix lengths and don't nominate any specific > ones > > > > Asking for both will be worse than choosing one or the other. > > Surely the most robust option is to say that CPE routers MUST handle any > prefix length, and ISPs SHOULD only issue from a fixed set of lengths - > would that latter requirement be better specified in a BCP ? While I'm not > a developer, I;d have thought that unless you only support 48 and 64 bit > prefix lengths, then supporting any prefix length is no harder than > supporting a fixed set that doesn't align on full 16 bit boundaries. > I still have memories of finding that a CPE router from a major brand > refused to accept a.b.c.0 as a valid IPv4 address, presumably because they > were stuck in "no-one has more than a /24" mentality. I think you are right > to assume that if the standards don't say "MUST" for the right things, CPE > vendors will do stupid things. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113a40840ae4ea054d37c0fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, so dumb user question here -- how on earth do I know what I can request= ? Do I just ask for a /48, and if that doesn't work, ask for a /64, and= if that does, try for a /56, and if that doesn't work try for a /60?
Nope, calling my ISP and asking isn't a good option, nor is readi= ng the 4-color glossies...


W
On Sat, Apr 15, 2017 at 5:46 AM Simon Hobson <linux@thehobsons.co.uk> wrote:
=
Mark Smith <markzzzsmith@gmail.com> wrote:

> In a residential environment, nobody should ever even see or have to > deal with an IPv6 address. No typing them in, reading them out,
> cutting-and-pasting them into devices, or ...

Checks out of window, no there's no porcine aerial display team practic= ing above our house :-)


> So the most robust choices are:
>
> - nominate a defined set of prefix lengths, and prohibit ISPs from
> providing and CPEs from supporting anything else
>
> - require support for any prefix lengths and don't nominate any sp= ecific ones
>
> Asking for both will be worse than choosing one or the other.

Surely the most robust option is to say that CPE routers MUST handle any pr= efix length, and ISPs SHOULD only issue from a fixed set of lengths - would= that latter requirement be better specified in a BCP ? While I'm not a= developer, I;d have thought that unless you only support 48 and 64 bit pre= fix lengths, then supporting any prefix length is no harder than supporting= a fixed set that doesn't align on full 16 bit boundaries.
I still have memories of finding that a CPE router from a major brand refus= ed to accept a.b.c.0 as a valid IPv4 address, presumably because they were = stuck in "no-one has more than a /24" mentality. I think you are = right to assume that if the standards don't say "MUST" for th= e right things, CPE vendors will do stupid things.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a113a40840ae4ea054d37c0fc-- From nobody Sat Apr 15 10:32: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 8156412943D for ; Sat, 15 Apr 2017 10:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 A8a3PImBo5Yy for ; Sat, 15 Apr 2017 10:32:28 -0700 (PDT) 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 BD8F512422F for ; Sat, 15 Apr 2017 10:32:28 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id f133so83792345qke.2 for ; Sat, 15 Apr 2017 10:32:28 -0700 (PDT) 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=MKI8CikKw6BauJo7snM98kNz44DrQxs1f/yV5l+8LFw=; b=AppmDzBfgT2IC83ZNQjJH9BZ5Ap7SPXD41gR7QSgne1qiRfi2yiFubQxX09R3m+QHz AVQ9DYe3KbXY8Hqcw3dN/VHnitFz2lkAPgoHGQv4j/10fIlF5z2aYUglApm/P9R4CHMt PiHTUW7xzKAd4ByySAyBU6ZEcjeSDC5umOkpA887MzAMykwu2PhbzeO1zotumdR546B/ FmyitIf8oMOw8hsfC34npz48AoZ8VnKDW7XT3BfB0XpNOrb50vYYx2Djk8yBotLXI1L6 aPVtHIqmZPUIzNVl2LjntnTkUt42U28DXcKOX6St0gtwAgze8a/7DPvHONOK3M81yw7j VBow== 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=MKI8CikKw6BauJo7snM98kNz44DrQxs1f/yV5l+8LFw=; b=CozWj4IsosBSlfXNTTHbsD/jlKY20lWUwrrfFna2d5LSLJ1Peu45JsX1BjzHe6t4pL dm1ZoKpEWwyBSRl6/pPtvqHomSB5n9zbeNzqLJViOozNXV5FxhQwkZBeTZ9RAB47z/Oa c5BPpnLOxDPSjLFnQI1XhM/jIfhPYHCygy5oZrzj4qs+FcKNV5LWx9SPkM/OVf4LuJzz LGQ0jzJyIcJj+9kZmtzE/GqZkQp8rx8Vpvuuj8w/j0e9eA/oUm2pYGbP5zxX+3bbi3Uh /IWj8ioHU5Ph+wBqhlxwSDJFlu4VjqEzc4xwKtuaNgcE2H8mmd/+lOL3S8PafECCeXTJ 7j1w== X-Gm-Message-State: AN3rC/49TqvFd5vZ803mToJydQDAVRgy3oHWfn4Qns0vPWMhFzW7ZaQZ gZaANJw4s06KzTiBNRU= X-Received: by 10.55.170.215 with SMTP id t206mr2523902qke.303.1492277547967; Sat, 15 Apr 2017 10:32:27 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e19sm3495945qta.68.2017.04.15.10.32.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 10:32:27 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4478545C-B757-41BD-A360-EDF8B7C6CD8E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 15 Apr 2017 13:32:25 -0400 In-Reply-To: Cc: Simon Hobson , "v6ops@ietf.org Operations" To: Warren Kumari References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 17:32:30 -0000 --Apple-Mail=_4478545C-B757-41BD-A360-EDF8B7C6CD8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 15, 2017, at 1:18 PM, Warren Kumari wrote: > Ok, so dumb user question here -- how on earth do I know what I can = request? Do I just ask for a /48, and if that doesn't work, ask for a = /64, and if that does, try for a /56, and if that doesn't work try for a = /60? You request what you want, the ISP gives you what they are willing to = give. If you send a zero for the prefix length, the ISP will give you = whatever their default is. --Apple-Mail=_4478545C-B757-41BD-A360-EDF8B7C6CD8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 15, 2017, at 1:18 PM, Warren Kumari <warren@kumari.net> = wrote:
Ok, so dumb user question here = -- how on earth do I know what I can request? Do I just ask for a /48, = and if that doesn't work, ask for a /64, and if that does, try for a = /56, and if that doesn't work try for a /60?

You = request what you want, the ISP gives you what they are willing to give. =   If you send a zero for the prefix length, the ISP will give you = whatever their default is.

= --Apple-Mail=_4478545C-B757-41BD-A360-EDF8B7C6CD8E-- From nobody Sat Apr 15 12:33: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 8D31512946E for ; Sat, 15 Apr 2017 12:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 u4Tu-pokQnGB for ; Sat, 15 Apr 2017 12:33:05 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d: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 D43CA126CE8 for ; Sat, 15 Apr 2017 12:33:04 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p68so84671855qke.1 for ; Sat, 15 Apr 2017 12:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lxsfygj2Ya6WPrOOy7k1QqbLJhBDiMKVWWrT3U6+QjU=; b=JRGJgUtjvUmcyKQ5wKxOC0fPsVGZF66c89XylH36LlA69FpDCm8309Yp9hPrS4t4Fc vUudnMVFlV2orEQuBux97+/xl+2zHhlFksElxWrOtBcvID2WXmTdSmW+rVNknPxx2MXR BUCEWLk6ToWn08JY1eUHQvrRtu9UfwM7gxLuvxnQh1lo4V+G1hjE6VbeGZn+0IlE0/Y/ t+ByWkJAC5YxpOBSyIeYYU90e94TuOlde5u72rYLa4drDSFwnqiSspwEfe/jf7ECphlF umFrrot0XlRIErxSPVaI8uPWexiX39RfiDf7Fyv8E+uKIyCDbhO46wK2WZaKLhSzryfe aWhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lxsfygj2Ya6WPrOOy7k1QqbLJhBDiMKVWWrT3U6+QjU=; b=frjbD2GLdwhmOia0oeei/Z02Dcykw0XJEg4H+8I9DplIDlzK4BrRTgqzl62XNEWPk5 U+yFOe5Ti64Csu5L+UaumErmAOan4+WeW25lIKP65wCToCBJJRzjZMdnhm9hOf2IkjCg jKsidIkfLj9AB681D/F/uI8z/djg5EI4nil8QzKOsM8P9xNFgwrJyC3KAlEUJg//4SZN co1s2+33ChThI7BxfwqbFJj9wZlCcnWMs0N1z/AQJA7rG/OFq1VZfFbi/atxU/RiubA5 iMHmEyZDZV4Ahc5hU9qkJvIqUoqhRAJpJQKc+kyOy6Jvf6wLKFl4bEVSjWxCWZeXkm/4 wuKA== X-Gm-Message-State: AN3rC/6aaMTknhddKxdQ238yzEy7O6WutGbnQ1EnCA0264qyNpMLe4GG Zo3yF9YQA68Q2i+5Xji3AOnNhDaq998jNxc= X-Received: by 10.55.203.67 with SMTP id d64mr3253438qkj.72.1492284783984; Sat, 15 Apr 2017 12:33:03 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> In-Reply-To: From: Warren Kumari Date: Sat, 15 Apr 2017 19:32:52 +0000 Message-ID: To: Ted Lemon Cc: Simon Hobson , "v6ops@ietf.org Operations" Content-Type: multipart/alternative; boundary=001a11409cc27419dd054d39a0bf Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 19:33:06 -0000 --001a11409cc27419dd054d39a0bf Content-Type: text/plain; charset=UTF-8 Oh. Cool. Well that seems obvious (now!) W On Sat, Apr 15, 2017 at 1:32 PM Ted Lemon wrote: > On Apr 15, 2017, at 1:18 PM, Warren Kumari wrote: > > Ok, so dumb user question here -- how on earth do I know what I can > request? Do I just ask for a /48, and if that doesn't work, ask for a /64, > and if that does, try for a /56, and if that doesn't work try for a /60? > > > You request what you want, the ISP gives you what they are willing to > give. If you send a zero for the prefix length, the ISP will give you > whatever their default is. > > --001a11409cc27419dd054d39a0bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oh. Cool. Well that seems obvious (now!)

W
On Sat, Apr 15, 2017 at 1:32 PM Ted Lemon <mellon@fugue.com> wrote:
On Apr 15, 20= 17, at 1:18 PM, Warren Kumari <warren@kumari.net> wrote:
Ok, so dumb user question here = -- how on earth do I know what I can request? Do I just ask for a /48, and = if that doesn't work, ask for a /64, and if that does, try for a /56, a= nd if that doesn't work try for a /60?
You request what you want,= the ISP gives you what they are willing to give. =C2=A0 If you send a zero= for the prefix length, the ISP will give you whatever their default is.

--001a11409cc27419dd054d39a0bf-- From nobody Sat Apr 15 13:22: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 D96B1127444 for ; Sat, 15 Apr 2017 13:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FDHS4qcdRXT1 for ; Sat, 15 Apr 2017 13:22:16 -0700 (PDT) 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 6D56D126DDF for ; Sat, 15 Apr 2017 13:22:16 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id 34so18144094pgx.3 for ; Sat, 15 Apr 2017 13:22:16 -0700 (PDT) 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=qIf9D/6Hl8RJ5Fl/CnuxqOBwFwlP5r/3B5E57w4rzgw=; b=dP/rcTaGCqFlVAh2cwTe6n9qiK92NOIFcPkdbCWikaxptz10MO/+Yi+WwZ/0rZ85u5 YNO1zkJGaXCS5i1xG3EhtZRHLHgmdCgkNsPkUw0Fn7sV6VLhXdTqrnLrtdk48hTu+7V8 DKD+hRspfBkZtXQ6v3pRR76ovUftsQtBzPf085amjJeVrNSsZRJz3LEBmMryL7cWMbLS r9yukLX3X0MRFLbNFBrufZcsTauDYSCqcI6WO4xjuTnZPcTQJIV1ic5mLB/IDj08j996 kmNysdgPsfEQOgHHvYo/Ijft1D5aJXmda4Uhu+YxQDp5BivUpVL/lX9+iebYpxd+jHqQ BYyw== 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=qIf9D/6Hl8RJ5Fl/CnuxqOBwFwlP5r/3B5E57w4rzgw=; b=CVNoH/5QUz+qMhmERzk/ilbQLBRZ1yMQp0sc7GD1/GQzgw0a7/OfKXpK6m5fR+ORKp AlaEP9/nPixh9PxzalidK5e2u2qbMlpIeslyzPESSydWaTRFKhvk0YagEWn91OLrapE7 fNmmioTkiC93hwdt/tMizVX3cZTL254H2scCmQP/M/zpXrnR2nq7bIYCO4PYOfRCTdYT XwT2YXZnC2Xx9HA32yfCDmerEbh7usz+d99yO2OUdRzm1k/HOjAV0M/OxVBTfAZxZZhy 54Wi44bQNLy4ULa35TWpDZ0qaMcMGhdUD7DxoqdmG/yXrODvAMUw8PgizQHzmxOFF2RB 53ew== X-Gm-Message-State: AN3rC/7AB+4cX+I8aRXXmU2OEME+opWwFowUrDkWJSopY5iPJe9H0Pgc Dx6CaDfN/WGlrzU+ X-Received: by 10.98.64.69 with SMTP id n66mr4146884pfa.211.1492287735857; Sat, 15 Apr 2017 13:22:15 -0700 (PDT) Received: from [192.168.178.26] ([118.148.126.238]) by smtp.gmail.com with ESMTPSA id u8sm9879837pfk.103.2017.04.15.13.22.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 13:22:15 -0700 (PDT) To: Ted Lemon , Warren Kumari References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> Cc: Simon Hobson , "v6ops@ietf.org Operations" From: Brian E Carpenter Organization: University of Auckland Message-ID: <68a96c66-fa90-723d-644c-3bd8e38f1122@gmail.com> Date: Sun, 16 Apr 2017 08:22:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 20:22:18 -0000 Ted, On 16/04/2017 05:32, Ted Lemon wrote: > On Apr 15, 2017, at 1:18 PM, Warren Kumari wrote: >> Ok, so dumb user question here -- how on earth do I know what I can request? Do I just ask for a /48, and if that doesn't work, ask for a /64, and if that does, try for a /56, and if that doesn't work try for a /60? > > You request what you want, the ISP gives you what they are willing to give. If you send a zero for the prefix length, the ISP will give you whatever their default is. I assume you are referring to a specific protocol there. Which one? PD? RADIUS? Both? There's nothing to say this is the only mechanism. (OK, I have skin in the game: draft-ietf-anima-prefix-management. Domestic CE is not its intended market, however.) But in any case, it's clear to me that the only future-proof rule is that the CE MUST support any prefix length that the ISP chooses to offer. That won't get us away from only supporting /64 subnets, but that's elsewhere in the spec. Brian From nobody Sat Apr 15 13:23: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 4E82A127444 for ; Sat, 15 Apr 2017 13:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C_UdOR4Ph9Cs for ; Sat, 15 Apr 2017 13:23:09 -0700 (PDT) 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 9A2DD126DDF for ; Sat, 15 Apr 2017 13:23:09 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id g60so15447826qtd.3 for ; Sat, 15 Apr 2017 13:23:09 -0700 (PDT) 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=wF6/czKCoRYYznRIA+UM+2Rn4wqhl0J6DGTlR4sPp3M=; b=wSDxacmQmR/XoDOkdopPlmYXePfDYNOf3zlCUVKJEqxUZDL/xY3HIP8l6/l73AJpBF +9p3quX9MMWrCme6Z7Ft+V5RNNU9GwqiH2GEa2ugCoAd9kc9GeNveOgHzpdvBEz4a6yk 8WxvXiKg1SSKIzd38dVZ87yUJsR8Z/5zIm/V3sWq+UiJ3i0jq5qquOnKKiadiUhF+gpD nXHn+rTGy3sRpMdoOlrkCo8p4RS25RCxn9FnPcvmN77tX6/Dog9kWpp1/VI1dQvJ0IQM 7Pd5Pm/FetzmgM6Pz6gKF/ubvdZg9GyHflYL+Pr2cNRmltnS1KUwlWWq4U/RNhSucQdb ltwQ== 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=wF6/czKCoRYYznRIA+UM+2Rn4wqhl0J6DGTlR4sPp3M=; b=CkWt6h8ZOYKTE+weXIHl89Aj8ZNgmH6ELbLwI69ioWa/LujbDFL9msZ0FmO9MeYtSS oezM9dyj006vEaaDDZsc0KZBSd0jV8mra2ByyY2uiPNlslGi6e8SvaB0ryIzSoI0jBhM 2+OxYl1pI3DNXgX7q6S4WOwIYmffBocrxt0irpfxDK/iEpCJnpIhq8dUwGJoyN8OhMpe Dfj3NqwyQGw95IUkfPzV7HeQv2mdNPCDZw2UiSr4/DWR7O19J5Hi6QjTWUuCIWKxKF7a 6URLUo4ed5f8WPc2mezAickq44l/yJpPV0w/To7/COxV2aONTFxULkByGWZRp5bwf/zH CBtw== X-Gm-Message-State: AN3rC/5g5kI1ZiCCXIkDhzPIwfLbMAWAcwdIt5RJ+t1UvolGNOnJxTLF mQe7GCfk/390Lg== X-Received: by 10.200.48.14 with SMTP id f14mr3209253qte.201.1492287788640; Sat, 15 Apr 2017 13:23:08 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i64sm27377qkd.5.2017.04.15.13.23.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 13:23:07 -0700 (PDT) From: Ted Lemon Message-Id: <25AE75BC-50AF-4EAB-A792-8D3B99FAFB5E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BAF8AEA9-DB2F-4775-87B8-A9F8279C01C9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 15 Apr 2017 16:23:06 -0400 In-Reply-To: <68a96c66-fa90-723d-644c-3bd8e38f1122@gmail.com> Cc: Warren Kumari , Simon Hobson , "v6ops@ietf.org Operations" To: Brian E Carpenter References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <68a96c66-fa90-723d-644c-3bd8e38f1122@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 20:23:11 -0000 --Apple-Mail=_BAF8AEA9-DB2F-4775-87B8-A9F8279C01C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 15, 2017, at 4:22 PM, Brian E Carpenter = wrote: > I assume you are referring to a specific protocol there. Which one? = PD? RADIUS? Both? Prefix delegation. --Apple-Mail=_BAF8AEA9-DB2F-4775-87B8-A9F8279C01C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 15, 2017, at 4:22 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
I assume you are referring to a specific = protocol there. Which one? PD? RADIUS? Both?

Prefix = delegation.

= --Apple-Mail=_BAF8AEA9-DB2F-4775-87B8-A9F8279C01C9-- From nobody Sat Apr 15 13:36: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 59488128D69 for ; Sat, 15 Apr 2017 13:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mX69O5G4JmnD for ; Sat, 15 Apr 2017 13:36:14 -0700 (PDT) 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 85514127444 for ; Sat, 15 Apr 2017 13:36:14 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id x125so56073047pgb.0 for ; Sat, 15 Apr 2017 13:36:14 -0700 (PDT) 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=H/Hekx51EoDtYhReEpUKL/uyo+5o6fxyg5tSMcXrWPY=; b=UJUnPHYbxyRivCxu0hTbYOwhIt1MIwtamRCObYRMMpSppuDtImbe+3IfH+R7IKPvZP o2yIDrhitoK3/d2A1C4l3mFO/ntBSKx8dgiGP7xnJ2vGjJrM0wj1UolyyZS7UhC0T5A1 sWmAjWlcklsTKvFk3CwTlaS9ozHaNHWBOYkJqiAFh5ePoxSCy8NcPNRSZORvda/zAczv 3XEj9eNA5+T0LxwFZVmN/lIU82tod9FjV9DYMeqSqJUX9lLT+Vx48FAyNYHQid2TiQSC XF/+5hhDX0cg5MJQr5i0zHI1baekOiAT8Pw9JC/feaKFiTwLul8m/Oo2WNGJ8iBgXsr+ A0RQ== 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=H/Hekx51EoDtYhReEpUKL/uyo+5o6fxyg5tSMcXrWPY=; b=C9mgudEwusIgdHC5TbpVXY13JGbm9P79eKocFXjIobNQZSNSzWdoGDNrB32Z42axBm L2tDI5IHV3Eyy74pFwKQRtS6vn1QtuxO2NOfnyWMOUzl5z7xqlLgwi9OBsB80skWVyvB JNdguAYl0prh1Q7H1CgOOV65ZfIU1zaWfWKywwMjJZaOyiJul+55T/Zdgl2Zw9aSmnCF CaFrDqMGKEx0rD79rnrkx8NDgvdsdAtNmvcRNLls52hpNvWGt/eqcwkVxgeC681sbF8j lvwlHQj+dwRLJimi7Xx3j0DJxra/oAO5OnzKk7cjZcxeG8UfAcgQ4A7W2cWrAiLBUSIs ik4A== X-Gm-Message-State: AN3rC/5GWW5PUi1yLS9vK8ZWim6ZMfuqjM0lyBtjXFNSQ38XAWwOVAU1 ERACdnvUIC/ToQ== X-Received: by 10.99.6.14 with SMTP id 14mr4069069pgg.83.1492288574108; Sat, 15 Apr 2017 13:36:14 -0700 (PDT) Received: from [192.168.178.26] ([118.148.126.238]) by smtp.gmail.com with ESMTPSA id t187sm9880518pfb.116.2017.04.15.13.36.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 13:36:13 -0700 (PDT) To: Simon Hobson , "v6ops@ietf.org Operations" References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> Date: Sun, 16 Apr 2017 08:36:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 20:36:16 -0000 On 15/04/2017 21:46, Simon Hobson wrote: > Mark Smith wrote: > >> In a residential environment, nobody should ever even see or have to >> deal with an IPv6 address. No typing them in, reading them out, >> cutting-and-pasting them into devices, or ... > > Checks out of window, no there's no porcine aerial display team practicing above our house :-) > > >> So the most robust choices are: >> >> - nominate a defined set of prefix lengths, and prohibit ISPs from >> providing and CPEs from supporting anything else >> >> - require support for any prefix lengths and don't nominate any specific ones >> >> Asking for both will be worse than choosing one or the other. > > Surely the most robust option is to say that CPE routers MUST handle any prefix length, +1 > and ISPs SHOULD only issue from a fixed set of lengths - would that latter requirement be better specified in a BCP? While I'm not a developer, I;d have thought that unless you only support 48 and 64 bit prefix lengths, then supporting any prefix length is no harder than supporting a fixed set that doesn't align on full 16 bit boundaries. The only real argument for a defined set of lengths, as mentioned in RFC6177, is to choose nibble boundaries: "- the operational considerations of managing and delegating the reverse DNS tree under ip6.arpa on nibble versus non-nibble boundaries should be given adequate consideration." So yes, IMHO there's a case for saying that for SOHO customers, an ISP MAY delegate one of {/48,/52,/56,/60} and SHOULD NOT delegate /64} Brian > I still have memories of finding that a CPE router from a major brand refused to accept a.b.c.0 as a valid IPv4 address, presumably because they were stuck in "no-one has more than a /24" mentality. I think you are right to assume that if the standards don't say "MUST" for the right things, CPE vendors will do stupid things. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Sun Apr 16 00:12: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 73E3E1293EE for ; Sun, 16 Apr 2017 00:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Zcmed7a_Vv2J for ; Sun, 16 Apr 2017 00:12:26 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BA0127978 for ; Sun, 16 Apr 2017 00:12:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id B19001BC37 for ; Sun, 16 Apr 2017 07:12:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Sun, 16 Apr 2017 08:12:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <13B0620D-032D-477E-84E1-4EF656EB0A52@thehobsons.co.uk> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 07:12:28 -0000 Ted Lemon wrote: > On Apr 15, 2017, at 1:18 PM, Warren Kumari wrote: >> Ok, so dumb user question here -- how on earth do I know what I can = request? Do I just ask for a /48, and if that doesn't work, ask for a = /64, and if that does, try for a /56, and if that doesn't work try for a = /60? >=20 > You request what you want, the ISP gives you what they are willing to = give. If you send a zero for the prefix length, the ISP will give you = whatever their default is. Or in the real world (with some ISPs), you ask for what you want, they = reply back "sorry, don't do that" when the sales person (who wouldn't = know their IPv6 from their SMTP) finds there isn't a matching tick box = on their screen. So you have to go back and forth a few times until you = guess the right number. Yes, I'm a bit cynical having dealt (on behalf of clients) with a number = of ISPs through work and the varying "quality" of their support = arrangements - many ISPs appear to be managed by marketing people with = little idea of what they are managing. So far I haven't come across one = making you upgrade to a business connection (at a higher price) in order = to get IPv6 ! From nobody Sun Apr 16 17:39: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 EFB9012941C for ; Sun, 16 Apr 2017 17:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 HDGV6whYOtmq for ; Sun, 16 Apr 2017 17:39:48 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 B5855129415 for ; Sun, 16 Apr 2017 17:39:48 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id q78so24479827vke.3 for ; Sun, 16 Apr 2017 17:39:48 -0700 (PDT) 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=yPYA6UIKMMmuQiCCkTkEHkjXfYDvDqgcOcrHhkpd0QM=; b=vwlYZFCGCXTmlGtBBGBa0GkPGvJN4rmVKoUqNm4oC5eBDsj+w2+Q1cWbUBycdQ5apw t8FcyPqM9BU+w/ujL5Rqim5jsm2Yysbc8wkH8l7/qvlAKilVu0IA2EaNfSY62vs2EzHR ui5n4kTLkopDeZbcSF5Ca1AIES+VcPlzjbIHLU4TwyjJZUPFQATzbH5h86rsbxDfbT4N jUDDUzzSwkK75Hvt9MsC7kTVWaJeWG8omZR0Stsx/ProSOM7OMqZc4uQjgeGbZcbsL71 E473aQkWYZ9wmViboj+lCWFl5g1lpynsqK2cP3fkKUmDV+S8b9RHuwCsifNgHpThnGg2 ySVg== 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=yPYA6UIKMMmuQiCCkTkEHkjXfYDvDqgcOcrHhkpd0QM=; b=sW1Bircpy8eIIbkRxvlQgL90rkJjpSBuh9AZKOQXjwa723Cyy4TrBHzj49ct+miSem X6mIU2IIO4xhmfiiYlJ4ku0iUp/fNbHTxYutysLq07FQYKptnqSsfQ5pgja2Kpv0T6O9 DzSdAYO99Ln9RfODvAaMk84RFx/JiRld70Rx41hHEq/pvb8+RYfEtl9KRpMQtAr0hHyG NgaBuntrwBAPb+x3uIdZjyRtHtu7A2SGO4DORyaSDQw5D+ffWbN1P4D2GtoFB3clas9S XsdRPbpRdkU8ht8dWi//MwTDoaGOpCyUg3ssbkvaObcHLiYeCgw15laHHsoyol0nL2K2 Uw5g== X-Gm-Message-State: AN3rC/5k8i5cGqAVWytshNj8kCcLQWJ3xAca6qjDzZ7RNxKoq2Kaa2P9 efC3D7V9qINoxjGANCWDeplCFR9wwZMk X-Received: by 10.31.11.73 with SMTP id 70mr7287554vkl.83.1492389587618; Sun, 16 Apr 2017 17:39:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Sun, 16 Apr 2017 17:39:26 -0700 (PDT) In-Reply-To: <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> From: Lorenzo Colitti Date: Mon, 17 Apr 2017 09:39:26 +0900 Message-ID: To: Brian E Carpenter Cc: Simon Hobson , "v6ops@ietf.org Operations" Content-Type: multipart/alternative; boundary=001a11437e883d0944054d520792 Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 00:39:50 -0000 --001a11437e883d0944054d520792 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > and ISPs SHOULD only issue from a fixed set of lengths Assigning prefixes on nibble boundaries consumes between 2 and 8 times the address space. I don't think it's a good idea to go out of our way to say that ISPs should only provide certain lengths just because they're easier for users to understand. We can certainly say that if an ISP wants to delegate reverse DNS then the only way to do that is to align on a nibble boundary. But if most ISPs don't do that anyway, there's no point saying they need to change prefix lengths to do it. --001a11437e883d0944054d520792 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Apr 16, 2017 at 5:36 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
> an= d ISPs SHOULD only issue from a fixed set of lengths

<= /div>
Assigning prefixes on nibble boundaries consumes between 2 and 8 = times the address space. I don't think it's a good idea to go out o= f our way to say that ISPs should only provide certain lengths just because= they're easier for users to understand.

We ca= n certainly say that if an ISP wants to delegate reverse DNS then the only = way to do that is to align on a nibble boundary. But if most ISPs don't= do that anyway, there's no point saying they need to change prefix len= gths to do it.
--001a11437e883d0944054d520792-- From nobody Mon Apr 17 08:36: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 31D3413147D for ; Mon, 17 Apr 2017 08:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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=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 n03N2Vl-WVCq for ; Mon, 17 Apr 2017 08:36:05 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 EB99F13147C for ; Mon, 17 Apr 2017 08:36:04 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id i5so67320264pfc.2 for ; Mon, 17 Apr 2017 08:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=mY4W4tY4SIPVTadtg34tIaj9yyelGwXN4X/tt8ltdu4=; b=u2vduQe76v5iH19/LEDxcwrizijCbQCPufYH8XM5ih3ce6MKdL8ByVcP/34aB9EkYK Pt0VXs/nokULf/PGPA68VuE2sWUnI9Z0dwv2helUSQ3trKBqoC8JasfdHEAKUHD/MRJa vn9pg7zuCtVf6p2aNzyHCEct4Y092uMC8vQJ1BoyF65DdEUah+Ktp1gVczXo4F/wzU75 7B2Cr6y8Zgie5owpVXS3jLNw93zph7PhLNbws9YiOhfzaVW7MnY1cHBGZ+4GTofKAjiU rw6e+/H8tEMJagvo6nrm6UCriYH0Qzy8yFmmUmHtY9mPG3I0nm1V1QoudXLkRjmiZ5sk Ej4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=mY4W4tY4SIPVTadtg34tIaj9yyelGwXN4X/tt8ltdu4=; b=kYAYiZkPIiO74AARqBUJQ5ObKV3vIv8mrYdxtisal3X3QX/U44wvjWu2yLiYfCygXo wimvk/VkofCC0DyhdVlarTllL0dRmCV0IlOkejAc0eh7hsBGS8cPQiuDbUlvOQIjflDM /Nmh20RhKtUhXsWH/Txje4Bq7VShjdrbxUdsClHB7CqURYwGctqZg4KE0N+eax8mlhtF XwPIy172ziE8G7L67s2WD9NulghDk4IeDmtjFqLr+9IbXkN8iDm5cNWsJCEI3YmJHOnO 6Rvg+IS30souOBf/tPqUlqmaO2KJmCEl4FtXIoF1zv6Z1v3UEmcpFJHjMWl1Q8Cwhgrt qtfw== X-Gm-Message-State: AN3rC/71bT1IvUe2EBpavIw5u86AJ3XMLI5HGYYR3i+ymduLfbiIWnDL P5PxnuxfMc+T/nx/ZD+z5g== X-Received: by 10.84.236.10 with SMTP id q10mr16967879plk.1.1492443364276; Mon, 17 Apr 2017 08:36:04 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:e5af:4e50:762b:fda5? ([2620:0:10e7:10:e5af:4e50:762b:fda5]) by smtp.gmail.com with ESMTPSA id d187sm18678252pfd.47.2017.04.17.08.36.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 08:36:03 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_BD2D89B3-27FD-4C9D-9462-D68868E2C468" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Apr 2017 08:36:09 -0700 References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> To: "v6ops@ietf.org Operations" In-Reply-To: Message-Id: <7FB131CD-C5D9-4823-8627-109E05C4DA71@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 15:36:06 -0000 --Apple-Mail=_BD2D89B3-27FD-4C9D-9462-D68868E2C468 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 15, 2017, at 10:32, Ted Lemon wrote: >=20 > You request what you want, the ISP gives you what they are willing to = give. If you send a zero for the prefix length, the ISP will give you = whatever their default is. Except, nope=E2=80=A6 if you request zero, some ISPs give you no prefix = (despite that being wrong). So you request /48, and you get what they = send. And the day ISPs start charging you more for requesting a /48 and = getting a /56 vs. requesting a /60 and getting a /60 is the day a whole = bunch of CPE routers have to be updated. Because of course this is how the architecture is supposed to work. Why = do you ask? --james woodyatt > --Apple-Mail=_BD2D89B3-27FD-4C9D-9462-D68868E2C468 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 15, 2017, at 10:32, Ted Lemon <mellon@fugue.com> = wrote:

You request = what you want, the ISP gives you what they are willing to give.   = If you send a zero for the prefix length, the ISP will give you whatever = their default is.

Except, nope=E2=80=A6 if you request zero, some = ISPs give you no prefix (despite that being wrong). So you request /48, = and you get what they send. And the day ISPs start charging you more for = requesting a /48 and getting a /56 vs. requesting a /60 and getting a = /60 is the day a whole bunch of CPE routers have to be = updated.

Because of course this is = how the architecture is supposed to work. Why do you ask?


--james woodyatt <jhw@google.com>



= --Apple-Mail=_BD2D89B3-27FD-4C9D-9462-D68868E2C468-- From nobody Mon Apr 17 10:10: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 DFC711316B7 for ; Mon, 17 Apr 2017 10:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Jp1rJlc0qLdq for ; Mon, 17 Apr 2017 10:10:46 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1503F1316A8 for ; Mon, 17 Apr 2017 10:10:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 5D11F1A071 for ; Mon, 17 Apr 2017 17:11:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Mon, 17 Apr 2017 18:10:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <34D7D175-1F94-4361-8009-5737334C5DE7@thehobsons.co.uk> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:10:48 -0000 Lorenzo Colitti wrote: > Assigning prefixes on nibble boundaries consumes between 2 and 8 times = the address space. I don't think it's a good idea to go out of our way = to say that ISPs should only provide certain lengths just because = they're easier for users to understand. Except that AIUI no ISP gets any allocation smaller than a /32, and if = they were to give out a /56 to every customer, then they could support = up to 16 million customers. In the UK, AIUI there are only something = like 30 million homes, and there are "quite a few" ISPs. Make that a /60 (still on a nibble boundary, gives the user up to 16 = networks to play with) then that goes up to supporting 256 million = customers - so several times more than the total number of connections = in the UK even if there were only one ISP. > We can certainly say that if an ISP wants to delegate reverse DNS then = the only way to do that is to align on a nibble boundary. But if most = ISPs don't do that anyway, there's no point saying they need to change = prefix lengths to do it. Realistically, every ISP needs to support delegation of the IPv6 reverse = address space IF the customer wants it. No way do I want the hassle of = maintaining an ISPs delegation via some form of portal designed by = someone who demonstrates that they've never managed any network services = (that's what some portals shout out). Even worse, I don't want to have to do the "email some service team and = they'll update it 'sometime'" From nobody Mon Apr 17 11:52: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 83C7D131784 for ; Mon, 17 Apr 2017 11:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 ywe6g0NR9NLG for ; Mon, 17 Apr 2017 11:52:43 -0700 (PDT) Received: from poseidon.nytt.no (poseidon.nytt.no [195.159.132.73]) (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 76F91131776 for ; Mon, 17 Apr 2017 11:52:42 -0700 (PDT) Received: from dhcp-94.olen.net (dhcp-91.olen.net [195.159.132.91] (may be forged)) (authenticated bits=0) by poseidon.nytt.no (8.15.2/8.15.2) with ESMTPSA id v3HIqZoa026466 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 17 Apr 2017 20:52:36 +0200 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> From: Ola Thoresen Message-ID: <9d0371eb-2cc1-0f10-b1b4-83de5c305305@nlogic.no> Date: Mon, 17 Apr 2017 20:52:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3E8C68365174454698AA41DA" Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 18:52:46 -0000 This is a multi-part message in MIME format. --------------3E8C68365174454698AA41DA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 17. april 2017 02:39, Lorenzo Colitti wrote: > On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter > > wrote: > > > and ISPs SHOULD only issue from a fixed set of lengths > > > Assigning prefixes on nibble boundaries consumes between 2 and 8 times > the address space. I don't think it's a good idea to go out of our way > to say that ISPs should only provide certain lengths just because > they're easier for users to understand. > Except that "easier for users to understand" IS an important thing. The routers and hosts can handle whatever we throw at them. But when I need to debug a network problem, the ability to easily read and understand all firewall-policies and routing entries and instantly recognize that a certain address belongs to a certain prefix which is assigned to a specific interface with a set of policies added to it, is of huge importance. Not keeping it within a nibble makes that job a LOT harder. And more error prone, which leads to all sorts of issues, both for the user in question, and also possibly for other users. I can't see any reason for an ISP to assign anything less than a /60, even to grandma and her cat. Worrying about wasting addresses, so you only give her one or two /64s is just silly, as Simon pointed out already. And if 16 subnets are not enough, even 256 or 4096 is not going to be a real world problem for the next 1000 generations. At least in the RIPE-region, any ISP will get a /29 without much of a problem. So making the network harder for the end users to maintain just to save some prefixes is pretty stupid. The only reason some ISPs do this is because they are still stuck in their IPv4 mindset where each address is an asset. And I think we should try to help the ISPs get out of that mindset. Making it clear that they should only assign prefixes on the nibble boundaries, and never EVER assign a single /64 is a way to force them to rethink their policies. /Ola (T) --------------3E8C68365174454698AA41DA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 17. april 2017 02:39, Lorenzo Colitti wrote:

On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> and ISPs SHOULD only issue from a fixed set of lengths

Assigning prefixes on nibble boundaries consumes between 2 and 8 times the address space. I don't think it's a good idea to go out of our way to say that ISPs should only provide certain lengths just because they're easier for users to understand.


Except that "easier for users to understand" IS an important thing.  The routers and hosts can handle whatever we throw at them.  But when I need to debug a network problem, the ability to easily read and understand all firewall-policies and routing entries and instantly recognize that a certain address belongs to a certain prefix which is assigned to a specific interface with a set of policies added to it, is of huge importance.

Not keeping it within a nibble makes that job a LOT harder.  And more error prone, which leads to all sorts of issues, both for the user in question, and also possibly for other users.

I can't see any reason for an ISP to assign anything less than a /60, even to grandma and her cat.  Worrying about wasting addresses, so you only give her one or two /64s is just silly, as Simon pointed out already.
And if 16 subnets are not enough, even 256 or 4096 is not going to be a real world problem for the next 1000 generations.  At least in the RIPE-region, any ISP will get a /29 without much of a problem.

So making the network harder for the end users to maintain just to save some prefixes is pretty stupid.  The only reason some ISPs do this is because they are still stuck in their IPv4 mindset where each address is an asset.  And I think we should try to help the ISPs get out of that mindset.
Making it clear that they should only assign prefixes on the nibble boundaries, and never EVER assign a single /64 is a way to force them to rethink their policies. 

/Ola (T)



--------------3E8C68365174454698AA41DA-- From nobody Mon Apr 17 12:30: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 40CCF131794 for ; Mon, 17 Apr 2017 12:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yUonBZK8G3eO for ; Mon, 17 Apr 2017 12:30:16 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 05FC31317AA for ; Mon, 17 Apr 2017 12:30:15 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id z127so12587513pgb.1 for ; Mon, 17 Apr 2017 12:30:14 -0700 (PDT) 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=pQI5FY9f6xI4SLsRRYbOSaqwyey6UzDnAcEpdxn39o4=; b=lT4/Z6LowYedk0iub5Hg31xsXPRme3UsicpQOAIhRP0Rrkh0tnNUgXZa49KNHxPct5 qplwLZxsK2TW/ZPBi/nrUJL1eZKMnGMd2N8gc6z9iMcaIxGs+VnCFxeIamecUFtRncyW 7eiaxohAfli+O0N5i2j6zsZnlnPdkKqqpOTi/D+bP265VhxEVEpckslWQ++YSYfRqSEd +76qVREkWPUFAvz8CpWFP4FspLAlL+yh+9HNQDexHynKFa0I9csG5q6dKMCHcRlW02I/ i62zlb46cUp5vIdzcoyp5gQ6t6fCY3L8ICKseVxBndcs5WxYlyqlTU9QgJ0PwLF3VRdb 2cpg== 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=pQI5FY9f6xI4SLsRRYbOSaqwyey6UzDnAcEpdxn39o4=; b=Ktj9cEpM6Ob50WC/pecZOEjyi/bevIWwvu3r5ADqkEV79Ok4muNqcMmqlyTxdvgq2H 4ObQbnhcO1Zhxu0qDJOmMnFZ3XJXlWzls0nox8V5IK87CxvzIfQLuozz8Mi4QzAD0pgf niwbYR9OlulVmM30GRQLzMkZdDKulDPKZ0laFeZlY/hxqJv0ueERKl3HucM0TuxNBccJ 1cR6Z3Ix0vsX0rkpLQc6YbEbUEMiko7YcE4lPvvy3pWdmndroAoR8j/jatCVapwkGWMR 4Ud1E6isG15ZiU8jal7xCRFS6OkOgixBOprQyg8gd+UMPyJoFrsI0aQzxnDiExgdr0vA iSxA== X-Gm-Message-State: AN3rC/4AtyYUyC+txbW2kKYXoJdXE3ucrw0uta/USwlEvmUxuO4TIKN8 YRpjeeR4CyJoa+gcI6g= X-Received: by 10.99.151.18 with SMTP id n18mr14184707pge.199.1492457414611; Mon, 17 Apr 2017 12:30:14 -0700 (PDT) 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 l22sm16676844pfi.2.2017.04.17.12.30.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 12:30:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <9d0371eb-2cc1-0f10-b1b4-83de5c305305@nlogic.no> Date: Mon, 17 Apr 2017 12:30:12 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <9d0371eb-2cc1-0f10-b1b4-83de5c305305@nlogic.no> To: Ola Thoresen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 19:30:18 -0000 No hats. I'm not sure I disagree with anything you said. That said, I would far = rather see a statement like this come from a *NOG in a BCOP than from = the IETF. Reason: there is no *architectural* reason that an IPv6 prefix = couldn't be any length one chooses; the reasons for given lengths have = to do with user experience, support, and so on.=20 My two yen. > On Apr 17, 2017, at 11:52 AM, Ola Thoresen wrote: >=20 > On 17. april 2017 02:39, Lorenzo Colitti wrote: >> On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter = wrote: >> > and ISPs SHOULD only issue from a fixed set of lengths >>=20 >> Assigning prefixes on nibble boundaries consumes between 2 and 8 = times the address space. I don't think it's a good idea to go out of our = way to say that ISPs should only provide certain lengths just because = they're easier for users to understand. >>=20 >=20 > Except that "easier for users to understand" IS an important thing. = The routers and hosts can handle whatever we throw at them. But when I = need to debug a network problem, the ability to easily read and = understand all firewall-policies and routing entries and instantly = recognize that a certain address belongs to a certain prefix which is = assigned to a specific interface with a set of policies added to it, is = of huge importance. >=20 > Not keeping it within a nibble makes that job a LOT harder. And more = error prone, which leads to all sorts of issues, both for the user in = question, and also possibly for other users. >=20 > I can't see any reason for an ISP to assign anything less than a /60, = even to grandma and her cat. Worrying about wasting addresses, so you = only give her one or two /64s is just silly, as Simon pointed out = already. > And if 16 subnets are not enough, even 256 or 4096 is not going to be = a real world problem for the next 1000 generations. At least in the = RIPE-region, any ISP will get a /29 without much of a problem. >=20 > So making the network harder for the end users to maintain just to = save some prefixes is pretty stupid. The only reason some ISPs do this = is because they are still stuck in their IPv4 mindset where each address = is an asset. And I think we should try to help the ISPs get out of that = mindset.=20 > Making it clear that they should only assign prefixes on the nibble = boundaries, and never EVER assign a single /64 is a way to force them to = rethink their policies. =20 >=20 > /Ola (T) >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 17 13:50: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 0377212946A for ; Mon, 17 Apr 2017 13:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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 Io-xG1z7eM9p for ; Mon, 17 Apr 2017 13:50:18 -0700 (PDT) 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 A17D2127977 for ; Mon, 17 Apr 2017 13:50:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 4EDE14B; Mon, 17 Apr 2017 22:50:15 +0200 (CEST) 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=1492462210; bh=MVHJvaqKFwTX+vPC7Askk7F0Dw1P 4nOmL+tz8xfGmpM=; b=LtG3W292lHEkZcjYl9GIZfyFyOwV99xgfmFlNoV6rGsc m9SvLj8Q/EP/eOtg5hMMS78u3lX+EIY0NctBaBOIf/5ewGRNu8E/uPUyHYEnGZ4n qk0Gsj0oCsQJOQjnJL9d3UgSm56enh1DBMNpwtSiyY8X+0PzRRXbcQKJNL5RnZY= 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 FBktEtFdS2ZT; Mon, 17 Apr 2017 22:50:10 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:9300:cd7f:7004:693c:d96e] (unknown [IPv6:2a02:a213:a300:9300:cd7f:7004:693c:d96e]) (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 0095849; Mon, 17 Apr 2017 22:50:09 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_BE50D3AD-DEA6-4A97-91E2-2EBB96572750"; 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: <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> Date: Mon, 17 Apr 2017 22:50:06 +0200 Cc: Ola Thoresen , v6ops@ietf.org Message-Id: <8F2BB1E5-DC2C-4708-8C5F-A11061AB7E9B@steffann.nl> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <9d0371eb-2cc1-0f10-b1b4-83de5c305305@nlogic.no> <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 20:50:20 -0000 --Apple-Mail=_BE50D3AD-DEA6-4A97-91E2-2EBB96572750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fred, > Op 17 apr. 2017, om 21:30 heeft Fred Baker = het volgende geschreven: >=20 > No hats. >=20 > I'm not sure I disagree with anything you said. That said, I would far = rather see a statement like this come from a *NOG in a BCOP than from = the IETF. You mean something like this: = https://www.ripe.net/ripe/mail/archives/bcop/2017-March/000159.html? ;-) > Jan Zorz - Go6 jan at go6.si > Mon Mar 27 15:30:58 CEST 2017 > Dear RIPE BCOP community, >=20 > As promised at last RIPE meeting in Madrid, we produced a first draft = of > "Best Current Operational Practice for operators: IPv6 prefix = assignment > for end-users - static (stable) or dynamic (non-stable) and what size = to > choose." >=20 > [...] Cheers, Sander --Apple-Mail=_BE50D3AD-DEA6-4A97-91E2-2EBB96572750 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----- iQEcBAEBCAAGBQJY9Sp+AAoJEKAtA7D+JBO5xGoH/3IWVDw3pymfagfBZC4WjU5Q BU0O1v5owZYSIktaU5GEt7ZKpOwH/uX3xd6DXgnl8asSv0pEvl94mXl/rzdxjgDz LNwcmUt9GAybJMhXeEjeFqfTsYZ3P8YrVB1UKZMhPFBYr90jhaW7oQfFBBWYvvCV ETSWQ/qGbFdVKzP9tEuJGiMR9AUWigQNCuQWrfyrnOqxwNTtNeY/i1BmPtjAXbdS miHlgW2dvUmyKgpOHnHiJPLX9/+7JRFWdvqAOiWjUU2W7qYj1dYM7uROkqWoEOwv cw3IgBVBCbQZP9turFwkJCyV8WLfq2whSRNE+AwjqIv4EU7r9MjgBqtawVrG9F4= =4djq -----END PGP SIGNATURE----- --Apple-Mail=_BE50D3AD-DEA6-4A97-91E2-2EBB96572750-- From nobody Mon Apr 17 14:25: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 9A406128BA2 for ; Mon, 17 Apr 2017 14:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 IlnHCeCcW-q7 for ; Mon, 17 Apr 2017 14:25:04 -0700 (PDT) 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 D57841242F7 for ; Mon, 17 Apr 2017 14:25:04 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id c198so71000872pfc.1 for ; Mon, 17 Apr 2017 14:25:04 -0700 (PDT) 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=KzSvjy0OEnaWcDGO+SqYuc1nW26rZYgQdRWo0YeCeuo=; b=No80sj3KsHTpFQD8/MjTFSrub9bV79ASwx6k6+VPEH7y0+tfMk46srRDUo1XpC7LHE 06LXg/3KBA1bzQsEeFDj2zy+bsgjIZcV6NaHfRWIBwBU9uKFqv1QCQ9fT8fEpVB3cKDL d0G/wb2mdpWTdmfSwFVsDjrNp/1q0Neu/tWhLlmC/T2Nw4ixkqQpjjji48EULr449SBZ 260SV9TyrUjyUw8TEs+PQncs7yjIWqMh38dY8IxHh7TkQyzTNIuZCWOpFBVYV9cBq2Ar sVVQ0ipz2d1IsIaq++P24u/KJjgAigGMFKwCssUpJwpdat7cbpliOVLOowbDfdxCNghf jg3g== 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=KzSvjy0OEnaWcDGO+SqYuc1nW26rZYgQdRWo0YeCeuo=; b=GwXJLS0nMhmr5EP9xZChqATXiFl3QSRH7Sc7PvvpYqDlSM4v/rf7duDGDM11L2S6Eg O4AZTJXFG+HUZ1tNAI56qnQ8R7SNj2SbGQXn30PhiS0aHxCiL7o4dEClGJuBqfuVcYrq XSy1ILxKvDVNwqeAombH+ZaUS0mwfBajkElEFsUSsyGf7MBGc4qRkn/k9B9OKVE4TiPK 8Y2ROiRm85Z5mFs85a2P5rhu8LtIlHC2eAePQtUlIRMlfiWcWiFTXNe60us28hTbVtcN 8l6cth2+/ajUDyNHA3ASETKP6u1hxA3I/KmfYcCabwJvKL6U/zjF1Kv0Q1VtG8Sb4O8C m4YA== X-Gm-Message-State: AN3rC/4rNGMs5qOxmw37I0RUYHlEic7Gj5qlHKUSgcBNKO+nkwInaszb naBvz5tnT+/qyDkXt2I= X-Received: by 10.84.168.129 with SMTP id f1mr18733060plb.180.1492464304417; Mon, 17 Apr 2017 14:25:04 -0700 (PDT) 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 a77sm19819508pfj.1.2017.04.17.14.25.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 14:25:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <8F2BB1E5-DC2C-4708-8C5F-A11061AB7E9B@steffann.nl> Date: Mon, 17 Apr 2017 14:25:02 -0700 Cc: Ola Thoresen , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9386EA90-9B46-4B4A-B836-3C8C1A223B51@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <9d0371eb-2cc1-0f10-b1b4-83de5c305305@nlogic.no> <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> <8F2BB1E5-DC2C-4708-8C5F-A11061AB7E9B@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:25:07 -0000 > On Apr 17, 2017, at 1:50 PM, Sander Steffann = wrote: >=20 > Hi Fred, >=20 >> Op 17 apr. 2017, om 21:30 heeft Fred Baker = het volgende geschreven: >>=20 >> No hats. >>=20 >> I'm not sure I disagree with anything you said. That said, I would = far rather see a statement like this come from a *NOG in a BCOP than = from the IETF. >=20 > You mean something like this: = https://www.ripe.net/ripe/mail/archives/bcop/2017-March/000159.html? ;-) Something like that, yes. I'll note that this is a random document sent = to an email list, advertised as a "first draft". I'd prefer something = the community had agreed to. That said, "yeah, something like that." >> Jan Zorz - Go6 jan at go6.si >> Mon Mar 27 15:30:58 CEST 2017 >> Dear RIPE BCOP community, >>=20 >> As promised at last RIPE meeting in Madrid, we produced a first draft = of >> "Best Current Operational Practice for operators: IPv6 prefix = assignment >> for end-users - static (stable) or dynamic (non-stable) and what size = to >> choose." >>=20 >> [...] >=20 > Cheers, > Sander >=20 From nobody Mon Apr 17 14:29: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 C18F512EC57 for ; Mon, 17 Apr 2017 14:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq8n61SQIevl for ; Mon, 17 Apr 2017 14:28:56 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2395D129480 for ; Mon, 17 Apr 2017 14:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492464534; x=1493069334; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=FS6Sflyawpykf6xDLiHcsZYVB 3+AJDu1ZFbUEfl/3gE=; b=B906uVqvWSqGL/Uq8TRZetymi77/y6/dRSrtVeJw0 HbpD9uNrxTVjX5VS9oWcpx98SSkEq1xDX3jxcntPScLWGwI2E9ab1JTC5y2fkKM7 oECxwUVH5WbksyTiFtWLh17Hgq1GcDoQCThE+sYp8bHM4lKtwWQNINsAXkoJN7ke bQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=sim8hSPLSuGi4cPW75/K1g8kY3vr7PkfHM80DY8u1hf2oIus2m6DbCOABZar FFi8CPX7aUNvebhdEtXWt7RQOQA/sNH/A9nzCnn4LqxAUdsPqiF8PdIoo 3Gzc2Avz0nBP8/iaUEITdYAMwyZGcmitY1DOpd15lDS6zwD8MF8GZo=; X-MDAV-Processed: mail.consulintel.es, Mon, 17 Apr 2017 23:28:54 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 17 Apr 2017 23:28:52 +0200 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005409990.msg for ; Mon, 17 Apr 2017 23:28:52 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170417:md50005409990::BP68OzVozIu6W3zk:00000mPk X-Return-Path: prvs=1280c0d824=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 17 Apr 2017 23:28:49 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <9d0371eb-2cc1-0f10-b1b4-83de5c305305@nlogic.no> <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> <8F2BB1E5-DC2C-4708-8C5F-A11061AB7E9B@steffann.nl> <9386EA90-9B46-4B4A-B836-3C8C1A223B51@gmail.com> In-Reply-To: <9386EA90-9B46-4B4A-B836-3C8C1A223B51@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:28:59 -0000 Hopefully we will have a new version published ahead the next RIPE meeting, and agreed by then ;-) Regards, Jordi -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: Fecha: lunes, 17 de abril de 2017, 23:25 Para: Sander Steffann CC: Asunto: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] > On Apr 17, 2017, at 1:50 PM, Sander Steffann wrote: > > Hi Fred, > >> Op 17 apr. 2017, om 21:30 heeft Fred Baker het volgende geschreven: >> >> No hats. >> >> I'm not sure I disagree with anything you said. That said, I would far rather see a statement like this come from a *NOG in a BCOP than from the IETF. > > You mean something like this: https://www.ripe.net/ripe/mail/archives/bcop/2017-March/000159.html? ;-) Something like that, yes. I'll note that this is a random document sent to an email list, advertised as a "first draft". I'd prefer something the community had agreed to. That said, "yeah, something like that." >> Jan Zorz - Go6 jan at go6.si >> Mon Mar 27 15:30:58 CEST 2017 >> Dear RIPE BCOP community, >> >> As promised at last RIPE meeting in Madrid, we produced a first draft of >> "Best Current Operational Practice for operators: IPv6 prefix assignment >> for end-users - static (stable) or dynamic (non-stable) and what size to >> choose." >> >> [...] > > Cheers, > Sander > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From nobody Mon Apr 17 17:10: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 56F6F1293F3 for ; Mon, 17 Apr 2017 17:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 M6ZdWlvJPRuC for ; Mon, 17 Apr 2017 17:10:02 -0700 (PDT) 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 26A77124D68 for ; Mon, 17 Apr 2017 17:10:02 -0700 (PDT) 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 4E841349314; Tue, 18 Apr 2017 00:10:00 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2FA41160044; Tue, 18 Apr 2017 00:10:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1A67A160074; Tue, 18 Apr 2017 00:10:00 +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 EnFEnMSIsTj7; Tue, 18 Apr 2017 00:10:00 +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 B66FF160044; Tue, 18 Apr 2017 00:09:59 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BCACF6B86628; Tue, 18 Apr 2017 10:09:56 +1000 (AEST) To: Lorenzo Colitti Cc: Brian E Carpenter , Simon Hobson , "v6ops@ietf.org Operations" From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> In-reply-to: Your message of "Mon, 17 Apr 2017 09:39:26 +0900." Date: Tue, 18 Apr 2017 10:09:56 +1000 Message-Id: <20170418000956.BCACF6B86628@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 00:10:03 -0000 In message , Lorenzo Colitti writes: > > On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > > and ISPs SHOULD only issue from a fixed set of lengths > > > Assigning prefixes on nibble boundaries consumes between 2 and 8 times the > address space. I don't think it's a good idea to go out of our way to say > that ISPs should only provide certain lengths just because they're easier > for users to understand. > > We can certainly say that if an ISP wants to delegate reverse DNS then the > only way to do that is to align on a nibble boundary. But if most ISPs > don't do that anyway, there's no point saying they need to change prefix > lengths to do it. This is despite the fact that it would be possible to automatically delegate the reverse zones quite easily. Or that people do actually setup reverse zones in the home because they want address to name mappings. Human factors are just as important as any other factor when designing how to run networks. ISP's should give everyone a /48. It saves money in the long run and there are enough to go around. It allow the site to hand out /64's as needed internally. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Apr 17 18:45: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 2ED68128D44 for ; Mon, 17 Apr 2017 18:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 hCVGcknfgZDS for ; Mon, 17 Apr 2017 18:45:12 -0700 (PDT) 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 E8D37128616 for ; Mon, 17 Apr 2017 18:45:11 -0700 (PDT) Received: from mbp-4.local ([IPv6:2620:11a:c081:20:ed2e:c65f:3010:423b]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v3I1j88U066540 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 18 Apr 2017 01:45:09 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:ed2e:c65f:3010:423b] claimed to be mbp-4.local To: Fred Baker , Ola Thoresen References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <9d0371eb-2cc1-0f10-b1b4-83de5c305305@nlogic.no> <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> Cc: v6ops@ietf.org From: joel jaeggli Message-ID: <4b993de3-98e4-58fe-a74d-fd920d0074fd@bogus.com> Date: Mon, 17 Apr 2017 18:45:03 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jCPWVpjwEldaSJNS5qHSxbGuFoK8wkm01" Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 01:45:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jCPWVpjwEldaSJNS5qHSxbGuFoK8wkm01 Content-Type: multipart/mixed; boundary="d5l4xSVMo6WhEpdk30JcCEff2B1gbVBaO"; protected-headers="v1" From: joel jaeggli To: Fred Baker , Ola Thoresen Cc: v6ops@ietf.org Message-ID: <4b993de3-98e4-58fe-a74d-fd920d0074fd@bogus.com> Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <9d0371eb-2cc1-0f10-b1b4-83de5c305305@nlogic.no> <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> In-Reply-To: <60ABF9BC-3C31-42F5-BFBD-4E19B86D6911@gmail.com> --d5l4xSVMo6WhEpdk30JcCEff2B1gbVBaO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/17/17 12:30, Fred Baker wrote: > No hats. > > I'm not sure I disagree with anything you said. That said, I would far = rather see a statement like this come from a *NOG in a BCOP than from the= IETF. Reason: there is no *architectural* reason that an IPv6 prefix cou= ldn't be any length one chooses; the reasons for given lengths have to do= with user experience, support, and so on.=20 There are quite a few asics over the years where implmentors have looked at the ietf ipv6 architecture; then produced optimizations that leverage it. The upshot therefore is that naively running roughshod over them can and does produce unexpected results. It's not unreasonable to expect that if expectations change that it'll be a few years before there's a congruence between what you expect and what happens. It's easy enough for example to store any entry for a /128 /127 /126 and all point to point link addresses in the exact match table. not so with /112s or /96s. You may not in general like your hardware capabilties when it comes to storing < /64 prefixes. > My two yen. > >> On Apr 17, 2017, at 11:52 AM, Ola Thoresen wrote: >> >> On 17. april 2017 02:39, Lorenzo Colitti wrote: >>> On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter wrote: >>>> and ISPs SHOULD only issue from a fixed set of lengths >>> Assigning prefixes on nibble boundaries consumes between 2 and 8 time= s the address space. I don't think it's a good idea to go out of our way = to say that ISPs should only provide certain lengths just because they're= easier for users to understand. >>> >> Except that "easier for users to understand" IS an important thing. T= he routers and hosts can handle whatever we throw at them. But when I ne= ed to debug a network problem, the ability to easily read and understand = all firewall-policies and routing entries and instantly recognize that a = certain address belongs to a certain prefix which is assigned to a specif= ic interface with a set of policies added to it, is of huge importance. >> >> Not keeping it within a nibble makes that job a LOT harder. And more = error prone, which leads to all sorts of issues, both for the user in que= stion, and also possibly for other users. >> >> I can't see any reason for an ISP to assign anything less than a /60, = even to grandma and her cat. Worrying about wasting addresses, so you on= ly give her one or two /64s is just silly, as Simon pointed out already. >> And if 16 subnets are not enough, even 256 or 4096 is not going to be = a real world problem for the next 1000 generations. At least in the = RIPE-region, any ISP will get a /29 without much of a problem. >> >> So making the network harder for the end users to maintain just to sav= e some prefixes is pretty stupid. The only reason some ISPs do this is b= ecause they are still stuck in their IPv4 mindset where each address is a= n asset. And I think we should try to help the ISPs get out of that mind= set.=20 >> Making it clear that they should only assign prefixes on the nibble bo= undaries, and never EVER assign a single /64 is a way to force them to re= think their policies. =20 >> >> /Ola (T) >> >> >> >> _______________________________________________ >> 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 > --d5l4xSVMo6WhEpdk30JcCEff2B1gbVBaO-- --jCPWVpjwEldaSJNS5qHSxbGuFoK8wkm01 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 iEYEARECAAYFAlj1b58ACgkQ8AA1q7Z/VrI/9ACfQVUsDIujfPtDJGuasDfalMG4 6xYAnRZ6zaHQe4xESIN1BaeoTd3hyTFO =252R -----END PGP SIGNATURE----- --jCPWVpjwEldaSJNS5qHSxbGuFoK8wkm01-- From nobody Mon Apr 17 19:42: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 EEE5A129426 for ; Mon, 17 Apr 2017 19:42:34 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 Y696mhLLHQFd for ; Mon, 17 Apr 2017 19:42:34 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 C48C8126DDF for ; Mon, 17 Apr 2017 19:42:33 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id q26so83673463uaa.0 for ; Mon, 17 Apr 2017 19:42:33 -0700 (PDT) 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=T6TaGqRWnkRxETb9ac01Ec0zvWMakuky9MNiZ154yt8=; b=CWmYPle/zkLOKQdoIa1kTbALbeX4Qr3iZIQS2wMTFvvttiq2x32XRZTmyYUzurnm3q QZhoRgV4tghRC5U5kr3Svh07ZG0XXSBL6YZAnvhPZag2CAEasETJgX7VFb8d2K+EDoLX ZZi/Wd2/s8ZAT3DjDbsuhuoXNm2Qo6hbkVI6baRfWEq3GAm0Ji4sClKuyigc8UGpoIA1 CQmW+1SJV9x2zZJtnBSty4xFihIB4qRygGApWdv1v9WeaOcqmRUN89f54vviqs5eBzdm +SnxjH7fPFchj9FIGV2ij7zFjRWtyYlDGkDiTTz3UNkz1X1sI/vH2iIHYX88/0MTA6eB la1A== 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=T6TaGqRWnkRxETb9ac01Ec0zvWMakuky9MNiZ154yt8=; b=mWMNie65FACU/svH9eM+a4ypE5RxPIMrsp/zdstYjCxQdFwWBwXmB9wtE2wQZC4GLC vcEisQ2os7OQdvn3OVSw+yD3M14LmjLITytmkq1+/+ca0QkcUUS9Wmiv6jv2jmXpW0DN KurwK49Rbm20QZDBmrzKJIBshczKduNno/5BV2VlrZK197A0xktW/SreRbddqM0Szi3k hR4GtsTgVeVEryZCe2GpD5NK5rJhRiCskr8zXUntJRQrkoyVfTZIah78m9kbbni9Ihlh /L/T4ZMf1ij0yro/9zqXKPqqvFoxs+Pn+n+p7AI6hPDQ8m00vJnyFBPgf9DYvJGQ3R1U A1SQ== X-Gm-Message-State: AN3rC/578Tg3aG7u7h/6QT3KT7VB0/DF2uCJV/KAd8TblvzTlnJjwGa8 4zI7Lay4cNZVY9hqI1QF9V1UubP2uaCQ X-Received: by 10.159.52.198 with SMTP id b6mr9640571uac.155.1492483352673; Mon, 17 Apr 2017 19:42:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Mon, 17 Apr 2017 19:42:11 -0700 (PDT) In-Reply-To: <20170418000956.BCACF6B86628@rock.dv.isc.org> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <20170418000956.BCACF6B86628@rock.dv.isc.org> From: Lorenzo Colitti Date: Tue, 18 Apr 2017 11:42:11 +0900 Message-ID: To: Mark Andrews Cc: Brian E Carpenter , Simon Hobson , "v6ops@ietf.org Operations" Content-Type: multipart/alternative; boundary=f403045e2a5a1224f2054d67dcc3 Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 02:42:35 -0000 --f403045e2a5a1224f2054d67dcc3 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 9:09 AM, Mark Andrews wrote: > > We can certainly say that if an ISP wants to delegate reverse DNS then > the > > only way to do that is to align on a nibble boundary. But if most ISPs > > don't do that anyway, there's no point saying they need to change prefix > > lengths to do it. > > This is despite the fact that it would be possible to automatically > delegate the reverse zones quite easily. And why don't they delegate reverse zones automatically? I'm pretty sure the reason is *not* "we'd be happy to delegate a reverse zone to you, but unfortunately we can't do that because we only gave you a /61 and that's not on a nibble boundary". If that's not the reason, then there's no point writing text to remove that reason. --f403045e2a5a1224f2054d67dcc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 18, 2017 at 9:09 AM, Mark Andrews <marka@isc.org> wrote:=
= > We can certainly say that if an ISP wants to delegate reverse DNS then= the
> only way to do that is to align on a nibble boundary. But if most ISPs=
> don't do that anyway, there's no point saying they need to cha= nge prefix
> lengths to do it.

This is despite the fact that it would be possible to automatic= ally
delegate the reverse zones quite easily.

An= d why don't they delegate reverse zones automatically?

I'm pretty sure the reason is *not* "we'd be happy to= delegate a reverse zone to you, but unfortunately we can't do that bec= ause we only gave you a /61 and that's not on a nibble boundary".<= /div>

If that's not the reason, then there's no = point writing text to remove that reason.
--f403045e2a5a1224f2054d67dcc3-- From nobody Mon Apr 17 23:58: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 C8EB8128D69 for ; Mon, 17 Apr 2017 23:58:44 -0700 (PDT) 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=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 UuwXw8dkCkUJ for ; Mon, 17 Apr 2017 23:58:42 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 58AF0128708 for ; Mon, 17 Apr 2017 23:58:42 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 06:58:40 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 77AE0D788D; Mon, 17 Apr 2017 23:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=/X2jhg/mRGvbx9tPgt/m3Ncf5Zo=; b= IlQgFMt/E4ioeiAYK4SAOJvan5AVCt+YQMCBDGSN2KF6OZuNMXvW13ttkUAt3T+R yrlYbiFzQTb5z/RXUyYReOXKFOYmz1q+4vfSjbEnND9kV90qxQl9W/iKCEIE+BIK 2jkT5bUOyj0SspDE9WXezVeCRUq2AKcDw40ZPyFCOAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=oVWKLutEYcqzNlBTjHcOft6 tY1Dk8byKYx4NRmtzidYarVspXxxL8rGokO+XCCudEgiE+LUNsSa2ZQ0IatSYM0+ 539f0VMRXPf9hdtQEN9ErJ/8mHkcwH3Ej/dCm2DEbDRd1xAaTHoYwptOy4+TcUFe qrrIIgDg0LwbxxSs/wUE= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 4394DD788B; Mon, 17 Apr 2017 23:58:40 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 56063A9F04FF; Tue, 18 Apr 2017 08:58:47 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_06430A61-4469-4757-9C17-D327282469AE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 08:58:46 +0200 In-Reply-To: Cc: Warren Kumari , Simon Hobson , "v6ops@ietf.org Operations" To: Ted Lemon References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 06:58:45 -0000 --Apple-Mail=_06430A61-4469-4757-9C17-D327282469AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Ok, so dumb user question here -- how on earth do I know what I can = request? Do I just ask for a /48, and if that doesn't work, ask for a = /64, and if that does, try for a /56, and if that doesn't work try for a = /60? >=20 > You request what you want, the ISP gives you what they are willing to = give. If you send a zero for the prefix length, the ISP will give you = whatever their default is. "you" being the IPv6 CE router. There is really very little way that CE = can know what to request for. Perhaps it could deduce something from = HNCP, but this deployment model is very unlikely. I think this idea that = CE's are going to request what they need and ISP's are going to adhere = to that request seems very far fetched. This is an out-of-band negotiation often involving money. In RFC3633 = this is purely a hint and the ISP is certainly not expected to adhere to = it, nor is the client expected to set it with very much confidence. Ole --Apple-Mail=_06430A61-4469-4757-9C17-D327282469AE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9bknAAoJEL7aWKiYQt92RK8P/03qfURWZDg6ic7hQUZqtV02 3s/jrhaPoQKGqVFc6kAnK5aAuUIRx1YlhBmUExP9s+ifP1DB6dElTvMd3UEJCb+C ZHiDUT7Abq/Igx2YFmL6zmvraBSnVK/9BzuiOSn1JXVg3sTJntiuFgs/5EuasatL bUj8sjI0tdXTJP+kmlurfSm/4fKn5kx1/RX5no/w+HYEphEs0sf/8GkWw3ze4N1A UeRo/sFomqOHFI9XX4QDZ1uSj6+gXxuu6z45ezTLhzPAjqkCE20dTzomiUW/eHad GwsxXlew3ojjrkUB+LYXQ3fcQUFJJoTu+hK6kc2Lb3a4xfVYziQX6XaXCVO7XFTM mUwk2+G657OoPx5mpiR6xHZruUKhN3B5bKRP39un1AvDadQgpU8AIa3cVLaTCRB8 qzauxNNJLm1/Q5Y8hbBrn5k2UO7sTqvJSF1RSUBrBvvqFmAw3dXpDmttX1mT8gSn AZdYublEw3uFZToAAz1Vbzp6qdoGlZtjaZWNKU2SUD5hxkxYiiWvVEgliI8TJMDQ kKapy+sgp6JcO/E+bWgJA6KN0m1U+i4YuTgCxRYsD40XEGXvBQ5Khr9eIoB4ARxN xj8MuPu9vlxYLyyHaZO9TUR3VVGZC2HDK/0GyaBvxE58CjBDqZiq3XjuSpdc0phS orS1osuKVGjodxF7gjON =r3wb -----END PGP SIGNATURE----- --Apple-Mail=_06430A61-4469-4757-9C17-D327282469AE-- From nobody Tue Apr 18 00:03: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 F406912946F for ; Tue, 18 Apr 2017 00:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-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=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 FGL9Im9_2_PC for ; Tue, 18 Apr 2017 00:03:00 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 36293128708 for ; Tue, 18 Apr 2017 00:03:00 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id j9so65367213ywj.3 for ; Tue, 18 Apr 2017 00:03:00 -0700 (PDT) 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=bEN+6Bd2ZmbHVAFuQ7BaF+wl0ELWgGfBxN4uAqf/qiQ=; b=dZ5MR+vGdH6Scc8dNJ3L5RMIZOoXTjzrma/8DdlQN/HRsuzONMC2zwx8qfwoibVXby FeMd7t5XaBHwhDhS0yUbvdAX2V/WfnUhnTYnONopX0yH4ctvBqeDlfgEdM+oyRV6kRAQ Q0s7Cp+K7ozJ7Nm+iZkhRUVdoU4SUbXfKBZccFEYBiax4Aa60ybOE9JKM9ax/w0bhicm GqwLD91NRf4wwWvhHGHGsGNVXnK2sd77hmHUxD96Z0c2ervaftLWm3yEtUF79GYcvm2Z PnGKrRTsVVb7BbDjoX8b5+qvKnmh8ZfcOABcNu6xxRSxMTOVw9/54PTAuzekY32Mba4e tLdg== 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=bEN+6Bd2ZmbHVAFuQ7BaF+wl0ELWgGfBxN4uAqf/qiQ=; b=J38QSUM2fRjvArOMQVSl3w1NDVLfABMAtePomtVKrq1ZgKyOKgAUmO/veAEYoMI/zu GdB2V2gES92HTqCzwPcqa4e4CI1kt50kj5cKXp5PIsn6Xg1IupoLwDkS+QGhPZPkYIWg dFCOok+rpwybzkR6wp0+s3KI/G4hDQQ/zCZSCrWZWvyH7mA+NkFOMjA8hPs5z4cNumpf 81Io6eCgAdAEcdcmqlayVFyW7HWlcCD3s8gQ8+mxg0P7pnWOZnQOhpNYhqlmPYH3BiEN e1zd/vUEpRFK7K8KjF2uFecHnqzHU5cRz5md1ZKMRhcIY05cMGVp1I57FuUtyVyjMYva zUYA== X-Gm-Message-State: AN3rC/4NxyMt+4mI9UzocsCXHXXthcB71Zoud8eajsv9WN9Y3dsnhuW0 gtJk2Uvv5ji3e/AifW5cgbPSohVcpB53 X-Received: by 10.13.242.198 with SMTP id b189mr17855139ywf.243.1492498979148; Tue, 18 Apr 2017 00:02:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.105.84 with HTTP; Tue, 18 Apr 2017 00:02:38 -0700 (PDT) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> From: Erik Kline Date: Tue, 18 Apr 2017 16:02:38 +0900 Message-ID: To: Ole Troan Cc: Ted Lemon , Simon Hobson , "v6ops@ietf.org Operations" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0356ec820d3f054d6b7fed" Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:03:02 -0000 --94eb2c0356ec820d3f054d6b7fed Content-Type: multipart/alternative; boundary=94eb2c0356ec7b4e78054d6b7f23 --94eb2c0356ec7b4e78054d6b7f23 Content-Type: text/plain; charset=UTF-8 On 18 April 2017 at 15:58, wrote: > >> Ok, so dumb user question here -- how on earth do I know what I can > request? Do I just ask for a /48, and if that doesn't work, ask for a /64, > and if that does, try for a /56, and if that doesn't work try for a /60? > > > > You request what you want, the ISP gives you what they are willing to > give. If you send a zero for the prefix length, the ISP will give you > whatever their default is. > > "you" being the IPv6 CE router. There is really very little way that CE > can know what to request for. Perhaps it could deduce something from HNCP, > but this deployment model is very unlikely. I think this idea that CE's are > going to request what they need and ISP's are going to adhere to that > request seems very far fetched. > > This is an out-of-band negotiation often involving money. In RFC3633 this > is purely a hint and the ISP is certainly not expected to adhere to it, nor > is the client expected to set it with very much confidence. > Certainly my assumption was always that we'd devolved to CPEs requesting a /48 and ISPs doing...whatever they want. --94eb2c0356ec7b4e78054d6b7f23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 18 April 2017 at 15:58, <otroan@employees.org> wr= ote:
>> Ok, so dum= b user question here -- how on earth do I know what I can request? Do I jus= t ask for a /48, and if that doesn't work, ask for a /64, and if that d= oes, try for a /56, and if that doesn't work try for a /60?
>
> You request what you want, the ISP gives you what they are willing to = give.=C2=A0 =C2=A0If you send a zero for the prefix length, the ISP will gi= ve you whatever their default is.

"you" being the IPv6 CE router. There is really very littl= e way that CE can know what to request for. Perhaps it could deduce somethi= ng from HNCP, but this deployment model is very unlikely. I think this idea= that CE's are going to request what they need and ISP's are going = to adhere to that request seems very far fetched.

This is an out-of-band negotiation often involving money. In RFC3633 this i= s purely a hint and the ISP is certainly not expected to adhere to it, nor = is the client expected to set it with very much confidence.

Certainly my assumption was always that we'd devol= ved to CPEs requesting a /48 and ISPs doing...whatever they want.
--94eb2c0356ec7b4e78054d6b7f23-- --94eb2c0356ec820d3f054d6b7fed 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgo24dP8ntNQ8awe3GCgSR89zVTFO4+F9o cp/QriOFilYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE4 MDcwMjU5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAKm3YXrRFbD5JVw2iA9YkAfRRVnmGxd+4tuQZxvKPzt6sLc6W0wW 2uGLqmIqJ2bQEbfnAaQKqSk5loKN/F0u6a9Jgjy4a9PGeYTLQbPyiJX1tP96fFF9ck/ISdj3Yg8c hQMk/XxmpP972mOSrWxiEmVdBSi4VNdCp9fNipOYzS/wykdmkSOhfjUDfGBJkq8XcdSwQHAX8Gl8 2YNBGneq+00LG5rLRF/jHPXLbg7APhMV/b/PIvo+DivhkL2qF6d++h/vVTC6N6SR8JIKhdZc20Ad zNrbrae1ftx0l5ump1jg74ZtpYaVMrTZ+7wbQm74BiYV+Iqvid7a+qDmoAlKmBI= --94eb2c0356ec820d3f054d6b7fed-- From nobody Tue Apr 18 00: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 636F112778E for ; Tue, 18 Apr 2017 00:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 UmoIXRhNfNnT for ; Tue, 18 Apr 2017 00:08:16 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A8F128A32 for ; Tue, 18 Apr 2017 00:08:13 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 2895F160322; Tue, 18 Apr 2017 09:08:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 0815B60062; Tue, 18 Apr 2017 09:08:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 09:08:11 +0200 From: To: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) Thread-Index: AQHStIgwGBf3ChplVkW1xKTg3XlzvaHKueRQ Date: Tue, 18 Apr 2017 07:08:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E4F72DOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:08:18 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E4F72DOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNCkhvdyBvYnNvbGV0aW5nIFJGQzcwODQgd2lsbCBiZSBkaWZmZXJlbnQgKGJl dHRlcj8pIGZvciBob21lbmV0IHZzIHVwZGF0aW5nIGl0PyBIb21lbmV0LXJlbGF0ZWQgcmVxdWly ZW1lbnRzIHdpbGwgYmUgYXQgYmVzdCBsaXN0ZWQgYXMgU0hPVUxEIGluIGEgb2Jzb2xldGVkL3Vw ZGF0ZWQgZG9jdW1lbnRzLg0KDQpJIGxpa2UgdGhlIGlkZWEgb2YgYW4gdXBkYXRlIGJlY2F1c2Ug SSBhbGxvd3Mgb3BlcmF0b3JzIHRvIGVhc2lseSBzY29wZSB0aGVpciByZXF1aXJlbWVudHMgdG8g dGhlaXIgcGFydGljdWxhciBjb250ZXh0Lg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgamFtZXMgd29vZHlh dHQNCkVudm95w6kgOiBqZXVkaSAxMyBhdnJpbCAyMDE3IDIxOjAwDQrDgCA6IHY2b3BzQGlldGYu b3JnDQpPYmpldCA6IFJlOiBbdjZvcHNdIE9ic29sZXRlIG9yIFVwZGF0ZSAoUkU6IExJU1Agc3Vw cG9ydCBmb3IgZHJhZnQtaWV0Zi12Nm9wcy1yZmM3MDg0LWJpcy0wMCkNCg0KT24gQXByIDEzLCAy MDE3LCBhdCAwMDo0OSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCklNTywgYXZvaWRpbmcgdG8gb2Jzb2xl dGUgUkZDNzA4NCBzZWVtcyB0aGUgcmlnaHQgYXBwcm9hY2ggdG8gZm9sbG93IGhlcmUuDQoNCkkg cHJlZmVyIHRvIG9ic29sZXRlLg0KDQpNeSByZWFzb25pbmc6IHdoaWxlIHRoZSB2YXJpb3VzIElQ djYgc2VydmljZSBwcm92aXNpb25pbmcgbWVjaGFuaXNtcyBhbmQgSVB2NCBzZXJ2aWNlIHRyYW5z aXRpb24gbWVjaGFuaXNtIGF2YWlsYWJsZSBoYXZlIGNoYW5nZWQgYW5kIHdpbGwgcHJvYmFibHkg Y29udGludWUgdG8gY2hhbmdlLCB0aGUgYmVoYXZpb3Igb2YgQ0Ugcm91dGVycyBpbiB0aGUgbG9j YWwgYXJlYSBpbnRlcmlvciByb3V0aW5nIGRvbWFpbiBpcyBiYWRseSBvdXQgb2YgZGF0ZSBhbmQg bmVlZHMgdG8gYmUgcmV2aXNlZCB0bw0KaW5jbHVkZSB0aGUgcHJvcG9zZWQgc3RhbmRhcmRzIGRl dmVsb3BlZCBpbiB0aGUgSE9NRU5FVCB3b3JraW5nIGdyb3VwLg0KDQpBbHNvIEnigJlkIGxpa2Ug dG8gZGVjbGFyZSB0aGF0IEnigJltIGluIGdlbmVyYWwgYWdyZWVtZW50IHdpdGggdGhlIHNwaXJp dCBvZiB3aGF0IEJhcmJhcmEgU3Rhcmsgd3JvdGUgZWFybGllciBvbiBwcm9wb3NlZCByZXF1aXJl bWVudHMgb24gdGhlIHdpZGUtYXJlYSBsaW5rIGludGVyZmFjZSBvZiB0aGUgQ0Ugcm91dGVyIGNh biBiZSBpbnRyb2R1Y2VkIGluIGFuIGFjY2VwdGFibGUgcmV2aXNpb24gb2YgUkZDIDcwODQuIFNo ZSB3cm90ZToNCg0KRm9yIHRoaXMgZG9jdW1lbnQgdG8gYmUgYSB0cnVlIHJlcGxhY2VtZW50IG9m IFJGQyA3MDg0LCBpdCBNVVNUIE5PVCBpbnRyb2R1Y2UgYW55ICJNVVNUIiByZXF1aXJlbWVudHMg dGhhdCBhbiBvcGVyYXRvciBjdXJyZW50bHkgdXNpbmcgUkZDIDcwODQgKGRpcmVjdGx5IG9yIGlu ZGlyZWN0bHkpIGRvZXMgbm90IHdhbnQgaW4gdGhlaXIgQ0Ugcm91dGVyLg0KNzA4NC1iaXMgTVVT VCBOT1QgaW50ZXJmZXJlIHdpdGgsIHBsYWNlIHVuZHVlIGJ1cmRlbiBvbiwgb3IgYWRkIGNvc3Qg dG8gZXhpc3RpbmcgZGVwbG95bWVudHMgYW5kIHRoZSBDRSByb3V0ZXJzIHVzZWQgaW4gdGhvc2Ug ZXhpc3RpbmcgZGVwbG95bWVudHMuDQpXaGVyZSBJIG1pZ2h0IGJlIGRlcGFydGluZyBmcm9tIGhl ciBvbiB0aGlzIHBvaW50IChub3Qgc3VyZSkgaXMgdGhhdCBJIGRvbuKAmXQgYmVsaWV2ZSBpdOKA mXMgYSBnb29kIGlkZWEsIG9yIGV2ZW4gcmVhbGx5IHBvc3NpYmxlLCB0byBwdWJsaXNoIFJGQyA3 MDg0LWJpcyB3aXRob3V0IGFkZGluZyBzb21lIG5vbi1yZWN1cnJpbmcgY29zdHMgdG8gdGhlIGRl dmVsb3BtZW50IG9mIG5ldyBDRSByb3V0ZXJzIHRoYXQgaW1wbGVtZW50IHRoZSBtb3JlIHJlY2Vu dCBIT01FTkVUIHN0YW5kYXJkcyBmb3IgdGhlIExBTiBpbnRlcmZhY2VzIGluIGhvbWUgbmV0d29y a3MuDQoNCk1heWJlIHRoZXJlIGFyZSBvcGVyYXRvcnMgdGhhdCBkb27igJl0IOKAnHdhbnTigJ0g dGhlaXIgQ0Ugcm91dGVycyB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgSE5DUCBkaXN0cmlidXRlZCBj b25zZW5zdXMgcHJvdG9jb2wgb24gdGhlIExBTiBpbnRlcmZhY2UuIElmIHRoZXJlIGFyZSBzdWNo IG9wZXJhdG9ycywgdGhlbiBJIHRoaW5rIGl0IHdvdWxkIGhlbHAgdG8gc3VyZmFjZSB0aGVpciBv YmplY3Rpb25zIHNvb25lciByYXRoZXIgdGhhbiBsYXRlci4NCg0KLS1qYW1lcyB3b29keWF0dCA8 amh3QGdvb2dsZS5jb208bWFpbHRvOmpod0Bnb29nbGUuY29tPj4NCg0KDQoNCg== --_000_787AE7BB302AE849A7480A190F8B933009E4F72DOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7DQoJcGFub3NlLTE6MCAwIDAg MCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJ Zm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1 cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5IaSBKYW1lcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+SG93IG9ic29sZXRpbmcgUkZDNzA4NCB3aWxsIGJlIGRpZmZl cmVudCAoYmV0dGVyPykgZm9yIGhvbWVuZXQgdnMgdXBkYXRpbmcgaXQ/IEhvbWVuZXQtcmVsYXRl ZCByZXF1aXJlbWVudHMgd2lsbCBiZSBhdCBiZXN0IGxpc3RlZCBhcyBTSE9VTEQgaW4gYSBvYnNv bGV0ZWQvdXBkYXRlZA0KIGRvY3VtZW50cy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgbGlrZSB0aGUgaWRlYSBvZiBhbiB1cGRhdGUgYmVjYXVz ZSBJIGFsbG93cyBvcGVyYXRvcnMgdG8gZWFzaWx5IHNjb3BlIHRoZWlyIHJlcXVpcmVtZW50cyB0 byB0aGVpciBwYXJ0aWN1bGFyIGNvbnRleHQuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRl Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBqYW1lcyB3 b29keWF0dDxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAxMyBhdnJpbCAyMDE3IDIx OjAwPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiB2Nm9wc0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5i c3A7OjwvYj4gUmU6IFt2Nm9wc10gT2Jzb2xldGUgb3IgVXBkYXRlIChSRTogTElTUCBzdXBwb3J0 IGZvciBkcmFmdC1pZXRmLXY2b3BzLXJmYzcwODQtYmlzLTAwKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEFwciAxMywgMjAxNywgYXQgMDA6NDksIDxh IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklNTywgYXZvaWRpbmcgdG8gb2Jzb2xldGUgUkZDNzA4NCBzZWVt cyB0aGUgcmlnaHQgYXBwcm9hY2ggdG8gZm9sbG93IGhlcmUuDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgcHJlZmVyIHRvIG9ic29sZXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSByZWFzb25pbmc6IHdoaWxlIHRoZSB2YXJp b3VzIElQdjYgc2VydmljZSBwcm92aXNpb25pbmcgbWVjaGFuaXNtcyBhbmQgSVB2NCBzZXJ2aWNl IHRyYW5zaXRpb24gbWVjaGFuaXNtIGF2YWlsYWJsZSBoYXZlIGNoYW5nZWQgYW5kIHdpbGwgcHJv YmFibHkgY29udGludWUgdG8gY2hhbmdlLCB0aGUgYmVoYXZpb3Igb2YgQ0Ugcm91dGVycyBpbiB0 aGUgbG9jYWwgYXJlYSBpbnRlcmlvciByb3V0aW5nIGRvbWFpbg0KIGlzIGJhZGx5IG91dCBvZiBk YXRlIGFuZCBuZWVkcyB0byBiZSByZXZpc2VkIHRvIDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPmluY2x1ZGUgdGhlIHByb3Bvc2VkIHN0YW5kYXJkcyBkZXZlbG9wZWQgaW4gdGhlIEhP TUVORVQgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkFsc28gSeKAmWQgbGlrZSB0byBkZWNsYXJlIHRoYXQgSeKAmW0gaW4gZ2Vu ZXJhbCBhZ3JlZW1lbnQgd2l0aCB0aGUgc3Bpcml0IG9mIHdoYXQgQmFyYmFyYSBTdGFyayB3cm90 ZSBlYXJsaWVyIG9uIHByb3Bvc2VkIHJlcXVpcmVtZW50cyBvbiB0aGUgd2lkZS1hcmVhIGxpbmsg aW50ZXJmYWNlIG9mIHRoZSBDRSByb3V0ZXIgY2FuIGJlIGludHJvZHVjZWQgaW4gYW4gYWNjZXB0 YWJsZSByZXZpc2lvbg0KIG9mIFJGQyA3MDg0LiA8L3NwYW4+U2hlIHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPkZvciB0aGlzIGRvY3VtZW50IHRvIGJlIGEgdHJ1ZSByZXBsYWNlbWVudCBv ZiBSRkMgNzA4NCwgaXQgTVVTVCBOT1QgaW50cm9kdWNlIGFueSAmcXVvdDtNVVNUJnF1b3Q7IHJl cXVpcmVtZW50cyB0aGF0IGFuIG9wZXJhdG9yIGN1cnJlbnRseSB1c2luZyBSRkMgNzA4NCAoZGly ZWN0bHkgb3IgaW5kaXJlY3RseSkgZG9lcw0KIG5vdCB3YW50IGluIHRoZWlyIENFIHJvdXRlci48 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij43MDg0LWJpcyBNVVNUIE5PVCBpbnRlcmZlcmUgd2l0aCwg cGxhY2UgdW5kdWUgYnVyZGVuIG9uLCBvciBhZGQgY29zdCB0byBleGlzdGluZyBkZXBsb3ltZW50 cyBhbmQgdGhlIENFIHJvdXRlcnMgdXNlZCBpbiB0aG9zZSBleGlzdGluZyBkZXBsb3ltZW50cy48 L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ V2hlcmUgSSBtaWdodCBiZSBkZXBhcnRpbmcgZnJvbSBoZXIgb24gdGhpcyBwb2ludCAobm90IHN1 cmUpIGlzIHRoYXQgSSBkb27igJl0IGJlbGlldmUgaXTigJlzIGEgZ29vZCBpZGVhLCBvciBldmVu IHJlYWxseSBwb3NzaWJsZSwgdG8gcHVibGlzaCBSRkMgNzA4NC1iaXMgd2l0aG91dCBhZGRpbmcg c29tZSBub24tcmVjdXJyaW5nIGNvc3RzIHRvIHRoZSBkZXZlbG9wbWVudCBvZiBuZXcNCiBDRSBy b3V0ZXJzIHRoYXQgaW1wbGVtZW50IHRoZSBtb3JlIHJlY2VudCBIT01FTkVUIHN0YW5kYXJkcyBm b3IgdGhlIExBTiBpbnRlcmZhY2VzIGluIGhvbWUgbmV0d29ya3MuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1heWJlIHRoZXJlIGFyZSBvcGVyYXRvcnMgdGhhdCBkb27igJl0IOKAnHdh bnTigJ0gdGhlaXIgQ0Ugcm91dGVycyB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgSE5DUCBkaXN0cmli dXRlZCBjb25zZW5zdXMgcHJvdG9jb2wgb24gdGhlIExBTiBpbnRlcmZhY2UuIElmIHRoZXJlIGFy ZSBzdWNoIG9wZXJhdG9ycywgdGhlbiBJIHRoaW5rIGl0IHdvdWxkIGhlbHAgdG8gc3VyZmFjZSB0 aGVpciBvYmplY3Rpb25zIHNvb25lciByYXRoZXINCiB0aGFuIGxhdGVyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1qYW1lcyB3b29keWF0dCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpod0Bnb29nbGUuY29tIj5qaHdAZ29vZ2xlLmNvbTwvYT4mZ3Q7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933009E4F72DOPEXCLILMA3corp_-- From nobody Tue Apr 18 00:18: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 018221315D0; Tue, 18 Apr 2017 00:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 T2-t9gtg998x; Tue, 18 Apr 2017 00:18:27 -0700 (PDT) Received: from st13p11im-asmtp003.me.com (st13p11im-asmtp003.me.com [17.164.40.218]) (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 57AE6131541; Tue, 18 Apr 2017 00:18:27 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p11im-asmtp003.me.com by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OOL00A00FYMU300@st13p11im-asmtp003.me.com>; Tue, 18 Apr 2017 07:18:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1492499888; bh=XKi1GtFR3ssq2E1gwynu/GtXs9pmNW4rOEB9eDSX5CA=; h=From:Content-type:MIME-version:Subject:Message-id:To:Date; b=kuGaOhR6gvWsGHcTn95o5xXn4IyVG6KUdo0FzH3NX1UxAz/V+H/P0U+lrrHK1FHrl meJmbbIqQ1Q7eFrH2cyrnI/615X4YBP7Zxz1D/tTglg0Ns4KF7Z++VxrAD/1rf8FF8 +0J/KblszPL5p+icj9P9vvEmyGoGU6pFPB4kQ/kdt401pXBLAVel8ZgZerIgtqgjfE mH5bOHleyiUyHQjJCnvbwzOkFA7moUf5a1hFHPMfgrV++ZSgttNCpWTyqTIZAQUWcf hQ8MRdNnInVnCi94OVlISbpHH96wLMZIi1+gos50usAaWZd8EYz45A1yyOFvqZj+Ek uvT+AKkJ1Pfqg== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OOL0061KGA68U40@st13p11im-asmtp003.me.com>; Tue, 18 Apr 2017 07:18:08 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-18_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1704180063 From: Gunter Van De Velde Content-type: multipart/alternative; boundary="Apple-Mail=_766784FF-9485-435A-BB33-568A06584210" MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-id: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> To: 6man@ietf.org, v6ops@ietf.org Date: Tue, 18 Apr 2017 09:18:05 +0200 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:18:29 -0000 --Apple-Mail=_766784FF-9485-435A-BB33-568A06584210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear 6man, v6ops, Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this = document may be of interest to both 6man as v6ops. Please send your feedback to OPSEC email list, where discussion around = this document should take place. Kind Regards, G/ > Begin forwarded message: >=20 > From: Gunter Van De Velde > Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 > Date: 12 April 2017 at 09:39:28 GMT+2 > To: opsec@ietf.org >=20 > This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-opsec-v6 = . > If you have not read it, please do so now. You may send nits to the = author, but substantive discussion should go to the list. >=20 > I will close the call on 26 April 2017 >=20 > G/=20 > Sent from iCloud > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_766784FF-9485-435A-BB33-568A06584210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear 6man, v6ops,

Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC = for this document may be of interest to both 6man as v6ops.

Please send your feedback to OPSEC email = list, where discussion around this document should take = place.

Kind = Regards,
G/

Begin forwarded message:

From: = Gunter Van De Velde <guntervandeveldecc@icloud.com>
Subject: = [OPSEC] WGLC for = draft-ietf-opsec-v6
Date: = 12 April 2017 at 09:39:28 = GMT+2
To: = opsec@ietf.org

This is to open a two week WGLC = for https://tools.ietf.org/html/draft-ietf-opsec-v6.
If you have not read it, please = do so now. You may send nits to the author, but substantive discussion = should go to the list.

I will close the = call on 26 April 2017

G/ 
Sent from =
iCloud
___________________________________________= ____
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

= --Apple-Mail=_766784FF-9485-435A-BB33-568A06584210-- From nobody Tue Apr 18 00:31: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 ED415131560 for ; Tue, 18 Apr 2017 00:31:11 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 q-K3OeYd_Gju for ; Tue, 18 Apr 2017 00:31:09 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 7F254131769 for ; Tue, 18 Apr 2017 00:31:09 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id l201so35391660ybf.0 for ; Tue, 18 Apr 2017 00:31:09 -0700 (PDT) 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=azW4KCdddCqEFfG3pbIj6DyuyNOAVMHGJb0z3F6kmNQ=; b=RKv4RQrY+kfWKipVCDe0iXxBajtpUuh4EJqPRYBCYsWMeRbT6V6HFuB4k0dWYDTfOe 8xTcmTnMRHoAe5qYaCkKYtsPrB6XxaWmSf88vPzhnpGvJO2vnvOT9CMc45m9b1qhF9Ii ZzDNV5zQfMWC7IHx/nhiqJQB6s5SDhDtQaiuUNDHUoxUvQDnkuxPHpFaENORfH4WtJM6 1kEoXis+Esho2HHZjJDtBYjLtMPtRQsO+jyqueo9l08qzNZE+r5KwRfi7pwsXkrsogI7 orEczaEzRApW9mbuGdyJm4Cc2/PgEihao6NklVYRFRF5mJogRaW11EkZDif9gh9Egqbo stPQ== 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=azW4KCdddCqEFfG3pbIj6DyuyNOAVMHGJb0z3F6kmNQ=; b=mGykOzzsPn6cNGayWDuMFcI1kZQZj/uN4PQzRBzonx+S9WNGTw2ANnrnRM4/40jfCH 0s/rQTSLo3PDAcNGCU1JHwSZFaYvrbI/w4lQeNYB+WyrCPkyJw27Dsnt1zSN0OiAZvkp +hOVTa6g2vtATTeFJSmJlN+jsatjM0cIacoq1YRf36902B0MBh178X3wzxPXnEzOykos KhqwoAVnl/Se9PNGhrdALF+w2VUY0RF/2Jj0zOjGTy/VfERwmc/FdQT3cCANZLef7z8B cr6/Sd94a0Y8BbF5/FcoH1T+gc9lkSVzIXU0RnABHqpJQgq629KqPGjeWsEDehzNFPy1 Idog== X-Gm-Message-State: AN3rC/6iZba2c9Y7nCvM+Bm0m96ht5Jv9uKQGGhglbMO1sLOd8g2XUdS dvofyqkw6Z6eHeG/yo99rRVHbNaG9D1i X-Received: by 10.37.87.134 with SMTP id l128mr18469850ybb.85.1492500668380; Tue, 18 Apr 2017 00:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.105.84 with HTTP; Tue, 18 Apr 2017 00:30:47 -0700 (PDT) In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> From: Erik Kline Date: Tue, 18 Apr 2017 16:30:47 +0900 Message-ID: To: Gunter Van De Velde Cc: 6man <6man@ietf.org>, "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113e6eee32bc16054d6be4f6" Archived-At: Subject: Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:31:12 -0000 --001a113e6eee32bc16054d6be4f6 Content-Type: multipart/alternative; boundary=001a113e6eee2acd23054d6be418 --001a113e6eee2acd23054d6be418 Content-Type: text/plain; charset=UTF-8 2.1.2. Use of ULAs Still? Really? On 18 April 2017 at 16:18, Gunter Van De Velde < guntervandeveldecc@icloud.com> wrote: > Dear 6man, v6ops, > > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this > document may be of interest to both 6man as v6ops. > > Please send your feedback to OPSEC email list, where discussion around > this document should take place. > > Kind Regards, > G/ > > Begin forwarded message: > > *From: *Gunter Van De Velde > *Subject: **[OPSEC] WGLC for draft-ietf-opsec-v6* > *Date: *12 April 2017 at 09:39:28 GMT+2 > *To: *opsec@ietf.org > > This is to open a two week WGLC for https://tools.ietf.org/ > html/draft-ietf-opsec-v6. > If you have not read it, please do so now. You may send nits to the > author, but substantive discussion should go to the list. > > I will close the call on 26 April 2017 > > G/ > > Sent from iCloud > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a113e6eee2acd23054d6be418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2.1.2.=C2=A0 Use of ULAs

Sti= ll?=C2=A0 Really?

On 18 April 2017 at 16:18, Gunter Van De Velde <gu= ntervandeveldecc@icloud.com> wrote:
Dear 6man, v6ops,

Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC W= GLC for this document may be of interest to both 6man as v6ops.
<= br>
Please send your feedback to OPSEC email list, where discussion aro= und this document should take place.

Kind Regards,=
G/

Begin forwarded = message:

From: Gunter V= an De Velde <guntervandeveldecc@icloud.com>
Subject: [OPSEC] WGL= C for draft-ietf-opsec-v6
Date: 12 April 2017 at 09:39:28 GMT+2
To: <= a href=3D"mailto:opsec@ietf.org" target=3D"_blank">opsec@ietf.org

This is to open a two week WGLC for=C2=A0https://tool= s.ietf.org/html/draft-ietf-opsec-v6.
If you have not read i= t, please do so now. You may send nits to the author, but substantive discu= ssion should go to the list.

I will close the call on 26 A= pril 2017

G/=C2=A0
Sent from iCloud
____________________= ___________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsec


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


--001a113e6eee2acd23054d6be418-- --001a113e6eee32bc16054d6be4f6 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQggXY5kGM7X/stWUIIVZHczEc4XGATbRrh zmdvm0QabKswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE4 MDczMTA4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBABUI1HCQShBBUPzor9OwSljSG89rU5nMer93cI/OKXlrsYm3jpWQ ZZtEQzBhyxpEgFOqhI7nU6hd9JlSa9UtQULlJUdLNz0kaqE//A0rChfdhxtDwt7pXmtj8BGupQIi 4FP/w5XCUdPjYu/mM8LqNlIJXNKrki3udmV59xiZrmBGQMpCpez3UFz50nfqPoOE3z7XZ9X128Dw XSDG/70NiREf+BhYnl646lGCGTMWIXHkbYvOYA8HPVFFUWSSNmca93PZUTXBvp5Jzn6ZirWebIwK d/uAlSq5W74F0JOIbzzSqvZ1Nj5uP5jAktPMYet/u6lBF73e0jlD2MeemtjFEgI= --001a113e6eee32bc16054d6be4f6-- From nobody Tue Apr 18 00:36: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 7EDBA1317BA for ; Tue, 18 Apr 2017 00:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 EvumgIQmIEiK for ; Tue, 18 Apr 2017 00:36:10 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121A11317B6 for ; Tue, 18 Apr 2017 00:36:10 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 65CCD20190; Tue, 18 Apr 2017 09:36:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 27ADE1A007B; Tue, 18 Apr 2017 09:36:08 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 09:36:08 +0200 From: To: Brian E Carpenter CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] Thread-Index: AQHStWN4iYYHc943HUyYJo9/PF0KjqHKvxeQ Date: Tue, 18 Apr 2017 07:36:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4F773@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> In-Reply-To: <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:36:11 -0000 Hi Brian,=20 I don't think we need to mandate any prefix length. I like the current word= ing of WPD-2 and WPD-3 because it does not impose any "hint" value.=20 We need to avoid CE routers making assumptions on the prefix length. It may= be appropriate to add an item so that CE routers comply with BCP198.=20 Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Brian E Carpen= ter > Envoy=E9=A0: vendredi 14 avril 2017 23:10 > =C0=A0: David Farmer; james woodyatt > Cc=A0: v6ops@ietf.org > Objet=A0: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] >=20 > On 15/04/2017 05:55, David Farmer wrote: > ... > > So if we really want to fix this rfc7084-bis needs a SHOULD support > prefix > > delegation of any length between /48 and /64, and MUST support prefix > > delegations of /48, /52, /56, /60, and /64. >=20 > Why wouldn't we simply say "MUST support prefix delegation of any > length between /48 and /64"? >=20 > Even that is not what the IPv6 routing architecture requires, which > is "MUST support prefix delegation of any length." >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 18 00: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 EC97A1317B6 for ; Tue, 18 Apr 2017 00:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 WxZDG-qPSuZb for ; Tue, 18 Apr 2017 00:36:53 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 E3D911317B7 for ; Tue, 18 Apr 2017 00:36:52 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=36232 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1d0Ngr-0006Rw-Iz; Tue, 18 Apr 2017 07:36:45 +0000 Date: Tue, 18 Apr 2017 09:36:44 +0200 From: Tore Anderson To: otroan@employees.org Cc: jordi.palet@consulintel.es, v6ops@ietf.org Message-ID: <20170418093644.16acdb43@echo.ms.redpill-linpro.com> In-Reply-To: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> References: <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:36:55 -0000 * otroan@employees.org > The standardisation of the "transitioning off IPv4 mechanisms" is a > prime example of IETF failure. > You are proposing to carry that failure forward and require all CE > implementations to implement _all_ the mechanisms in existence? >=20 > That is not providing "value add" to the community. +1 > If I remember correctly that list is now: RFC2473, GRE, L2TP, LISP, > MAP-E, MAP-T, 4RD, 464XLAT, Public 4over6, LW46, Dynamic LW46, ... Yup. Almost half of the requirements section in this document named =C2=AB*Basic* Requirements for *IPv6* Customer Edge Routers=C2=BB (emphasis mine) is talking about this plethora of *IPv4* stuff. It is getting ridiculous. IMO: Nuke section 5.4 completely. Relegate the list of all current =C2=ABtransitioning off IPv4=C2=BB technologies to a short appendix contain= ing informative references. Let the individual ISPs specify which of those technologies, if any, is a MUST for CE routers to be deployed in their specific networks. Tore From nobody Tue Apr 18 00:51: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 AB3D01317D6 for ; Tue, 18 Apr 2017 00:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[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=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 s3jZsaVBLGDF for ; Tue, 18 Apr 2017 00:51:41 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 190F21317DF for ; Tue, 18 Apr 2017 00:51:41 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id j127so64705237vkh.0 for ; Tue, 18 Apr 2017 00:51:41 -0700 (PDT) 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=mDwgh9I/9bu36KvVHZ4jH4OzP1kVjib45PQ1UVQtJfQ=; b=o0Pazzmr3JUJJAueR9nW7PbqfH1OK0ptbJzpzSq4qYy0lbs0OmhUjxnNfxzSFi9M43 akEg8D0gF2uD0Dwy6gUPJBAtH8lgXHtKHw5xQ3+MBnpJiqBuEClh45PkZkGT6TNlnlut uMFS/dBlSYJ5Tub14TQ+Ve7QUFu9B2PBOr3IJrPUOE/qMEslAEFZumqZ/EtNcYYwRUqv Vp7sfyqcfCLKxyL4q4CAMmjhARAtwd9SYE8YRiS/njg438bqfgs/RttV3u4f5vXs0PEl L/HnG0sAPvoFIY/ItsoyGyXD4xTQERPsp3Z/yMwrhabuYxWMmm0rgFdSByJkRDbnDP5X H6Cw== 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=mDwgh9I/9bu36KvVHZ4jH4OzP1kVjib45PQ1UVQtJfQ=; b=q6sifesYActaxYPdbdp0Sv4RYrTKsWWskZ2yakGVeDzRc9f8P7DEPhGrfplOo23wzv PbAgclNWPeI0QdcdscqEIhnFlAZgowkFYH6zODS21sSzx/gvIdF7b6L2R83NaVxwxskd eOlq4WqjAeI+Mg2PaJQ/z7d/NfRtCekKiYtT8LGL8Yy8YhNq4qxj2HjTD709wN6p7eS7 0BoHYQYnCXMbCGBhkM6nE+cQudX+6zCcCUApPDuYnjkMOtNddV6VXY9CiQ+AHj6iu6UM lMPkMPFYZwlWiK+Nk8Y6xCU5I3YqGmKT3+PY580l4uVzjqwEgICfECWBFVN0wIXyELKJ CQzw== X-Gm-Message-State: AN3rC/6b/owdDPVkEpIGjqaPq1aUVZ6RZ4ReaHXqV+jrty3Pa0nfutSA SpsNvGuLZeSzqBEbKObbUhcQS1CWmJw7AiQ= X-Received: by 10.31.146.12 with SMTP id u12mr4233404vkd.102.1492501899987; Tue, 18 Apr 2017 00:51:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Tue, 18 Apr 2017 00:51:19 -0700 (PDT) In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> From: Lorenzo Colitti Date: Tue, 18 Apr 2017 16:51:19 +0900 Message-ID: To: Gunter Van De Velde Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" , "opsec@ietf.org" Content-Type: multipart/alternative; boundary=001a1142f13093ca92054d6c2d3a Archived-At: Subject: Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:51:43 -0000 --001a1142f13093ca92054d6c2d3a Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 4:18 PM, Gunter Van De Velde < guntervandeveldecc@icloud.com> wrote: > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this > document may be of interest to both 6man as v6ops. > > Please send your feedback to OPSEC email list, where discussion around > this document should take place. > I share Erik's concern around the ULA section. The has been controversial for years. For example, see the thread starting at https://www.ietf.org/mail-archive/web/opsec/current/msg02012.html . The vast majority of the text in 2.1.2 has not changed in any substantial way since that heated debate, as shown by the diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-opsec- v6-08.txt&url2=draft-ietf-opsec-v6-11.txt . Do we really have to have that debate again? --001a1142f13093ca92054d6c2d3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 18, 2017 at 4:18 PM, Gunter Van De Velde <guntervandev= eldecc@icloud.com> wrote:
Due to the = IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this docum= ent may be of interest to both 6man as v6ops.

Please sen= d your feedback to OPSEC email list, where discussion around this document = should take place.

I shar= e Erik's concern around the ULA section. The has been controversial for= years. For example, see the thread starting at=C2=A0h= ttps://www.ietf.org/mail-archive/web/opsec/current/msg02012.html<= /a> .


Do we really have to have that debate again?
--001a1142f13093ca92054d6c2d3a-- From nobody Tue Apr 18 01:18: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 F108C131803; Tue, 18 Apr 2017 01:18:46 -0700 (PDT) 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=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 VyLtvEzzxvVU; Tue, 18 Apr 2017 01:18:45 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 73935131802; Tue, 18 Apr 2017 01:18:45 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 08:18:44 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id F1CA5D788B; Tue, 18 Apr 2017 01:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=jF0ILG3gQ31F4GyevJNrtzifVwg=; b= HrmaupHZEhu/lYEQ2z11K9D6AXRCGbmBhMa/d0GLwDkSHhaZ9Xc+TZna/niCTgLo AfFRlnJ/Yuq68GjtmqErLpXfff37Kly4SIDKsz2xV7x31/mWAWoskvnmiRGo+KG+ c3BMA1EPSaRfJxQeQdkmvB6T1ZrMEi21PO8h09VwW84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=ZthPxr+1DNrZMeWKj/TRc1F eW6hX1KqA08HvrgM7njIjIq1d/SWWWyNh9/C8lONS++aeJiS0i5znCFtBtiMpNvX 6FRncfGXL4BsfGwVZ7jJcitXR/Uwv2J2Ms7UI8VaaQdrQ0rExfxh1pNajsE4NxYj Ar1XZ/jpPbhWBO4W/EXs= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 951F4D788A; Tue, 18 Apr 2017 01:18:43 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 948BFAA06E4E; Tue, 18 Apr 2017 10:18:41 +0200 (CEST) From: otroan@employees.org Message-Id: <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_DE90BA24-E781-4B99-8A9A-4ABA677A6721"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 10:18:40 +0200 In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> Cc: 6man@ietf.org, "v6ops@ietf.org Operations" , Gunter Van De Velde To: opsec@ietf.ortg References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 08:18:47 -0000 --Apple-Mail=_DE90BA24-E781-4B99-8A9A-4ABA677A6721 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A few initial comments. Draft is not quite ready. Section 2.1.3: 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. The ping pong attack is mitigated in RFC4443. I am not convinced there is justification that this document should = recommend /127 for "security reasons". Section 2.1.4: The description of the IID needs to be updated with the latest = recommendations in 4291bis etc. The IID is no longer recommend to be created by MAC address for = example. It might also be worth clarifying that the operator can only control = a host's choice of IID / privacy by disabling SLAAC altogether. Section 2.1.6: "DNS is often used for malware activities"... That just doesn't read = well. I presume you aren't proposing to disable DNS? ;-) Section 2.2: I am not sure that extension headers are one of the most critical = differentiators between IPv4 and IPv6. IPv4 had variable length = options... Section 2.2.2: This section should be updated to reflect the new text in 2460bis. The = reference to hbh-header-handling is no longer needed. Section 2.2.3 s/Fragment Extension Header/Fragment header Same for Hop by Hop options header. Please get the names of the = headers correct. Section 2.3.2: Consider Secure DHCPv6? Section 2.3.3: I don't think those individual drafts are "actively" discussing = methods to rate limit RA anymore. Wirth update / rewrite with summary = from those discussions. Section 2.7.2 Remove the historic tunnel mechanisms? ISATAP, Teredo, 6to4? Section 2.7.2.7: DS-lite is not a translation mechanism. Section 2.7.2.8 s/tunnel and encapsulation/encapsulation and translation/ Section 2.7.3.1: Why in an IPv6 document? Section 3.1: In general update references. e.g. ipv6-eh-filtering is outdated. I question referencing opsec-ipv6-eh-filtering. It has wrong and = outdated advice. E.g. on section of HBH header. The advice in ipv6-eh-filtering is essentially to ossify the network. Section 5: Reference to balanced-ipv6-security... I don't think it is worth = referencing an expired draft. Why not summarise the points in a = paragraph? Ole > On 18 Apr 2017, at 09:18, Gunter Van De Velde = wrote: >=20 > Dear 6man, v6ops, >=20 > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this = document may be of interest to both 6man as v6ops. >=20 > Please send your feedback to OPSEC email list, where discussion around = this document should take place. >=20 > Kind Regards, > G/ >=20 >> Begin forwarded message: >>=20 >> From: Gunter Van De Velde >> Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 >> Date: 12 April 2017 at 09:39:28 GMT+2 >> To: opsec@ietf.org >>=20 >> This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-opsec-v6. >> If you have not read it, please do so now. You may send nits to the = author, but substantive discussion should go to the list. >>=20 >> I will close the call on 26 April 2017 >>=20 >> G/ >> Sent from iCloud >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_DE90BA24-E781-4B99-8A9A-4ABA677A6721 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9cvhAAoJEL7aWKiYQt92qIIQAIpTcBsbFUQmgNojyrHoiwyx MGXLjt2eHD7BkY0y1Gkz4AVEdqOFNcDRyKnT4KvaaW2GEpSs4SqsZjY9xZbHq8CN xKcLA8Mt/PDBuuUMZvA1jWZnOspCa6u4YetE4s4O+wzPOf+KEj0Tc9qJqcQlRTFT tkLsercYcFBPMZGDPWWdn9sGl2VawrqNDDLkcsJ5eWOSmBboogAWUYOQVgPYPaJf IVOYXzDNEleZ0p1AKLtZddiQJvHxwPmblXbhpdbdzF/naNEiTJzg/QJ+KIFMR1fk LVcXt2Ah+fYQTfSObV/sXbBxrnbPqX4aUZG7Yqhqm4yzIP/FXoiLalu6RiBdPyAU Q8Y5gyhWLClNgbAF1I/M9gz5nYNF6W4eyiCSSVxDoCmHopwOrl3Tcy3aVZaohpB4 AHi6knLUjNqhKBc11GX028asTM99GgojK8cPVZFqCSegrNUDAKyK/NOBxuQSLluH 8JAy7Gn5BdW2iOiiCX5lUcxKMC+bzXk6kcUlwYigWS3DD1gxryZPcXws0goC2heK XbRyzujfHLacWMQTCAKN6ECssMxrwZkzF0vSKWNr5FnwAfaVowDHlcn7I9TLcsHU No9+BFBEbmrG7ypwnc4p+WzbjbwteWIB3xnQXM1Eh41/ay5dZvKNnuD0snv4P36o mVKz5tkQbTT6s9Ilsbxd =pcg9 -----END PGP SIGNATURE----- --Apple-Mail=_DE90BA24-E781-4B99-8A9A-4ABA677A6721-- From nobody Tue Apr 18 03:43: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 57BE6129BCA for ; Tue, 18 Apr 2017 03:43:35 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 b--vxYBgStOJ for ; Tue, 18 Apr 2017 03:43:34 -0700 (PDT) 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 C8CBF129C34 for ; Tue, 18 Apr 2017 03:43:33 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id a1so88612666uaf.3 for ; Tue, 18 Apr 2017 03:43:33 -0700 (PDT) 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=/2cvq+Vs/wRhsd6/rRptLnzSgciIshG+I3TYXG+pK6A=; b=axTf6yjm30gZUH3u9UP0uaq/3JSGuVsWWzLIfJyNMr5uzZtI0Ql0z+iOpeWK6qWQnp mU99fLoY6vTu9S3vV2JSBA23cjOCH9Jd2mIDWmskpPJDC2KJx0KyZ88wV7esZVImvH75 tSvCo6p6htQV/I3qJquBlrA1qyWxQDa60IPDaQHTJDieoLTZJGTZOmQztQ3iHy8GhFH2 B+B7K/fCcOyz/4HflXUCfmny5UoxT2S0ik49cI+0RkYUrENQREtvg6ffyyZjCDTpDZXK QCll4qadygNeDiBS1d2Xh+CgWtr/wXHlf7WfUfDgaS/8dRzcTKMhI6Y0s8d6Q4MBRpMF 54+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=/2cvq+Vs/wRhsd6/rRptLnzSgciIshG+I3TYXG+pK6A=; b=IRq0F1P8uDRgdfWSvLiHCLaz2W6QMQs7kyq0OFTvVqehwg028yZX3q8cD8cuJJ/a3Z L7SELjc0SGb6ps3EeaO4ku3bYm4NS0LQB7NQoo4b9H0y1WiXDyOkcxQ0LFl3pmO2HaTv +ejoCU5yi5hwkHsr8/HdjNAVrASOwUqRmS7b+8mjdhOdeUzf+fdCU7CZ7rrZUPNtS8a9 dXi3kMdtLonm77OIRb6sQSOR5981HSDZ0eqSzY/YX7HscU+AnGP2wXP/1VYvYM06JAtn 6cRprMN2bZQDKRyjJVf9qBnna9jl4x5+onnAGHhYyizVEqfLIHKRvr4D3p2AapivrTBO 4Zhg== X-Gm-Message-State: AN3rC/50FJgIWxlkqf/CH0oGxkvR1Y373WChofG+X00L0D8TekWItBYI lvV5Gtkae0ixHKHNYzW0alhv0fsr81b6 X-Received: by 10.176.82.238 with SMTP id w43mr12958210uaw.171.1492512212807; Tue, 18 Apr 2017 03:43:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Tue, 18 Apr 2017 03:43:12 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4F773@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <787AE7BB302AE849A7480A190F8B933009E4F773@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Tue, 18 Apr 2017 19:43:12 +0900 Message-ID: To: "" Cc: Brian E Carpenter , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c18f5e244de2a054d6e94e7 Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 10:43:35 -0000 --94eb2c18f5e244de2a054d6e94e7 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 4:36 PM, wrote: > We need to avoid CE routers making assumptions on the prefix length. It > may be appropriate to add an item so that CE routers comply with BCP198. > BCP198 talks about forwarding, not address assignment. It's still the case that the address block assigned to a CPE must be a /64 or shorter. --94eb2c18f5e244de2a054d6e94e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 18, 2017 at 4:36 PM, <mohamed.boucadair@orange.com= > wrote:
We need to avoid CE ro= uters making assumptions on the prefix length. It may be appropriate to add= an item so that CE routers comply with BCP198.

BCP198 talks about forwarding, not address assignment. It's st= ill the case that the address block assigned to a CPE must be a /64 or shor= ter.
--94eb2c18f5e244de2a054d6e94e7-- From nobody Tue Apr 18 04:02: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 ADB0912EA64 for ; Tue, 18 Apr 2017 04:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 16VZL-WdXfaq for ; Tue, 18 Apr 2017 04:02:00 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DCF126FB3 for ; Tue, 18 Apr 2017 04:02:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 829271A071 for ; Tue, 18 Apr 2017 11:02:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Tue, 18 Apr 2017 12:01:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <20170418000956.BCACF6B86628@rock.dv.isc.org> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:02:03 -0000 Lorenzo Colitti wrote: > And why don't they delegate reverse zones automatically? >=20 > I'm pretty sure the reason is *not* "we'd be happy to delegate a = reverse zone to you, but unfortunately we can't do that because we only = gave you a /61 and that's not on a nibble boundary". No, it won't be at the moment ... > If that's not the reason, then there's no point writing text to remove = that reason. I disagree. Just because there are other reasons, doesn't negate it = being a good idea to nip this one in the bud before it does become an = issue. Better to be clear up front so bad implementations can be called = out for being "wrong"*, rather than telling people after the fact that = "we've just change the rules, what you implemented and was allowed under = the old rules is now wrong* under the new rules". Or put another way, = better to make it clear up front what "right" is, than try and change = things after they have been implemented. * However you define "wrong" - against the RFCs, against a best practice = document, whatever. Bear in mind that ISPs are mostly still getting to grips with a whole = change in manglement mindset about IPv6 - that much is clear from the = discussions about prefix lengths and how some ISPs are still treating = addresses as "scarce" like they do with IPv4. Given that it's now = uncommon to get as much as a /24 in address space, delegating reverse = DNS will be unfamiliar to most ISPs, and for those that do do it, it'll = almost certainly be a manual process - quite justifiable when a /24 only = comes with an expensive business service, and probably only taken up by = those with network management skills. As it happens, I manage delegated reverse DNS for a /24 and a /23 at = work. So I wouldn't put much store on what ISPs are or aren't doing right now = with IPv6 reverse DNS delegation - it's probably down the list, well = below "getting an IPv6 service that works". Just as the population at = large still aren't asking for IPv6, fewer still will be asking for = reverse DNS delegation - so the "when people start asking for it ..." = argument applies. From nobody Tue Apr 18 04:09: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 CC16A12EA94 for ; Tue, 18 Apr 2017 04:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 a-xc-_C45ACP for ; Tue, 18 Apr 2017 04:09:13 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1215012943A for ; Tue, 18 Apr 2017 04:09:13 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7D3ACC0534; Tue, 18 Apr 2017 13:09:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 45DC81A007B; Tue, 18 Apr 2017 13:09:11 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 13:09:10 +0200 From: To: Lorenzo Colitti CC: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] Thread-Index: AQHSuDChbnnXS30MiUiHb2Mx683knKHK9bTQ Date: Tue, 18 Apr 2017 11:09:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4F966@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <787AE7BB302AE849A7480A190F8B933009E4F773@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E4F966OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:09:15 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E4F966OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IG1hcmRpIDE4 IGF2cmlsIDIwMTcgMTI6NDMNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2MgOiBC cmlhbiBFIENhcnBlbnRlcjsgdjZvcHNAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFt2Nm9wc10gUHJl Zml4IGxlbmd0aHMgW3dhczogcmZjNzA4NC1iaXMgYW5kIGhvbWVuZXRdDQoNCk9uIFR1ZSwgQXBy IDE4LCAyMDE3IGF0IDQ6MzYgUE0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQpXZSBuZWVkIHRvIGF2b2lk IENFIHJvdXRlcnMgbWFraW5nIGFzc3VtcHRpb25zIG9uIHRoZSBwcmVmaXggbGVuZ3RoLiBJdCBt YXkgYmUgYXBwcm9wcmlhdGUgdG8gYWRkIGFuIGl0ZW0gc28gdGhhdCBDRSByb3V0ZXJzIGNvbXBs eSB3aXRoIEJDUDE5OC4NCg0KQkNQMTk4IHRhbGtzIGFib3V0IGZvcndhcmRpbmcsIG5vdCBhZGRy ZXNzIGFzc2lnbm1lbnQuDQpbTWVkXSBJIGtub3cgd2hhdCB0aGF0IFJGQyBpcyBhYm91dC4gUHJl Zml4IGxlbmd0aCBpcyBub3Qgb25seSByZWxhdGVkIHRvIGFzc2lnbm1lbnQgYnV0IGFsc28gdG8g b3RoZXIgbWF0dGVycyBzdWNoIGFzIGZvcndhcmRpbmcsIGhlbmNlIG15IHByb3Bvc2FsIHRvIGFk ZCBhbiBpdGVtIGZvciBCQ1AxOTguDQoNCkl0J3Mgc3RpbGwgdGhlIGNhc2UgdGhhdCB0aGUgYWRk cmVzcyBibG9jayBhc3NpZ25lZCB0byBhIENQRSBtdXN0IGJlIGEgLzY0IG9yIHNob3J0ZXIuDQpb TWVkXSBUaGVyZSBpcyBhbHJlYWR5IEJDUCAxNTcgZm9yIHRoaXMuIFdQRC0yIGFuZCBXUEQtMyBj aXRlZCBpbiBteSBpbml0aWFsIG1lc3NhZ2UgYXJlIElNSE8gY29uc2lzdGVudCB3aXRoIHRoYXQg QkNQLg0K --_000_787AE7BB302AE849A7480A190F8B933009E4F966OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5SZS0s PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4N CjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJkaSAxOCBhdnJpbCAyMDE3IDEyOjQzPGJyPg0KPGI+ w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6 PC9iPiBCcmlhbiBFIENhcnBlbnRlcjsgdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNw Ozo8L2I+IFJlOiBbdjZvcHNdIFByZWZpeCBsZW5ndGhzIFt3YXM6IHJmYzcwODQtYmlzIGFuZCBo b21lbmV0XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDE4LCAyMDE3IGF0IDQ6MzYgUE0sICZsdDs8 YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIG5lZWQgdG8gYXZvaWQgQ0Ugcm91dGVycyBt YWtpbmcgYXNzdW1wdGlvbnMgb24gdGhlIHByZWZpeCBsZW5ndGguIEl0IG1heSBiZSBhcHByb3By aWF0ZSB0byBhZGQgYW4gaXRlbSBzbyB0aGF0IENFIHJvdXRlcnMgY29tcGx5IHdpdGggQkNQMTk4 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QkNQMTk4IHRh bGtzIGFib3V0IGZvcndhcmRpbmcsIG5vdCBhZGRyZXNzIGFzc2lnbm1lbnQuPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEkga25vdyB3aGF0IHRo YXQgUkZDIGlzIGFib3V0LiBQcmVmaXggbGVuZ3RoIGlzIG5vdCBvbmx5IHJlbGF0ZWQgdG8gYXNz aWdubWVudCBidXQgYWxzbyB0byBvdGhlciBtYXR0ZXJzIHN1Y2ggYXMgZm9yd2FyZGluZywgaGVu Y2UgbXkgcHJvcG9zYWwgdG8gYWRkDQogYW4gaXRlbSBmb3IgQkNQMTk4LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0J3Mgc3RpbGwgdGhlIGNhc2UgdGhhdCB0aGUgYWRkcmVz cyBibG9jayBhc3NpZ25lZCB0byBhIENQRSBtdXN0IGJlIGEgLzY0IG9yIHNob3J0ZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGVyZSBpcyBhbHJlYWR5IEJDUDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4x NTcgZm9yIHRoaXMuIFdQRC0yIGFuZCBXUEQtMyBjaXRlZCBpbiBteSBpbml0aWFsIG1lc3NhZ2Ug YXJlIElNSE8gY29uc2lzdGVudCB3aXRoIHRoYXQgQkNQLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933009E4F966OPEXCLILMA3corp_-- From nobody Tue Apr 18 04: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 D7EC312EAAD; Tue, 18 Apr 2017 04:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 HorlItuqbVIo; Tue, 18 Apr 2017 04:10:50 -0700 (PDT) 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 9F04512EAAA; Tue, 18 Apr 2017 04:10:50 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 3C29880142; Tue, 18 Apr 2017 13:10:47 +0200 (CEST) To: otroan@employees.org, opsec@ietf.ortg References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> Cc: Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Date: Tue, 18 Apr 2017 12:10:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:10:53 -0000 On 04/18/2017 09:18 AM, otroan@employees.org wrote: > A few initial comments. Draft is not quite ready. > > Section 2.1.3: > 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. Agreed on this. > The ping pong attack is mitigated in RFC4443. I must be missing something.. what does RFC4443 have to do with this? A ping pong attack does not require the attack packets to be ICMPv6 echo requests... > I am not convinced there is justification that this document should recommend /127 for "security reasons". Besides ping-pong, there's NCE. While I do agree that the real solution to the above two issues is *not* to use a /127, this document being an operational one, I can see why the authors may want to recommend /127. > Section 2.2: > I am not sure that extension headers are one of the most critical differentiators between IPv4 and IPv6. IPv4 had variable length options... The packet structure does make a big difference. For instance, it's trivial to find (in IPv4-based packets) the upper layer protocol type and protocol header, while in IPv6 it actually isn't. > Section 2.3.2: > Consider Secure DHCPv6? Question: is that doable? (i.e., widely supported) > Section 3.1: > In general update references. e.g. ipv6-eh-filtering is outdated. > I question referencing opsec-ipv6-eh-filtering. It has wrong and outdated advice. E.g. on section of HBH header. > The advice in ipv6-eh-filtering is essentially to ossify the network. Have you read the I-D? Because the I-D boils down to: "pass all EHs unless they are known to be very harmdful". Thanks! 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 Apr 18 04: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 CAE6F12EB0A; Tue, 18 Apr 2017 04:39:31 -0700 (PDT) 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=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 vuDwlVznUuhP; Tue, 18 Apr 2017 04:39:28 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8366212EB07; Tue, 18 Apr 2017 04:39:28 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 11:39:27 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 32EFCD788B; Tue, 18 Apr 2017 04:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=MEeFQNqvGE5Vfsua+UUSMzhRvew=; b= ng7oLgsBlAjDFQu63miRdNbFKFCv/xTV+ZqLMk/GafkjG7/a+IwtTMVUjzZa15rk eIXnox4UsweFQfY/BIgq067FXc+B6bSNh8EaA3msPZdW2LZYvH1cKG8VDtX/laAZ YFJYtDdvQH+RYT+duIzT7iz8VBnraiE5ljq5S0jXu1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=YPvLRvv592mqK3bb7PGwSHA m14ezUYAL6gvkny3BYZfqQwwwHuGeXUq5PEFmkNmTDufrAMfS912u83wARsKaHv7 nucjFAPpAO1xBJWxuMmVKQ+U6nqv09blL8UCNViNQiW1SComa1ZZEVvhtYhTzUvb /IJ3cQEzuhgZ7tP1SZ74= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 B1B77D788A; Tue, 18 Apr 2017 04:39:26 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 82F40AA3DF0B; Tue, 18 Apr 2017 13:39:24 +0200 (CEST) From: otroan@employees.org Message-Id: <2E8529D6-0CC8-4C59-88D3-12891011E1AD@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_38C16313-E875-4047-B1B6-C54E70D9D88E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 13:39:23 +0200 In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Cc: opsec@ietf.ortg, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:39:32 -0000 --Apple-Mail=_38C16313-E875-4047-B1B6-C54E70D9D88E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Apr 2017, at 13:10, Fernando Gont wrote: >=20 > On 04/18/2017 09:18 AM, otroan@employees.org wrote: >> A few initial comments. Draft is not quite ready. >>=20 >> Section 2.1.3: >> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. >=20 > Agreed on this. >=20 >=20 >> The ping pong attack is mitigated in RFC4443. >=20 > I must be missing something.. what does RFC4443 have to do with this? = A > ping pong attack does not require the attack packets to be ICMPv6 echo > requests... https://tools.ietf.org/html/rfc4443#section-3.1 One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. Most implementations I'm aware of now implement this. >> I am not convinced there is justification that this document should = recommend /127 for "security reasons". >=20 > Besides ping-pong, there's NCE. While I do agree that the real = solution > to the above two issues is *not* to use a /127, this document being an > operational one, I can see why the authors may want to recommend /127. Neighbour cache exhaustion has to be mitigated anyway. On router-router links that's a relatively simple problem compared to = links with hosts. I'm still not convinced that /127 should be recommended over any of the = other addressing models for router to router links. /64, link-local only, /128s. >> Section 2.2: >> I am not sure that extension headers are one of the most critical = differentiators between IPv4 and IPv6. IPv4 had variable length = options... >=20 > The packet structure does make a big difference. For instance, it's > trivial to find (in IPv4-based packets) the upper layer protocol type > and protocol header, while in IPv6 it actually isn't. It isn't supposed to be. >> Section 2.3.2: >> Consider Secure DHCPv6? >=20 > Question: is that doable? (i.e., widely supported) You expect this document to have a short lifetime? (Which I guess is the exact problem of publishing this type of advice as = an IETF RFC). >> Section 3.1: >> In general update references. e.g. ipv6-eh-filtering is outdated. >> I question referencing opsec-ipv6-eh-filtering. It has wrong and = outdated advice. E.g. on section of HBH header. >> The advice in ipv6-eh-filtering is essentially to ossify the = network. >=20 > Have you read the I-D? Because the I-D boils down to: "pass all EHs > unless they are known to be very harmdful". Hmm, I see the latest opsec version has put this right, thanks. I must have read the earlier individual draft, cause that said "should = drop HBH". Best regards, Ole --Apple-Mail=_38C16313-E875-4047-B1B6-C54E70D9D88E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9frsAAoJEL7aWKiYQt92PFUQAJwkVo7+HJoh9mo6WXb2SEns 7jHBTB9L057Wb6UKtKrZqxo6S/SkFZcHWX18uU0hOFr10vCn2g4ipXHcNFDT/gI+ hlpB+tNvzEsYL7y88mBzKmv4ZDUt5IMJqd7nVfySI+oaBQwbZyq8ee4+T2r1xOgl TRgJbGm760cJVsRYsz6dQZgcnBCNRy+ZfY0d+92j5XfzTFx8/Y2/XV4IFopUteco XrpnQUgqPFNvgLzy42T8XrFmnZq19ykLDPqXK+X5eRi+ryUSpsLDgW0hx/YNhF8D ExW1zeGx10FtTAelVir8Nrvk9HupLUPe6z14PVZt70GCDvyOIBcFrVX+M/sau+yS 0eeicuSYIyfIwclgejKIsMk73T9HkwYKyeFh55Mn203ep3PpPdZq8mcjqnaxVHK9 qyIFFCWtoMgztJZvpr6mOWp8TR3x4Cq2Y/3T6M1P0Sqjk/E9bv1PFqVfBhcey2Z/ VdXXQ7CjM2v0EEfBTt5JzQzGtGlpqzvYqdS+WNnuOUZ2Pm5BA1gP2vjGxbrQYyGL lhzLJB2igqWdpfkrAt1kVNPCjVpGGEMWZ3avr8k/8aLfe1hbOiZ3+URfarzpUjeS qoomW5WqGMJlbMceMlNtVf8YhD9qALp44j7KKNeCKhmz3d21d/9Tqeui/rE/kGch aC4O0bPFNQ2Mib1Vj05k =qlCS -----END PGP SIGNATURE----- --Apple-Mail=_38C16313-E875-4047-B1B6-C54E70D9D88E-- From nobody Tue Apr 18 04:45: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 806F212EAF6; Tue, 18 Apr 2017 04:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 kip--Hzj8hW3; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3A8129481; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 11:44:47 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1DBD9D788B; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=yhQgaSTwtKWUDSSleodGkfbxePY=; b= q13bhEs4npatv82KBDKrd+CmsB4qAm2xEDT/miLKv5zZPq+efZFWoSQE3LPUSZtm Kma76DIh95shECkDY+lDG5eKKCJWeqWnKTk2dwBVTOAjtAKAS/spy1pWVNaJbdAH TQJaT+Jvh/WM8MhbIBLxk8Yck5oUeQWkQdRCEoz3utg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=r6rflq/j3c7N1irgYXSwB8Q ZiMCn5IulXjW8OpwoIR2L6PkCXY8NjcbX5cs5mVoW/tFUr1gEyrpAo+PxAiQ1iC4 nu3NPqbLxiZLGPL0VC+W4s7hAgbEbvX7IFgPE5cxKK/yizpJNNvxwW3lTDB+shqW GvwmQTBcRs4HrKgm0JSQ= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 63663D788A; Tue, 18 Apr 2017 04:44:46 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DD2F8AA3FB43; Tue, 18 Apr 2017 13:44:44 +0200 (CEST) From: otroan@employees.org Message-Id: <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 13:44:44 +0200 In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:44:50 -0000 --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC Content-Type: multipart/alternative; boundary="Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C" --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > On 18 Apr 2017, at 13:10, Fernando Gont wrote: >=20 > On 04/18/2017 09:18 AM, otroan@employees.org wrote: >> A few initial comments. Draft is not quite ready. >>=20 >> Section 2.1.3: >> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. >=20 > Agreed on this. >=20 >=20 >> The ping pong attack is mitigated in RFC4443. >=20 > I must be missing something.. what does RFC4443 have to do with this? = A > ping pong attack does not require the attack packets to be ICMPv6 echo > requests... https://tools.ietf.org/html/rfc4443#section-3.1 = One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. Most implementations I'm aware of now implement this. >> I am not convinced there is justification that this document should = recommend /127 for "security reasons". >=20 > Besides ping-pong, there's NCE. While I do agree that the real = solution > to the above two issues is *not* to use a /127, this document being an > operational one, I can see why the authors may want to recommend /127. Neighbour cache exhaustion has to be mitigated anyway. On router-router links that's a relatively simple problem compared to = links with hosts. I'm still not convinced that /127 should be recommended over any of the = other addressing models for router to router links. /64, link-local only, /128s. >> Section 2.2: >> I am not sure that extension headers are one of the most critical = differentiators between IPv4 and IPv6. IPv4 had variable length = options... >=20 > The packet structure does make a big difference. For instance, it's > trivial to find (in IPv4-based packets) the upper layer protocol type > and protocol header, while in IPv6 it actually isn't. It isn't supposed to be. >> Section 2.3.2: >> Consider Secure DHCPv6? >=20 > Question: is that doable? (i.e., widely supported) You expect this document to have a short lifetime? (Which I guess is the exact problem of publishing this type of advice as = an IETF RFC). >> Section 3.1: >> In general update references. e.g. ipv6-eh-filtering is outdated. >> I question referencing opsec-ipv6-eh-filtering. It has wrong and = outdated advice. E.g. on section of HBH header. >> The advice in ipv6-eh-filtering is essentially to ossify the network. >=20 > Have you read the I-D? Because the I-D boils down to: "pass all EHs > unless they are known to be very harmdful". Hmm, I see the latest opsec version has put this right, thanks. I must have read the earlier individual draft, cause that said "should = drop HBH". Best regards, Ole --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 18 Apr 2017, at 13:10, Fernando = Gont <fgont@si6networks.com> wrote:

On 04/18/2017 09:18 AM, otroan@employees.org wrote:
A few initial comments. Draft is not quite = ready.

Section 2.1.3:
6164 = does not _recommend_ /127 it _permits_ /127 on p2p links.

Agreed on this.


The ping = pong attack is mitigated in RFC4443.

I must be missing something.. what does RFC4443 have to do = with this? A
ping pong attack does not require the attack = packets to be ICMPv6 echo
requests...

https://tools.ietf.org/html/rfc4443#section-3.1
  One specific = case in which a Destination Unreachable message is sent
  with a code 3 is = in response to a packet received by a router from a
  point-to-point = link, destined to an address within a subnet assigned
  to that same = link (other than one of the receiving router's own
  addresses). =  In such a case, the packet MUST NOT be forwarded back
  onto the arrival = link.

Most implementations I'm aware of now implement = this.

I am not convinced there is justification that this document = should recommend /127 for "security reasons".

Besides ping-pong, there's NCE. = While I do agree that the real solution
to the above two = issues is *not* to use a /127, this document being an
operational one, I can see why the authors may want to = recommend /127.

Neighbour cache exhaustion has to be mitigated = anyway.
On router-router links = that's a relatively simple problem compared to links with = hosts.
I'm still not convinced that = /127 should be recommended over any of the other addressing models for = router to router links.
/64, link-local only, /128s.

Section 2.2:
I am not sure that extension headers are one of the most = critical differentiators between IPv4 and IPv6. IPv4 had variable length = options...

The packet = structure does make a big difference. For instance, it's
trivial to find (in IPv4-based packets) the upper layer = protocol type
and protocol header, while in IPv6 it = actually isn't.

It isn't supposed to be.

Section 2.3.2:
Consider Secure DHCPv6?

Question: is that doable? (i.e., widely supported)

You expect this document to = have a short lifetime?
(Which I guess is the exact problem of publishing this = type of advice as an IETF RFC).

Section 3.1:
In general update references. e.g. ipv6-eh-filtering is = outdated.
I question referencing opsec-ipv6-eh-filtering. = It has wrong and outdated advice. E.g. on section of HBH header.
The advice in ipv6-eh-filtering is essentially to ossify the = network.

Have you read the = I-D? Because the I-D boils down to: "pass all EHs
unless = they are known to be very harmdful".

Hmm, I see the latest opsec = version has put this right, thanks.
I must have read the earlier individual draft, cause = that said "should drop HBH".

Best regards,
Ole= --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C-- --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9fwsAAoJEL7aWKiYQt925cQP/0VXnKmWVBwsBsv4TG6QeGWA Ro+pucXspLl6nwv5QZKYtuGOSe13QzrQFo/lBN7bh5MV6YCfTxdxTvSUFBfb3Cms 2xtye4MyZppKNXLwjnPd57kapsPLpm2YGPG545F6Ccmy88YcnySlMxlSSSwbmYt8 52fpfV+wPEjR9kCO65MzUAyv0yXBv6aG5O3n64PMuTVSzik8ZijwH8Vh2ZfixAEz 0W1bgqxTCtf3GU2Sxx+5cenhhxt9dTbyKgA8hiwbQjikW2zzKdFYHAwuBJbWT+sQ Omudl8eQm6zGJxx3OlxP2hCTDI1v8GFUBX0zyTNPPO/jUWqpmzTxSXcFd8lP10j+ lY5v0RmsdytE8FsPiDpMOorT2qsuz2nS3zyKGErwSBjodcmf27h2c9ZqGKxosqFM GG51DbR4cvuyV6WxoDtOALvpMEZutwiR0JdBSG22hCoJX8KDz0p9TddzEux8pc5l APwpEHa9uh1sZ9sgCdncYQrgQBJOpfoALJIGC2OcEQeMEH6UM8npLueppvB1J/ul F612k+xluMFHj6XrYMLhRfTEoo2Qi6w/R7nnIn7XNQf5qas89TzrCQivq0Tj0Ur5 MdzUo/IEqpvKNSIczJUmgp779bX6/xpljy1Td7GbBtwjusWcs3KxazmWJPFc4itH HTmkfsaUzZk/P0ed9b0F =1jo3 -----END PGP SIGNATURE----- --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC-- From nobody Tue Apr 18 05:03: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 AB5C01204DA; Tue, 18 Apr 2017 05:03:38 -0700 (PDT) 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, HK_RANDOM_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 zza2UiP5fj93; Tue, 18 Apr 2017 05:03:32 -0700 (PDT) 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 8B33A12EB3A; Tue, 18 Apr 2017 05:03:32 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id q78so43456704vke.3; Tue, 18 Apr 2017 05:03:32 -0700 (PDT) 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=NPKEny7QXgzG7tZ3DhNn+ztgj4AxLdybqMGCs0mSszg=; b=I7qLpUPT0fi0ebuEHkcmjzxNCguJj8uUNnICaulIjFysiyhPaGrWbtH2w3tm/299Rw Tyfasu8z44xsB+vjBFsCiJKIZbL6gw54G2ES83DW4zmmgp0kWbSF+kxTLIle9AmA0tJi NIk8K2cc78UNH8se9cUERBsV/ZXCZbgeVIokYvfpxEUyP8qdcSPt8ObXWOqLNTOEude8 Y0cXXv302hIvHVrj3eebeEI1M9c2n3EoT6F6GsVHuWVPDMNjoCttoXBo2ipm3DkMVp7H nFRFZRQA+GEs4x/Qaz6jVAZUJv+r9KXKshS3bIEJpRZJ7YFQ1Va14U51fdg/GmxsxqVq PgCQ== 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=NPKEny7QXgzG7tZ3DhNn+ztgj4AxLdybqMGCs0mSszg=; b=sx2dJEjKiEpPmZ2fzV6b3OEliNTgaQgi2u0EiXOXxoR4ugTpdzbHb5I/CAnlDqM1Rb g0nUF2P4t6bBfRun3RsJY5w6Dq7SYSjRq4uDIPSBH7OLjYo/9OdSwF2YXcOSOkhJI9+v pqJQWotbGOSLWjcMxXN6C9zSMGyeniZAibJdIHpTC8fqViMxJ+PJjYFK9acEjzwXDezg +9qZV9FrNHsDz27C42pv416h5ZHWa7intonRc0EA0V/ON3arwovwN67ZDh2zXOle4p6U 0KJTDuObjiCz4PB9wb96U9Zt5RswpQal1zKGTqN9THmbHKCD+fC1WH3rVGTQysI1PBAh 1xRw== X-Gm-Message-State: AN3rC/5cxpC3ar+H4nnqg2kEE/o/fl4Ax7zhMcrEKtMpJtT14dpboxBV 67stk9KLHCCeK7GC/AiwaIh6wXXrhg== X-Received: by 10.31.60.65 with SMTP id j62mr8230097vka.25.1492517011513; Tue, 18 Apr 2017 05:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 18 Apr 2017 05:03:01 -0700 (PDT) In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> From: Mark Smith Date: Tue, 18 Apr 2017 22:03:01 +1000 Message-ID: To: Fernando Gont Cc: Ole Troan , opsec@ietf.ortg, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 12:03:39 -0000 On 18 April 2017 at 21:10, Fernando Gont wrote: > On 04/18/2017 09:18 AM, otroan@employees.org wrote: >> A few initial comments. Draft is not quite ready. >> >> Section 2.1.3: >> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. > > Agreed on this. > > >> The ping pong attack is mitigated in RFC4443. > > I must be missing something.. what does RFC4443 have to do with this? A > ping pong attack does not require the attack packets to be ICMPv6 echo > requests... > "One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link." > >> I am not convinced there is justification that this document should recommend /127 for "security reasons". > > Besides ping-pong, there's NCE. While I do agree that the real solution > to the above two issues is *not* to use a /127, this document being an > operational one, I can see why the authors may want to recommend /127. > > However, there aren't many places to hide IIDs in a /127. It's likely the operator (being humans) will assign /127s sequentially. If an attacker finds one, they'll easily find the IIDs in it, and find the IIDs in all of the adjacent ones. A TCP SYN attack on the BGP process becomes easy. GTSM mitigates this, however if the router interface IID can't be easily discovered (c.f., RFC7217), then the attacker can't send malicious packets to the device in the first place. The advice should be something like choose a /64 or shorter in the addressing plan for for /127 assignment, and then to randomly assign (using a computer or dice!) /127s from within it. Alternatively, have /64s on the inter-router links, RFC7217 IIDs on their interfaces, and then have edge ACLs only permit packets to these addresses and drop packets to all other ones within the /64. It also should be pointed out that address scopes limit the severity of the threat. It's unlikely that /127s are needed from the ULA address space, as the threat of ND cache attacks is likely to be a lot lower because hosts and their end-users that can successfully send packets to ULA addresses are going to be more trusted to not launch an ND cache attack - they have a vested interest in the network staying available. Regards, Mark. From nobody Tue Apr 18 06:11: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 6CDAB12EBBB; Tue, 18 Apr 2017 06:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 giy4j33YWZqD; Tue, 18 Apr 2017 06:11:33 -0700 (PDT) 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 DA0951274D0; Tue, 18 Apr 2017 06:11:32 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 D9ADB80D2A; Tue, 18 Apr 2017 15:11:30 +0200 (CEST) To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Date: Tue, 18 Apr 2017 13:12:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:11:35 -0000 Hi, Ole, On 04/18/2017 12:44 PM, otroan@employees.org wrote: >>> The ping pong attack is mitigated in RFC4443. >> >> I must be missing something.. what does RFC4443 have to do with this? A >> ping pong attack does not require the attack packets to be ICMPv6 echo >> requests... > > https://tools.ietf.org/html/rfc4443#section-3.1 > One specific case in which a Destination Unreachable message is sent > with a code 3 is in response to a packet received by a router from a > point-to-point link, destined to an address within a subnet assigned > to that same link (other than one of the receiving router's own > addresses). In such a case, the packet MUST NOT be forwarded back > onto the arrival link. > > Most implementations I'm aware of now implement this. Why wouldn't an attacker send *any* packet meant for the p2p link, but that not correspond to the address of any of the two endpoints? i.e., I don't see the need to focus on a specific kind of packet... I guess I'm missing something? >>> I am not convinced there is justification that this document should >>> recommend /127 for "security reasons". >> >> Besides ping-pong, there's NCE. While I do agree that the real solution >> to the above two issues is *not* to use a /127, this document being an >> operational one, I can see why the authors may want to recommend /127. > > Neighbour cache exhaustion has to be mitigated anyway. > On router-router links that's a relatively simple problem compared to > links with hosts. > I'm still not convinced that /127 should be recommended over any of the > other addressing models for router to router links. > /64, link-local only, /128s. How do you mitigate it when the implementation does not limit the number of NC entries? (i.e., operationally) >>> Section 2.2: >>> I am not sure that extension headers are one of the most critical >>> differentiators between IPv4 and IPv6. IPv4 had variable length >>> options... >> >> The packet structure does make a big difference. For instance, it's >> trivial to find (in IPv4-based packets) the upper layer protocol type >> and protocol header, while in IPv6 it actually isn't. > > It isn't supposed to be. Which for people running networks translates to "broken by design". >>> Section 2.3.2: >>> Consider Secure DHCPv6? >> >> Question: is that doable? (i.e., widely supported) > > You expect this document to have a short lifetime? > (Which I guess is the exact problem of publishing this type of advice as > an IETF RFC). I didn't even think about the lifetime. But I wouldn't suggest a mitigation that isn't doable at the time of publication. If Secure DHCPv6 is not widely implemented, this would be like saying "secure ND with SEND" ("yeah... in your dreams!"). FWIW, I do support this document. I think it contains valuable and much needed information. >>> Section 3.1: >>> In general update references. e.g. ipv6-eh-filtering is outdated. >>> I question referencing opsec-ipv6-eh-filtering. It has wrong and >>> outdated advice. E.g. on section of HBH header. >>> The advice in ipv6-eh-filtering is essentially to ossify the network. >> >> Have you read the I-D? Because the I-D boils down to: "pass all EHs >> unless they are known to be very harmdful". > > Hmm, I see the latest opsec version has put this right, thanks. > I must have read the earlier individual draft, cause that said "should > drop HBH". We've certainly been improving th document as part of the process. Thanks! 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 Apr 18 06:15: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 14D4512EBD5; Tue, 18 Apr 2017 06:15:40 -0700 (PDT) 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=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 6RIgZyp2WSJS; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A553412EB9C; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 13:15:38 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2D5EFD788D; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=VRRaZZt47pYL+C8HqUQlxUV+4A8=; b= qRofvgPqgmbdeHJuLshgb/LHYBH/DXLNyrnfWVC60DDcV27OzBZGGVqtBpxMuv+M GpXYLa9Cz/Cf78DRI+oG/DqvTaAkru9qtqIpb2/hvBPbN85mpPNhi5AThQQCvzbc KPt8yDDV317sZeQmhTObSZ7s2bYcP1VWe3mcIXxhdMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=GmL5CuWPXegXUNSl0kbxp7N 3xYNN5yOBZGJk7hS1gxapPYRbzisYF6K1k0ORqagxlroaIb6RSnAMiCOkIL0qxVJ qoaMWeRuYkux1rM3/b13aUO2yUgNPtJnD44d5KHJUgZQ8mLA6ugOpRLk3NxUWibE NL9f3xxlK2eQKFU4evI0= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 0187DD788B; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7383CAA599EB; Tue, 18 Apr 2017 15:15:36 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 15:15:35 +0200 In-Reply-To: <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:15:40 -0000 --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fernando, >>>> The ping pong attack is mitigated in RFC4443. >>>=20 >>> I must be missing something.. what does RFC4443 have to do with = this? A >>> ping pong attack does not require the attack packets to be ICMPv6 = echo >>> requests... >>=20 >> https://tools.ietf.org/html/rfc4443#section-3.1 >> One specific case in which a Destination Unreachable message is sent >> with a code 3 is in response to a packet received by a router from a >> point-to-point link, destined to an address within a subnet assigned >> to that same link (other than one of the receiving router's own >> addresses). In such a case, the packet MUST NOT be forwarded back >> onto the arrival link. >>=20 >> Most implementations I'm aware of now implement this. >=20 > Why wouldn't an attacker send *any* packet meant for the p2p link, but > that not correspond to the address of any of the two endpoints? >=20 > i.e., I don't see the need to focus on a specific kind of packet... I > guess I'm missing something? Yes, you are missing something. RFC4443 specifies what behaviour should be if a router receives a packet = on a point to point link that would end up being forwarded back out the = same link. The specified behaviour is drop and send destination = unreachable. That solves the problem for any packet obviously. And any prefix length = assigned to the link. Cheers, Ole --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9hF3AAoJEL7aWKiYQt92qK0P/jzKw4Kw6gaw/J06uvjnuGLP yCa0NQOhIW92Txx4YXNkbP/6YpAdiPNkxfFoDva6FUmSkKPZ05EgQhKH/bdfo/2g BoQgs8WjDidVnk2YApf69UJ2gUD2VNVYai7eOIrVwdmdF9EXLadGKHXR5JTum9VT gSR8iuyhbtF2QqT2ZU14Yq1a05to61FmdPN0gX9knqCvsyag9phEQV8H2CUta/kn XrnqKHQM9KohvX3YhdmpsB95slFRePfDZfNobm2bPxGoWwAuqpP5Cr5GCQGBceYA OPRjFqkxb9fNYeDYKbRLJUWlcPfe3RMe63XVYryr2vMmFVrsgJCp/0k4mqPiHlwv dO2YLUwzelaiUDWWzDwKC11PK2fphIXmWuPe8KYqtcGMRrXwdQoDnDKw4TZydfqG cBKtxY9t2lQKOoPiGn888fPW24jPNiVk/ks9pf1alvfO99GnNWBjjWgYEljpy9dZ nPdwH1ZYOFaiJ86gK9f82QSz7/BWS/uWUIk66tRicQ9Z3YE5BcqtceyjxhPAegCu p+LaKbqAQWnKJGyXpSfCy7bJDSCCkFupu2std99JTPhqoquzvdG4VGiaBsr1LAVE zuSK3MJxeGuzoxqDGg3TT6Exj3Q+NWSOIAqO3Z3cxvUGc/0RygYcTJ/0Ljzdi8LL 9ZKMWpNJNryByg2WGPSC =w9er -----END PGP SIGNATURE----- --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4-- From nobody Tue Apr 18 06:27: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 07D2912EBFD; Tue, 18 Apr 2017 06:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 j6afuF0QdKh0; Tue, 18 Apr 2017 06:27:34 -0700 (PDT) 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 2245D12EBFB; Tue, 18 Apr 2017 06:27:34 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 48AC68013E; Tue, 18 Apr 2017 15:27:32 +0200 (CEST) To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Date: Tue, 18 Apr 2017 14:27:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:27:40 -0000 On 04/18/2017 02:15 PM, otroan@employees.org wrote: > Fernando, > >>>>> The ping pong attack is mitigated in RFC4443. >>>> >>>> I must be missing something.. what does RFC4443 have to do with >>>> this? A ping pong attack does not require the attack packets to >>>> be ICMPv6 echo requests... >>> >>> https://tools.ietf.org/html/rfc4443#section-3.1 One specific case >>> in which a Destination Unreachable message is sent with a code 3 >>> is in response to a packet received by a router from a >>> point-to-point link, destined to an address within a subnet >>> assigned to that same link (other than one of the receiving >>> router's own addresses). In such a case, the packet MUST NOT be >>> forwarded back onto the arrival link. >>> >>> Most implementations I'm aware of now implement this. >> >> Why wouldn't an attacker send *any* packet meant for the p2p link, >> but that not correspond to the address of any of the two >> endpoints? >> >> i.e., I don't see the need to focus on a specific kind of packet... >> I guess I'm missing something? > > Yes, you are missing something. RFC4443 specifies what behaviour > should be if a router receives a packet on a point to point link that > would end up being forwarded back out the same link. The specified > behaviour is drop and send destination unreachable. That solves the > problem for any packet obviously. And any prefix length assigned to > the link. How could RFC4443 possibly address this for all packets without formally updating RFC2460? P.S.: For a specification pov, this shouldn't be buried in RFC4443, and, as noted, no matter where this "patch" is specified, such doc should certainly update RFC2460. Thanks! 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 Apr 18 06:31: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 CD665129453; Tue, 18 Apr 2017 06:31:20 -0700 (PDT) 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=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 I6l-0-hm_RvI; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 448B4127866; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 13:31:19 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 05262D788D; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=Y2KtCjM84UDsyN4JUvzhwk2HKyM=; b= THcf0psYM5eTzk/HoyHztlsP47niUb+KbWjaEmH7PvTm/HGvFpOKrTcMVdeBjFb+ d26UxTOjmcanUjZ3poqPXKAYHmcIPBuNvfF6ubS2H1HCXqCxgF3zWr+ipZP9EMBb Og3YMMcrva7L3oHdg1IS7i3LVD3Ui7CSulFlCNzpMss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=UFfxg+UuDTAwQCiFkQvrXkd hK2JJFvJrNHzw2wNtx7gKEz3bk1BPIkPEdQi63zNAMKR1RzVNBEdxPHMsjKfQ7JS 5t3k90VBZ8njWHQsZqTYQGIGJdN7R6o2zKN1dd7ktOjvdQKLKWL3zK42YBRr4vl0 lyE3wDazOiOPCS+tXSZ8= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 8BE8ED788E; Tue, 18 Apr 2017 06:31:18 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0CF52AA5DDE1; Tue, 18 Apr 2017 15:31:17 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 15:31:16 +0200 In-Reply-To: <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:31:21 -0000 --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>>>>> The ping pong attack is mitigated in RFC4443. >>>>>=20 >>>>> I must be missing something.. what does RFC4443 have to do with >>>>> this? A ping pong attack does not require the attack packets to >>>>> be ICMPv6 echo requests... >>>>=20 >>>> https://tools.ietf.org/html/rfc4443#section-3.1 One specific case >>>> in which a Destination Unreachable message is sent with a code 3 >>>> is in response to a packet received by a router from a >>>> point-to-point link, destined to an address within a subnet >>>> assigned to that same link (other than one of the receiving >>>> router's own addresses). In such a case, the packet MUST NOT be >>>> forwarded back onto the arrival link. >>>>=20 >>>> Most implementations I'm aware of now implement this. >>>=20 >>> Why wouldn't an attacker send *any* packet meant for the p2p link, >>> but that not correspond to the address of any of the two >>> endpoints? >>>=20 >>> i.e., I don't see the need to focus on a specific kind of packet... >>> I guess I'm missing something? >>=20 >> Yes, you are missing something. RFC4443 specifies what behaviour >> should be if a router receives a packet on a point to point link that >> would end up being forwarded back out the same link. The specified >> behaviour is drop and send destination unreachable. That solves the >> problem for any packet obviously. And any prefix length assigned to >> the link. >=20 > How could RFC4443 possibly address this for all packets without = formally > updating RFC2460? >=20 > P.S.: For a specification pov, this shouldn't be buried in RFC4443, = and, > as noted, no matter where this "patch" is specified, such doc should > certainly update RFC2460. You will probably save everyone a lot of energy if you just admit you = had missed it, and moved on. Ole --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9hUkAAoJEL7aWKiYQt92OZgP/i/uokmPW9y4T3dsmjjJkrpE sNjL2XvmUUnEFf9cULpgJMem0Xw6JmsLrehafvsfffAhLHZIYvL+qA8TIRdSFSJ3 TnSGyPIeIaTBNKAggQzCuqnfRsEuRZFxpB1zq878Q6RFwiwpOljxeOX4SdE8vI7r fbjxk94YigsO1fA7qMW69nsbZkZF7aAdnY7oP3+BF0aUZQEamxTshCb1DgpbfI62 KKSDqMHxmlBEvzCYBLohw8RdAkMjRUqnHaoPrpVV/fswwOLfGunGIP3O/LVZJWfX OJH6LNnBptqcwHpz6acxOnstgTR2+xqfpa+etviiQsZCjoW1jl8OlBmQvtqEwmb0 N2kT4N1ebyv4kLzVV239kbPJAHPRoTBs67eZ2AiXaDiFGsaDO4edpXJFc4+0b+Li PW9LZRQToYg5j6MVXhcakG8Ajt56rnWtE+AuWbgFzMru1wmc900jA7kXPMyYrq6l NRBJICP0FEkP1/emHuCUbZBEuPWMnu5rbqONWQswpweHnhS2HfFWtpqZaTOZzHdI Ff3oWteQjBXhlq1dY/Mqw6BQ4LTV6oxSQCFJrv5T8VyLNgWIc7MeSwlRiz5K26vw zmK1pT7Zk8CFfiKopmbrKk9naBAy14nN1XNZ5PavGegU0xEPW/dF/TVttUbG8oTu UKlfZ+XOoi8kGKTcxG1l =MlFa -----END PGP SIGNATURE----- --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2-- From nobody Tue Apr 18 07:39: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 A8EE5131883; Tue, 18 Apr 2017 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 xS2ToyMvilZO; Tue, 18 Apr 2017 07:39:21 -0700 (PDT) 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 ABA881317D0; Tue, 18 Apr 2017 07:39:21 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 3EF9C80890; Tue, 18 Apr 2017 16:39:19 +0200 (CEST) To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 18 Apr 2017 15:15:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 14:39:24 -0000 On 04/18/2017 02:31 PM, otroan@employees.org wrote: >>> >>> Yes, you are missing something. RFC4443 specifies what behaviour >>> should be if a router receives a packet on a point to point link that >>> would end up being forwarded back out the same link. The specified >>> behaviour is drop and send destination unreachable. That solves the >>> problem for any packet obviously. And any prefix length assigned to >>> the link. >> >> How could RFC4443 possibly address this for all packets without formally >> updating RFC2460? >> >> P.S.: For a specification pov, this shouldn't be buried in RFC4443, and, >> as noted, no matter where this "patch" is specified, such doc should >> certainly update RFC2460. > > You will probably save everyone a lot of energy if you just admit you had missed it, and moved on. Huh? I obviously missed it. But this should still be in RFC2460 (or rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding for IPv6 packets. Having important requirements spread into a number of documents where they don't belong doesn't help, and in the long run takes more energy (and creates more problems) than spending the energy in doing what is right. 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 Apr 18 11:04: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 E9EE6127BA3 for ; Tue, 18 Apr 2017 11:04:28 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 GThDmFZKU-hJ for ; Tue, 18 Apr 2017 11:04:27 -0700 (PDT) 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 4FF6612EABC for ; Tue, 18 Apr 2017 11:04:27 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id a188so285276pfa.0 for ; Tue, 18 Apr 2017 11:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=hwJemLzdWz9v36Gz2mI71j2uCh0hN8y+bPxVtn8radM=; b=vSSFOba8J/hFpeQyutcziXkqSZHRKukzCf8PaXTcATb8rVni1GsAROg2lhLCd+0lEL jN6JQCzt6Vaj+P27Qwy1XQqJeEh1741YSAvaxESO+9F4rZX9ayDkyPGdB9BQV3CU+zE8 /yE+3gIeGSnOcRytEsNz+GLjWpL6a7DZx4/K6upivrlgj5gw1Sc9spgUwYXP1Su+rqxb l00oCdVIa9c8G+c0yB0Y+UvXizXk0A4rw3F9bQOjALqR5B+LAhYi36UDDZjbZw0sR5Ec hAEQSht1QztQcoLFc3w5do69M99HhUVM85Yz67/2xuh34AIxUWePnl7PC7lHv87b5762 2ARQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=hwJemLzdWz9v36Gz2mI71j2uCh0hN8y+bPxVtn8radM=; b=jfPHxEo0JBbmJ2KWbOxpBKenQ4zdJk7yM5U3Uluq5PlTXjO15uSdpeY+rfx4R8zZ59 dcQ54LohIAogQpTnIpe6yNn+9cX80cOzSFSxCsk9IQEapKKxvmQ57tsPsP4GYWaeyhKI nMR8HwGG/s4yQmX/MAidkzKAfYoQaqnv4Uertk47Ja03D5t8++F9nBcHKVK12YEUstxl tPS6oIOYS1eKszET5vmNOzmrjuXIwTr/stlfcJbZnBo6Rr2zwl+YnqiGgrLX43PP8vXo vJRJ/IJtZI97b1UzKHLu4+JKL2PlL+7RFDWA0n4lZxYVR5nI9dlWYxEVR9SRQ0VP7b+G ZiFA== X-Gm-Message-State: AN3rC/5M6QEnFHgln22Ur9o7mMWH0FxYlKzenYnrbnLE4OifToXbsYtH bmoSqgXKknGTzVWEfzTf8Q== X-Received: by 10.98.12.134 with SMTP id 6mr19829721pfm.66.1492538666565; Tue, 18 Apr 2017 11:04:26 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:2935:f4b2:cc20:d9a9? ([2620:0:10e7:10:2935:f4b2:cc20:d9a9]) by smtp.gmail.com with ESMTPSA id m4sm25438514pgm.25.2017.04.18.11.04.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 11:04:26 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_609B8D8D-F290-46B3-B6FE-EEC34259A494" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 11:04:29 -0700 References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: "v6ops@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Message-Id: <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:04:29 -0000 --Apple-Mail=_609B8D8D-F290-46B3-B6FE-EEC34259A494 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 18, 2017, at 00:08, mohamed.boucadair@orange.com wrote: > =20 > How obsoleting RFC7084 will be different (better?) for homenet vs = updating it? Homenet-related requirements will be at best listed as = SHOULD in a obsoleted/updated documents.=20 > =20 > I like the idea of an update because I allows operators to easily = scope their requirements to their particular context. =20 Let me come at this from a slightly different angle=E2=80=A6 if the only = community of interest for this document are the operators of internet = service distribution networks, and the interests of application = developers and consumer-oriented host operating system developers are = not to be given any consideration, then why is it even necessary for = IETF to be involved? Shouldn=E2=80=99t this work be handed off to some = industry consortium, e.g. BBF or CableLabs? I=E2=80=99m beginning to think I should just object on general principle = to publishing this document. Perhaps it would be better to advocate = moving RFC 7084 to Historical. --james woodyatt > --Apple-Mail=_609B8D8D-F290-46B3-B6FE-EEC34259A494 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 18, 2017, at 00:08, mohamed.boucadair@orange.com wrote:
 
How obsoleting RFC7084 will be = different (better?) for homenet vs updating it? Homenet-related = requirements will be at best listed as SHOULD in a obsoleted/updated = documents. 
 
I like the idea of an update = because I allows operators to easily scope their requirements to their = particular context.  

Let me come at this from a slightly different = angle=E2=80=A6 if the only community of interest for this document are = the operators of internet service distribution networks, and the = interests of application developers and consumer-oriented host operating = system developers are not to be given any consideration, then why is it = even necessary for IETF to be involved? Shouldn=E2=80=99t this work be = handed off to some industry consortium, e.g. BBF or = CableLabs?

I=E2=80=99m beginning to = think I should just object on general principle to publishing this = document. Perhaps it would be better to advocate moving RFC 7084 to = Historical.


=
--james woodyatt <jhw@google.com>



= --Apple-Mail=_609B8D8D-F290-46B3-B6FE-EEC34259A494-- From nobody Tue Apr 18 12:32: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 F029A1293D9 for ; Tue, 18 Apr 2017 12:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ATLtbGgZBhsF for ; Tue, 18 Apr 2017 12:32:12 -0700 (PDT) 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 6B9A0127869 for ; Tue, 18 Apr 2017 12:32:12 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id c198so1222047pfc.1 for ; Tue, 18 Apr 2017 12:32:12 -0700 (PDT) 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=lHaN8rUwELfEuY+RTvnTAggG2ZEQDvNztjQYj0Z791k=; b=pdr4w1Qxo45Y8wR3zJelM+hEgaPS3pniz6y5eEJ521XARZAd1t44HUqt19/dByBZBW WrqlcsQhEZiKgyarUWiWQxXxfwWkW/llssutYfoqMJAjwZGY7lMeJ4Pr8CPW8i7ZcuvD SWUKyN5M8ZLmyWwWGeKAPS5uw0X9K5lU5pmWt/3bv3onEbz5Lg6NlLWOjyQwMx7niWFP 4g3ivqsAlovixTnCvc51l0ALnlgLvIh/ansavuxeU38alk7iImHsPy/RFOD4Bk5Acu/Q Jb1ocT8EVzDHSG3dR/QePTO6Oh8EqaoxEO7JWmin/6NnERtezqXNnTpPBdlb7Y5Kbra6 xoaA== 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=lHaN8rUwELfEuY+RTvnTAggG2ZEQDvNztjQYj0Z791k=; b=RWrGURnKP7wMfENi5yN0T3qLksI87IS50NPHNzmXG899lBJ20SM37t38YE3yJGnwEd U3b69dl5fqh6jzJ9mKK0LegP7QDwmN5cBHT7ddIAqaiYCey+CxBmzkoZnvJ8ve0+DEIq FudGDPDAXMPssb873Q/u4QMXngzQUsl4vxl47+R41t4O40XpTJH+29jL85fnwsHs3XZb oxJM2V3sg2mMHS9wCiGlujp1C2s7QI5NsWGBrMTndOcs2+fpSnEHkDZ+gBdIF5RrC0Qj d/2lfoltB41G5ZU7n+axaR+glCIUN4fPWcaPSeg53e9ujSgTumpo+nZlEGNZN5kxBdmZ VyiQ== X-Gm-Message-State: AN3rC/4oIUCvpcid6bCO5+P/P7uZF7QdGKhdW8IaTjpYb8IS6+eXvrw3 gQSsq896yMxwqK2yyy0= X-Received: by 10.84.217.67 with SMTP id e3mr25410147plj.108.1492543931996; Tue, 18 Apr 2017 12:32:11 -0700 (PDT) Received: from [192.168.1.13] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id q5sm75441pgn.59.2017.04.18.12.32.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 12:32:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Tue, 18 Apr 2017 12:32:10 -0700 Cc: "v6ops@ietf.org Operations" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <20170418000956.BCACF6B86628@rock.dv.isc.org> To: Simon Hobson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:32:14 -0000 On Apr 18, 2017, at 4:01 AM, Simon Hobson = wrote: > Bear in mind that ISPs are mostly still getting to grips with a whole = change in manglement mindset about IPv6 - that much is clear from the = discussions about prefix lengths and how some ISPs are still treating = addresses as "scarce" like they do with IPv4. Again, no hats. I have had an idea, which I'd like to validate or have invalidated, that = a primary reason people don't implement reverse DNS in IPv6 is that = they're not sure how. In IPv4, it has been pretty straightforward: = either they have names for all of the addresses they would respond to, = or they implement one for the prefix that has a default name for any = addresses they didn't have names for, or maybe they figure out how to = create a name for the unused addresses - they are able to implement it = as a (potentially large) database of individual names. In IPv6, almost = all addresses (if I have 1000 IIDs in a /64, I still have = 18,446,744,073,709,550,616 addresses) fall into the default category, = and as a result they need a layered strategy - they look up the actual = address, and it that fails, back off to a name-per-prefix.=20 If they don't see people asking for it, they don't see much impetus to = implement anything. In separate news, I asked someone who might know about email use of = IPv6. The statement I got back (which I'm not allowed to quote or = attribute) said that they weren't sure of their methodology, but if it = was correct, a vanishingly small subset of emails use it. In that, I = wonder about chickens and eggs. If information security policy requires = reverse DNS validation (which in IPv4 it usually does) and there is no = way to do it, does that mean that the sender chooses to use IPv4? Or is = it the other way around - that folks prefer IPv4, perhaps because their = mail systems do, or their mail systems are not yet IPv6-capable or on = IPv6 networks? I know when CERNET started mailing lists for SAVI = discussion, the servers were IPv6-only, and that didn't work so well.= From nobody Tue Apr 18 13:12: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 49BC312EABC for ; Tue, 18 Apr 2017 13:12:49 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 7DZYARejfbzp for ; Tue, 18 Apr 2017 13:12:47 -0700 (PDT) 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 B635E1293D9 for ; Tue, 18 Apr 2017 13:12:47 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id c198so1647576pfc.1 for ; Tue, 18 Apr 2017 13:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=guKWZ+ToDKxo8xE6c3bMnhyuiKiljLnrZYDymH054ic=; b=OMdldgBsNNeXCyx65fqSDl91jdjGgbUa36A+clye6rhuLLQGIifuD4fQcxmQwLKFMp qVZ6t5OGB9X/dd67O59PvGEIhn7eirTnyUth6RUGoiz3+vdZElbZWGBs7fnRcJhO6DHi VwY6Hw1SYOSuFOIWihXqwT2ikFdw10eP5MT9QsPwM4h+nX6PZd1O+J/pqnHhx7IQufEn vfw9lmWIBCl32USlruKtMhl6BExm1Ou+GraQV4tjYLRQxFudUC2B+j6xukg/JnfYvwn1 c3d8t90001y2rzpiLLn7DgEO2cL+VpTdNpLEfXUhN8TKKXxFc0rf2kh+LjiYh+Tiia3f mz/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=guKWZ+ToDKxo8xE6c3bMnhyuiKiljLnrZYDymH054ic=; b=mpmMV08wBP0TZDqqI5GYZXIQzwdLcEnCKx9TQzJxFc0Wawq1RJeLdCGMKi0lRbDJ6+ 0N9SRmAhU9FyBThytMCwin3Qj3kEXxnLqCL00R3zMBKJhhiEJgQHY0hUxnHI94aBudMC cIS68eS0Dl8Buo9rtvqwmIob6sJO69ptr2LiIRX0cn+mwBrn/MxxV265zBY1UtFdH1HU 6fnAyHUJdpynVX4Wmf5anElAU00CJMQZ10ughscZIMCzyTCoa6PpeQsd/cY9kwmAgqTL 3do0Rgc6HCFt4rFmRjmYF7fxGc4pf1N/duyHAVG5DrxPPtvRjoc37GOONTn2ePsLgEMg ClZw== X-Gm-Message-State: AN3rC/5RYxma107GRLH4DmZdCHpyRNfr7k6j0YabRN4WCN9pzh4ndmDO GparBfVqly23NWS7qyrizw== X-Received: by 10.99.8.67 with SMTP id 64mr19824457pgi.220.1492546367063; Tue, 18 Apr 2017 13:12:47 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:2935:f4b2:cc20:d9a9? ([2620:0:10e7:10:2935:f4b2:cc20:d9a9]) by smtp.gmail.com with ESMTPSA id y28sm190616pfk.16.2017.04.18.13.12.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 13:12:46 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_830187E8-C2A9-488C-ACFA-8B90742C80F5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 13:12:45 -0700 References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "v6ops@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:12:49 -0000 --Apple-Mail=_830187E8-C2A9-488C-ACFA-8B90742C80F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 18, 2017, at 11:48, STARK, BARBARA H wrote: >=20 > [=E2=80=A6] I do think that obsoleting RFC7084 with something that is = a shopping list isn't very useful to anyone. I would say it's the opposite of useful. If that=E2=80=99s all this = draft can accomplish when published, then I would argue that it should = be published by somebody other than IETF. If there is any value to IETF = publishing its own guide to the available transition technologies, then = it should not be published as an update to, or an obsoleting of, RFC = 7084. A simple informational category draft as an Independent Submission = is probably a better vehicle. That said, I=E2=80=99m a little saddened that RFC 7084 cannot be revised = to recommend inclusion of the HOMENET protocols. That really does take a = lot of wind out of the case for IPv6 in the home appliance networking = case. --james woodyatt > --Apple-Mail=_830187E8-C2A9-488C-ACFA-8B90742C80F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 18, 2017, at 11:48, STARK, BARBARA H <bs7652@att.com> = wrote:

[=E2=80=A6] I do = think that obsoleting RFC7084 with something that is a shopping list = isn't very useful to anyone.

I would say it's the = opposite of useful. If that=E2=80=99s all this draft can accomplish when = published, then I would argue that it should be published by somebody = other than IETF. If there is any value to IETF publishing its own guide = to the available transition technologies, then it should not be = published as an update to, or an obsoleting of, RFC 7084. A simple = informational category draft as an Independent Submission is probably a = better vehicle.

That said, I=E2=80=99m a little saddened that RFC 7084 cannot = be revised to recommend inclusion of the HOMENET protocols. That really = does take a lot of wind out of the case for IPv6 in the home appliance = networking case.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_830187E8-C2A9-488C-ACFA-8B90742C80F5-- From nobody Tue Apr 18 13:18: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 856931293D9 for ; Tue, 18 Apr 2017 13:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 4TwR22MQ8uPn for ; Tue, 18 Apr 2017 13:18:16 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 AE015127876 for ; Tue, 18 Apr 2017 13:18:16 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p68so3901309qke.1 for ; Tue, 18 Apr 2017 13:18:16 -0700 (PDT) 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=T33/a81gZTPmN2agcniUqG56R53Xl3p2WWw0nHrchR4=; b=l8aFWDQGxJ0UFWklqk82RfKRKHDwkTJ09QWInP5GaK44+WFe1CbT7QCFofe51cAdxm TRJ+saeo9lYytogvyDK3V30TFTmw1l05rYn7PC8s/0HMnlskoOZUQIPFcEVMwWsv9iE/ DGQsyJrdH/8bRUSEqISfYyA4xUl9DvzB9g2l/bnGzqiyekeCJiEpLM32nuCcsizfwc7F dixaxtGVU56yy8xF/oGF7If69TYPu4BJvHHexKUbUpQxlK8TEvbYLh5ARiEo5HRJ4bma /zIMWCAwGtx8hXOjebBS3B23UxUZ7VvePSviwnTFWWYPjVk4+Gm0xRqWQuP0/HeyHdyA x+fA== 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=T33/a81gZTPmN2agcniUqG56R53Xl3p2WWw0nHrchR4=; b=d9zUXneXt+QGoHm1yJ7W2qcmdjpgMhhweJtxgJuSXcz11YELX6fs+HQPXhtgx6NY+r 4ck2+lFikzpmFZoHSoCaUbo/+5Y31s/SsdFZCsRYa9wCLoouamKP+3JLvO/lfwx9x/ee fvika1e8t1fQGLe0bIGSMXO78OtmkeSaO7kFlbwkjyiVEyKynmmDJ2tFU1h4mU8hO7pq 5wbaAl9Q/U26M7vdsptJKxgdPmGzKj9UCpSQ6SDtKXabfH3AUuILTye9QldGU6Bd2ReG 6AFo5prW91BVh6BykpKOyzIsY+ZbR/e9LRafYhooSnrUse4ijiqsmNlcCwUVvKLF/8gs yPxg== X-Gm-Message-State: AN3rC/6eThVCBxzubWTa3CHakDShzDU34BVSwibO8YZDoD+qxVtHpdQX PzoUzL4IO/k7e/QQC0OPhU3JUUbz28nG/fs= X-Received: by 10.55.92.71 with SMTP id q68mr14561868qkb.219.1492546695724; Tue, 18 Apr 2017 13:18:15 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Tue, 18 Apr 2017 13:18:15 -0700 (PDT) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 18 Apr 2017 13:18:15 -0700 X-Google-Sender-Auth: yCyna0HLphw-OEZ3k89XmJK5-84 Message-ID: To: Ole Troan Cc: Ted Lemon , Simon Hobson , "v6ops@ietf.org Operations" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:18:18 -0000 At Tue, 18 Apr 2017 08:58:46 +0200, otroan@employees.org wrote: > > You request what you want, the ISP gives you what they are willing to give. If you send a zero for the prefix length, the ISP will give you whatever their default is. > > "you" being the IPv6 CE router. There is really very little way that > CE can know what to request for. Perhaps it could deduce something > from HNCP, but this deployment model is very unlikely. I think this > idea that CE's are going to request what they need and ISP's are > going to adhere to that request seems very far fetched. > > This is an out-of-band negotiation often involving money. In RFC3633 > this is purely a hint and the ISP is certainly not expected to > adhere to it, nor is the client expected to set it with very much > confidence. FWIW, this is basically what I thought when I raised a question on the practicality of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue: https://www.ietf.org/mail-archive/web/dhcwg/current/msg17360.html but at that time I was told that there is a real need for the smartness of the CE router (i.e. PD client) side. I don't remember I heard specifically what it is, though. -- JINMEI, Tatuya From nobody Tue Apr 18 15:50: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 2C1A91314AC for ; Tue, 18 Apr 2017 15:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 WJRpBDuzhgCx for ; Tue, 18 Apr 2017 15:50:44 -0700 (PDT) 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 DD1EB12945D for ; Tue, 18 Apr 2017 15:50:43 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id c198so3158437pfc.1 for ; Tue, 18 Apr 2017 15:50:43 -0700 (PDT) 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=EtI0l3A78ygIIWO7+EOfZyjQpGbiaOw+lLpsphkq4Ds=; b=Zremost0HSigp09jihN7gN5JShsM7Oh2bKhDvQcRssmYKYaGndpbPXopsLtdi8B4OT oxqvkm116hfTPcnouZ5lQ8K9qy57CA2R6QxubP7SMM1BFDkXUiMb1xpK5PVqFTOnWBAz wCWrwif7m8aR5DrX0BxDeUn70AXPQewJW/MHGDOAbNwn8MtWeVG55RqOew6ZlU6UQSar faXnCnGALKvx+hehWRQ3HNlWs0UmzZD9IhtvORvOwQ7hMrlJTvLpwj9HNkMIhxbFwK7u slhYJIPPDQnueN0WsmOft+44+m5jcjLc2Ft6B/VFxIqNyGD2kogmEPFJMbliJUgD3+Di PK6Q== 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=EtI0l3A78ygIIWO7+EOfZyjQpGbiaOw+lLpsphkq4Ds=; b=CirSAHMl2EQsgbzuFGrkT2GZxzVpri1ZL6jvO+Wq453J1YCWHmn0dUv17DTBhMCMG9 YsZ3DqQ3aD9K8u75qRhZWI9NyTdB46UV76xUZ+T8DaXmRJO1G43DW+iKqlUGL/C4wtGD qsPcgk5qJN5xo1fvEPWAHlL+ciD69iK+tYs5ItA7BvIvQxdIRUNZsoKnYEevqtadDwDb nyRfvbTzFWolS5XPjm9mAdcMkZZa22YloDt6QQ0vjDUVElyKflfi/+lpckOK4IICcpuO wn4h7qFn3Wxr9hOr0nTPI9FwjjyoF7Xl+tg7z5qMe6fjaVY8ZNPiMravUruWzzBqUtk8 cxxQ== X-Gm-Message-State: AN3rC/7yHTyCyBKd4xHTB4Qi97HjC4MKIjallvAapnZU+qmSBTzePxBC k1VOTsQwWNJ37H89 X-Received: by 10.99.125.18 with SMTP id y18mr3975764pgc.32.1492555843283; Tue, 18 Apr 2017 15:50:43 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q1sm464597pfc.35.2017.04.18.15.50.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 15:50:42 -0700 (PDT) To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5c1c487f-730f-dea0-b3e0-1a47e33fafac@gmail.com> Date: Wed, 19 Apr 2017 10:50:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 22:50:45 -0000 On 18/04/2017 19:02, Erik Kline wrote: > On 18 April 2017 at 15:58, wrote: > >>>> Ok, so dumb user question here -- how on earth do I know what I can >> request? Do I just ask for a /48, and if that doesn't work, ask for a /64, >> and if that does, try for a /56, and if that doesn't work try for a /60? >>> >>> You request what you want, the ISP gives you what they are willing to >> give. If you send a zero for the prefix length, the ISP will give you >> whatever their default is. >> >> "you" being the IPv6 CE router. There is really very little way that CE >> can know what to request for. Perhaps it could deduce something from HNCP, >> but this deployment model is very unlikely. I think this idea that CE's are >> going to request what they need and ISP's are going to adhere to that >> request seems very far fetched. >> >> This is an out-of-band negotiation often involving money. In RFC3633 this >> is purely a hint and the ISP is certainly not expected to adhere to it, nor >> is the client expected to set it with very much confidence. >> > > Certainly my assumption was always that we'd devolved to CPEs requesting a > /48 and ISPs doing...whatever they want. That might be a reasonable default behaviour, but if the ISP responds with a /49, we need to be clear that the CPE MUST be capable of handling it. Brian From nobody Tue Apr 18 16:04: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 C10D31314DF for ; Tue, 18 Apr 2017 16:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 vs2CUOpum3kL for ; Tue, 18 Apr 2017 16:04:53 -0700 (PDT) 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 6738812F28A for ; Tue, 18 Apr 2017 16:04:53 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3IImddU030595; Tue, 18 Apr 2017 14:48:49 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 29wqnbshxq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Apr 2017 14:48:49 -0400 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 v3IImmqb005363; Tue, 18 Apr 2017 14:48:49 -0400 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 v3IImfb5005244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 14:48:43 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 18 Apr 2017 18:48:29 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.98]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 14:48:29 -0400 From: "STARK, BARBARA H" To: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) Thread-Index: AQHStIgzg97T9V9Zskqo7aJnuXxFc6HK/xGAgAC3XoD//8X8wA== Date: Tue, 18 Apr 2017 18:48:28 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> In-Reply-To: <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.82.208] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-18_15:, , 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-1703280000 definitions=main-1704180147 Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 23:04:55 -0000 Pj4gSG93IG9ic29sZXRpbmcgUkZDNzA4NCB3aWxsIGJlIGRpZmZlcmVudCAoYmV0dGVyPykgZm9y IGhvbWVuZXQgdnMgdXBkYXRpbmcgaXQ/IEhvbWVuZXQtcmVsYXRlZCByZXF1aXJlbWVudHMgd2ls bCBiZSBhdCBiZXN0IGxpc3RlZCBhcyBTSE9VTEQgaW4gYSBvYnNvbGV0ZWQvdXBkYXRlZCBkb2N1 bWVudHMuwqANCj4+IEkgbGlrZSB0aGUgaWRlYSBvZiBhbiB1cGRhdGUgYmVjYXVzZSBJIGFsbG93 cyBvcGVyYXRvcnMgdG8gZWFzaWx5IHNjb3BlIHRoZWlyIHJlcXVpcmVtZW50cyB0byB0aGVpciBw YXJ0aWN1bGFyIGNvbnRleHQuIMKgDQoNCj4gTGV0IG1lIGNvbWUgYXQgdGhpcyBmcm9tIGEgc2xp Z2h0bHkgZGlmZmVyZW50IGFuZ2xl4oCmIGlmIHRoZSBvbmx5IGNvbW11bml0eSBvZiBpbnRlcmVz dCANCj4gZm9yIHRoaXMgZG9jdW1lbnQgYXJlIHRoZSBvcGVyYXRvcnMgb2YgaW50ZXJuZXQgc2Vy dmljZSBkaXN0cmlidXRpb24gbmV0d29ya3MsIGFuZCB0aGUgDQo+IGludGVyZXN0cyBvZiBhcHBs aWNhdGlvbiBkZXZlbG9wZXJzIGFuZCBjb25zdW1lci1vcmllbnRlZCBob3N0IG9wZXJhdGluZyBz eXN0ZW0gDQo+IGRldmVsb3BlcnMgYXJlIG5vdCB0byBiZSBnaXZlbiBhbnkgY29uc2lkZXJhdGlv biwgdGhlbiB3aHkgaXMgaXQgZXZlbiBuZWNlc3NhcnkgZm9yIA0KPiBJRVRGIHRvIGJlIGludm9s dmVkPyBTaG91bGRu4oCZdCB0aGlzIHdvcmsgYmUgaGFuZGVkIG9mZiB0byBzb21lIGluZHVzdHJ5 IGNvbnNvcnRpdW0sIA0KPiBlLmcuIEJCRiBvciBDYWJsZUxhYnM/DQoNCj4gSeKAmW0gYmVnaW5u aW5nIHRvIHRoaW5rIEkgc2hvdWxkIGp1c3Qgb2JqZWN0IG9uIGdlbmVyYWwgcHJpbmNpcGxlIHRv IHB1Ymxpc2hpbmcgdGhpcyBkb2N1bWVudC4gDQo+IFBlcmhhcHMgaXQgd291bGQgYmUgYmV0dGVy IHRvIGFkdm9jYXRlIG1vdmluZyBSRkMgNzA4NCB0byBIaXN0b3JpY2FsLg0KDQpUaGUgY3VycmVu dCBSRkMgNzA4NCB2ZXJ5IG11Y2ggdG9vayBpbnRvIGFjY291bnQgdGhlIGNvbnN1bWVyLW9yaWVu dGVkIENFIHJvdXRlciB2ZW5kb3JzLiBDYWJsZUxhYnMgYW5kIEJCRiBoYWQgYWxyZWFkeSB0YWtl biBjYXJlIG9mIHRoZWlyIG1lbWJlciBvcGVyYXRvcnMuIEFuZCBSRkMgNzA4NCAoaW4gaXRzIGN1 cnJlbnQgZm9ybSkgaXMgc3RpbGwgdmVyeSByZWxldmFudCB0byB0aG9zZSBkZXZpY2VzLg0KDQpU aGUgcGVvcGxlIHB1c2hpbmcgZm9yIHRoaXMgYXJlIHJlcHJlc2VudGluZyBvcGVyYXRvcnMgd2hv IGRvbuKAmXQgcGFydGljaXBhdGUgaW4gQkJGIG9yIGhhdmUgYW55IGdyZWF0IGluZmx1ZW5jZSBp biBDYWJsZUxhYnMgKEkgaGF2ZSBubyBpZGVhIGlmIHRoZXkgYXJlIGV2ZW4gbWVtYmVycyBvZiBD YWJsZUxhYnMsIHRob3VnaCBJIGhlYXIgQ2FibGVMYWJzIGlzIGRvaW5nIHNvbWUgd29yayBmb3Ig bm9uLVVTIGNhYmxlIG9wZXJhdG9ycykuDQoNCkJ1dCBJIGhhdmUgdG8gc2F5IHRoYXQgc2luY2Ug dGhlIHJlcXVlc3Qgc2VlbXMgdG8gYmUgdG8gc3VwcGx5IHRoZXNlIHNtYWxsZXIgb3BlcmF0b3Jz IHdpdGggYSBzaG9wcGluZyBsaXN0IG9mIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIHRoZXkgY2Fu IHVzZSBhcyBhIHJlZmVyZW5jZSB3aGVuIHRoZXkgZ28gc2hvcHBpbmcsIEkgdGhpbmsgTW9oYW1l ZOKAmXMgc3VnZ2VzdGlvbiBvZiBhbiB1cGRhdGUgaW5zdGVhZCBvZiAtYmlzIG1ha2VzIGEgbG90 IG9mIHNlbnNlLiBJIGRvIHRoaW5rIHRoYXQgb2Jzb2xldGluZyBSRkM3MDg0IHdpdGggc29tZXRo aW5nIHRoYXQgaXMgYSBzaG9wcGluZyBsaXN0IGlzbid0IHZlcnkgdXNlZnVsIHRvIGFueW9uZS4N Cg0KQmFyYmFyYQ0K From nobody Tue Apr 18 16:05: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 0F8B11314EF for ; Tue, 18 Apr 2017 16:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 a-0HuVArxZsD for ; Tue, 18 Apr 2017 16:05:02 -0700 (PDT) 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 5D8E212F28A for ; Tue, 18 Apr 2017 16:05:02 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id q26so4673429uaa.0 for ; Tue, 18 Apr 2017 16:05:02 -0700 (PDT) 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=HdEe2TrHwRCdaHr48AWmCodgaLFRkhq9DpPjIhOGytE=; b=JylWRmkNepnrg25vSOTGZfh7TSn9f0dXw5Wo9vcE3m7uTihMZoL20WASv4pJbpbCNy gwnrboFiYnQGqXaSwo3dRWm71Q2Zq1+Uik8PrXYiKxIavmdylLN/2FhFVspcojk89ati SKM2UuAMEY7mrQv8fnnrdlvG8i+aXmmkyl1JD2hD8qMumE93hKz/4BQ9EcnMxMW8xGkn iDVNJ4IyaRfxh4T+fIc8mbMoPUomOYb5YWLjpehmigLBWauZtCC4puVWO0E3rZ7MCLPI sAf0gGWNGiq10ksg+72wAMT7fasCLrhQqfxVAr7OBc66VVHwWx2Xd5ZK7Nv1muNfJAW5 szDw== 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=HdEe2TrHwRCdaHr48AWmCodgaLFRkhq9DpPjIhOGytE=; b=Wh8S/MCobrQT3M8D3uwDN6Crxo4bdLr5k96p6zWM23eWj/tSOLqS5RiNRbIP36iGI7 /bLoVqSb9u5IBRrDXqSoj40S4y7UBPDoZ7A8Wfm4J2vpTzSDFAhQOjf37vXmZblSJxVf 7XPi/xMeTseZGFbDvwcFYvieNGA0EnPnbc4w2Ciix501F6FJHtaRqr2wsO19RGrW1bjE BjASzekPCyC02nDqHCShnn5gFpW+Y9CMyoN0XL07UhApcJjjjNIpXffRvZ1C4AzzFBFC +NsrlYIJz5PNQ2PTZTpiYY9rn9/I3x3OQYSthTwMty/88UilKqHEcoIzTutr/WtfMJBB pBQg== X-Gm-Message-State: AN3rC/4/T0I1MhgwOTwa7LWZAIWQhPHeJtUnIeCb54bi/Dij3Jw+CZ/q MgqtCwYNlvVZhgJa4JZZABnBMFC0Ug== X-Received: by 10.176.90.200 with SMTP id x8mr13574011uae.44.1492556701500; Tue, 18 Apr 2017 16:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.88 with HTTP; Tue, 18 Apr 2017 16:04:40 -0700 (PDT) In-Reply-To: <5c1c487f-730f-dea0-b3e0-1a47e33fafac@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <5c1c487f-730f-dea0-b3e0-1a47e33fafac@gmail.com> From: Nicolas Antoniello Date: Tue, 18 Apr 2017 18:04:40 -0500 Message-ID: To: Brian E Carpenter Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary=f403045f8adc000c1a054d78f05a Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 23:05:08 -0000 --f403045f8adc000c1a054d78f05a Content-Type: text/plain; charset=UTF-8 Just to do some philosophy here: why should any ISP give as much as a /4x (with x = whatever) while there is almost no domestic CPE that even if they can handle that /4x delegation they do not give the "common" user the possibility to divide or decide anything about the subnetting of her/his networks... with this I mean if we possible have to make an effort in telling the CPEs industry that they have to start thinking in equipments and interfaces that make that process of deciding about my own network a funny and easy task? (may be this should be enforced in some or though some BCPs or RFCs). Regards, Nicolas On Tue, Apr 18, 2017 at 5:50 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 18/04/2017 19:02, Erik Kline wrote: > > On 18 April 2017 at 15:58, wrote: > > > >>>> Ok, so dumb user question here -- how on earth do I know what I can > >> request? Do I just ask for a /48, and if that doesn't work, ask for a > /64, > >> and if that does, try for a /56, and if that doesn't work try for a /60? > >>> > >>> You request what you want, the ISP gives you what they are willing to > >> give. If you send a zero for the prefix length, the ISP will give you > >> whatever their default is. > >> > >> "you" being the IPv6 CE router. There is really very little way that CE > >> can know what to request for. Perhaps it could deduce something from > HNCP, > >> but this deployment model is very unlikely. I think this idea that CE's > are > >> going to request what they need and ISP's are going to adhere to that > >> request seems very far fetched. > >> > >> This is an out-of-band negotiation often involving money. In RFC3633 > this > >> is purely a hint and the ISP is certainly not expected to adhere to it, > nor > >> is the client expected to set it with very much confidence. > >> > > > > Certainly my assumption was always that we'd devolved to CPEs requesting > a > > /48 and ISPs doing...whatever they want. > > That might be a reasonable default behaviour, but if the ISP responds with > a > /49, we need to be clear that the CPE MUST be capable of handling it. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f403045f8adc000c1a054d78f05a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to do some philosophy here: why should any ISP give a= s much as a /4x (with x =3D whatever) while there is almost no domestic CPE= that even if they can handle that /4x delegation they do not give the &quo= t;common" user the possibility to divide or decide anything about the = subnetting of her/his networks... with this I mean if we possible have to m= ake an effort in telling the CPEs industry that they have to start thinking= in equipments and interfaces that make that process of deciding about my o= wn network a funny and easy task? (may be this should be enforced in some o= r though some BCPs or RFCs).

Regards,
Nicolas<= /div>


On Tue, Apr 18, 2017 at 5:50 PM, Brian E Carpenter <bri= an.e.carpenter@gmail.com> wrote:
On 18/04/2017 19:02, Erik Kli= ne wrote:
> On 18 April 2017 at 15:58, <otroan@employees.org> wrote:
>
>>>> Ok, so dumb user question here -- how on earth do I know w= hat I can
>> request? Do I just ask for a /48, and if that doesn't work, as= k for a /64,
>> and if that does, try for a /56, and if that doesn't work try = for a /60?
>>>
>>> You request what you want, the ISP gives you what they are wil= ling to
>> give.=C2=A0 =C2=A0If you send a zero for the prefix length, the IS= P will give you
>> whatever their default is.
>>
>> "you" being the IPv6 CE router. There is really very lit= tle way that CE
>> can know what to request for. Perhaps it could deduce something fr= om HNCP,
>> but this deployment model is very unlikely. I think this idea that= CE's are
>> going to request what they need and ISP's are going to adhere = to that
>> request seems very far fetched.
>>
>> This is an out-of-band negotiation often involving money. In RFC36= 33 this
>> is purely a hint and the ISP is certainly not expected to adhere t= o it, nor
>> is the client expected to set it with very much confidence.
>>
>
> Certainly my assumption was always that we'd devolved to CPEs requ= esting a
> /48 and ISPs doing...whatever they want.

That might be a reasonable default behaviour, but if the ISP re= sponds with a
/49, we need to be clear that the CPE MUST be capable of handling it.

=C2=A0 =C2=A0Brian

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

--f403045f8adc000c1a054d78f05a-- From nobody Tue Apr 18 16: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 C7E1C12F28A for ; Tue, 18 Apr 2017 16:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 JEFN4Y9zuhK9 for ; Tue, 18 Apr 2017 16:06:35 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 ED4B11289B5 for ; Tue, 18 Apr 2017 16:06:34 -0700 (PDT) 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.ams1.isc.org (Postfix) with ESMTPS id E24DA24AE0A; Tue, 18 Apr 2017 23:06:28 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7B806160079; Tue, 18 Apr 2017 23:06:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3B18816007B; Tue, 18 Apr 2017 23:06:29 +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 tw0IgwdNjjaC; Tue, 18 Apr 2017 23:06:29 +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 A68F6160079; Tue, 18 Apr 2017 23:06:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1FEE76BFC2EC; Wed, 19 Apr 2017 09:06:25 +1000 (AEST) To: Fred Baker Cc: Simon Hobson , "v6ops@ietf.org Operations" From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <6151df8b-3a1e-3951-0865-2fbd6b1a924d@gmail.com> <20170418000956.BCACF6B86628@rock.dv.isc.org> In-reply-to: Your message of "Tue, 18 Apr 2017 12:32:10 -0700." Date: Wed, 19 Apr 2017 09:06:25 +1000 Message-Id: <20170418230625.1FEE76BFC2EC@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 23:06:37 -0000 In message , Fred Baker writes: > > On Apr 18, 2017, at 4:01 AM, Simon Hobson wrote: > > Bear in mind that ISPs are mostly still getting to grips with a whole chang > e in manglement mindset about IPv6 - that much is clear from the discussions > about prefix lengths and how some ISPs are still treating addresses as "scar > ce" like they do with IPv4. > > Again, no hats. > > I have had an idea, which I'd like to validate or have invalidated, that a pr > imary reason people don't implement reverse DNS in IPv6 is that they're not s > ure how. In IPv4, it has been pretty straightforward: either they have names > for all of the addresses they would respond to, or they implement one for the > prefix that has a default name for any addresses they didn't have names for, > or maybe they figure out how to create a name for the unused addresses - the > y are able to implement it as a (potentially large) database of individual na > mes. In IPv6, almost all addresses (if I have 1000 IIDs in a /64, I still hav > e 18,446,744,073,709,550,616 addresses) fall into the default category, and a > s a result they need a layered strategy - they look up the actual address, an > d it that fails, back off to a name-per-prefix. > > If they don't see people asking for it, they don't see much impetus to implem > ent anything. > > In separate news, I asked someone who might know about email use of IPv6. The > statement I got back (which I'm not allowed to quote or attribute) said that > they weren't sure of their methodology, but if it was correct, a vanishingly > small subset of emails use it. In that, I wonder about chickens and eggs. If > information security policy requires reverse DNS validation (which in IPv4 i > t usually does) and there is no way to do it, does that mean that the sender > chooses to use IPv4? Or is it the other way around - that folks prefer IPv4, > perhaps because their mail systems do, or their mail systems are not yet IPv6 > -capable or on IPv6 networks? I know when CERNET started mailing lists for SA > VI discussion, the servers were IPv6-only, and that didn't work so well. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops Well I never got any traction with https://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-02 but it show how easy it could be to automatically delegate reverse zones along with the prefix delegation. Reading through I saw a minor typo (s/DNS KEY/DNSKEY/). DHCP servers update DNS servers all the time. Adding PTR records is just as easy but you use TCP as the initial authenticator. There already exists nameservers and DNS UPDATE clients that are capable of doing this part. named supports "tcp-self" as a update policy method which looks at the IP address of the TCP connection the UPDATE message is sent over and computes the reverse name and if the update is updating that name it is allowed. We wrote the code to support this over a decade ago now. nsupdate -v local
del PTR add 3600 IN PTR send -v: use TCP local: sets the source address del: clean out any existing PTR records add: add the new PTR record send: figure out where to send the UPDATE message by looking for the SOA record of the containing zone then send the UPDATE over TCP Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Apr 18 16:19: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 B1E551314EB for ; Tue, 18 Apr 2017 16:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 iNfTk82ZJ631 for ; Tue, 18 Apr 2017 16:19:00 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 A92F6129463 for ; Tue, 18 Apr 2017 16:19:00 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id g2so3586799pge.3 for ; Tue, 18 Apr 2017 16:19:00 -0700 (PDT) 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=5Nvnh1oq/vPjlsgHFUtLDWK8gSOXVhUdoXuBf3VrlYA=; b=D1ExFAdhEhBnuwYa7Fk4m3aV3uhI9y0I/Kvjf9/89jrvyEgNj97KN4akEvhA36Nf5j 1xQqt/7xCG41Xx99btDdGJnbdiQ/XCzth2zAEJhrCGomDBY6QiqtOCfujpxXnYZnepTu XjFdjjT6CsRV1ohvgDdBo4CL+znme0GkpXpAVkJuN5yMMDeHZcdBv6gbqAguOx3V+Pkx N/wUURHjvQvJjImWp0IpNK6fsv6gjU7gkNLkAi2WhIHSBtjKT0kYxb4f/fEC9Keu95X4 zYb9QYuZUiO0BIDY6F43wW4Nyez4Yo+IMrhk5QYvS2iuX/88NSZDrYPmcp7sgLsaTjFI 6evA== 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=5Nvnh1oq/vPjlsgHFUtLDWK8gSOXVhUdoXuBf3VrlYA=; b=Th+1NeZ8WPqIiiPeVeFd+QG6iDYlCH0+CBaLJ21c/EYSi9tb/TLuWVK1N3qsAYlNxq aZ1mrofRhdFlzu0NKko6VxJ9l1zyWbobLS5rJxRZPerzKcZPhBk8uULDHo8HTIkW0D9B lKHfv486X9fPcLvTkr3kQoI+Hg3XKI6QB1kmqGerG9Bd6TUGPJvOsgaclhNN7DMcydXf EnX3o2qLUU1Ls1/csjW6bavyeT+8dECRVTDBHukCvW0jI9QPoVJHuY6zNDJNFVpSzium qbs+jWo5WL+diw6dhWbRGYub9h0qtmC4FHAHpZK/znY7O86XQ33ybq9h5zZwd2n1i0TN 8vQQ== X-Gm-Message-State: AN3rC/6VJN+s9nGMCMqyezzKSYEIvAZ9fSJh5PXOXTXahJRoerCoi1bz /hRDRif5x82kNA== X-Received: by 10.98.157.11 with SMTP id i11mr19952040pfd.166.1492557540281; Tue, 18 Apr 2017 16:19:00 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a184sm486587pfb.118.2017.04.18.16.18.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 16:18:59 -0700 (PDT) To: james woodyatt , "v6ops@ietf.org" References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <34a6d022-4faf-dd10-7b84-b5b3b4c1665d@gmail.com> Date: Wed, 19 Apr 2017 11:19:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 23:19:02 -0000 On 19/04/2017 06:04, james woodyatt wrote: ... > why is it even necessary for IETF to be involved? Because it's our mission to make the Internet work better? Do you really trust a trade association to do that? (BTW, I also think the homenet stuff should be listed, at least as desirable, if not recommended.) Brian From nobody Tue Apr 18 16:37: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 9CD40129410 for ; Tue, 18 Apr 2017 16:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 iOdbJr4Rl6dp for ; Tue, 18 Apr 2017 16:37:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 16FFE126B6D for ; Tue, 18 Apr 2017 16:37:13 -0700 (PDT) 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.ams1.isc.org (Postfix) with ESMTPS id 0DAE824AE12; Tue, 18 Apr 2017 23:35:53 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8A383160079; Tue, 18 Apr 2017 23:35:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 48D9116007B; Tue, 18 Apr 2017 23:35:53 +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 FQwFcQ7I5WBU; Tue, 18 Apr 2017 23:35:53 +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 C22DD160079; Tue, 18 Apr 2017 23:35:52 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 830F86BFE8E6; Wed, 19 Apr 2017 09:35:50 +1000 (AEST) To: Nicolas Antoniello Cc: Brian E Carpenter , IPv6 Ops WG From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <5c1c487f-730f-dea0-b3e0-1a47e33fafac@gmail.com> In-reply-to: Your message of "Tue, 18 Apr 2017 18:04:40 -0500." Date: Wed, 19 Apr 2017 09:35:50 +1000 Message-Id: <20170418233550.830F86BFE8E6@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 23:37:15 -0000 In message , Nicolas Antoniello writes: > > Just to do some philosophy here: why should any ISP give as much as a /4x > (with x = whatever) while there is almost no domestic CPE that even if they > can handle that /4x delegation they do not give the "common" user the > possibility to divide or decide anything about the subnetting of her/his > networks... with this I mean if we possible have to make an effort in > telling the CPEs industry that they have to start thinking in equipments > and interfaces that make that process of deciding about my own network a > funny and easy task? (may be this should be enforced in some or though some > BCPs or RFCs). > > Regards, > Nicolas I already have 3 /64s connected to my CPE router. One for the wired net, one for the 5G WiFi and one for the 2G WiFi. If I had a second router it can request the /64's it needs for its downstream interfaces from the CPE router. I don't need to do a address plan. The CPE works it out. When a second router is connected, it too will work it out based on the prefixes it gets from the CPE router. Or when I add a virtual network and router on one of the machines for testing. Yes, there will end up being lots of /64 routes installed. That really doesn't matter however as the hardware is more than capable of handling it. My IPv6 ISP (HE) gives me a /48. I can do all this because they are not stingy. You needed a address plan with IPv4 because there were not enough addresses to go around so you had to size each subnet differently. With IPv6 you just give each subnet a /64 and let the routing sort out how to deliver the packets. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Apr 18 17:01:32 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B5E1293EC; Tue, 18 Apr 2017 17:01:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149256008998.29061.13670477424788932201.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 17:01:29 -0700 Archived-At: Subject: [v6ops] v6ops - New Meeting Session Request for IETF 99 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 00:01:30 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man 6lo 6tisch homenet opsawg anima isis Second Priority: intarea opsec Third Priority: dnsop tsvwg People who must be present: Fred Baker Joel Jaeggli Ron Bonica Lee Howard Warren Kumari Resources Requested: Special Requests: Please meet on Monday-Wednesday --------------------------------------------------------- From nobody Tue Apr 18 17:08: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 63DAB12EB30; Tue, 18 Apr 2017 17:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 QYddJjjBklP8; Tue, 18 Apr 2017 17:08:52 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 B87A7129471; Tue, 18 Apr 2017 17:08:51 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id z109so4938349wrb.1; Tue, 18 Apr 2017 17:08:51 -0700 (PDT) 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:reply-to :content-transfer-encoding:message-id:references:to; bh=H/mIq5TXzhYku9VxJbCB61Z+AAFgr/Qel7/YHStKHUo=; b=DWDvbzVQKt46NnLaUuAHrxywrY9m35vD+0yiQ3OgJIy0UF1aKYMzyXOlnKLNOZ7gry W8Lambc4v59YNj+0iXA1O6PRiCR4PwIS7PTsBEuhUfiU2Xh1qvr3v7BEwq1HHE0Tt6uk lxBwGujFIsqW74rWnW96QJg6AVhMDf1cJUVI8EPM0bl0cuHV9q8B+0iKbq9HWU/3JeNo YKMWUPHTxBPBIZizorl0ooy/v3VQd0iNvQOh8l7Yts3w5jvBw8/C394xwVSAiPvuxeWh kGXty8vDRRaYf+BuhJE9bqEjAfOgatjSGf/2R8yPPjarQNJugtURArKVWTezuHAv0LG0 lA6A== 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 :reply-to:content-transfer-encoding:message-id:references:to; bh=H/mIq5TXzhYku9VxJbCB61Z+AAFgr/Qel7/YHStKHUo=; b=VH3Tos+u6MmBQB4WVCLThftLh0caCs6OjWx3XbWYQjKnQgdVrFFAPM47BTlxnEW3XP 9g2NZrs3MDvOxEeJ4FCkjOtCeIQbVwmbFABnaeCkS+7Yn7rVnr6hq/eUbEEimsVkhUFT D1Yb2hmPj0nYmwwiNm/1NhLugqFbSj7rO/gApcWWvOCYJ92Y2UdAkppfua4brhzEu/nX 7l/EU1Iz82QNc+wWulpz6AJpOzqVpYdR4a2osoNm9XC+M7wVurd+pVZjGM5dEQPkQvKG 5GlQKLeu4C+CR3mf+ZZU6wEFH4GGEExjsKcJw1Ypay95m4ebxZoZTqfq3scZD/N/jXNE TK9w== X-Gm-Message-State: AN3rC/4psQoCPTyVsmdW3lzg7tYJhnwAteJgXibEaisVencdV5or5Ei8 EW2F1SL6PjhLmMIEcXA= X-Received: by 10.223.173.74 with SMTP id p68mr42660wrc.137.1492560530111; Tue, 18 Apr 2017 17:08:50 -0700 (PDT) Received: from 199.66.20.149.in-addr.arpa (199.66.20.149.in-addr.arpa. [149.20.66.199]) by smtp.gmail.com with ESMTPSA id m139sm1341455wmb.27.2017.04.18.17.08.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 17:08:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <149256008998.29061.13670477424788932201.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 17:08:45 -0700 Cc: Warren Kumari , V6ops Chairs Reply-To: V6ops Chairs Content-Transfer-Encoding: quoted-printable Message-Id: <2AA957C2-D976-4097-83F9-EDB2190BBB41@gmail.com> References: <149256008998.29061.13670477424788932201.idtracker@ietfa.amsl.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] v6ops - New Meeting Session Request for IETF 99 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 00:08:53 -0000 FYI, I have requested sessions at IETF 99. Based on our experience at = IETF 98 and an expectation that we will have more drafts to discuss, I = have asked for two 2-hour slots (as opposed to 1) and for a room to fit = 150 people (as opposed to 100). It's easier to drop a meeting than to = add one. When the meeting at IETF 98 was scheduled, I got a frustrated email from = someone who had a conflict. I tend to consider conflicts normal; they = are something I deal with on every meeting. However, if you have = something you would like v6ops to not conflict with, please respond to = the chairs, so we can add it to the clash list. No guarantees, but the = secretariat tries pretty hard. On Apr 18, 2017, at 5:01 PM, IETF Meeting Session Request Tool = wrote: > A new meeting session request has just been submitted by Fred Baker, a = Chair of the v6ops working group. >=20 > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker >=20 > Number of Sessions: 2 > Length of Session(s): 2 Hours, 2 Hours > Number of Attendees: 150 > Conflicts to Avoid:=20 > First Priority: 6man 6lo 6tisch homenet opsawg anima isis > Second Priority: intarea opsec > Third Priority: dnsop tsvwg >=20 >=20 > People who must be present: > Fred Baker > Joel Jaeggli > Ron Bonica > Lee Howard > Warren Kumari >=20 > Resources Requested: >=20 > Special Requests: > Please meet on Monday-Wednesday > --------------------------------------------------------- >=20 From nobody Tue Apr 18 20:10: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 258EC12708C for ; Tue, 18 Apr 2017 20:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 XgPmgYn6Edm6 for ; Tue, 18 Apr 2017 20:10:44 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 A2225128D44 for ; Tue, 18 Apr 2017 20:10:44 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id 194so5554991pfv.3 for ; Tue, 18 Apr 2017 20:10:44 -0700 (PDT) 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=id1Z8UeC6ooUkGk4umnZXJr3w2aKIboEoU2/I0quPI8=; b=GaSrq6JnRMAUqfpBWOa7oVblWp5PQ9dyrTUREH8HxXHSJ8hiz4bwUMLsleEJmOHaZu +ZzEOSGiGfsLQ0Qo+mtTC+/oGVxYEcCj5IJhcr2nsPWXd8LR2BObqmh0nOrx94nh0QQP K036sYqw50ORwxdyHAwD2j5eElqZMgv+QVQ6U0INalnDN0tRzwYz1AodrMOCpB1ZeqNJ GUH6KD74BHCjwAkqUiCsDUl93d4NW92qudXq9mptbghorqNJvKF24sP6O6ZrmsB1kg1c is+qET+qZpPqhNolHmxnNSJN4s88plsQGOMrWIpRxRwHYe3tlMGst/WiX4Djj5Q9l5TI h30w== 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=id1Z8UeC6ooUkGk4umnZXJr3w2aKIboEoU2/I0quPI8=; b=TLLf+K4wlTW2N4RrDDIU8aBKRnLnJXSQVgKJouve5l7N2BKrACrkL9SNkV8IT+rs5t txVaK1aM1ruiB/X9I9JwW2T/kR/9xeI0cN2rXWVstQ4h8elEIPoPPBOV/Sl9HTBozazA Sa67XW/Frfo4jBeFKpZChyB/hO8NvGE1S9vnSczwUDdsDUYw23X6w0HE9VZiDu2SJxKJ dTNgB1Maczj2N0euiAXYXa85b46KEeZOI1ZWUpjUbJjt5ieaduVm5pF27PCF/eQZ9dra Lwhc5/AZ3+MTgofxeGe+fc+nBE/KUleAqUGjX8UDr7kETgB1u0FRiIo2nQGqPK/hTxZd JaBA== X-Gm-Message-State: AN3rC/4jlPd7IXeS8xYhk53RXisA1rsxG51AWu0e9CUf2XrURpXLo+Ej ad2c2WjPAyZpFVgK X-Received: by 10.98.141.16 with SMTP id z16mr767053pfd.91.1492571444054; Tue, 18 Apr 2017 20:10:44 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q85sm958966pfj.112.2017.04.18.20.10.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 20:10:43 -0700 (PDT) To: Mark Andrews , Nicolas Antoniello References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <5c1c487f-730f-dea0-b3e0-1a47e33fafac@gmail.com> <20170418233550.830F86BFE8E6@rock.dv.isc.org> Cc: IPv6 Ops WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 19 Apr 2017 15:10:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170418233550.830F86BFE8E6@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 03:10:46 -0000 On 19/04/2017 11:35, Mark Andrews wrote: > In message > , Nicolas Antoniello writes: >> >> Just to do some philosophy here: why should any ISP give as much as a /4x >> (with x = whatever) while there is almost no domestic CPE that even if they >> can handle that /4x delegation they do not give the "common" user the >> possibility to divide or decide anything about the subnetting of her/his >> networks... with this I mean if we possible have to make an effort in >> telling the CPEs industry that they have to start thinking in equipments >> and interfaces that make that process of deciding about my own network a >> funny and easy task? (may be this should be enforced in some or though some >> BCPs or RFCs). In addition to what Mark says below, we have HNCP now. We should plan for a future where SOHO networks contain a large number of subnets, with all addressing and routing being automated. So we certainly need the CE router to support this, and ISPs will slowly come to understand their new market. IMHO, our job is to write specs that nudge vendors in the right direction. Brian >> >> Regards, >> Nicolas > > I already have 3 /64s connected to my CPE router. One for the wired > net, one for the 5G WiFi and one for the 2G WiFi. If I had a second > router it can request the /64's it needs for its downstream interfaces > from the CPE router. I don't need to do a address plan. The CPE > works it out. When a second router is connected, it too will work > it out based on the prefixes it gets from the CPE router. Or when > I add a virtual network and router on one of the machines for > testing. > > Yes, there will end up being lots of /64 routes installed. That > really doesn't matter however as the hardware is more than capable > of handling it. > > My IPv6 ISP (HE) gives me a /48. I can do all this because they > are not stingy. > > You needed a address plan with IPv4 because there were not enough > addresses to go around so you had to size each subnet differently. > > With IPv6 you just give each subnet a /64 and let the routing sort > out how to deliver the packets. > > Mark > From nobody Tue Apr 18 21:03: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 4F21D1200DF; Tue, 18 Apr 2017 21:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 dfC1IO2hCfgR; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) 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 CE56D126CF6; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id a188so1855081pfa.2; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) 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=4+RnCCMSY4QLUn2YKL6B+5CQfjMeD0F85oDxQGe3etI=; b=mSVkhc1P+UMjd3DjE5jqKdcSammtpfVLakd3nXTMT540l58gVqvLKEexMgf36dGmMA hCuxoqkYKX3YnN10dVHa4Iqt+uyURq+5iylXoEz4F9wFPMJHUjqBxpUvzbQZYalvjDrc mWkTnNqy8Y/htKqRQ5A0/EmAbYj5taQFPt8tgxIOoWMvyfV2tJVhGAxTQLpdZsKH0nST R1N2CCbHXbOasN2gjt25KHQ9oY6/lCpxHu8usNE10WGsVdEeO9cDd8/zZUoVUO9aASpc WEq2STns6c8l9SKolxaAmFNjYr0uLfTtFNI0kOJYUXMML1hkOaLoXUZgFA1lg9KmrIwj QOvQ== 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=4+RnCCMSY4QLUn2YKL6B+5CQfjMeD0F85oDxQGe3etI=; b=efjBoGMB5cSxJT76wPDUIw/OweQXNExN24rg06bwt9xfqd52eCSC+R4oF2+IjPRaYs t3a+0KXvIDGogI6qeb882Vm+00v9lzA5fjx/4sdH5AjN1o0k9wZk/rOkwAubgnWxpa+7 /6fA4MnO5EdNAsQVmJ2OAEouWCzxguNn2FB7PWLmhPvFz3onEdzICfQNSQw6SCaHav71 cIV5lTxbes5g9pZg3ahBpsy75lt6v9VcITCfo0P0qZy9qNqo/tQ2+fpb7MMEaLG7c5JM Xa0Sjfo+QpvcN45HzNGeDRJDCEiSn7UNEimMc02dd6ZrAJ89+jqE7QkwYD+SLV6AM1Pp BQzQ== X-Gm-Message-State: AN3rC/4urD4XNhjybd9dyP28dy+CXroVSTKqFPjkqyn55YFDLE5I/v2q W8qtNEMbwVlW8A== X-Received: by 10.98.71.202 with SMTP id p71mr899509pfi.39.1492574576291; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m4sm1152766pfi.74.2017.04.18.21.02.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 21:02:55 -0700 (PDT) To: Gunter Van De Velde , "opsec@ietf.org" References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> Cc: Lorenzo Colitti , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Date: Wed, 19 Apr 2017 16:02:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 04:02:58 -0000 There are several issues in this section, not just the NAT: > 2.1.2. Use of ULAs > > ULAs are intended for scenarios where IP addresses will not have > global scope so they should not appear in the global BGP routing > table. We need to align that with the clarification in draft-bchv-rfc6890bis: ULAs are intended for scenarios where IP addresses are not globally reachable, despite formally having global scope. They must not appear in the routing system outside the administrative domain where they are considered valid. Therefore, packets with ULA source and/or destination addresses MUST be filtered at the domain boundary. > ULAs could be useful for infrastructure hiding as described in > RFC4864 [RFC4864]. Alternatively Link-Local addresses RFC7404 > [RFC7404] could also be used. LL addresses don't help if you have multiple LANs. I suggest simply deleting the second sentence; it will confuse people. > Although ULAs are supposed to be used > in conjunction with global addresses for hosts that desire external > connectivity Change that to ULAs may be used for internal communication, in conjunction with globally reachable unicast addresses (GUAs) for hosts that also require external connectivity through a firewall. For this reason, no form of address translation is required in conjunction with ULAs. Then I suggest deleting *all* the rest of the section, but add this at the end: Using ULAs as described here might simplify the filtering rules needed at the domain boundary, by allowing a regime in which only hosts that require external connectivity possess a globally reachable address. However, this does not remove the need for careful design of the filtering rules. Thus the whole section would read (with a little more editing): 2.1.2. Use of Unique Local Addresses Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios where IP addresses are not globally reachable, despite formally having global scope. They must not appear in the routing system outside the administrative domain where they are considered valid. Therefore, packets with ULA source and/or destination addresses MUST be filtered at the domain boundary. ULAs are assigned within pseudo-random /48 prefixes created as specified in [RFC4193]. They could be useful for infrastructure hiding as described in [RFC4864]. ULAs may be used for internal communication, in conjunction with globally reachable unicast addresses (GUAs) for hosts that also require external connectivity through a firewall. For this reason, no form of address translation is required in conjunction with ULAs. Using ULAs as described here might simplify the filtering rules needed at the domain boundary, by allowing a regime in which only hosts that require external connectivity possess a globally reachable address. However, this does not remove the need for careful design of the filtering rules. Brian From nobody Wed Apr 19 02:41: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 66DE8129555 for ; Wed, 19 Apr 2017 02:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdnSHOvHcSO6 for ; Wed, 19 Apr 2017 02:41:03 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526DD1293D8 for ; Wed, 19 Apr 2017 02:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492594860; x=1493199660; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=CCLyhdLzCG9djhl7ZFJfHnzjF 2ykdjUXf9AxvByrMHw=; b=si00KOirMZEyGfpVGvNtqCVtOA7OEVWl9WWlgGk92 2L6kBzhcN/wDyMEFbBCnoI4UfmH2FaZr0WWrnA9v1q6dsTXrtCNWBqTrYKNWTa5Q cQoiU9D/TlqYg9CE+QggevbnVMklfBDdq/jE8wkuIu9kDAPnfjP/cQrPBQqU+2ZD Rc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ncCmgJXhOGfcXKvN3b5xreJMpPDJ9DODYuO2CIQ6El0paKd/DL8/Qx5PA4k7 jw57EEzWUUo1syqhj3UJ4LV7lD+TwZ0JR9YyvsNG9GEoGPftAhVBEUMzp /H8qp16N1ERNUzGis3lPeLZPAzIcnOrOTp3wSMdFzZ3A6T8OLsgS1g=; X-MDAV-Processed: mail.consulintel.es, Wed, 19 Apr 2017 11:41:00 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 19 Apr 2017 11:40:59 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005410908.msg for ; Wed, 19 Apr 2017 11:40:58 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170419:md50005410908::1FpQDgkEiKYMj2Lr:00005138 X-Return-Path: prvs=1282ce1966=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 19 Apr 2017 11:40:57 +0200 From: JORDI PALET MARTINEZ To: , james woodyatt , "v6ops@ietf.org" Message-ID: <767FC962-931F-4B75-A358-3314E7EE259D@consulintel.es> Thread-Topic: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 09:41:05 -0000 I think it has been clear that there is no such differentiation among vendo= rs/products for ISPs or retail. Both are the same products, sometimes with = OEM labels. Small and medium, even some times large ISPs from all the world, don=E2=80= =99t have the resources to participate in BBF/CableLabs, so the right place= to do this is IETF. This document RFC7084 is being used in many references, so if we declare it= historic, I think we may break existing RFQs, etc. and don=E2=80=99t think= is the intend. I still believe that obsoleting it is the most reasonable w= ay, if we don=E2=80=99t change to MUST the requirements that were SHOULD, s= o we don=E2=80=99t break existing references, RFQs, etc. I think the concept of shopping list comes because, despite implementing 5 = instead of 2 doesn=E2=80=99t mean extra code which is something workable fo= r actual products in the market (so even easier for new ones), because most= of the code is shared, we have them as SHOULD instead of MUST. Note that I= =E2=80=99m not saying we should change that, just explaining why it may loo= k as a shopping list. However, if I=E2=80=99m a vendor, and know that I can= implement all them at no extra cost, so I can compete better in the market= , will do, right? Let me to repeat this again. The code needed for LW4o6 is NAT44 plus 4in6, = which is the same as for DS-Lite. 6in4 and 6rd use the same code. 464XLAT a= nd MAP-T share the same 4to6 translation, MAP-E uses 4in6. I know it is not= so simple as that, but basically is what we have. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Responder a: Fecha: martes, 18 de abril de 2017, 20:48 Para: james woodyatt , "v6ops@ietf.org" Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6o= ps-rfc7084-bis-00) >> How obsoleting RFC7084 will be different (better?) for homenet vs up= dating it? Homenet-related requirements will be at best listed as SHOULD in= a obsoleted/updated documents.=20 >> I like the idea of an update because I allows operators to easily sc= ope their requirements to their particular context. =20 =20 > Let me come at this from a slightly different angle=E2=80=A6 if the o= nly community of interest=20 > for this document are the operators of internet service distribution = networks, and the=20 > interests of application developers and consumer-oriented host operat= ing system=20 > developers are not to be given any consideration, then why is it even= necessary for=20 > IETF to be involved? Shouldn=E2=80=99t this work be handed off to som= e industry consortium,=20 > e.g. BBF or CableLabs? =20 > I=E2=80=99m beginning to think I should just object on general princi= ple to publishing this document.=20 > Perhaps it would be better to advocate moving RFC 7084 to Historical. =20 The current RFC 7084 very much took into account the consumer-oriented = CE router vendors. CableLabs and BBF had already taken care of their member= operators. And RFC 7084 (in its current form) is still very relevant to th= ose devices. =20 The people pushing for this are representing operators who don=E2=80=99= t participate in BBF or have any great influence in CableLabs (I have no id= ea if they are even members of CableLabs, though I hear CableLabs is doing = some work for non-US cable operators). =20 But I have to say that since the request seems to be to supply these sm= aller operators with a shopping list of transition technologies they can us= e as a reference when they go shopping, I think Mohamed=E2=80=99s suggestio= n of an update instead of -bis makes a lot of sense. I do think that obsole= ting RFC7084 with something that is a shopping list isn't very useful to an= yone. =20 Barbara _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 19 02:51: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 0F2371270A0 for ; Wed, 19 Apr 2017 02:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 HVQdJ7YrpgXS for ; Wed, 19 Apr 2017 02:51:35 -0700 (PDT) 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 47CAD120454 for ; Wed, 19 Apr 2017 02:51:35 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id r203so21276991oib.3 for ; Wed, 19 Apr 2017 02:51:35 -0700 (PDT) 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=jKRN8sA1J81HAHtWglmPwxd6j95WvNBg0oh1Eq/dUO4=; b=bNAqWvwU2w5e8yBd5ESnKlawRoM9bv7XrLCQekTTRY0SZdVdWUtIq06+odKkFh+2Mr HiRkye1ouJBHGWkw7am9Rygkb1pYC6On7oX+ZpqmmTAmMEoO9ivwH3VKSXfYt9j8QoO5 LJl3A6Q4OoWbALWl8Ijs3KBEadqOsSgo9lU9aIIKwF1wHJhWvpt64BRvRXv3BRZ7GyAl xtJJdyLXS2wg22RKcwR27rrAx7qv6+7d1p7f5Zb9a3HkZBUJXfABqGz+bOwpQBvSOirL 5k9AQq80uh8pUhP1mqrtqV93fybgC4nt/HuFNZoB41njHZ5qX9Si/Klotq5bcjJyXnts Rw7A== 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=jKRN8sA1J81HAHtWglmPwxd6j95WvNBg0oh1Eq/dUO4=; b=csUFaaFv1y70Sd0Di0ewjCD+mr4V/glVembsAr+up8mG57Q+PmU4kFHfuSh5W4wZHh BiV10XLA91fEFSW6CUTOW48cN4gkIK96Spd8nCXL8/wC5P52f+MT79oROBDdb69qY/+v u63hpR/fpbiokwuVQApKyy+JATxMYSNrlp8MQJKPahMX3GajYbH8kYIBgouvitpZor/D 66Ma3mQlR5ReWvyb8jb9n/9IZy8zqRx9rmcl4iLE7rxt1eLCdlFp/vTpLQwhVTVn97Vy RBGx3C4dG+QJEUCiuGOc+/g0GES/XJ1YrliTxbk70qVqcywPr4H5b0Z3i3mmV34tXAGV Wbuw== X-Gm-Message-State: AN3rC/61z7Dk/S4dwkFvYhpsH7VS7NumErqWJXn0uGDnCYulRnKEUykJ fXpWco1HQuwop/DIoErES9DJTJOcHA== X-Received: by 10.157.26.61 with SMTP id a58mr868473ote.74.1492595494657; Wed, 19 Apr 2017 02:51:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.40.211 with HTTP; Wed, 19 Apr 2017 02:51:33 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Hans Liu Date: Wed, 19 Apr 2017 17:51:33 +0800 Message-ID: To: "STARK, BARBARA H" Cc: "v6ops@ietf.org" , Hans Liu , Claire Cheng Content-Type: multipart/alternative; boundary=001a1141c14a40a3c8054d81f862 Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 09:51:37 -0000 --001a1141c14a40a3c8054d81f862 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 19, 2017 at 2:48 AM, STARK, BARBARA H wrote: > > > The current RFC 7084 very much took into account the consumer-oriented CE > router vendors. CableLabs and BBF had already taken care of their member > operators. And RFC 7084 (in its current form) is still very relevant to > those devices. > CE-router is not entirely provided by operators, it is still available in the retail market. Since RFC 6204, there have been only a few vendors follow RFC 7084 in their products, and even less submitted their implementations for IPv6 CE-Router Ready Logo certification. IMHO, the more we add into the specification the less vendor gonna follow it. That then doesn't help IPv6 deployment. As a CE-router vendor that supports IPv6 in the retail models, I used to support 6to4, 6in4, and 6rd, all three of them (and Teredo pass-through, required by "Work with Vista" logo program. :p) in the router in 2008. I gradually removed most transition protocols as I realized they are merely configured and used by users. I still don't understand why 9 years later we want to add them back to the specification? > > The people pushing for this are representing operators who don=E2=80=99t > participate in BBF or have any great influence in CableLabs (I have no id= ea > if they are even members of CableLabs, though I hear CableLabs is doing > some work for non-US cable operators). > > But I have to say that since the request seems to be to supply these > smaller operators with a shopping list of transition technologies they ca= n > use as a reference when they go shopping, I think Mohamed=E2=80=99s sugge= stion of > an update instead of -bis makes a lot of sense. I do think that obsoletin= g > RFC7084 with something that is a shopping list isn't very useful to anyon= e. > +1 > > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1141c14a40a3c8054d81f862 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 19, 2017 at 2:48 AM, STARK, BARBARA H <= ;bs7652@att.com>= wrote:


The current RFC 7084 very much took into account the consumer-orient= ed CE router vendors. CableLabs and BBF had already taken care of their mem= ber operators. And RFC 7084 (in its current form) is still very relevant to= those devices.

CE-router is not entire= ly provided by operators, it is still available in the retail market. Since= RFC 6204, there have been only a few vendors follow RFC 7084 in their prod= ucts, and even less submitted their implementations for IPv6 CE-Router Read= y Logo certification.=C2=A0 IMHO, the more we add into the specification th= e less vendor gonna follow it. That then doesn't help IPv6 deployment. = =C2=A0 As a CE-router vendor that supports IPv6 in the retail models, I use= d to support 6to4, 6in4, and 6rd, all three of them (and Teredo pass-throug= h, required by "Work with Vista" logo program. :p) in the router = in 2008.=C2=A0 I gradually removed most transition protocols as I realized = they are merely configured and used by users.=C2=A0 I still don't under= stand why 9 years later we want to add them back to the specification? =C2= =A0

=C2=A0

The people pushing for this are representing operators who don=E2=80=99t pa= rticipate in BBF or have any great influence in CableLabs (I have no idea i= f they are even members of CableLabs, though I hear CableLabs is doing some= work for non-US cable operators).

But I have to say that since the request seems to be to supply these smalle= r operators with a shopping list of transition technologies they can use as= a reference when they go shopping, I think Mohamed=E2=80=99s suggestion of= an update instead of -bis makes a lot of sense. I do think that obsoleting= RFC7084 with something that is a shopping list isn't very useful to an= yone.

+1
=C2=A0

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


--001a1141c14a40a3c8054d81f862-- From nobody Wed Apr 19 03:00: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 5F9DE1267BB for ; Wed, 19 Apr 2017 03:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLCovrhBUbav for ; Wed, 19 Apr 2017 03:00:13 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94965120454 for ; Wed, 19 Apr 2017 03:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492596010; x=1493200810; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=wRnNtU70JanKrWD1DLlm7FuV9 fFNx9YECzI+aRIYs4w=; b=KAyKFh0mOpu4P2jUUp8GHsB0Xy2Qr25PpTau/+GIP V1GrEymYABRq5U9vOjXqkSRTt2j6+880BWe3Dgmyb02leZ3FzwPFXcDAJOdleLbt Cz/IUvbGbrPKzosCt2AWhbgln5m41hi2ronuvo0IFgJ0Kkn/ZSt+hIV2uYcuJ+Nh vw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=JHYzG7JFeEbUEl7OB8Zc7KxAq1LkIsCiz5hFMubByINBqlIjQQuCogkqAC+c TKfp5xbNLoiacprzXYpt+YsVP31QQCB66fOSJdrXhiYf1/p2ru/2qB9bg 6/feUBhx+7x4dsR7v8jJFfE+H49YC8vPysYvuNiSaGorY+829tSZxU=; X-MDAV-Processed: mail.consulintel.es, Wed, 19 Apr 2017 12:00:10 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 19 Apr 2017 12:00:09 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005410923.msg for ; Wed, 19 Apr 2017 12:00:09 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170419:md50005410923::dJj/uQKI2pB5ZJHl:00004cYD X-Return-Path: prvs=1282ce1966=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 19 Apr 2017 12:00:05 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <8714D043-F732-45ED-84F8-CEB40DFAA595@consulintel.es> Thread-Topic: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 10:00:15 -0000 So, how you will support customers (ISPs and retail) that need a router wit= h IPv6-only in the WAN, but still need IPv4 support in the LANs and to talk= to IPv4-only servers in the real Internet? Do you think this is not a real scenario and will become more and more freq= uent in the next years, until we get rid-off IPv4? Even if you only supply (which is not the case as I know), routers to ISPs = for big RFQs, you need to realize that end-customers of those ISPs my need = a more powerful router than the one delivered by the ISP, or that other ISP= s don=E2=80=99t have the purchasing power to do big RFQs, so just go to the= retail market and by 10 or 100 units each week or month. This is a reality= . I don=E2=80=99t think adding more, if it is a SHOULD, will make it worst, i= s a guidance, because you participate in IETF, but there are many ISPs and = vendors that don=E2=80=99t do, so they don=E2=80=99t read all the RFCs or u= nderstand the need for other transition mechanisms. Including them in this = document means they will wake up and read more and then they will decide wh= atever they want to do, but at least, we provided a guidance in a single do= cument that introduces the =E2=80=9Cwhys and hows=E2=80=9D. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Hans Liu Responder a: Fecha: mi=C3=A9rcoles, 19 de abril de 2017, 11:51 Para: "STARK, BARBARA H" CC: "v6ops@ietf.org" , Hans Liu , C= laire Cheng Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6o= ps-rfc7084-bis-00) =20 =20 On Wed, Apr 19, 2017 at 2:48 AM, STARK, BARBARA H wrot= e: =20 =20 =20 The current RFC 7084 very much took into account the consumer-oriented = CE router vendors. CableLabs and BBF had already taken care of their member= operators. And RFC 7084 (in its current form) is still very relevant to th= ose devices. =20 =20 =20 CE-router is not entirely provided by operators, it is still available = in the retail market. Since RFC 6204, there have been only a few vendors fo= llow RFC 7084 in their products, and even less submitted their implementati= ons for IPv6 CE-Router Ready Logo certification. IMHO, the more we add int= o the specification the less vendor gonna follow it. That then doesn't help= IPv6 deployment. As a CE-router vendor that supports IPv6 in the retail = models, I used to support 6to4, 6in4, and 6rd, all three of them (and Tered= o pass-through, required by "Work with Vista" logo program. :p) in the rout= er in 2008. I gradually removed most transition protocols as I realized th= ey are merely configured and used by users. I still don't understand why 9= years later we want to add them back to the specification? =20 =20 =20 =20 =20 The people pushing for this are representing operators who don=E2=80=99= t participate in BBF or have any great influence in CableLabs (I have no id= ea if they are even members of CableLabs, though I hear CableLabs is doing = some work for non-US cable operators). =20 But I have to say that since the request seems to be to supply these sm= aller operators with a shopping list of transition technologies they can us= e as a reference when they go shopping, I think Mohamed=E2=80=99s suggestio= n of an update instead of -bis makes a lot of sense. I do think that obsole= ting RFC7084 with something that is a shopping list isn't very useful to an= yone. =20 =20 =20 +1 =20 =20 =20 Barbara _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 19 06:24: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 047391294B5 for ; Wed, 19 Apr 2017 06:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tum.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkwfQNoL6yU0 for ; Wed, 19 Apr 2017 06:24:33 -0700 (PDT) Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [129.187.255.138]) (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 8719C127342 for ; Wed, 19 Apr 2017 06:24:33 -0700 (PDT) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout2.mail.lrz.de (Postfix) with ESMTP id 3w7N5C4NmjzyTB for ; Wed, 19 Apr 2017 15:24:31 +0200 (CEST) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= mime-version:content-transfer-encoding:content-id:content-type :content-type:content-language:accept-language:in-reply-to :references:message-id:date:date:subject:subject:from:from :received:received:received:received; s=postout; t=1492608270; bh=Hej0tCLytUF6N8X7Mx6wq7Nx++xDOrNEe4tURYP9l6w=; b=RvFfQ3FHwxdF JwCbZmCkaRwJqP6QpkUWK2eEBBQytLEWyULN1Gm4NcA6tRwOBlGzNR8K3ZOM0AAt gJTPi7y8GAnm70XF21f5qclprxQ+Ple5LNHzwtrfN4KNw/I33pVy1sZaOzcH/AXt WCSXdZuR44YFZZouKtQnDthNJG16OSKcCjLNvinr1rNOGrIPoHY/TPZVRBbTWaNV k79jK/Upj/XIUJYFC+0k8Yss1AceKA1BsWHcFwRjjD3Bh1A38Bh6nq7Ocsn21Xv5 cwTU/K+7D77dKiJvJVCemjPUbkB61gZn1CJ0/+SNyxMvGGO5x5l+g5bzKyxMOln0 rSeYr+vr8Q== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout2.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id tsspmA6icdFq for ; Wed, 19 Apr 2017 15:24:30 +0200 (CEST) Received: from BADWLRZ-SWMBX03.ads.mwn.de (BADWLRZ-SWMBX03.ads.mwn.de [IPv6:2001:4ca0:0:108::159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX03", Issuer "BADWLRZ-SWMBX03" (not verified)) by postout2.mail.lrz.de (Postfix) with ESMTPS id 3w7N5B4wCBzyRr for ; Wed, 19 Apr 2017 15:24:30 +0200 (CEST) Received: from BADWLRZ-SWMBX02.ads.mwn.de (2001:4ca0:0:108::158) by BADWLRZ-SWMBX03.ads.mwn.de (2001:4ca0:0:108::159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32; Wed, 19 Apr 2017 15:24:27 +0200 Received: from BADWLRZ-SWMBX02.ads.mwn.de ([fe80::19fa:4919:5296:5c3b]) by BADWLRZ-SWMBX02.ads.mwn.de ([fe80::19fa:4919:5296:5c3b%14]) with mapi id 15.01.0669.032; Wed, 19 Apr 2017 15:24:26 +0200 From: "Bajpai, Vaibhav" To: "v6ops@ietf.org" Thread-Topic: [review]: draft-ietf-v6ops-rfc6555bis-00 Thread-Index: AQHSuRBEer5QjXwG0EaLW03r2YKNzg== Date: Wed, 19 Apr 2017 13:24:26 +0000 Message-ID: <58edb7fb-8352-40ac-9c1f-6fa65eaa2c0e@BADWLRZ-SWMBX03.ads.mwn.de> References: <149184472785.3090.17232934855800683894.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [131.159.24.54] Content-Type: text/plain; charset="utf-8" Content-ID: <95E3340129C1884D98C63F578D91C2CF@ads.mwn.de> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [v6ops] [review]: draft-ietf-v6ops-rfc6555bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:24:36 -0000 SGVsbG8sDQoNCj4gT24gMTAuIEFwciAyMDE3LCBhdCAxOTo0MywgRGF2aWQgU2NoaW5hemkgPGRz Y2hpbmF6aUBhcHBsZS5jb20+IHdyb3RlOg0KPiANCj4gV2UndmUgdXBkYXRlZCBvdXIgIlVwZGF0 ZSB0byBIYXBweSBFeWViYWxscyIgZG9jdW1lbnQgdG8gYWRkcmVzcyBmZWVkYmFjayByZWNlaXZl ZCBzbyBmYXI6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3Bz LXJmYzY1NTViaXMtMDANCj4gDQo+IFsuLi5dDQo+IA0KPiBUaGFua3MgdG8gZXZlcnlvbmUgd2hv IHNlbnQgZmVlZGJhY2ssIGFuZCBwbGVhc2UgbGV0IHVzIGtub3cgaWYgdGhpcyBhZGRyZXNzZXMg eW91cnMuDQoNCkkgcmVhZCBkcmFmdC1pZXRmLXY2b3BzLXJmYzY1NTViaXMtMDAuIA0KSXQgc2Vl bXMgbXkgY29uY2VybnMgc3RpbGwgZXhpc3QsIHdoaWxlIEkgYWxzbyBhZGRlZCBmZXcgbW9yZToN Cg0KLS0gVmFpYmhhdg0KDQoNCg0KZGV0YWlscw0KLS0tLS0tLQ0KDQotLSBUaGUgdGl0bGUgaXMg bXVjaCBiZXR0ZXIuDQoNCg0KDQovLyDCpyBBYnN0cmFjdA0KDQotLSAnTWFueSBjb21tdW5pY2F0 aW9uIHByb3RvY29scyBvcGVyYXRlZCBvdmVyIHRoZSBtb2Rlcm4gSW50ZXJuZXQnDQoNCldoYXQg aXMgbW9kZXJuIEludGVybmV0Pw0KDQotLSAnVGhlc2Ugb2Z0ZW4gcmVzb2x2ZSB0byBtdWx0aXBs ZSBJUCBhZGRyZXNzZXMsIGVhY2ggb2Ygd2hpY2ggbWF5IGhhdmUNCmRpZmZlcmVudCBwZXJmb3Jt YW5jZSBhbmQgY29ubmVjdGl2aXR5IGNoYXJhY3RlcmlzdGljcy4nDQoNCkkgZG9uJ3QgdGhpbmsg SVAgYWRkcmVzc2VzIGhhdmUgcGVyZm9ybWFuY2UgY2hhcmFjdGVyaXN0aWNzLiBUaGUgSVAgcGF0 aHMgZG8uDQoNCg0KDQoNCi8vIMKnMTogSW50cm9kdWN0aW9uDQoNClRoZSBmaXJzdCBwYXJhZ3Jh cGggaXMgdmVyYmF0aW0gY29waWVkIGZyb20gYWJzdHJhY3QuDQoNCg0KJ05vdyB0aGF0IHRoaXMg YXBwcm9hY2ggaGFzIGJlZW4gZGVwbG95ZWQgYXQgc2NhbGUgYW5kIG1lYXN1cmVkIGZvciBzZXZl cmFsDQp5ZWFycywgdGhlIGFsZ29yaXRobSBzcGVjaWZpY2F0aW9uIGNhbiBiZSByZWZpbmVkIHRv IGltcHJvdmUgaXRzIHJlbGlhYmlsaXR5DQphbmQgZ2VuZXJhbGl6YXRpb24uJw0KDQpUaGlzIGlz IG5vdCBhIGNvbnZpbmNpbmcgYXJndW1lbnQgdG8gdXBkYXRlIGEgc3BlY2lmaWNhdGlvbi4gVGhp bmsgYWJvdXQgaG93DQptYW55IHNwZWNpZmljYXRpb25zIGRlc2VydmUgYW4gdXBkYXRlIGFjY29y ZGluZyB0byBeIHJlYXNvbmluZy4gIFRoZSBkcmFmdA0KbmVlZHMgdG8gZXhwbGljaXRseSBzdGF0 ZSB3aGF0IGlzIHRoZSBwcm9ibGVtIHdpdGggY3VycmVudCBSRkMgNjU1NQ0KZGVzY3JpcHRpb24g YW5kIHdoeSBpdCBuZWVkcyBhbiB1cGRhdGUuICBJIHRoaW5rIHlvdSBzaG91bGQgbWVudGlvbiB0 aGUNCnNob3J0Y29taW5ncyBTdHVhcnQgcG9pbnRlZCBvdXQgaW4gW2FdLg0KDQpbYV0gaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy92Nm9wcy9QbmNuUzlLd2ZLeHN5YTM1Y0h4 MlBIN0ZtOHcNCg0KDQoNCg0KLy8gwqcyOiBPdmVydmlldw0KDQonSWYgdGhlIGhvc3QgaXMgY29u ZmlndXJlZCBkaWZmZXJlbnRseSwgdGhlIHJlY29tbWVuZGF0aW9ucyBpbiB0aGlzIGRvY3VtZW50 DQpjYW4gYmUgZWFzaWx5IGFkYXB0ZWQuJw0KDQpIb3c/DQoNCi0tIEl0IGlzIG5vdCBjbGVhciBo b3cgdGhlIHJlY29tbWVuZGF0aW9ucyBtYWRlIGluIHRoaXMgZHJhZnQgcmVsYXRlIHRvDQpBcHBs ZSdzIFthXSBpbXBsZW1lbnRhdGlvbi4NCg0KW2FdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cyMjQ1NS5odG1sDQoNCg0KDQoNCg0KDQovLyDC pzM6IEhvc3RuYW1lIFJlc29sdXRpb24gUXVlcnkgSGFuZGxpbmcNCg0KLS0gJ0lmIG9uZSBxdWVy eSBmYWlscyB0byByZXR1cm4sIG9yIHRha2VzIHNpZ25pZmljYW50bHkgbG9uZ2VyIHRvIHJldHVy bicNCg0KaG93IGxvbmcgaXMgc2lnbmlmaWNhbnRseSBsb25nPyBhbmQgSSB0aGluayB5b3UgbWVh biAnb25lIHF1ZXJ5IHJlc3BvbnNlIGZhaWxzDQp0byByZXR1cm4nIC0tIFRoaXMgaXMgcmVwZWF0 ZWQgYXQgbXVsdGlwbGUgcGxhY2VzIGluIHRoZSBkcmFmdC4NCg0KDQotLSAnVGhpcyBkZWxheSB3 aWxsIGJlIHJlZmVycmVkIHRvIGFzIHRoZSAiUmVzb2x1dGlvbiBEZWxheSIuICBUaGUgUkVDT01N RU5ERUQNCnZhbHVlIGZvciB0aGUgUmVzb2x1dGlvbiBEZWxheSBpcyA1MCBtaWxsaXNlY29uZHMu 4oCZDQoNCmhvdyBpcyB0aGlzIHZhbHVlIG9mIDUwIG1zIGRldGVybWluZWQ/IERvZXNuJ3QgQXBw bGUncyBpbXBsZW1lbnRhdGlvbiB1c2UgYQ0KMjUgbXMgdGltZXIgaW5zdGVhZD8gW2FdDQoNCg0K DQpbYV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50 L21zZzIyNDU1Lmh0bWwNCg0KLS0gd2hhdCBpcyBhICdzdGFnZ2VyZWQnIGNvbm5lY3Rpb24/DQoN Ci0tIEluIHdoYXQgJSBvZiBjYXNlcyB5b3Ugc2VlIHRoYXQgRE5TIHF1ZXJpZXMgYXJlIG1hZGUg b3ZlciB2NiB0cmFuc3BvcnQ/DQoNCi0tIEluIHdoYXQgJSBvZiBjYXNlcywgeW91IHNlZSB0aGF0 IEFBQUEgcXVlcmllcyBub3QgY2FjaGVkLCBidXQgQSBxdWVyaWVzDQphcmU/IElzIHRoaXMgaW52 YXJpYW50IG9mIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydD8NCg0KDQotLSAnQ2xpZW50IHN5c3Rl bXMgU0hPVUxEIE5PVCBoYXZlIGFuIGV4cGxpY2l0IGxpbWl0IHRvIHRoZSBudW1iZXIgb2YgRE5T DQogICBzZXJ2ZXJzIHRoYXQgY2FuIGJlIGNvbmZpZ3VyZWQsIGVpdGhlciBtYW51YWxseSBvciBi eSB0aGUgbmV0d29yay4NCiAgIElmIHN1Y2ggYSBsaW1pdCBpcyByZXF1aXJlZCBieSBoYXJkd2Fy ZSBsaW1pdGF0aW9ucywgaXQgaXMNCiAgIFJFQ09NTUVOREVEIHRvIHVzZSBhdCBsZWFzdCBvbmUg YWRkcmVzcyBmcm9tIGVhY2ggYWRkcmVzcyBmYW1pbHkgZnJvbQ0KICAgdGhlIGF2YWlsYWJsZSBs aXN0LicNCg0KDQpIb3cgaXMgYSBjYW5kaWRhdGUgYWRkcmVzcyBmcm9tIGVhY2ggQUYgY2hvc2Vu Pw0KDQoNCg0KDQovLyDCpzQ6IFNvcnRpbmcgQWRkcmVzc2VzDQoNCi0tICdJZiB0aGUgY2xpZW50 IGlzIHN0YXRlZnVsIGFuZCBoYXMgaGlzdG9yeSBvZiBleHBlY3RlZCByb3VuZC10cmlwDQogIHRp bWVzIChSVFQpIGZvciB0aGUgcm91dGVz4oCZDQoNCkhvdyBsb25nIHNob3VsZCBiZSB0aGUgaGlz dG9yeT8NCg0KDQotLSAnVGhpcyBoaXN0b3JpY2FsIGRhdGEgTVVTVCBOT1QgYmUgdXNlZCBhY3Jv c3MgbmV0d29ya3MsIGFuZCBTSE9VTEQgYmUNCmZsdXNoZWQgb24gbmV0d29yayBjaGFuZ2VzLuKA mQ0KDQpVbmNsZWFyIHdoYXQgeW91IG1lYW4gYnkgbmV0d29yayBjaGFuZ2UsIGFuIGV4YW1wbGUg aGVyZSB3b3VsZCBiZSBuaWNlLg0KDQoNCg0KDQovLyDCpzU6IENvbm5lY3Rpb24gQXR0ZW1wdHMN Cg0KLS0gJ1RoaXMgZGVsYXkgaXMgcmVmZXJyZWQgdG8gYXMgdGhlICJDb25uZWN0aW9uIEF0dGVt cHQgRGVsYXkiLiAgT25lDQpyZWNvbW1lbmRlZCB2YWx1ZSBmb3IgdGhpcyBkZWxheSBpcyAyNTAg bWlsbGlzZWNvbmRzLuKAmQ0KDQpIb3cgaXMgdGhpcyB2YWx1ZSBkZXRlcm1pbmVkPyBUaGlzIGlz IG5vdCB3aGF0IEFwcGxlJ3MgaW1wbGVtZW50YXRpb24gW2FdDQpkb2VzIHJpZ2h0PyBUaGVuIGhv dyBkbyB5b3UgcmVjb21tZW5kIHRoaXMgdmFsdWU/DQoNClthXSBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjI0NTUuaHRtbA0KDQotLSAnVGhl IHJlY29tbWVuZGVkIGZvcm11bGEgZm9yIGNhbGN1bGF0aW5nIHRoZSBkZWxheSBhZnRlciBzdGFy dGluZyBhDQpjb25uZWN0aW9uIGF0dGVtcHQgaXM6IE1BWCggMS4yNSAqIFJUVF9NRUFOICsgNCAq IFJUVF9WQVJJQU5DRSwgMiAqIFJUVF9NRUFODQopLCB3aGVyZSB0aGUgUlRUIHZhbHVlcyBhcmUg YmFzZWQgb24gdGhlIHN0YXRpc3RpY3MgZm9yIHByZXZpb3VzIGFkZHJlc3MNCnVzZWQu4oCZDQoN CkhvdyBpcyB0aGlzIGZvcm11bGEgZGV0ZXJtaW5lZD8gV2h5IGRvZXMgdGhpcyBnaXZlIGdvb2Qg cmVzdWx0cz8NCg0KLS0gJy4uLiBhbGwgb3RoZXIgY29ubmVjdGlvbnMgYXR0ZW1wdHMgdGhhdCBo YXZlIG5vdCB5ZXQNCiAgc3VjY2VlZGVkIFNIT1VMRCBiZSBjYW5jZWxsZWQu4oCZDQoNCkkgdGhp bmsgeW91IG1lYW4gdGVybWluYXRlZC4NCg0KDQotLSAnV2hpbGUgVENQIGltcGxlbWVudGF0aW9u cyBvZnRlbiBsZXZlcmFnZSBhbiBleHBvbmVudGlhbCBiYWNrb2ZmIHdoZW4gdGhleQ0KICAgIGRl dGVjdCBwYWNrZXQgbG9zcywgdGhlICJDb25uZWN0aW9uIEF0dGVtcHQgRGVsYXkiIFNIT1VMRCBO T1Qgc3VjaCBhbg0KICAgIGFnZ3Jlc3NpdmUgYmFja29mZiwgYXMgaXQgd291bGQgaGFybSB1c2Vy IGV4cGVyaWVuY2UuJw0KDQoNClRoaXMgc3RhdGVtZW50IG5lZWRzIHRvIGJlIGJhY2tlZCB1cCBi eSBldmlkZW5jZS4NCg0KDQotLSAnTW9yZSBzcGVjaWZpY2FsbHksIGEgc3Vic2VxdWVudCBjb25u ZWN0aW9uIE1VU1QgTk9UIGJlIHN0YXJ0ZWQgd2l0aGluIDEwDQogICAgbWlsbGlzZWNvbmRzIG9m IHRoZSBwcmV2aW91cyBhdHRlbXB0LiAgVGhlIHJlY29tbWVuZGVkIG1pbmltdW0gdmFsdWUgaXMg MTAwDQogICAgbWlsbGlzZWNvbmRzLCB3aGljaCBpcyByZWZlcnJlZCB0byBhcyB0aGUgIk1pbmlt dW0gQ29ubmVjdGlvbiBBdHRlbXB0IERlbGF5Ii4NCiAgICBUaGlzIG1pbmltdW0gdmFsdWUgaXMg cmVxdWlyZWQgdG8gYXZvaWQgY29uZ2VzdGl2ZSBjb2xsYXBzZSBpbiB0aGUgcHJlc2VuY2Ugb2YN CiAgICBoaWdoIHBhY2tldCBsb3NzIHJhdGVzLiAgVGhlIENvbm5lY3Rpb24gQXR0ZW1wdCBEZWxh eSBTSE9VTEQgaGF2ZSBhbiB1cHBlcg0KICAgIGJvdW5kLCByZWZlcnJlZCB0byBhcyB0aGUgIk1h eGltdW0gQ29ubmVjdGlvbiBBdHRlbXB0IERlbGF5Ii4gIFRoZSBjdXJyZW50DQogICAgcmVjb21t ZW5kZWQgdmFsdWUgaXMgMiBzZWNvbmRzLicNCg0KDQpIb3cgYXJlIHRoZXNlIHZhbHVlcyBkZXRl cm1pbmVkPw0KDQoNCg0KLy8gwqc4OiBDb25uZWN0aW9uIEF0dGVtcHRzDQoNCi0tICdTaW5jZSBI YXBweSBFeWViYWxscyBpcyBvbmx5IGFjdGl2ZSBkdXJpbmcgdGhlIGluaXRpYWwgaGFuZHNoYWtl IGFuZA0KICAgVENQIGRvZXMgbm90IHBhcyB0aGUgaW5pdGlhbCBoYW5kc2hha2UnDQoNCg0KSSB0 aGluayB5b3UgbWVhbiBIRSBkb2VzIG5vdCB0YWtlIGVmZmVjdCBiZXlvbmQgdGhlIFRDUCBoYW5k c2hha2UuIFRoZXJlIGlzDQphbHNvIGEgdHlwbyBoZXJlLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpWYWliaGF2IEJhanBhaQ0Kd3d3LnZhaWJoYXZiYWpwYWkuY29tDQoNClBvc3Rk b2N0b3JhbCBSZXNlYXJjaGVyDQpUVSBNdW5pY2gsIEdlcm1hbnkNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCg0KDQoNCg0KDQo= From nobody Wed Apr 19 06:27: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 EBE9512957F for ; Wed, 19 Apr 2017 06:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 jFuGO_6XzPZa for ; Wed, 19 Apr 2017 06:27:18 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 44B2B1295A0 for ; Wed, 19 Apr 2017 06:27:08 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id d131so19595370qkc.3 for ; Wed, 19 Apr 2017 06:27:08 -0700 (PDT) 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=NaiZCxXPQ4mqykwTSBS7Y2NfyTkTfZtIUDm4TEDRZZY=; b=M9zKJPhsqnK8XNWEIzvBfJUXP6S+47Nf6ziojRxNMLmY1v6NCvYNjkTdrAs14dGcT4 zyu7+CE/01crye0d2c3c13i36O5cKipw5pX+3mVvLBnDojIFLmX5q2mQ/6HJe36bB/eQ o/ZkGA+EZygwkT3v+7qGcGrwRuK6KyccAsTzBJ+kBwdMoQrF+yh3ik+QpEc0n+be7LWV zksTWd6V9f7+2iuKn2GRT1YWGOvvoy3et5w/Kt9f5BNe+7eLt4yJQK5d6wads0klVTQt W4+oRnx945PqEeL61VCuSsvaRw7BDkYu4O6IgRGAXSiVoA3J0obEIcm9R5GNhZZXEXiG EEBg== 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=NaiZCxXPQ4mqykwTSBS7Y2NfyTkTfZtIUDm4TEDRZZY=; b=rPvZST+K19zwdCj3dql0na/kRiTb96ypUn0KUD1p/XXEmErsCNzZTvFu4+P9iL6qLi sJKxWAlA1N73LtO7x3aJh/fDkf8irqGi0vIG1suJ6Pxv5RrSAXTNnk//hWESH1jG4xT/ HLuXjKKfXzHi0+VhiIEWrG8HEpeuJ6Ndsc0mx+ma8VxUBcWnzAlOuhnZHwOr2mzsUZze owcaR8PzUEzZ7hYw0iNoJuqucRoznH+TMfMXkXgm84tuvYv7DPGfB4XL/kptOe9HrqKE ++A0CBj7FM68qIG2L+pCgyQQVdDdVPSSXYZuS6PSRMCrj9D/Gju7EpfgUxO3GBto63xN iOsA== X-Gm-Message-State: AN3rC/4ndbk9p1+xs9K4zboTq5z6kazy4qhTefiQ4/mm6WNZrTdNFypf MsN6qvm1P8srsc+ea34= X-Received: by 10.55.115.67 with SMTP id o64mr2349407qkc.216.1492608427286; Wed, 19 Apr 2017 06:27:07 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t45sm236437qtt.9.2017.04.19.06.27.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 06:27:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Date: Wed, 19 Apr 2017 09:27:04 -0400 Cc: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:27:20 -0000 This would be a huge improvement on the existing text=E2=80=94thanks for = writing it! > On Apr 19, 2017, at 12:02 AM, Brian E Carpenter = wrote: >=20 > There are several issues in this section, not just the NAT: >=20 >> 2.1.2. Use of ULAs >>=20 >> ULAs are intended for scenarios where IP addresses will not have >> global scope so they should not appear in the global BGP routing >> table.=20 >=20 > We need to align that with the clarification in draft-bchv-rfc6890bis: >=20 > ULAs are intended for scenarios where IP addresses are not globally > reachable, despite formally having global scope. They must not appear > in the routing system outside the administrative domain where they > are considered valid. Therefore, packets with ULA source and/or > destination addresses MUST be filtered at the domain boundary. >=20 >> ULAs could be useful for infrastructure hiding as described in >> RFC4864 [RFC4864]. Alternatively Link-Local addresses RFC7404 >> [RFC7404] could also be used. >=20 > LL addresses don't help if you have multiple LANs. I suggest simply > deleting the second sentence; it will confuse people. >=20 >> Although ULAs are supposed to be used >> in conjunction with global addresses for hosts that desire external >> connectivity >=20 > Change that to >=20 > ULAs may be used for internal communication, in conjunction with > globally reachable unicast addresses (GUAs) for hosts that also > require external connectivity through a firewall. For this reason, > no form of address translation is required in conjunction with ULAs. >=20 > Then I suggest deleting *all* the rest of the section, but add this > at the end: >=20 > Using ULAs as described here might simplify the filtering rules > needed at the domain boundary, by allowing a regime in which > only hosts that require external connectivity possess a globally > reachable address. However, this does not remove the need for > careful design of the filtering rules. >=20 > Thus the whole section would read (with a little more editing): >=20 > 2.1.2. Use of Unique Local Addresses >=20 > Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios > where IP addresses are not globally reachable, despite formally > having global scope. They must not appear in the routing system > outside the administrative domain where they are considered valid. > Therefore, packets with ULA source and/or destination addresses > MUST be filtered at the domain boundary. >=20 > ULAs are assigned within pseudo-random /48 prefixes created as > specified in [RFC4193]. They could be useful for infrastructure > hiding as described in [RFC4864]. >=20 > ULAs may be used for internal communication, in conjunction with > globally reachable unicast addresses (GUAs) for hosts that also > require external connectivity through a firewall. For this reason, > no form of address translation is required in conjunction with ULAs. >=20 > Using ULAs as described here might simplify the filtering rules > needed at the domain boundary, by allowing a regime in which > only hosts that require external connectivity possess a globally > reachable address. However, this does not remove the need for > careful design of the filtering rules. >=20 > Brian >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 19 07:55: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 7AA2F129ADC for ; Wed, 19 Apr 2017 07:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[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, 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 5FLymfrT9HMA for ; Wed, 19 Apr 2017 07:55:42 -0700 (PDT) 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 0D753129AE7 for ; Wed, 19 Apr 2017 07:55:39 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id k13so11705672ywk.1 for ; Wed, 19 Apr 2017 07:55:39 -0700 (PDT) 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=dndRf7WMZmR3F1E5QfNJo4Fp/+ler+GDpo+1p0//LEU=; b=ZRWVsgowmWWScTkD6exqn+6EMyx/4cLmFiVruY2JoAx44sUOhxVeE76gRb9QWWfWuA m0ZjryHeMTMVEjZauyAJouQ2qxbRNVlfBUDAXOE4tG+xJsdRWxSAcxyC6ZKQf8h3B6Ij X1AMRPR4EhAfYzxeQB3sclupoHBsuURFtkqyMgrvEy5Uhzo1wxpYWTz6WwSk0SkkPSCo 8mwrwd5qfEEXqt3oHlN8UqeJsV1vnh8812TqtYYTh9Mi7PeSTgfhhJOMKw6IRDG2iidY Qmg8zyIu9tSOiBi6v7PsmHkdcKLOSEEt51dB+if2AL0BdL3mBiojltjUvcNdDHhFRWIJ RstQ== 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=dndRf7WMZmR3F1E5QfNJo4Fp/+ler+GDpo+1p0//LEU=; b=An6EsWi7YBXqrbLPXzdR5OXWuv/Ydevc7P8O31mhzeV5uAvP/+LsCxRKIKwiL2S0FF ki3Qx1Xw7yj1D5qSmHO8d41alsanEow7r/PWWje6TIqUwjqI6Okr3vC8+56hHR77wodF jLqfVNVOEuBMFMmZXtDWaA0vtRejeWIwL0egN4IPuDlG7J72srb86QARq4qF3liNjX7N yNpvNvZ7SDifly8sgn0STwyVhODm4nFTFiEYKfc2GMo2w/IdK3pqJJwvSiVJRAArzoay 5B/SmZTiOziE/pdHG1B0UpLyH77aAXfmxGHxHPGNq8bY9CWo5oXhrOPdL2vdp83pxuF5 dSUw== X-Gm-Message-State: AN3rC/7wSPlY2HrgVeH1o1cacE9rBlbuRrUay+Gg9WS+fgd4uqLAWLOQ 1dbRNIM1GcL6jnH5cEzXkvB+3BydaHu7L1Y= X-Received: by 10.157.26.61 with SMTP id a58mr1587119ote.74.1492613738281; Wed, 19 Apr 2017 07:55:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.42.79 with HTTP; Wed, 19 Apr 2017 07:55:37 -0700 (PDT) In-Reply-To: <8714D043-F732-45ED-84F8-CEB40DFAA595@consulintel.es> References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> <8714D043-F732-45ED-84F8-CEB40DFAA595@consulintel.es> From: Hans Liu Date: Wed, 19 Apr 2017 22:55:37 +0800 Message-ID: To: jordi.palet@consulintel.es Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a1141c14aa8400d054d8637ac Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:55:45 -0000 --001a1141c14aa8400d054d8637ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 19, 2017 at 6:00 PM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > So, how you will support customers (ISPs and retail) that need a router > with IPv6-only in the WAN, but still need IPv4 support in the LANs and to > talk to IPv4-only servers in the real Internet? I'm not standing against all those transition protocols. For retail users, IMHO, giving them a shopping list doesn't help as most of them don't know how to get it correctly configured. > > I don=E2=80=99t think adding more, if it is a SHOULD, will make it worst,= is a > guidance, because you participate in IETF, but there are many ISPs and > vendors that don=E2=80=99t do, so they don=E2=80=99t read all the RFCs or= understand the > need for other transition mechanisms. Including them in this document mea= ns > they will wake up and read more and then they will decide whatever they > want to do, but at least, we provided a guidance in a single document tha= t > introduces the =E2=80=9Cwhys and hows=E2=80=9D. > Including them in a single document as a clear guidance definitely will help CE router vendors during the development. I actually appreciate the work. However, I don't think that means we should obsolete 7084. > > Regards, > Jordi > > > -----Mensaje original----- > De: v6ops en nombre de Hans Liu < > hansliu@gmail.com> > Responder a: > Fecha: mi=C3=A9rcoles, 19 de abril de 2017, 11:51 > Para: "STARK, BARBARA H" > CC: "v6ops@ietf.org" , Hans Liu , > Claire Cheng > Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for > draft-ietf-v6ops-rfc7084-bis-00) > > > > On Wed, Apr 19, 2017 at 2:48 AM, STARK, BARBARA H > wrote: > > > > The current RFC 7084 very much took into account the consumer-oriente= d > CE router vendors. CableLabs and BBF had already taken care of their memb= er > operators. And RFC 7084 (in its current form) is still very relevant to > those devices. > > > > CE-router is not entirely provided by operators, it is still availabl= e > in the retail market. Since RFC 6204, there have been only a few vendors > follow RFC 7084 in their products, and even less submitted their > implementations for IPv6 CE-Router Ready Logo certification. IMHO, the > more we add into the specification the less vendor gonna follow it. That > then doesn't help IPv6 deployment. As a CE-router vendor that supports > IPv6 in the retail models, I used to support 6to4, 6in4, and 6rd, all thr= ee > of them (and Teredo pass-through, required by "Work with Vista" logo > program. :p) in the router in 2008. I gradually removed most transition > protocols as I realized they are merely configured and used by users. I > still don't understand why 9 years later we want to add them back to the > specification? > > > > > The people pushing for this are representing operators who don=E2=80= =99t > participate in BBF or have any great influence in CableLabs (I have no id= ea > if they are even members of CableLabs, though I hear CableLabs is doing > some work for non-US cable operators). > > But I have to say that since the request seems to be to supply these > smaller operators with a shopping list of transition technologies they ca= n > use as a reference when they go shopping, I think Mohamed=E2=80=99s sugge= stion of > an update instead of -bis makes a lot of sense. I do think that obsoletin= g > RFC7084 with something that is a shopping list isn't very useful to anyon= e. > > > > +1 > > > > Barbara > _______________________________________________ > 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 > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Instead of following the fashion, we lead it through. --001a1141c14aa8400d054d8637ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 19, 2017 at 6:00 PM, JORDI PALET MARTINEZ <jordi.= palet@consulintel.es> wrote:
So, how you will support customers (ISPs and retail) t= hat need a router with IPv6-only in the WAN, but still need IPv4 support in= the LANs and to talk to IPv4-only servers in the real Internet?=C2=A0

I'm not standing against all those transiti= on protocols.=C2=A0For retail users, IMHO, giving them a shopping list does= n't help as most of them don't know how to get it correctly configu= red. =C2=A0
=C2=A0

I don=E2=80=99t think adding more, if it is a SHOULD, will make it worst, i= s a guidance, because you participate in IETF, but there are many ISPs and = vendors that don=E2=80=99t do, so they don=E2=80=99t read all the RFCs or u= nderstand the need for other transition mechanisms. Including them in this = document means they will wake up and read more and then they will decide wh= atever they want to do, but at least, we provided a guidance in a single do= cument that introduces the =E2=80=9Cwhys and hows=E2=80=9D.

Including them in a single document as a clear guidanc= e definitely will help CE router vendors during the development. I actually= appreciate the work. However, I don't think that means we should obsol= ete 7084. =C2=A0

Regards,
Jordi


-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.= org> en nombre de Hans Liu <= hansliu@gmail.com>
Responder a: <hansliu@gmail.com= >
Fecha: mi=C3=A9rcoles, 19 de abril de 2017, 11:51
Para: "STARK, BARBARA H" <bs= 7652@att.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, Hans Liu <hans.liu@dlinkcorp.com>, Claire = Cheng <claire.cheng@dlinkc= orp.com>
Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6o= ps-rfc7084-bis-00)



=C2=A0 =C2=A0 On Wed, Apr 19, 2017 at 2:48 AM, STARK, BARBARA H <bs7652@att.com> wrote:



=C2=A0 =C2=A0 The current RFC 7084 very much took into account the consumer= -oriented CE router vendors. CableLabs and BBF had already taken care of th= eir member operators. And RFC 7084 (in its current form) is still very rele= vant to those devices.



=C2=A0 =C2=A0 CE-router is not entirely provided by operators, it is still = available in the retail market. Since RFC 6204, there have been only a few = vendors follow RFC 7084 in their products, and even less submitted their im= plementations for IPv6 CE-Router Ready Logo certification.=C2=A0 IMHO, the = more we add into the specification the less vendor gonna follow it. That th= en doesn't help IPv6 deployment.=C2=A0 =C2=A0As a CE-router vendor that= supports IPv6 in the retail models, I used to support 6to4, 6in4, and 6rd,= all three of them (and Teredo pass-through, required by "Work with Vi= sta" logo program. :p) in the router in 2008.=C2=A0 I gradually remove= d most transition protocols as I realized they are merely configured and us= ed by users.=C2=A0 I still don't understand why 9 years later we want t= o add them back to the specification?




=C2=A0 =C2=A0 The people pushing for this are representing operators who do= n=E2=80=99t participate in BBF or have any great influence in CableLabs (I = have no idea if they are even members of CableLabs, though I hear CableLabs= is doing some work for non-US cable operators).

=C2=A0 =C2=A0 But I have to say that since the request seems to be to suppl= y these smaller operators with a shopping list of transition technologies t= hey can use as a reference when they go shopping, I think Mohamed=E2=80=99s= suggestion of an update instead of -bis makes a lot of sense. I do think t= hat obsoleting RFC7084 with something that is a shopping list isn't ver= y useful to anyone.



=C2=A0 =C2=A0 +1



=C2=A0 =C2=A0 Barbara
=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops









=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops




*************************= *********************
IPv4 is over
Are you ready for the new Internet ?
= http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited.



________________= _______________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



--
=
Instead of following the fashion, we lead it= through.
--001a1141c14aa8400d054d8637ac-- From nobody Wed Apr 19 08:25: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 239B6128B90 for ; Wed, 19 Apr 2017 08:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPllBgMwTJHY for ; Wed, 19 Apr 2017 08:25:12 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9141129AF3 for ; Wed, 19 Apr 2017 08:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492615509; x=1493220309; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=lXphyFcgQPTnsniV5uoiH7Sg8 k9RRDYCGUbpgL1/7YE=; b=PQb5JkIBWAowuWtGudcgB5s/KZCtWbAjSgWZdontf bWQ1nUb8SeqMthDZAj1KAfSWogQcJqAywzQ36JyoRkp4G5FdmqpuKoD2Ha+QH/CM jdg2WTcon5JkydCjZbXQIp5Od8URFeTr7xk8jTp08TDRfpTvpz9hDqPmpb4i3/id dY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=BTey32mO7IRp1Si3J+QHD5kmRkTdf2a/zP556JXTMdLK8x/FvTW4cgFKfM/M r/O2hoYIRKMSwFWd90cGUOEZgRAlmECOhkzT1NaMI1RmpU5cMnC4cI9rk bFlkQnM38JSG2BTd8Rnmh6tOJBgqu066inb+P1fDxpxTiaB8rl5Rc4=; X-MDAV-Processed: mail.consulintel.es, Wed, 19 Apr 2017 17:25:08 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 19 Apr 2017 17:25:08 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005411097.msg for ; Wed, 19 Apr 2017 17:25:07 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170419:md50005411097::EEDDV/dRB7l5aaQN:00001eY6 X-Return-Path: prvs=1282ce1966=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 19 Apr 2017 17:25:04 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) References: <787AE7BB302AE849A7480A190F8B933009E4CD91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E4F72D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4AAAEBAF-E0D3-4B23-9780-7FDE8436CD77@google.com> <2D09D61DDFA73D4C884805CC7865E6114DB2A28E@GAALPA1MSGUSRBF.ITServices.sbc.com> <8714D043-F732-45ED-84F8-CEB40DFAA595@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 15:25:15 -0000 Hi Hans, Users will not need to choose, unless the ISP don=E2=80=99t have a provisio= ning system that does it, or the ISP tells them what to configure (which in= some places is still the way it works, unfortunately). I=E2=80=99ve seen even cases where each router is pre-configured by the ISP= before =E2=80=9Cshipping=E2=80=9D it to the customer, or the technician th= at installs it setup for the customer on-site. Ideally, the ISP decides which transition mech is going to use in the netwo= rk, so when user=E2=80=99s plugin the router, it should be configured by th= e provisioning system. Regards, Jordi =20 -----Mensaje original----- De: Hans Liu Responder a: Fecha: mi=C3=A9rcoles, 19 de abril de 2017, 16:55 Para: CC: "v6ops@ietf.org" Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6o= ps-rfc7084-bis-00) =20 =20 On Wed, Apr 19, 2017 at 6:00 PM, JORDI PALET MARTINEZ wrote: =20 So, how you will support customers (ISPs and retail) that need a router= with IPv6-only in the WAN, but still need IPv4 support in the LANs and to = talk to IPv4-only servers in the real Internet?=20 =20 =20 I'm not standing against all those transition protocols. For retail use= rs, IMHO, giving them a shopping list doesn't help as most of them don't kn= ow how to get it correctly configured. =20 =20 =20 =20 I don=E2=80=99t think adding more, if it is a SHOULD, will make it wors= t, is a guidance, because you participate in IETF, but there are many ISPs = and vendors that don=E2=80=99t do, so they don=E2=80=99t read all the RFCs = or understand the need for other transition mechanisms. Including them in t= his document means they will wake up and read more and then they will decid= e whatever they want to do, but at least, we provided a guidance in a singl= e document that introduces the =E2=80=9Cwhys and hows=E2=80=9D. =20 =20 =20 Including them in a single document as a clear guidance definitely will= help CE router vendors during the development. I actually appreciate the w= ork. However, I don't think that means we should obsolete 7084. =20 =20 =20 =20 Regards, Jordi =20 =20 -----Mensaje original----- De: v6ops en nombre de Hans Liu Responder a: Fecha: mi=C3=A9rcoles, 19 de abril de 2017, 11:51 Para: "STARK, BARBARA H" CC: "v6ops@ietf.org" , Hans Liu , Claire Cheng Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf= -v6ops-rfc7084-bis-00) =20 =20 =20 On Wed, Apr 19, 2017 at 2:48 AM, STARK, BARBARA H = wrote: =20 =20 =20 The current RFC 7084 very much took into account the consumer-orien= ted CE router vendors. CableLabs and BBF had already taken care of their me= mber operators. And RFC 7084 (in its current form) is still very relevant t= o those devices. =20 =20 =20 CE-router is not entirely provided by operators, it is still availa= ble in the retail market. Since RFC 6204, there have been only a few vendor= s follow RFC 7084 in their products, and even less submitted their implemen= tations for IPv6 CE-Router Ready Logo certification. IMHO, the more we add= into the specification the less vendor gonna follow it. That then doesn't = help IPv6 deployment. As a CE-router vendor that supports IPv6 in the ret= ail models, I used to support 6to4, 6in4, and 6rd, all three of them (and T= eredo pass-through, required by "Work with Vista" logo program. :p) in the = router in 2008. I gradually removed most transition protocols as I realize= d they are merely configured and used by users. I still don't understand w= hy 9 years later we want to add them back to the specification? =20 =20 =20 =20 The people pushing for this are representing operators who don=E2= =80=99t participate in BBF or have any great influence in CableLabs (I have= no idea if they are even members of CableLabs, though I hear CableLabs is = doing some work for non-US cable operators). =20 But I have to say that since the request seems to be to supply thes= e smaller operators with a shopping list of transition technologies they ca= n use as a reference when they go shopping, I think Mohamed=E2=80=99s sugge= stion of an update instead of -bis makes a lot of sense. I do think that ob= soleting RFC7084 with something that is a shopping list isn't very useful t= o anyone. =20 =20 =20 +1 =20 =20 =20 Barbara _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 =20 =20 =20 --=20 Instead of following the fashion, we lead it through. =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Apr 19 14:16: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 2CB681293D9 for ; Wed, 19 Apr 2017 14:15:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 NxPnoLUIJb8i for ; Wed, 19 Apr 2017 14:15:56 -0700 (PDT) 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 EC376129ABE for ; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id s22so17097730ybe.3 for ; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=upV80KC12V4hIAaF9bCzrG0Fr/GPrVML96VHHbRohAM=; b=slbvLTa8uctCuoLTjuo/yEW+kIUhpNPv4C6ajdUhqsTlUMbAnVv4IqtAtsyLujVne6 uUwMsko8eoPReIhecGdtJb+usV57i7/bn6UTCOrswaI6vtWqoasXICRoKjBm+KrlnsDq Zmx5QOCf2WEV97JBsEcJkPf/wrAHs/4OuOl+/6Lq0YgyOWGLD01TqFaOEVmJ9Awed0N9 W6/gGvOgyVk/P4cqWlWdCakvSzjZcr5WvdDd853Tj0uEeSHsnDYeeT7ihAr1wcA/Ye2D YKrbnPbCn1xBZKm7gQrR2E25XZyH+xHGM1wATIfrs3NFz+ZoBYJ5IkbiqCUD4htH08sz IR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=upV80KC12V4hIAaF9bCzrG0Fr/GPrVML96VHHbRohAM=; b=gTrXBYamKHWrtnwbJ60/a6QPB3fpsrOcC8VWQDP8q+vtuiA6hYQ4JmqjYXq/TR80yj N08XS8W7Ci8JMMlKBLqzP6bdqHj0sl6ayKcGhQboQdcfVVGNy+7Rp0mPuMmaIbDqZQSD nt5AqpBP3zvkx6zt5fo6xqZ5regn8EQ/Pfi/giUr6wTs1fiXzqJrWIlqnV25AAf7ygDw c0l0Ck6/REd/KoxQe85EAHKcLV3vcUEify/d+bZD0zPEmW4km1VtkIhFGL2pyEScJvdD U1qYM+KkydT/F6KkyXjAHnNfqnhx/4dfte3DFFuWKR5GTVwVUVOsMVLzdfZIv+s7Sc4Y 6AOg== X-Gm-Message-State: AN3rC/7KzvWjnKcpL72oqsogfWYJnhq6N5TZ633xPdJcAXJQkkeLmbgk vBzXqZAwMT3y6EWh X-Received: by 10.84.213.8 with SMTP id f8mr6368822pli.156.1492636555084; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:2dd0:a83f:1f58:e25? ([2620:0:10e7:10:2dd0:a83f:1f58:e25]) by smtp.gmail.com with ESMTPSA id z123sm6223509pfz.56.2017.04.19.14.15.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 14:15:54 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Apr 2017 14:15:53 -0700 References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> To: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> In-Reply-To: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Message-Id: <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:15:58 -0000 --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 18, 2017, at 21:02, Brian E Carpenter = wrote: >=20 > ULAs are intended for scenarios where IP addresses are not globally > reachable, despite formally having global scope. They must not appear > in the routing system outside the administrative domain where they > are considered valid. Therefore, packets with ULA source and/or > destination addresses MUST be filtered at the domain boundary. I don=E2=80=99t think it's quite right yet. It=E2=80=99s greatly = improved, but I have a quibble. ULA are intended for scenarios where IP addresses are not *publicly* = reachable. Nothing about them constrains their private routing or usage = over any geographic area. They may appear as source or destination in = packets in transit across any private routing system, including any = system organized in a private multilateral agreement between domain = administrators. Therefore, packets with ULA source and/or destination addresses MUST be = filtered at the public boundary of a routing domain, and SHOULD be = filtered at private boundaries to limit their reachability according to = local policy. I would amend Brian=E2=80=99s proposed text for =C2=A72.1.2 Use of = Unique Local Addresses like so: >> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios = where IP addresses are not publicly reachable, despite their global = address scope. They MUST NOT appear in the default-free routing domain = of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize them. >>=20 >> Routing prefixes for ULA are /48 prefixes, and contain 40-bit = pseudo-random global identifiers. which are generated according to = [RFC4193]. They could be useful for infrastructure hiding as described = in [RFC4864]. They could also be useful for communication between hosts = in private routing domains, and private groups of autonomous routing = systems organized by multilateral agreement. Hosts that require = connectivity to the public Internet SHOULD communicate using publicly = routed general-unicast (GUA) addresses. No form of address translation = is required where ULA addresses for private connectivity are used in = conjunction with GUA addresses for public connectivity. >>=20 >> The usage of ULA as described here could simplify the filtering rules = needed at domain boundaries, by allowing a regime in which only hosts = that require communication with the public are assigned general-unicast = addresses (GUA). However, this does not remove the need for careful = design of filtering rules at domain boundaries. --james woodyatt > --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 18, 2017, at 21:02, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

ULAs are intended = for scenarios where IP addresses are not globally
reachable, despite formally having global scope. = They must not appear
in the routing = system outside the administrative domain where they
are considered valid. Therefore, packets with = ULA source and/or
destination = addresses MUST be filtered at the domain = boundary.

I don=E2=80=99t think it's quite right = yet. It=E2=80=99s greatly improved, but I have a quibble.

ULA are intended for = scenarios where IP addresses are not *publicly* reachable. Nothing about = them constrains their private routing or usage over any geographic area. = They may appear as source or destination in packets in transit across = any private routing system, including any system organized in a private = multilateral agreement between domain administrators.

Therefore, packets with = ULA source and/or destination addresses MUST be filtered at the public = boundary of a routing domain, and SHOULD be filtered at private = boundaries to limit their reachability according to local = policy.

I = would amend Brian=E2=80=99s proposed text for =C2=A72.1.2 Use of Unique = Local Addresses like so:

Unique = Local Addresses (ULA) [RFC4193] are intended for scenarios where IP = addresses are not publicly reachable, despite their global address = scope. They MUST NOT appear in the default-free routing domain of the = public Internet, and gateways at the boundaries of private routing = domains SHOULD NOT forward packets from or to ULA addresses where = multilateral transit agreements do not explicitly recognize = them.

Routing = prefixes for ULA are /48 prefixes, and contain 40-bit pseudo-random = global identifiers. which are generated according to [RFC4193]. They = could be useful for infrastructure hiding as described in [RFC4864]. = They could also be useful for communication between hosts in private = routing domains, and private groups of autonomous routing systems = organized by multilateral agreement. Hosts that require connectivity to = the public Internet SHOULD communicate using publicly routed = general-unicast (GUA) addresses. No form of address translation is = required where ULA addresses for private connectivity are used in = conjunction with GUA addresses for public = connectivity.

The usage of ULA as = described here could simplify the filtering rules needed at domain = boundaries, by allowing a regime in which only hosts that require = communication with the public are assigned general-unicast addresses = (GUA). However, this does not remove the need for careful design of = filtering rules at domain boundaries.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4-- From nobody Wed Apr 19 15:15: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 18DAC129BBF; Wed, 19 Apr 2017 15:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 D-v_44RrDoqq; Wed, 19 Apr 2017 15:15:18 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 F283F12950A; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id m36so31724130qtb.0; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) 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=vzEkAXCY7FJsIexOypcsXKg2PSMdDvJB6HZg5m7ycsY=; b=aAa/7HvZwtIO9iDkj9n8Wq/j6Z6d5qW/K1YhlFReMa5spVSM5Lo3a4Q/X/paYd+Nuv Np39u+hbcNpiaWwdoNzzefWslfbi6IZ6ToPpKoIp/36NQVLnWt6mS0rf+GCimKhS3Cen 8fF9sIibJZBxAx0h4hqPArvDKgXHbdmCvYMAbwq8FvJ9A8eHKdJgPObKwa3HaLqmzcnt xhwMegIcF9aKcMlEZYFRVzrrPTu2TeAfaGQRyRwHYfMldADWIA3Lx5Vkslkz5JFrnQSt QTRO51uS/COia7D1XcpThiQuOCqk8rKjPkIlayCIhLiLHXmxWtsz+r6PU0AuyGYbJ0Z6 5uLw== 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=vzEkAXCY7FJsIexOypcsXKg2PSMdDvJB6HZg5m7ycsY=; b=jspemVwp2VO3vuwU+SNgPdvphkDuVh6XSLFG5LFqU4Vky8Lm8tGOyBvVcKvJwKrEuR fKTekgg3b92fY7dE1QERLXZSB86zvu/ghOV2XLauFg6aL32+5gD4ZxZhcm+sFV4fg+o1 e9D/f4Pam0j6KQeLiVE+5G2KUF6+3IucVJxXAbvgEui75rkfK9GOCyKAgwKXUvc9Z50P J1BwjjiFtvc3FFDSkt+ae48nBDj10sSTPu6/YZ42EIdmN9Cr54tlz4+hrEk1dqHkMj68 DgSMJqhPUD7U9ephnpTEIY9uAHsxGZr3Zsr/BxUZHRR6oPxN1G4V67CrUKGdeUiDc4xR sHSQ== X-Gm-Message-State: AN3rC/4gahTRUbkhUCg27n5tMwpz7X306HebERuhpVEUdT0k9c953aRP UE+RsFpFtIMiG+BQtpvBPtFWaeHwWA== X-Received: by 10.237.57.170 with SMTP id m39mr4733481qte.163.1492640117020; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Wed, 19 Apr 2017 15:15:16 -0700 (PDT) In-Reply-To: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 19 Apr 2017 15:15:16 -0700 X-Google-Sender-Auth: pgHIftga7RlC6QZJwc-R8_B9WTQ Message-ID: To: Fernando Gont Cc: Ole Troan , Gunter Van De Velde , "opsec@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org Operations" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:15:19 -0000 At Tue, 18 Apr 2017 15:15:37 +0100, Fernando Gont wrote: > > You will probably save everyone a lot of energy if you just admit > > you had missed it, and moved on. > > Huh? > > I obviously missed it. But this should still be in RFC2460 (or > rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding > for IPv6 packets. > > Having important requirements spread into a number of documents where > they don't belong doesn't help, and in the long run takes more energy > (and creates more problems) than spending the energy in doing what is right. I see your point, but this is not the only case where a description in RFC4443 could also be in RFC2460 but isn't. Destination unreachable code 2 (Beyond scope of source address) is also related to forwarding, but it's not documented in RFC2460. Code 4 (Port unreachable) is a matter of upper layer consideration, but it's not documented in Section 8 of RFC2460. I'm sure there are more. In the ideal world we could make all these points perfect: everything is documented everywhere consistently with minimal redundancy or scattering but still avoiding to push everything in a single monster document. Obviously it's an impossible goal in the real world, and we should accept some level of redundancy or scattering (or even inconsistency as a matter of fact). In this particular case I personally think it's acceptable: the ICMPv6 specification is so fundamental, so I'd say it's reasonable to say that any serious implementer should read it carefully. There should always be someone who overlooks some particular point (like you missed this specific one), but that doesn't necessarily mean we should update the documentation so that that particular person would not have missed it. There would still be someone who miss it no matter redundantly we describe it. In that sense, I tend to agree with Ole. (But I wouldn't be opposed to making this in rfc2460bis either if that's the wg consensus, although at this moment no one else seems to think this is an issue to be fixed). -- JINMEI, Tatuya From nobody Wed Apr 19 15: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 C766B129BB0 for ; Wed, 19 Apr 2017 15:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YJs604lt8BYp for ; Wed, 19 Apr 2017 15:47:23 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 687C0129B75 for ; Wed, 19 Apr 2017 15:47:22 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id c45so32147876qtb.1 for ; Wed, 19 Apr 2017 15:47:22 -0700 (PDT) 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=E2woGOgy8yWSa+a4aikB5m5Bjiz8XnZVhJsGSL/Rw4o=; b=LWo5QvaqyWu9LCNeu0Zx9M0gJTBuszzn38sRM82eo8brayV3j9xSpaoOeRF7fgZrtK hDU/miiOTrleinmc/Gj3SLGWO1tRwmx/a/bd6AO7TlsFhr/gYr3yCxs3188DBDhvkwU4 UOkB/D1mz3cALI88oGesjbRrrRaCMX+h/5wtcAUa6zu32Df/0Duysb/NGJ8yf8LEfxvx m334B/u89yFyfrhF2KCftQCfctNQw38kt5Noixc5pH8KJVyrBXLYTKm/tlQMdantmMPh 7PNYkL7nADOm46vCxQvpbV4G3s+4h47hw+eHLWl8jbCxaA1jJtaeErgm60XZUj1IOHZB NGLg== 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=E2woGOgy8yWSa+a4aikB5m5Bjiz8XnZVhJsGSL/Rw4o=; b=QtQlOIATpbkt1ZjM0RjPqwRErR9+sDaZSV3hOTUHhMGTULcCDiYlBbl3xwClRBFNim xdJ62zFSRbd57UFbPy90sBa3TC3yCVuCEtY6uiQhIwEPGMVWocn2wOAmYtgU7WnHxoKc w0RJul2dLXDM6V7xX0PwXuktcNitSKufsL78KUpbA25EUtpVH7HL/ZMpB2DwlYbVjwjN iXPicUkhYscXnKSPOalEq9OAwOVhlIFzPENMic/sA+RKVmevk87jfBJVeZHBW+SHLrRB yyD7nlFfAIzd99wXpKszy0bCgIQhmp4DDlRih65I5Q6EDlc6ARQSaThS9fjqT5a3rD6+ X6ng== X-Gm-Message-State: AN3rC/4DbwCktgCk70MeTZmTqHGjGAgzlYDxaeOil6YNuPqv7UhRTYVy RdemlMqeemATYjrVHyc= X-Received: by 10.200.37.136 with SMTP id e8mr5154297qte.30.1492642041608; Wed, 19 Apr 2017 15:47:21 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 144sm2900007qkj.35.2017.04.19.15.47.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 15:47:20 -0700 (PDT) From: Ted Lemon Message-Id: <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Apr 2017 18:47:19 -0400 In-Reply-To: <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> Cc: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> To: james woodyatt References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:47:25 -0000 --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2017, at 5:15 PM, james woodyatt wrote: >>> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios = where IP addresses are not publicly reachable, despite their global = address scope. They MUST NOT appear in the default-free routing domain = of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize them. Changing the first "globally" to "publicly" isn't necessary. Actually, = I think this whole change just makes things less clear. Publicly and = globally mean the same thing. ULAs are never globally reachable. If = you have more than one site, and route ULAs between them, the ULAs have = to be routed over your private links, not over the public internet. I = get that in principle it may be possible to route your ULAs over a link = that also carries global traffic and that is not "your link," but it = would be better to clarify this in an additional paragraph; by adding = the text where you have, you are going to confuse the heck out of any = reader who doesn't know what a "multilateral link" is. --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 19, 2017, at 5:15 PM, james woodyatt <jhw@google.com> = wrote:
Unique Local Addresses (ULA) [RFC4193] are intended for = scenarios where IP addresses are not publicly reachable, despite their = global address scope. They MUST NOT appear in the default-free routing = domain of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize = them.

Changing the first "globally" to "publicly" isn't = necessary.  Actually, I think this whole change just makes things = less clear.   Publicly and globally mean the same thing.   = ULAs are never globally reachable.   If you have more than one = site, and route ULAs between them, the ULAs have to be routed over your = private links, not over the public internet.   I get that in = principle it may be possible to route your ULAs over a link that also = carries global traffic and that is not "your link," but it would be = better to clarify this in an additional paragraph; by adding the text = where you have, you are going to confuse the heck out of any reader who = doesn't know what a "multilateral link" is.

= --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045-- From nobody Wed Apr 19 17:10: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 B271E12EAC7; Wed, 19 Apr 2017 17:10:42 -0700 (PDT) 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 D-l0QNLey6Bu; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 7B6F112EAC9; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id k87so44229524ioi.0; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) 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=qRBkmVlojpaC+zC9sQ6BJdIGagwKnd2/TW+vRijJ9kg=; b=nD0YNrldyPrnH/7BO20sXQedBRpcCcukGgrN6pdwFvhfjnvSISucqEw9rFPl7Nx+Ri S7ltn7yyM/Rjx/gXNDNXKF1XHomGbKEw3BCVI/SI0agPml4eaUYSDMPT52WoCx5864kw ruCpNwb7cemvkssacRV9bZbepPZDg0ofWJhj5x7vEbMql6FE7LBFvoYwRpoaGuJsKW8x TdiykNNUoOEw9OUfAuOb4kGVbijewsK+ove8giVrjrqJ02aEFsvyUIjaxSMSSjh8oWE7 n9+QkNsEF01lnbC3UXSS4oDgdgiIhq6mGwtYXBVHSFXxj2ibehs6szGHS01ByuGKWJQk HSvw== 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=qRBkmVlojpaC+zC9sQ6BJdIGagwKnd2/TW+vRijJ9kg=; b=EZereMZ+3DtC0j1KgjsMwtYtGpHxg9KlzrNDzflpIMJRnxZZGWduIfEFFHmBThrJqk 7Fu+Jo0c2PM2KumrVydEbD+4pUTQVLKv+MIVfQyn2YGTT7NT1euezTRN8iNee9nppVmq 3xfN9tMz5pjHMiz8SPVjGjbIyWvaQoE532zcK1lESak3MCbaIv1bv7DI1vZn92U6Avb9 mkYuRwBTeKXCtmz/EfqlRGrM4EG1nyflLk039u759HOxmNcncM/YSmD9eF2SzU8phSiA n0ouG5IE0t88cAWdhYcNeMn6FvD3VzKPAFT0OeW2N3qCArZBNVQRy4OvpdMswCI/t3Ro A/Ig== X-Gm-Message-State: AN3rC/7OGAkJB1NSr1jJjvYoA7y0TGJv0AeklWeJWgTis9sYfBqT3m1T Ey+fb21VIaBBxg== X-Received: by 10.99.9.66 with SMTP id 63mr5519822pgj.22.1492647040098; Wed, 19 Apr 2017 17:10:40 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id j73sm6499308pfe.108.2017.04.19.17.10.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 17:10:39 -0700 (PDT) To: Ted Lemon , james woodyatt References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Cc: "opsec@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Apr 2017 12:10:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 00:10:43 -0000 On 20/04/2017 10:47, Ted Lemon wrote: > On Apr 19, 2017, at 5:15 PM, james woodyatt wrote: >>>> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios where IP addresses are not publicly reachable, despite their global address scope. They MUST NOT appear in the default-free routing domain of the public Internet, and gateways at the boundaries of private routing domains SHOULD NOT forward packets from or to ULA addresses where multilateral transit agreements do not explicitly recognize them. > > Changing the first "globally" to "publicly" isn't necessary. Actually, I think this whole change just makes things less clear. Publicly and globally mean the same thing. ULAs are never globally reachable. If you have more than one site, and route ULAs between them, the ULAs have to be routed over your private links, not over the public internet. I get that in principle it may be possible to route your ULAs over a link that also carries global traffic and that is not "your link," but it would be better to clarify this in an additional paragraph; by adding the text where you have, you are going to confuse the heck out of any reader who doesn't know what a "multilateral link" is. Also, "globally reachable" is a term of art in draft-bchv-rfc6890bis and in the new form of the IANA registry that it defines. Once that's final, there is work to do elsewhere (for example, the de facto meaning of "global" in the Python ipaddress module is plain wrong). So this is important terminology. I have no problem mentioning transit agreements, but I think James' SHOULD NOT should also be a MUST NOT. My routing friends tell me that there's no such thing as a true DFZ any more, too. Brian From nobody Thu Apr 20 02:36: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 0B86812EBC0 for ; Thu, 20 Apr 2017 02:36:47 -0700 (PDT) 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=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 I9NnQjdBDOVx for ; Thu, 20 Apr 2017 02:36:45 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7312EBC9 for ; Thu, 20 Apr 2017 02:36:45 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 20 Apr 2017 09:36:45 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D0743D788B; Thu, 20 Apr 2017 02:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=A8DopDBbrN6k35B7sS7g/PxbNsI=; b= RA20kG6Q+bgvDK2U3jgBUCXcFDA8e2gwacvxKGQ6XB1QEVBaxVaCFLXxQIYu+1Mg kaS7qvMG8O3BPuSpYtBg+iDaj6F4F5rtvuKhAgI16KG96KgXD24qbzN+xdwfPDnf 7lHtBKwfBxhJ66/HdSxepQomsS3iywxVn/p8spL9Hjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=ohe2x/u/wJwJT+J1bYUyG+j CZJbpk3CEA/hR7cFOG935BwOlvJ6qX2mVCMtMNwT3+SXvecxFObtb7iUu7JcyGX/ s32v58sU+Re+Z8wMhhJl7GRRcANcP4KnSimInz80ziJzvYuysJH7mIuURRAXAnaU tfv7t6A6OUyH2rNnXi2w= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 9C443D788A; Thu, 20 Apr 2017 02:36:44 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D8200AC1E674; Thu, 20 Apr 2017 11:36:41 +0200 (CEST) From: otroan@employees.org Message-Id: <52CAB2B8-86E6-4B6D-8977-E8B9EFAF49A4@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F0B0D115-8AFA-4302-9809-719BBA7E9709"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Apr 2017 11:36:41 +0200 In-Reply-To: Cc: v6ops@ietf.org To: jordi.palet@consulintel.es References: <149201230991.15796.10423245600175984626@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:36:47 -0000 --Apple-Mail=_F0B0D115-8AFA-4302-9809-719BBA7E9709 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jordi, > 1. LW4O6-5 changed to port-restricted to conform with [RFC7596]. > 2. MAPE-3 changed to port-restricted to conform with [RFC7597]. > 3. MAPT-3 changed to port-restricted to conform with [RFC7599]. MAPE-3: The IPv6 CE router MUST perform port-restricted IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated using = MAP-E. These MUST requirements are all wrong. All these mechanisms support full IPv4 address, or shared IPv4 address. Or IPv4 prefix. Ole --Apple-Mail=_F0B0D115-8AFA-4302-9809-719BBA7E9709 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY+IEpAAoJEL7aWKiYQt92rkIP/jdnhDSjFbA3v5seYpc6qN3w HFdjuLleYcrPfHNz9EZDWi9+MoToDiNUeT2w3lHq12R8EdjqScHMBM188J19pb2B K257TUDXkW8Do6xRoU2gOSiy/c1GMCbTOUDo9hgNW9KAr4RjWKLwoQsHQqNBYaRC uipHRy9xuII73HsY7qyW6M/cQ9ZiJirJS9pXk5rWKGLjZ3b3C99kAQ41JAkb0Yzm BYPQ+/ODFPEO7+bwUbfhrLCHJYtvfBRmUQ5dWT4l7DlGd5F7kt8XrRZnDSZmarHA VPqb7lM8t5vhKM7R/IcoP/8crGVa18dFhRbHS1zW1QdSK5FWiubc39g60sz29Bfs xJfbYk2kydqu9DpRsAwBwTACK2DltSh3ZAnDCBD004YRGv/Kkce6qlikBDCazLid gBGKsB/9Q0rPHrZ5Ogkwlk6EsNBfGOUg1iM5sD+zBKeX6uosg7kGQ5e/F1D57KNx w7R+XLiY3FdS0TdqtdbgIlnfVMXiOkvmaqO6tJbsQpPoCSuMOE9Av5vzMyGkFld1 kkWl49MXVf2UevjMvFioj8hQCgz6uFdWdP6ZFdGRwWK3vI1DJ8GsXI0SQ9TOhraK dMWZfzApVF+AVdbYP2UH5sgLATJ9AqXyRI6umgT0nQ1qpIRRDz4s3qCHsKrZnqYP b9VN2uP22F8YwNkp0OYp =9m7U -----END PGP SIGNATURE----- --Apple-Mail=_F0B0D115-8AFA-4302-9809-719BBA7E9709-- From nobody Thu Apr 20 02:55: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 15D8912EC51 for ; Thu, 20 Apr 2017 02:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Qigtnw5E5yr for ; Thu, 20 Apr 2017 02:54:57 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8234612EC4E for ; Thu, 20 Apr 2017 02:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492682095; x=1493286895; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=ChdNZBEtyLDwwXfc1hzWUmab8 NtFKZsFeFyWi8jWHhc=; b=JNVpXrUL4qKd7BNOKKtlJBXlybCLq6v+Su7HRkhDD FnXOmtS8pAwwlNjGY4b1ZRBfKWPgZnxzUrN6GDEQtyS0xaFWLJlMvwXn25kuVFbb +vGyrNX6qB/KD/xsCEJfdJKTBcqWmz6r9ivfiDo282Sr1o+jPz0EvwOcDnACSmLc /k= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ghbhZIO2J8uhaV8Mr40jKpWwHpWSV0IvCTAZWYQg11PFO9T/ORt6p2gFfUAx m3ycYMO86gQwPP3SAjdURv6I68NTcaY1C2Fv4fJQ1RbTkiXE/U8xrtCnX qI5YvGGVLeP/cXo2w402XzF5RGGyKu9U+yqVFMrbXi3iupFD3NE/5k=; X-MDAV-Processed: mail.consulintel.es, Thu, 20 Apr 2017 11:54:55 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 20 Apr 2017 11:54:54 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005411574.msg for ; Thu, 20 Apr 2017 11:54:54 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170420:md50005411574::WMkCkrVoKyCRTP5h:00002OYn X-Return-Path: prvs=12830127ab=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 20 Apr 2017 11:54:54 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <9098F32C-8CE3-496E-BD3A-AC400E4AF620@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt References: <149201230991.15796.10423245600175984626@ietfa.amsl.com> <52CAB2B8-86E6-4B6D-8977-E8B9EFAF49A4@employees.org> In-Reply-To: <52CAB2B8-86E6-4B6D-8977-E8B9EFAF49A4@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:55:00 -0000 Hi Ole, Initially I didn=E2=80=99t include such point, because I know you can alloc= ate in the 3 mechs full or shared IPv4 addresses. However, Mohamed pointed me to the =E2=80=9Cport-restricted=E2=80=9D notati= on in the RFC of those mechs. May be the question is just a clarification of how to say it. I think we ha= ve 3 choices (actual is 1): 1) The IPv6 CE router MUST perform port-restricted IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated using M= AP-E. 2) The IPv6 CE router MUST perform IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated using M= AP-E. 3) The IPv6 CE router MUST perform IPv4 Network Address Translation (NAT), including support for port-restrict= ed mode, on IPv4 traffic encapsulated using MAP-E. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: jueves, 20 de abril de 2017, 11:36 Para: CC: Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt Jordi, =20 > 1. LW4O6-5 changed to port-restricted to conform with [RFC7596]. > 2. MAPE-3 changed to port-restricted to conform with [RFC7597]. > 3. MAPT-3 changed to port-restricted to conform with [RFC7599]. =20 MAPE-3: The IPv6 CE router MUST perform port-restricted IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated usin= g MAP-E. =20 These MUST requirements are all wrong. All these mechanisms support full IPv4 address, or shared IPv4 address. Or IPv4 prefix. =20 Ole =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Apr 20 02:59: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 D40B812EC98 for ; Thu, 20 Apr 2017 02:59:37 -0700 (PDT) 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=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 nH0YKvIXyHSV for ; Thu, 20 Apr 2017 02:59:36 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F812EC9F for ; Thu, 20 Apr 2017 02:59:35 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 20 Apr 2017 09:59:34 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 382FCD788D; Thu, 20 Apr 2017 02:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=5tlj5ISnlTlMrCxUgUss5tbnCpk=; b= iCj56nQsQ0mj7BYQWfqgMDEZt7FG+/YvL8m+vDl2uYqr2R9lmnrQM8rhO7vYuUiu tUkyeovZwBYikC8wW8H6m55yIOJs0Q2LG5jNMZZgZMIyoAUGHZ/Nnslza46erzLq XlgV8ikylMw9L8ZMf091BSRGkcNEjFv7F0Ez7H5U8Gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=DGdMVT87qG831l85o+vF2iD qiWtNN1wDYAZ6IMUQMOaWpm67H5rMflJ/DZLK18pMA1ltON9hLpgWm/9RrdNpJSz /Qo6FY6+ZrXoVybxhkVRjV6QuB/6IQrtDIXgT6q0T79Ec7PBQ4uKYvSx6Db4aAR2 g7Rowyk364Yh1SKe1XX8= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 0C002D788A; Thu, 20 Apr 2017 02:59:34 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7E8EFAC249DA; Thu, 20 Apr 2017 11:59:32 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7D621F60-FF33-4CE7-9293-517D719C8E82"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Apr 2017 11:59:31 +0200 In-Reply-To: <9098F32C-8CE3-496E-BD3A-AC400E4AF620@consulintel.es> Cc: v6ops@ietf.org To: jordi.palet@consulintel.es References: <149201230991.15796.10423245600175984626@ietfa.amsl.com> <52CAB2B8-86E6-4B6D-8977-E8B9EFAF49A4@employees.org> <9098F32C-8CE3-496E-BD3A-AC400E4AF620@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:59:38 -0000 --Apple-Mail=_7D621F60-FF33-4CE7-9293-517D719C8E82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jordi, > Initially I didn=E2=80=99t include such point, because I know you can = allocate in the 3 mechs full or shared IPv4 addresses. >=20 > However, Mohamed pointed me to the =E2=80=9Cport-restricted=E2=80=9D = notation in the RFC of those mechs. >=20 > May be the question is just a clarification of how to say it. I think = we have 3 choices (actual is 1): >=20 > 1) The IPv6 CE router MUST perform port-restricted IPv4 Network > Address Translation (NAT) on IPv4 traffic encapsulated = using MAP-E. >=20 > 2) The IPv6 CE router MUST perform IPv4 Network > Address Translation (NAT) on IPv4 traffic encapsulated = using MAP-E. >=20 > 3) The IPv6 CE router MUST perform IPv4 Network > Address Translation (NAT), including support for = port-restricted mode, > on IPv4 traffic encapsulated using MAP-E. No. These are all wrong. This is where things go bad when you try to restate what's written in = existing specifications. Just reference the MAP-E RFC if you want to say something, instead of = making faulty requirements. Ole --Apple-Mail=_7D621F60-FF33-4CE7-9293-517D719C8E82 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY+IaEAAoJEL7aWKiYQt92fDAQAKMQIHMB/ad3B11UFJ9XII6d S3rbVbqIMbiOpuE09WoobWsGtB5h8w2UgARMbvuB6PXphWVveKA9lSBw1VHtDnoQ KVd9fdxDjJWn3lLuRio2UVc9Btn/jyu1xqiJRllZ1u2SHYRKnF3XpRfgfd8fqiIZ 3MpKOXEpUCpR8UqMi6BRwSUwWyOZc+RR7vv/cXirECekLx+xl6QPjIRWdgS3Ah7t e/8zTmaCcCp53nQUVwjCixB5eJuyiTwpHBAbCDdYLmMBTA4xTdkWe4dlinyveGHB gqiTQadlb3ojCHJZhlXIFv4R+183PBK8RsQFyaSyj4/OF4/62xhKXrsCnQMAAcqO /XAseUE9wyLAYidrXvGtKVB/DwXSMbcO4qILMdmL2HNRHlrkCdbwZybYO0caPu+N 4zqFBUR+9b2qskDyBUp45D5OggNuunjzgsZJ/SLKGdVI16x1qq5yiFzCymuKmXaN wdhbSWTgFjmNGStzlcYxQlCd41etdZPyOwNOa2WxIlZK+5phKdQMZbUR8ej0UaTr qq4jiDmswQX72xkudZhV1IpRvv4zHcQgkaA8wYAL+77nuKiExAFs7Hr1+oPtkB31 6zIitqIp6sNKch7IUhaG+Qnl5lGh0NIrog6iniIimGGDbfeX4249CQ5BK3KmDLjo jeNp5nyw2OD5izmq/ElL =HfDT -----END PGP SIGNATURE----- --Apple-Mail=_7D621F60-FF33-4CE7-9293-517D719C8E82-- From nobody Thu Apr 20 04: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 B13CF129B06 for ; Thu, 20 Apr 2017 04:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 VtnCTnpS8RmM for ; Thu, 20 Apr 2017 04:34:20 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C9A129494 for ; Thu, 20 Apr 2017 04:34:19 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 3942318044B; Thu, 20 Apr 2017 13:34:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 0D4992006F; Thu, 20 Apr 2017 13:34:18 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 13:34:17 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt Thread-Index: AQHSubwz3L4zTyQSuUK9SVteUCFI1aHOHxBw Date: Thu, 20 Apr 2017 11:34:17 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E513CA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149201230991.15796.10423245600175984626@ietfa.amsl.com> <52CAB2B8-86E6-4B6D-8977-E8B9EFAF49A4@employees.org> <9098F32C-8CE3-496E-BD3A-AC400E4AF620@consulintel.es> In-Reply-To: <9098F32C-8CE3-496E-BD3A-AC400E4AF620@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 11:34:22 -0000 Sm9yZGksIA0KDQpUaGUgc3VnZ2VzdGlvbiBJIG1hZGUgaXMgdG8gcmV1c2UgdGhlIHdvcmRpbmcg aW4gdGhlIGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9ucy4gSSdtIGNvcHlpbmcvcGFzdGluZyB0aGF0 IGNvbW1lbnQgaGVyZTogDQoNCj09PT0NCltNZWRdIEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1l bnRzIGFib3V0IHRoZSBOQVQgcmVxdWlyZW1lbnRzOg0KDQpPTEQ6DQogICBMVzRPNi00OiAgVGhl IElQdjYgQ0Ugcm91dGVyIE1VU1QgcGVyZm9ybSBJUHY0IE5ldHdvcmsgQWRkcmVzcw0KICAgICAg ICAgICAgIFRyYW5zbGF0aW9uIChOQVQpIG9uIElQdjQgdHJhZmZpYyBlbmNhcHN1bGF0ZWQgdXNp bmcgbHc0bzYuDQoNClRoaXMgb25lIHNob3VsZCBtZW50aW9uIHBvcnQgcmVzdHJpY3RlZCBOQVQu IEZXSVcsIHlvdSBjYW4gcmV1c2UgdGhlIHNhbWUgd29yZGluZyBpbiBSRkM3NTk2Og0KDQoiICBB biBsd0I0IE1VU1Qgc3VwcG9ydCBkeW5hbWljIHBvcnQtcmVzdHJpY3RlZCBJUHY0IGFkZHJlc3MN CiAgIHByb3Zpc2lvbmluZy4gIFRoZSBwb3J0LXNldCBhbGdvcml0aG0gZm9yIHByb3Zpc2lvbmlu ZyB0aGlzIGlzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjEgb2YgW1JGQzc1OTddLiAgRm9y IGx3NG82LCB0aGUgbnVtYmVyIG9mDQogICBhLWJpdHMgU0hPVUxEIGJlIDAsIHRodXMgYWxsb2Nh dGluZyBhIHNpbmdsZSBjb250aWd1b3VzIHBvcnQgc2V0IHRvDQogICBlYWNoIGx3QjQuIiANCg0K DQpPTEQ6DQogICBNQVAqLTQ6ICBUaGUgSVB2NiBDRSByb3V0ZXIgTVVTVCBwZXJmb3JtIElQdjQg TmV0d29yayBBZGRyZXNzDQogICAgICAgICAgICBUcmFuc2xhdGlvbiAoTkFUKSBvbiBJUHY0IHRy YWZmaWMgZW5jYXBzdWxhdGVkIHVzaW5nIE1BUC0qLg0KDQpJZGVtIGFzIGFib3ZlLiBQb3J0LXJl c3RyaWN0ZWQgTkFUIHNob3VsZCBiZSBtZW50aW9uZWQgZXhwbGljaXRseS4gWW91IGNhbiByZXVz ZSB0aGlzIHRleHQgZnJvbSBSRkM3NTk3L1JGQzc1OTk6DQoNCiAgIFRoZSBOQVQ0NCBpbXBsZW1l bnRlZCBpbiB0aGUgTUFQIENFIFNIT1VMRCBjb25mb3JtIHRvIHRoZSBiZWhhdmlvcg0KICAgYW5k IGJlc3QgY3VycmVudCBwcmFjdGljZXMgZG9jdW1lbnRlZCBpbiBbUkZDNDc4N10sIFtSRkM1NTA4 XSwgYW5kDQogICBbUkZDNTM4Ml0uICBJbiBNQVAgYWRkcmVzcy1zaGFyaW5nIG1vZGUgKGRldGVy bWluZWQgYnkgdGhlIE1BUA0KICAgZG9tYWluIC8gcnVsZSBjb25maWd1cmF0aW9uIHBhcmFtZXRl cnMpLCB0aGUgb3BlcmF0aW9uIG9mIHRoZSBOQVQ0NA0KICAgTVVTVCBiZSByZXN0cmljdGVkIHRv IHRoZSBhdmFpbGFibGUgcG9ydCBudW1iZXJzIGRlcml2ZWQgdmlhIHRoZQ0KICAgQmFzaWMgTWFw cGluZyBSdWxlLg0KPT09PQ0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gRGXCoDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIEpPUkRJIFBBTEVUDQo+IE1BUlRJTkVaDQo+IEVudm95w6nCoDogamV1ZGkg MjAgYXZyaWwgMjAxNyAxMTo1NQ0KPiDDgMKgOiB2Nm9wc0BpZXRmLm9yZw0KPiBPYmpldMKgOiBS ZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXJmYzcwODQtYmlzLTAxLnR4 dA0KPiANCj4gSGkgT2xlLA0KPiANCj4gSW5pdGlhbGx5IEkgZGlkbuKAmXQgaW5jbHVkZSBzdWNo IHBvaW50LCBiZWNhdXNlIEkga25vdyB5b3UgY2FuIGFsbG9jYXRlIGluDQo+IHRoZSAzIG1lY2hz IGZ1bGwgb3Igc2hhcmVkIElQdjQgYWRkcmVzc2VzLg0KPiANCj4gSG93ZXZlciwgTW9oYW1lZCBw b2ludGVkIG1lIHRvIHRoZSDigJxwb3J0LXJlc3RyaWN0ZWTigJ0gbm90YXRpb24gaW4gdGhlIFJG Qw0KPiBvZiB0aG9zZSBtZWNocy4NCj4gDQo+IE1heSBiZSB0aGUgcXVlc3Rpb24gaXMganVzdCBh IGNsYXJpZmljYXRpb24gb2YgaG93IHRvIHNheSBpdC4gSSB0aGluayB3ZQ0KPiBoYXZlIDMgY2hv aWNlcyAoYWN0dWFsIGlzIDEpOg0KPiANCj4gMSkgCVRoZSBJUHY2IENFIHJvdXRlciBNVVNUIHBl cmZvcm0gcG9ydC1yZXN0cmljdGVkIElQdjQgTmV0d29yaw0KPiAgICAgICAgICAgICAgQWRkcmVz cyBUcmFuc2xhdGlvbiAoTkFUKSBvbiBJUHY0IHRyYWZmaWMgZW5jYXBzdWxhdGVkIHVzaW5nDQo+ IE1BUC1FLg0KPiANCj4gMikJVGhlIElQdjYgQ0Ugcm91dGVyIE1VU1QgcGVyZm9ybSBJUHY0IE5l dHdvcmsNCj4gICAgICAgICAgICAgIEFkZHJlc3MgVHJhbnNsYXRpb24gKE5BVCkgb24gSVB2NCB0 cmFmZmljIGVuY2Fwc3VsYXRlZCB1c2luZw0KPiBNQVAtRS4NCj4gDQo+IDMpCVRoZSBJUHY2IENF IHJvdXRlciBNVVNUIHBlcmZvcm0gSVB2NCBOZXR3b3JrDQo+ICAgICAgICAgICAgICBBZGRyZXNz IFRyYW5zbGF0aW9uIChOQVQpLCBpbmNsdWRpbmcgc3VwcG9ydCBmb3IgcG9ydC0NCj4gcmVzdHJp Y3RlZCBtb2RlLA0KPiAgICAgICAgb24gSVB2NCB0cmFmZmljIGVuY2Fwc3VsYXRlZCB1c2luZyBN QVAtRS4NCj4gDQo+IA0KPiBSZWdhcmRzLA0KPiBKb3JkaQ0KPiANCj4gDQo+IC0tLS0tTWVuc2Fq ZSBvcmlnaW5hbC0tLS0tDQo+IERlOiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+DQo+IFJlc3BvbmRl ciBhOiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+DQo+IEZlY2hhOiBqdWV2ZXMsIDIwIGRlIGFicmls IGRlIDIwMTcsIDExOjM2DQo+IFBhcmE6IDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4NCj4g Q0M6IDx2Nm9wc0BpZXRmLm9yZz4NCj4gQXN1bnRvOiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXY2b3BzLXJmYzcwODQtYmlzLTAxLnR4dA0KPiANCj4gICAgIEpvcmRpLA0KPiAN Cj4gICAgID4gMS4gTFc0TzYtNSBjaGFuZ2VkIHRvIHBvcnQtcmVzdHJpY3RlZCB0byBjb25mb3Jt IHdpdGggW1JGQzc1OTZdLg0KPiAgICAgPiAyLiBNQVBFLTMgY2hhbmdlZCB0byBwb3J0LXJlc3Ry aWN0ZWQgdG8gY29uZm9ybSB3aXRoIFtSRkM3NTk3XS4NCj4gICAgID4gMy4gTUFQVC0zIGNoYW5n ZWQgdG8gcG9ydC1yZXN0cmljdGVkIHRvIGNvbmZvcm0gd2l0aCBbUkZDNzU5OV0uDQo+IA0KPiAg ICAgTUFQRS0zOiAgVGhlIElQdjYgQ0Ugcm91dGVyIE1VU1QgcGVyZm9ybSBwb3J0LXJlc3RyaWN0 ZWQgSVB2NCBOZXR3b3JrDQo+ICAgICAgICAgICAgICAgICBBZGRyZXNzIFRyYW5zbGF0aW9uIChO QVQpIG9uIElQdjQgdHJhZmZpYyBlbmNhcHN1bGF0ZWQNCj4gdXNpbmcgTUFQLUUuDQo+IA0KPiAg ICAgVGhlc2UgTVVTVCByZXF1aXJlbWVudHMgYXJlIGFsbCB3cm9uZy4NCj4gICAgIEFsbCB0aGVz ZSBtZWNoYW5pc21zIHN1cHBvcnQgZnVsbCBJUHY0IGFkZHJlc3MsIG9yIHNoYXJlZCBJUHY0DQo+ IGFkZHJlc3MuDQo+ICAgICBPciBJUHY0IHByZWZpeC4NCj4gDQo+ICAgICBPbGUNCj4gDQo+IA0K PiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0 ID8NCj4gaHR0cDovL3d3dy5jb25zdWxpbnRlbC5lcw0KPiBUaGUgSVB2NiBDb21wYW55DQo+IA0K PiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkg YmUgcHJpdmlsZWdlZCBvcg0KPiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRl bmRlZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUNCj4gaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92 ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZQ0KPiB0aGF0 IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250 ZW50cyBvZiB0aGlzDQo+IGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlz IHByb2hpYml0ZWQuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu Apr 20 17:00:53 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 693BA120326; Thu, 20 Apr 2017 17:00:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149273284642.22377.7722556001299500657.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 17:00:46 -0700 Archived-At: Subject: [v6ops] v6ops - Update to a Meeting Session Request for IETF 99 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 00:00:46 -0000 An update to a meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man 6lo 6tisch homenet opsawg anima isis Second Priority: intarea opsec mtgvenue Third Priority: dnsop tsvwg People who must be present: Fred Baker Joel Jaeggli Ron Bonica Lee Howard Warren Kumari Resources Requested: Special Requests: Please meet on Monday-Wednesday --------------------------------------------------------- From nobody Thu Apr 20 17:02:12 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDDF120326; Thu, 20 Apr 2017 17:02:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149273293132.22306.5878999367744877446.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 17:02:11 -0700 Archived-At: Subject: [v6ops] v6ops - Update to a Meeting Session Request for IETF 99 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 00:02:11 -0000 An update to a meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man 6lo 6tisch homenet opsawg anima isis Second Priority: opsec intarea mtgvenue bmwg Third Priority: dnsop tsvwg People who must be present: Fred Baker Joel Jaeggli Ron Bonica Lee Howard Warren Kumari Resources Requested: Special Requests: Please meet on Monday-Wednesday --------------------------------------------------------- From nobody Thu Apr 20 17:03:06 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE79129BCD; Thu, 20 Apr 2017 17:03:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149273298462.22323.10462471856172611791.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 17:03:04 -0700 Archived-At: Subject: [v6ops] v6ops - Update to a Meeting Session Request for IETF 99 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 00:03:05 -0000 An update to a meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man 6lo 6tisch homenet opsawg anima isis Second Priority: mtgvenue intarea opsec bmwg sunset4 Third Priority: dnsop tsvwg People who must be present: Fred Baker Joel Jaeggli Ron Bonica Lee Howard Warren Kumari Resources Requested: Special Requests: Please meet on Monday-Wednesday --------------------------------------------------------- From nobody Fri Apr 21 06:54: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 13407128C81 for ; Fri, 21 Apr 2017 06:54:24 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7bK66z82yV0Q for ; Fri, 21 Apr 2017 06:54:22 -0700 (PDT) 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 0D459120227 for ; Fri, 21 Apr 2017 06:54:22 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E3125AD; Fri, 21 Apr 2017 15:54:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492782859; bh=FVoY53t5Dh6oy8hHKNz/ojUS+jKxHpUk69DG/g5eyKo=; h=Date:From:To:Subject:In-Reply-To:References:From; b=22HNn/hGvMMGQyz/1eDEhcXsniOB4lu0SUm30ndN/DiDjf8M39Q7flxq76CLpNYcs 9SffIhSYji2N37K6yG9OoLvp5lCqTrsKdW952bLZTeRHoaVK9now19UnI/v/+KzQhY BRUz70Tq88QbJFW4HDwRUioEVIOOXYdNPQ3zM/FM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E0785A6 for ; Fri, 21 Apr 2017 15:54:19 +0200 (CEST) Date: Fri, 21 Apr 2017 15:54:19 +0200 (CEST) From: Mikael Abrahamsson To: IPv6 Ops WG In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 13:54:24 -0000 On Wed, 22 Mar 2017, Ron Bonica wrote: > 3) The title of Section 5.3 is "Maximum Transmission Unit and Jumbo > Frames". However, there is no further mention of Jumbo Frames. Could we > explore Jumbo's possibly with an eye towards deprecation. I am strongly in favour of support of jumbo frames. I would like to see the document specify an L3 MTU of 9180 as its SHOULD requirement. All major core router vendor supports this today. The reason for 9180 is that this is what RFC2225, RFC2492, RFC1209 mention. Other comments: 3.3 It would be good if the draft referenced for instance RFC8071 for Netconf-call-home and draft-ietf-netconf-zerotouch-13 for zerotouch plug'n'play provisioning. 5.4. The ICMP ECHO/REPLY requirement here opposes what's in RFC4890. I prefer what RFC4890 says. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Apr 21 08:21: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 EC6B2129516 for ; Fri, 21 Apr 2017 08:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2jLrefbZa-L for ; Fri, 21 Apr 2017 08:20:59 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0116.outbound.protection.outlook.com [104.47.33.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EE3127868 for ; Fri, 21 Apr 2017 08:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iMi0hzM3zE69qeTn1AF2CKviqhyHc4vMktwrCxCTDeM=; b=GfQrMMqpFbJXR4MRQGBBYRZ8SbmhYhumkXeKM9h/Jt8wiuS/PfZmfeQBByVzW1VK/rmaqBU44tJlM8PcEAAooetkmpPb0ZLfX+69/h/yM6HJvoA9j8KFFnvE6IWCq3+TIoj40KkVC9ZysUJEt2nbd2qKaLfhn38kZpKXQCco7Ic= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Fri, 21 Apr 2017 15:20:57 +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.1047.013; Fri, 21 Apr 2017 15:20:56 +0000 From: Ron Bonica To: Mikael Abrahamsson , IPv6 Ops WG Thread-Topic: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 Thread-Index: AdKjJhGQY5pAI/PHRFaFoUctqzGS6gXgLQOAAAL819A= Date: Fri, 21 Apr 2017 15:20:56 +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: swm.pp.se; dkim=none (message not signed) header.d=none;swm.pp.se; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 7:iYS8i5NE2KQZgGGAOd6vxvxiRFPp9IIA7hyi7ZzJNCTA1fnqjiCR+90nszFgDZZ2p2FdMfMR+0HJ1gGflm3x3IEDdgVKOoTkdZaWKGf0hPDNc0CkQbXTR33siFljp8O0IzkiAs6g43Tv0w6OXapmkuLdMA6xXjBiPHAcVttOc0zyZmPqJYSA499Gz1gbaaAECTHZJ7kdyV342d5Fpct7Cxe9qWDxDGo5XuA0YwkqUOxA2OiykUVVRWfg4eBLXVCghyZ0AzjyqprlIy6TKmfYU8Fe+djhpQsnYX93wdP7+g0taAsVxj6M7GXed2D6nQClLiP6iv/vna+8vFgyx67dtA== x-ms-office365-filtering-correlation-id: 293eefdd-74db-4770-c82a-08d488ca0248 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR0501MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(377454003)(13464003)(24454002)(252514010)(3660700001)(230783001)(2900100001)(7696004)(8676002)(8936002)(229853002)(3280700002)(6246003)(7736002)(305945005)(122556002)(38730400002)(74316002)(66066001)(9686003)(86362001)(189998001)(5660300001)(77096006)(3846002)(102836003)(6116002)(33656002)(2950100002)(2906002)(81166006)(6506006)(54356999)(6306002)(6436002)(25786009)(53936002)(53546009)(50986999)(55016002)(99286003)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 21 Apr 2017 15:20:56.8057 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052 Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:21:01 -0000 Hi Mikael, When I made the comment that you quote, I was confusing Jumbo Frames with J= umbograms. = Sorry, = Ron > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael > Abrahamsson > Sent: Friday, April 21, 2017 9:54 AM > To: IPv6 Ops WG > Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 >=20 > On Wed, 22 Mar 2017, Ron Bonica wrote: >=20 > > 3) The title of Section 5.3 is "Maximum Transmission Unit and Jumbo > > Frames". However, there is no further mention of Jumbo Frames. Could > > we explore Jumbo's possibly with an eye towards deprecation. >=20 > I am strongly in favour of support of jumbo frames. >=20 > I would like to see the document specify an L3 MTU of 9180 as its SHOULD > requirement. All major core router vendor supports this today. The reason > for 9180 is that this is what RFC2225, RFC2492, RFC1209 mention. >=20 > Other comments: >=20 > 3.3 It would be good if the draft referenced for instance RFC8071 for > Netconf-call-home and draft-ietf-netconf-zerotouch-13 for zerotouch > plug'n'play provisioning. >=20 > 5.4. The ICMP ECHO/REPLY requirement here opposes what's in RFC4890. I > prefer what RFC4890 says. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 21 10:49: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 6AA42129B55 for ; Fri, 21 Apr 2017 10:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 U3Z6mVc-FPGn for ; Fri, 21 Apr 2017 10:49:52 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 401011294AC for ; Fri, 21 Apr 2017 10:49:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v3LHnmDK030568; Fri, 21 Apr 2017 19:49:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DB2FC209DE4; Fri, 21 Apr 2017 19:49:48 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BB7DA209D97; Fri, 21 Apr 2017 19:49:48 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v3LHnm7q016736; Fri, 21 Apr 2017 19:49:48 +0200 To: Mark Andrews , Nicolas Antoniello References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <5c1c487f-730f-dea0-b3e0-1a47e33fafac@gmail.com> <20170418233550.830F86BFE8E6@rock.dv.isc.org> Cc: IPv6 Ops WG From: Alexandre Petrescu Message-ID: <6213fff1-f92a-d80b-e2b7-aec51f2c7467@gmail.com> Date: Fri, 21 Apr 2017 19:49:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170418233550.830F86BFE8E6@rock.dv.isc.org> Content-Type: multipart/alternative; boundary="------------50D3CEC31698762AE7DF69F1" Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:49:54 -0000 This is a multi-part message in MIME format. --------------50D3CEC31698762AE7DF69F1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 19/04/2017 à 01:35, Mark Andrews a écrit : > > In message > > , Nicolas Antoniello writes: >> >> Just to do some philosophy here: why should any ISP give as much >> as a /4x (with x = whatever) while there is almost no domestic CPE >> that even if they can handle that /4x delegation they do not give >> the "common" user the possibility to divide or decide anything >> about the subnetting of her/his networks... with this I mean if we >> possible have to make an effort in telling the CPEs industry that >> they have to start thinking in equipments and interfaces that make >> that process of deciding about my own network a funny and easy >> task? (may be this should be enforced in some or though some BCPs >> or RFCs). >> >> Regards, Nicolas > > I already have 3 /64s connected to my CPE router. I have 8 such /64s :-) My DSL operator "free" 'delegates' my DSL box a fixed /56 and provides me a GUI, shown below, to manually configure 8 /64 routes towards the IPv6 address of in-home routers. It is great that I can have many /64s in-home. But I dont like that I have to manually configure these route entries, even though it's a GUI. And I dont like that there is no freedom in deciding maybe a /63 towards an IP (GUI form hardcodes '/64'). > One for the wired net, one for the 5G WiFi and one for the 2G WiFi. > If I had a second router it can request the /64's it needs for its > downstream interfaces from the CPE router. I don't need to do a > address plan. The CPE works it out. When a second router is > connected, it too will work it out based on the prefixes it gets > from the CPE router. Or when I add a virtual network and router on > one of the machines for testing. > > Yes, there will end up being lots of /64 routes installed. That > really doesn't matter however as the hardware is more than capable > of handling it. > > My IPv6 ISP (HE) gives me a /48. I can do all this because they are > not stingy. > > You needed a address plan with IPv4 because there were not enough > addresses to go around so you had to size each subnet differently. > > With IPv6 you just give each subnet a /64 and let the routing sort > out how to deliver the packets. I read it, and disagree with some parts. Alex > > Mark > --------------50D3CEC31698762AE7DF69F1 Content-Type: multipart/related; boundary="------------7E05D27D981DE1695B9825F2" --------------7E05D27D981DE1695B9825F2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Le 19/04/2017 à 01:35, Mark Andrews a écrit :
> > In message > <CADHEbK9P4vMf=Qk7fkorej2xQ8315ejTxy9B1brb7zs0yH0_DQ@mail.gmail.com> > , Nicolas Antoniello writes: >> >> Just to do some philosophy here: why should any ISP give as much >> as a /4x (with x = whatever) while there is almost no domestic CPE >> that even if they can handle that /4x delegation they do not give >> the "common" user the possibility to divide or decide anything >> about the subnetting of her/his networks... with this I mean if we >> possible have to make an effort in telling the CPEs industry that >> they have to start thinking in equipments and interfaces that make >> that process of deciding about my own network a funny and easy >> task? (may be this should be enforced in some or though some BCPs >> or RFCs). >> >> Regards, Nicolas > > I already have 3 /64s connected to my CPE router.

I have 8 such /64s :-)

My DSL operator "free" 'delegates' my DSL box a fixed /56 and provides me a GUI, shown below, to manually configure 8 /64 routes towards the IPv6 address of in-home routers.

It is great that I can have many /64s in-home. 

But I dont like that I have to manually configure these route entries, even though it's a GUI.

And I dont like that there is no freedom in deciding maybe a /63 towards an IP (GUI form hardcodes '/64').



> One for the wired net, one for the 5G WiFi and one for the 2G WiFi. > If I had a second router it can request the /64's it needs for its > downstream interfaces from the CPE router.  I don't need to do a > address plan.  The CPE works it out.  When a second router is > connected, it too will work it out based on the prefixes it gets > from the CPE router.  Or when I add a virtual network and router on > one of the machines for testing. > > Yes, there will end up being lots of /64 routes installed.  That > really doesn't matter however as the hardware is more than capable > of handling it. > > My IPv6 ISP (HE) gives me a /48.  I can do all this because they are > not stingy. > > You needed a address plan with IPv4 because there were not enough > addresses to go around so you had to size each subnet differently. > > With IPv6 you just give each subnet a /64 and let the routing sort > out how to deliver the packets.

I read it, and disagree with some parts.

Alex

> > Mark >

--------------7E05D27D981DE1695B9825F2 Content-Type: image/png; name="hbidlljindaofdll.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="hbidlljindaofdll.png" iVBORw0KGgoAAAANSUhEUgAAAq4AAAKvCAIAAAAkwdr0AAAgAElEQVR4nOzdZ1wTSR8H8NXz Hk+v2dudd7bHgigt2WQTQieAgGADRKVIECn23nvvih3ELhbsFQFRAQVJoYVO6AlJ6C39/7wA EQveeXfe+Rzz/eQFJLOzk90k88vsZhYDBEEQBEHaMeyfbgCCIAiCIP8kFAUQBEEQpF1DUQBB EARB2jUUBRAEQRCkXUNRAEEQBEHaNRQFEARBEKRdQ1EAQRAEQdo1FAUQBEEQpF1rMwqMmzCF YWxCQxAEQRDk38vIxKTNKEAjiH+6eQiCIAiCfHZtRwEEQRAEQdqBPxQFCBqdSqNT/642IgiC IAjy2XxyFDCk0Kh0qr45mWSK06gECgQIgiAI0oJo2ycVfr/8JxX+pJZ8YhQgaFpO5J83UUed sB4WaD5wEVnfioLSAIIgCILQaDQGg8FkMi0/hMlkmpqatu6GCYL4YMkmFhYW7xQ2MzNrqzCT yTQ0NHyrKYaGdAsLqqXl+zeapaWhsXHryj8hCtApxAg3XOu647KcwHWFwRsKg2ckrR2830TP mmL45aUB3EBXV1dXn0yl/9Mt+ZzoBAXX19XVJ1P++pM86VSyvp7uG3oG+GffmBSSrq6urh6J 8pnXgyAI8tczMjKiUqm92zZy5Ehzc/OmPpggCAsLiz59+rRVuG/fvi1poKnwsGHDPlI5nU5n MBhNLSEMDa1NTDYOH36hd++zvXuf7d373Ovb+d69Dw8cONnQkGiVBn5vFKATNNyU+vNJky1F p6ekrfr1xQTtV9MWCwKnpawdPJ9CEFTaB/sigoKTSa99jv6qDXT64gvpWensuzvcdf9Av0JQ WzWbhLfRbioFJ5NIZMpny0FNzSC3tX4ahaRrM3PNzaTsOztn29IMqMS7i1P++MbH9cc47Xr0 IiNXkJ8vyM3JykqJOb/GWcfgL+6km9uIUwiCRlApc4LZWRmp0Ye8DcifvlXf2Ws4jpNb/f+R 7fj+8n/jSxVBkH+Hpi/lXbp0wdrWqVMnLS2tprEBc3PzHj16fKQwhmG9e/duig5mZmbDhw/v 2LHjRwp37dqVwWAYGhrSDA3HmZruGzo0rWNHAYblYljW61suhuVjWDaGXe7Tx4nBoL1OA787 ClBooyeTDCM8NhQEf/OEhkUaYBG6lFfuCwoOaO+3MjDB3z9MQCXrmvnsjkoVS8RisVgsKknY MYWgNOebd45XfPgwRlsHN967872laLRN0RrQVCcH+YzVx2kfqKTNAycUnLB2XnZHIBZLJBKJ RCIWPzvEsmaQKNTWpakkXeM5Rx5kSSSZ5+ZZGFGpzf1w22tq67BNy4rfvpOgEua2flfyJJK0 yF3eJjoG73dOFAMdC9/d4XVQeH75NEMDcusCVLI+w2XRxRdCiUQsFosl0vTjLCb93VZ8eFvQ aFSSrunCkDgpAPcEy9nFNTgZQFH6ZK/bGD38A81vXdt7fxKv98h7CxK4Ad15wcEXEono8QEP e5q+vsHK+zUAyoLQeXokyiftNSqFMLfzv5L1Zq9FX7nyPDVVJGneAJJi/r0dM8bq4x+sj0Yl 6zGmbr30oqzpxZp2dqblW6NnCIIgH8dgMKhUKoZhnTt37tSpk4uLC4fDSUtLW758eY8ePTp3 7ty5c2cMwwYPHtzUu1taWn799df/+c9/Orfh66+/7tKli6WlJUEQFhYWAwcO7NChwzdtwzDM 0NDQ0NCQwmB4EkRex46FnTvnmZvn4bjgq6+yMSwXwwqGDMmaOLGoW7ciDNs1fDhuZkZ8UhQw JNN+nW3gzl43J2cPM2leQPbumembjbm+I9gufc4Y6dlS6W99XSQM9I08N17MUKhV1U83zZxg ZuQakiQpvLpIn0ShM0yZVtY242ysrZimhjSCIGiGJhZMS0tLMwtLG2trK6a5sSGdIOhG5paW TKaZuYWNjbUV08Lc2LDpqyPNyMzCysbGxsbGimlpTKfQGGZMayumhamRIYHTjMwtmNZWZibm NnZ2djZMUxqVMDQ2t7K2sRlnY21laUynUgkanWFqybS0sDS3ZNpYW1lZmhrRW02kQCeoZIdZ hyLLACS3N/uPo9BN32qJmTEd1zdgrrz0qhKg8sGGKQ7W1lbmDIKg0Y0tmp6atZW5MZ0gCBrN yIzJZFqYGzNoJhZMc1MTU1MLJtPc3Nza2traimlpZkSj0mgElaAbmTKtmzaLlRmDSqEQVlNW RtUCSJJPLZtgbGFpbsygt+6bKGRdK/f9UVJNZthCJ0P9N1+jCZxMnzB7d3ydSiVLDlox3Zhk vyu6oDJyG4NOEHQTy9ctNDMypBFUgm789nY2Y9BxEtn9eHy+EmpuLnO2ZpqamtvY2dlaWxgT VLqxmWXTxrRiMpmWFsaGdEMTcybT0tzUiE6lG5tZMJlMc2NDOt3IjMm0tDA3ZtBNLJhmxsYm phZW1jY2NjY21laWlmYMgkIiGXmuu5ADoOGdX+A2zsLSwszc2s7Obpy1GZ1K0I3MrJo3iKWJ IUEQBI1hYsm0tLQ0b3qdWJoZG9LfylIU2+kbbxYA1EQFzrc0XRyeVw0gPjvL1sF5N08DUMo+ vsiWbmrBNDcxpNMIGmFkaslkMi1NDElW7rseFMkbk48tdjWh0o2Mjd4+5oYgCPIbWqJAp06d zM3NMzIy5HJ5eXl5Q0PDzZs3O3fu/N1333311VdDhgxpiQKdO3fu2rXrt23o0qVL165dW6LA L7/8gmFYXFycQqFQvk0ul7u6uraOAjOpVAGGpQ8cKI2IEF27ltSvHx/Dkr7+Om/NmnqBIN3Q sBjD9gwbRv7UKECnEH3Wkbbmnb5XHrs894hjyrLpaet3Fpx3y9z4423GKBf8rShAIRnYzzr2 TAzQ8Hj3bGuqAYUgjBhTNm/2Jxk5rT/7qr6xqqxQXKOofX548QRj3NgtqAQU9dXsF89EFXVK ddbD9e5GOtZr48oaAHixkUJxpQwqskNXO5L1SHRj/wuphZWSMmGppL6x9sbKiVNnH06uV0Ml Z7+vPdn3REGNojY5aNa2pwDqIu7xabQZBx9kNNSWi4qkDeryexs9LA0Nxy8Iq4Z6iZD76qW4 plHdyD7rN8mY0jLUTyHrWLnveVgKIApb7cYwX/1C0gjAi4kUiqtkUJ55fgmT7ro+PLNBDaCq rxAJS3P5Z731rXw33yqQ1YgLSyvqFTm3N7vbkmn05U8BFOUFNw6veVapfHn94vU7WQDZ7Ji8 gpJatVrOC2IxKDhOmbLpfJyotkJUJKxRaDhBs+2ZRr7BaQ1qAJW8RiosKWEHL55h1qrDp5AM rN1XRper0y6vn0TTffMAlUI2n7AyTACgZF/aOJnQJVOpFNxx69Z5hLG9767HVao6SZGosr4h +dpudzN9kuOO5FqFWs2JjRJJquUg4h72dZi5LSynQaEBkFWV5eZd37InHkDOj9jj5Lj8TlpF Y5VUWCxt0IBGkbl7mpXHiVSARvbVNVaD7HdGZSgAXu2bbGG+Mg5AIcq8dnTzyzrls4OHTt+M L6kQl5aUCKvl6vqMI57GdBuPwCcSBQDIaqRlpSUl99dtiwRQlwsuziScNl/mNdRXigrFdcrq qD0BdkZUc9Y5Mciry9kvY8qq6lVK/s3l083wlr1GxfXMJ6+6mgdQGb7X19hw/oOcSgBhsIcR g2l/hAMgL8nOSMqsAyi5O9+FSTKgrItoBJDzb231X3i5DCAv/OTiGRMmT3GaYmf+7tEWBEGQ j2qJAh07dpwzZ45AIHByctLW1i4vL+fz+d98880PP/zQqVOnd6LAd999930bvv3229ZRYODA gRiGcbncoqKivFZycnJqa2s9PT1bogCVwZhBpcZh2KsuXZIMDMpjY/nz53O7dXtlZFSXm8uz tk7q2fMlhm0cNozyaVGAoJGNKL8cMzkrfuiRvlE7wZWVsdUxZalu4ozVguM23PmD/fG3vq+S 9MZ5rYkUAqgS9/tPIgxwgkajERQDwsL/MBug5vmpudT+jJXXeTJQRa13snQ/VgSa+qL41Y5G foFxKoBXx+ZZ2y1/VloHUHXGmzbOP7QSoOjZCXejKQefFUPjqzU2tNEjTHdyGqFeeGa+lfPa W5J6Nf/63ZgsUZ3kwRJzI8v1kQCNgvT7F0JSQSO6tmG6wUCrvfHFaqi5Onec/fwrVaCp4IX5 WFlvupGuBvXjDW4WxOsx9nejwKrYsnqNujyERbOdc6UKoOhZkJuevm/QcwmA+Np8I6reWF3a lAVhYmhIODPPoPuQydtvl2gg/5KfldmSKIVaKW/IS32VzHtyfG9g6L0MDcifbZvEsN+cqtI0 lMevszH33RfXAGVXVjlr99byvZTcAJC4x9HUxu9uJUBpwgFv2nBtvbdPSiDIJIbzopDCxqIr G90ouqSW7U+lkM0c3S9lAUDu1a0z6TokalN5nHBaF9UIyuzIzWY/kb33PigHSD7mbz15M6da rm4sPuxGm7Tsdh1A7oM9k0aP2xGdKQd4vsXKgExM3BsPUJOUEvk4UgKqnKC5jvpD3EKF1cqm KHA8GaD+1ZXVVoPsd0TwZQDxeydbmK+IAVA11uemvEpOij6+Yv3u7cvdJhppDR02xj2kEqCq +Ia3tt6kxcfTAFQvj7rbGGiP0aUtv6sBeVnRw1OBbIDKxwd98AEmGx5mKED2YMUEK+8QEWhq c54stjNddIqtAojdP8eW9vrYyYejQOnxqRSqqcuFPICq5PP7tgTFVmtAeH6OkxFlemi+TFGb u9/bZtHVfABljaQoK7WgSg2Qc8PL0RAdIEAQ5PdrigIdO3bs1avX999/36VLlwEDBpw9e7am pobFYv344489e/bs3LnzO1Gge/fu3bt37/ae7t27//jjj+9HgfT0dG1t7U6dOrU+LnD69On5 8+djGEan05uigCuVehPDrmLYTQyL09cvu3cvyddX/Pgxd+LEexh2DcNuYdjyYcOonxQF6FTa GFsSfmPqxqKQ4S+n7Cw8f1caEyaOmspfa5e8yCd356iNZjiD0nLmYKsowD4Q0BwFCCqZZuFw OhOgLv3y2ikjtEZM2xFeJIf6iLXjWCeLQSnKCHIebDJrx/1ygORTC8c5LHtWWq9WRywkGdlP C8wEKHlyfPnqnbEigNLYY4d2bd627WxCPYAsI8T7V33LJcGxVQBQlxey2I5Gw5kbowDqKyoS 07IApDE7/W1Ha4/0CebXKqH06kL7eVdrQJEZuc1uoOXKSwn1oHq2w4NJ/1gUUKnC5xsYjZ9x JAtAGHPai0YKOBUrBZDcWMo0ptLMbLY+lYNSwrt7fM26tbuvvJCqAbKCHKxXRypBU10cuoAY NnzkCML9+JMigOzDM+yNSAsilOoGUeK+OTNOJgHU5z68eHDd+nUH7+doAODZVjP7eQ+qAISJ h/3Nmjv0FlScZDx+6bkcKH+5e7b52FZn8zVFgdBsAMi9ts2Lrtu0JJVMoe+KB1BIEgI9R2qN clx8nFsN6sSDTl672JUyWe0tX23GZL+QfIDC8ANTyfa7n2bLAWJ3jqczjCbvjQeoKi1NyswD Td6Nha5G2mN9wkQ1vxkF1OW5p/3xoaN09PW0R1BtZs1btWXbtp3br2UA1BY9W26mP3lpcDqA KuGktyOdRMYZK+6qNLLa2he8VICapOBlE0aMGuF+ILZMATX3l4+bfVYMyiJO4MRfTeYcjqwG SDw6z57x8ShQHXNq74Gj0eWgSL+9exqd7HsoolwD3IMz7XxDiuTq+qzjTqZOe5/JACoeH5pN 6W2+/XmODCAnyM3ww6fCIgiCfACDwaBQKJ06dRo4cOCAAQO6det2+PBhADh27Fjfvn1/+umn n3766bvvvmt9rkDnzp379+//008//frrr7+87aeffurXr987UaBDhw4ZGRmGhoZ9+/Yd8Nq3 33576dKlJUuWtEQBgsFwplLPYlgQhp3FsDhdXZ6bW8nt28n+/jwrq8uv758/bBjxaVGAQtOa YGD+yHu+YL/+K7cDRZcPFl05WnLdL2sXkzd3tmCXzh4rkjHeciS76Zy1a3w5qDOO+k2i6ZKo NBrFgOEW4LfvpQrqM1qiQKEMFM8223oHFYOyLDPE9b8mPjvvlwMU3Vg9wXnp05J6tTp6CdXI fsbhTICqhNCdu3fFiQAq0sMf3r11+87Na5fOnwrcMMtWl2Y+/1i0EADKE7axLHEqpSkKiMpe vGSroTx2p7/t6DEjfYL4NUoov72iKQpkRe0cP4i5KjShHiAteJaNMal5WPjDUSBqEcVovPuR bIAa7o15VqSAU3HlAOKwxZZGFLrZuF2xKlBVC9iPr9y4c+dm2OXzIcGbZlmYrXyiBmV5wVEv HX0SScfY60RUIUDuMY/xRviiSCUopPnnN7mdSgGQCbkxD6/dvH37+tVL504dXjbdfPyCRzUA pa8C/UzfiQJUnGLqOPtyEZQ9P+llpN36QYKC08ZN3R9bC1B6a+csIy09Kp2G6zOme05dFd7Q FAVGjB7puPgYtxog+Zgza09iZaOs9l6ALmOyf0g+QMWLEJap3a7od6OAUJiUnQ8qzmm/ifjY sT5XX0cBz5OpAHUJl1cxf7Hb/jitdRSQCzMOuI/RNcDptq4LTsZUNJRxox7evR1fClBTFL3M 1GDKslMZAKqXJ1gOtJYoUFUV8yxOCbXJQcsmjNAa7n4gRqQAWcS6pihQzD06Zajp3CORVQB5 V5ZNMtdvHi75QBSoAGjIen7/9q2w80f3eFlpjdUZa+J3iC1Rq5NPH3oskClqXmyePNZi8qYH 5QCVEUcXmA8d6382qVIF8HI341/9O1QEQf5aTaMCnTp16t+/f79+/bp167ZgwYK9e/f269ev T58+/fr169+/f9euXd+JAr169dLW1g4NDT3byqVLl4YPH96rV6/3RwUyMjLGjBnz9ddftx4V OHPmzOLFi1tHgSlU6gkMu/Cf/9zr3Zu/ZYvw/v3on38WHD9eePnyg0GDrn37bRCGzfkDUUDX Cte+7Li9+OzI+CmLcg5cl0SfEd23SZo/OXXFrJztI1YbUQxb/Z6QoOgStkuDE2pBlRcdOMOY PFpr9Iz1d9m3d3ofTgWofHzIa2xv/XnnEuoBEvfMYHocKwZV6yhQELbK0endKFCdeHWBj981 vhxqOGsmkob8MvCXoSPJEwMWuVo6Lr1YUCdPf/CUm19TmR7CYlAt1kcCNOZmPLh0IQ80BWeX Txrdn7YhMl8NykcrHe3nX3snCqSc9G6JAgRZ97+Gk7fcKQYoDV00iWS4LObtKFDNuTHPaqTn 4ecSNTRGrDMkjRmlQ/cMTAZofBU8nzyo78CBP/3E8FjlM9HSbMUTFSjLC457630wCijL84/M G7/qWimA+OqaKaMH9v/ll4GDmH4bvW1M7TyuCQEqeCfnmg/672gDnEI0d04ETjGaGHCqDMqf HPGjjSG99e2VoJKoZm4bb5UBlKVeXjieoTVsqP3C0LSHe1y2xmpAkX5rOd5Xe9rm6yIAwfnF ts6bOVWy1lGgPO6Ul8n7UaCan/E8LqEeKh6vdCaG6c+LENerFJm7XSzd9sQDKFPC1ltojT/w JEcF8LIlCogyD3nqjBkzdvyqC7lygMKzjpSRg6mrkwBqi54uN9O2XxCYJAfgn/O0JQ0foU1d fkcDClHxo5DjfADx7e0ztPuQloSlyAFit7pYeZ9+JwrkhC6daNYcBQiK/kiqzcILOQAV97a5 k0n+97KrAEqOueDa2tpjdXRJVDqdwMcypgZG5DaoKqX1aqU0Yp4ZSY9iPXvX00ZQ86+stxmh t/gGvx6g8CwLjQogCPL7tRwgaJoq4Pvvv1+yZMmxY8d+/fXXXr169e7du0+fPl26dHnnAEGP Hj20tLQuXLgQ0sq5c+eGDRvWvXv396OAQCB4+PBhaGjoldfOnTsnEonmzZv3ThQ4hWEPBgwo OnGigssNHzXqeqdOYV99JXz4UBIe/pxMPo9hcz81CtAIGo0gBqyn+KXvWJJ7SOfVdAveXBp7 ljk3YFPRaeMo1ghXMu3dAWzCxMpxw7XEWlCVZCa/SkgorMs+7W5Ps/UPCs9prClKep4ilDWm 3djvZU0z8ThdCVBbeGH6MBO/fZGNAJK76ya4rIivBICXy6lG491PFAKoMx4unYTbuiy5kiIt L0zjvEpIYPNSs8oybpyNlGhAlX7IZ9LUXZH1AKKofTN3vAAAMf/sbJuF1xJL60Q5nJiMCqiP D1k9xZThsOiOGqAobp/Dr1brricDQM4Zn3HGJCpBo1II5gT/E3HppXUAAFUF6RcDL2Y3KgHi llKMHDxPFgOo0h8scxxGtlx5t7AOVGU8TuKzqECWmeum4/dyaitzOC/j41++zK2uur/K3nJV LAA0Sk756OqTSGONvU/HSQFKg2c6GOFLYwFAXh7iS2bYeB+5yS6pKOYnvkxISHhV2Ci84EWh mfvveFoJUFXEf/Hy3h5/F9Pmsy6oFGOrBReKQMw94E19JwnQaDSCQjBMrBeeuFOohoqi9IS4 OEF94a2FrnSL6VsuchvUEv5znkDaUPD80iJHGmXCrkwVgCZing5jytwLYoBGznlvE/v9L4sB gL3Pgc4wmnIoCQCyYo4snh+cVqMqy0lNiEzMkymU8sx9kwlT1xUPcgHqRGnP4nMq5QDAOzTF 0mJNIgDUFB7zGqtjYMBgzruUIgGVJIWX+OpZWiWAujx+nfVofYb7wcd5GqjN5fPi488s2f4M AOqEYXOYfiHR+Y0V+bznaWJlY1LodjdLmsWsS3UAFRlBzkNMF5yMVQCUXF8xyUyfQqURVMLU 2vPQ09T8KgCAutKsK0dDU6R1ANXnWWatj/pTdPQmbrkjUgMAVD5YakoQVJzKGOcf8rwEZOIM TppYBTLueb9JdHSqAIIgv19LFOjdu3evXr2++eabI0eOvHr1avDgwT169GhKA+9HgZ49e/bq 1atpIKG1Xr169ejR450o0LlzZwcHB19fX/9WAgICvLy8xowZ06FDh5Yo4EKhXMGwx717523Y kDlr1p2uXUMw7ErHjklmZgVHj8ZpaV3DsMVDh37auQI0Gs2QStO1pfx6ysIne/vWwtOLcg6t yju6uei0VeLcQStpuBFBe29eAQpZn24xfpqnj59/wJw5c2Z7TzIj4xQKYWw9xXu2X8DcAF8f r4kWhlQKlW7m4M5ieUx3NCXTLWyneLBYbpOsjU2snN1nsljOVjS6kdn46SyWp+tka2OygR7Z 3NGV1VRpQICft9d0J2d3Xx+Wm5ONGUExd5zhOcvX24lp68xisdxd7RkkmsX4qbN8/QPm+s+e 5THemIJTaUbMiZ4sr+lOtkYkhvXEqTNZrGkO5k2/1SMImpGZ3Qxff18fbxbLe7afv7uL0wxP Ty8vJyZBNzIbP4PF8nSdZGVMIRswbF1meM3yDQiY4zd7qiWZRGEwXbxn+wfMmTNnzhz/2Z6T rRiGVk4slpeH23hzKpUgqHRzByc3FmvGeDMjOsF08mJ5ebo7WFBIBmRDi/EzfPyaFp3jN3u6 gxlBpTGMbad5z5rt5z9nzixnWwtDKrVpygETa+9rZWph4ilP0ljyh3osKk4ijJhT3Gb5+vnP mTPHb7YLkyAICoUwdfSc5RswN8DPd5azrRkNJ1ONbV1nennNnGxJpZtYOrqxWB4uDuZ0I1vn GV4sloutEY1ON7GbymJ5TZ9sRaeajHdh+fr6+Cw6yauSqZQ5h5ypZBrDeornLB9ff59ZM71m erFYLnYmhobWLiyWl/t0ezMqlUZQSIbWk6bOnDXbPyAggOXpzmJ5ujlbM6g4iW5hN8Vj1mw/ /4A5c9zH2zmxWF4eMxyNyYTJOKfXr5OZE8xoFCrV0NzRg+Xl5jrehGxoOd7Jk8WaMdHK2JBK 0GgEQWMYW0+bHeA3exaL5e3j6+/h6jLd3Z3Fcncwf/uHgQSFbukw3Z3FYrGm2Zs0DQPhVEML O2eWj69/QICvzyw3B1MK+gkBgiCfouUXBD/++GNTRz5s2LDRo0f37t27qb/v3r17hw4dWh8g 6NSpU9euXXv27NnjPT179uzSpcs333zTEgV+/vnnjh07dv2Qph8ftvyCgGZo6GBsvL9Xr0cd Ojz57ruorl1vd+hwHcNuYVhk587RP/wQ2anTmS5d3HCc9noi5E+5BgFB07GnDN5uNPaRs1m8 n1Gc94ir9sPmE2RToq2RVIL6ZrZBMhmnNt/55j68eUSeQiaRyTiFoDdPP0emUAmCipPJTUsR BAUnkch48+dzq1pJZDIZp1DwlsqoFDKZRCJTCCpOaqrz7VY0nWJGUClkEhnHqQS9uba3pqJ7 d7ZBSuuWkN+0hKC8ntCOTKYQNBrx9oJkCpVGo+JkEpncMn0d0TxFIUG88xDR1PK3pzhseuKv K2uugkowxvlfqNRUvDw2S0+H3Nbr8u3GtGx8ypuN3/wkmrZzU/spr6c3JKg4mUwi4a+LkEj6 OjrjFm7esXHNdMqI4RYrbpc1gFJwcQaDIFrWRCaTyS1LNe+A160mqDj+eluRyW9eD633Dk5t tUne2mvvv05eT/XYal6B1rMrvt5rH5w48HXVrR4j3npRfb4ZJBEE+fcyMjLS1tbu0KFDx44d W2YG7NhK3759TUxMmgo3fYPv2LZOnToxGAw6vfnAsImJSc+ePdsq3KFDBx0dHSMjo6bChkZG znR6SM+eLzDs2du3WAy7/c03Pvr6xqamLZ+An3xlQgqDquNAGe1GGe1K0beiELQ2cwDy+dAZ JhYWZiZG9L9x21MMdGzm77+XX1NVLpVWVNc15F32sTZFex9BEKQFg8EwMzMz/RAzMzNjY+PW hel0+gdLNjExMWnJAU1MTEzaKmxmZtZyAYKWltiYm9uamn7gZm5u2ioH0P5AFGhG0FAf8M8i /vmfvf/zLUAQBEE+gvjQ7X1/NAogCIIgCPKvgKIAgiAIgrRrvxEFqFSqrq6uHoIgCIIg/y66 urpUKvU3ogCFQnFwcNi9e/cWBEEQBEH+XSiiV4wAACAASURBVHbv3u3g4EChUD4WBchksqen p1gsbkAQBEEQ5N9FLBZ7enqSyeTfiAJubm5lZWVtlUEQBEEQ5P9UWVmZm5vb74oCIpHo72wZ giAIgiB/A5FIhKIAgiAIgrRfKAogCIIgSLuGogCCIAiCtGsoCiAIgiBIu4aiAIIgCIK0aygK IAiCIEi7hqIAgiAIgrRrKAogCIIgSLuGogCCIAiCtGsoCiAIgiBIu/Y3RgGNqrq6obyqXlIp a1QqKivrxRV1ovKGWoW6rQUa6xtE0jpJnVKl+VNrRhAEQRCkLX9jFKjLX704aIDpfvLMiLDE KH3zg7rTj2vbh3idTs9pfK+r16gqszKWrgwZOiGQeTijtP5PrRlBEARBkLb8vQcIqlOdFsRl adTCxOdOG1IbAUAu3Lzx3pZHuVx+uUiuBgClsj6HXympEB7dcn1JpPTPrhFBEARBkI/6a6KA TCYTtqG0tLSmpqa5nCRp0rznyQ2K4sTnThvTlACgEu9Zd3f3Lfb8+aHbk2pUGpCkx40PiHue mbZ4Sei6m0lBYZzH+Y2q1ytSKpWlpaVtrQtBEARBkA+SyWSfNwoIhcKEhITcD8nOzpZKX3+5 fx0FhOxoY9crK449WbHljvvOmKdCtSj8OjMov75Bk3jmmu/L8ry4Z+MnX5i1L3zB5nNWy+Kf lyuaDiHI5fLs7OwPrghBEARBkA9KSEgQCoWfPQrk5eW19egbLVEg8amp+40t51/svJz2SqgA AKgUzF767GVdybZlj5PVas7juOXb+VUAALWHFl3dklgp/+3aEQRBEAT5gLy8vL8jCuTk5Px2 W2pTnRbG5YBGmPjcaWPa2727hnPs2vJzjxwDi1WgKeYkBay5c1cMAOK1Ptd2pVQrfrt2BEEQ BEE+ICcn58uIAnUF65cH9zc9QPhEXkl4NmEl751zApXZMdYTbp6uVAOAWtb49Fa4/bSjuk4n Pc7k5svb+sEhgiAIgiC/4YuJAmqFRFxTXFZdKKyvlcvLq9+bT0CjkEgaFW+Ky8uEFXnF1RVy NKsAgiAIgvxxX0wUQBAEQRDkn4CiAIIgCIK0aygKIAiCIMj/PbVGk5xf9SxV/DxN/DxNHJsu KZT83rl4URRAEARBkP9v+WV1B+9k2W16TlsWYbQyymhlFG15pHfgq7sJJbI2L+XzBooCCIIg CPJ/LFdY63kgwXlP/LqwrEVXMn3O8v3O81ddz152kW+76fnuGxmNv5UGUBRAEARBkP9Xao3G ZVfcygtpq67nOBzkrg7LOhFddPRJoUdQisvxpJ33BZ4HE/bdzPx4JSgKIAiCIMj/JQ3Ahaf5 rnvj19/JG7kqdlFoRr1Muf9xfnxeVW5Z/eg1sXYHuOuvZ7MOveLkVnykHhQFkP8bYbEpC47f WhJ0d2nwm9uS4LtLgppvS0/dq2lo84oaCIIg/zJqjQZfFL77fr7xrkStNXFn4kqfZFRorY6z P8itk6sMtydQtyRMC0r1P5m09kLyR+pp91FA1SAIdh08ynL1wcsX5lEHO255WYzmLPpC7br2 JCQ2JVFc8VIobbq9EEoTReUZksrksgqOtMrz4FVJVd0/3UwEQZC/iVqjGcy6szQs13QX23wP e/whru1+7tj1L07Hlao1YLmHa76bPflYiuPexAUn2R+p54uJAhreRjPt7t9936Of+4O2+mKV PGTyDz1HMgKTAAAUr07NoP70k9W23HLlb1T+Ear6zN1G2NfDZ204cXBSz95Ox89s8ycGd//x xx9+6NZH23Dx5eS9xj/80K1Hrz79+vXq0e2/XucEFW2cf6FRNmYcMvq5f79+/fr1G2W//A7q lP5ae8KiH2QIjqSrN7xSbkpUbnilPMxXh6eKF228fis8uRbA79gtFAUQBGk/NBrNEO+73hcy 7QKT7Q8n2x5KYuxiH4gsbFSoN9wRWB3g2QYmOwfxzba9XBLM+Ug9X0oUkMVtN/i5yzffd+nY qavHlfrXYUBVW16aL8jLzRUUCCtrynI2GWFf9Rm14lZubm6hWCIpE5cUlknLhSUlxcWVMgBQ yarLiotKy2sVAKpqcXFeXm5efmFplQJALasSFZdKGhoaaiTSiobm6xqDqj5rrynWeTjr0PVb q6dNXXWlUKMRBjv17oJ11lsv0Mjz4taOwLBRrrvT1OqIFVZ9OmADfW+WFBYVlwprFAAaRV2F qLiwrEbeUPNo+eAenXvODGvrKVaUlJSUVqDx6z9sT1j0/fS8vcmqyznqm3nqG3lqToXm8q1E rK/fvHVhUrlyzsnbKAogCNJ+aDSaQay7riHpTidSJx9PnXw81XwfLyK94vDTYrvApInHUiYf T3UN4VPWxy0J5n6kni8kCkjPzsK/wwatubyD9mOXHpQ1GWoAdaP0VZCLXt9uA4Zqaf3c+Wff U9sdBnyPdej0Td8hWlpaVmuW+VkS32MGM5cSfTphmPMVJciKbgcMwrBh806zJYLT9qOHDv7v qME9OnWx2ycQFkUu0sI6j5k7z89moK775VfNMy80RYGvB089nNLSmuJg5z5dsW/0N+SDQhC3 biSGaU3blQygerRUpxeGmc9fpdMR69Jr4ROAavbuCd0xzPho3LWVJsM6YT1nnHwcE/PiVTK/ 9N0u6f5kDMO+cnrw0Q2BfERTFNidpArL04SXQEQpJBdV27of6zZ6WWhERgWA77GbKAogCNJ+ aDSasQH3nE6kup3NmhaS7hqSPvkkf+a5jMkn+U5B/Gkh6dNDMtzPZhFrn68/z/tIPV9GFBDe 8DTohg1d+Kqy4Djzx6966O/ga0D4bKXxdx16TTyfXA9QcGptaE69MmQ89vXPpMB0AAAouTlD vwtG3hh32GXAd53HLompL+etJ77qoj/rUvjNufo/dGUeqQLQXHLo8HUX03URCesoWKduw8km tjas4MT85osgv4kCb06peD8KaHsE5gMUBs389T/Yd1OvJh1kfv2fnrb7M+ry77OGY99bb01K vDZdtxf2zS+4EYPAf8awH5kbHxe/NdETd5/LlCmu+z+2N5CP2hMWfS8972i6+nlBY7ygml8D 9yNSsH5+PssuPi+sT5eD/3EUBRAEaV+2X3yhuyza72oe60KO5/ms8cfTCsobtz4qnBqSMfN8 1uzQXKcTfKOV4TFJ+R+p5IuIAkVXloz9HiNvi9cANMTMGfSfbpbbMmozb03qgw1w2s+pfF1O 2XjUBvv6J73diQAAkHdtukFXTG9VXvb1qQO//XG09/WUs+bYf/CAS+E3thM/YD+Z+azcvG2H qzaGYb/Y7wrfQMY6jV54Mfutdf92FFg/GsP66Nov3rbcYmDXH7XH731eIys6z+j89RDbVWER O3Wwb8dtf1KXGsQY8jU2aGEmACieu/fFsIHEnngFIH+dPWHRt9Pykmpg25EIt/nnsoqrx3kc 76G97PbjFG41JNVDAIoCCIK0MxKJ1GjxXYtd7IW3C+eE5budz77Elqy4XTArNHf+jQKf0Fz9 ZU9WB8eA5mNHp7+AKFCXGehN7oJhQ8ydvHxnz/a37INh/Y3nXY2MmNofG+B0oFUUaAhkYl// rL+36eyHpiiguzyzvPKu5+CuPwzwWOHds+tQ/9Cy0gfryN9h/QxnzFm0dMnK9dt2Hrpw5cHN lfrYt+Q1N95ORr8jCmhjWE8tY7dFy1av33QxsQYAQCU6avl9t19HT/Od8m0PYmtEJUgv2I74 Hvve5UG9Ql1bsccUw/pSVt+rbvNZI5+uKQqk1MLOE1Edfp03aVZwh0HzpvieqqhujJeoM2Ro VABBkPboSQLfbPk9YsMLv8t5qx6WLrxTvPxB6dJ7xa5B/DGLIucciBCKxB+v4Z+PAlXxxx0H /wcb7bJ+59HDgYGBgYd3TR2BddPy2XFlm/l3Hfo7X05vBNA8u3Avv7b6mut3WE/ttc8AAKD0 1gz9Lpjusowydf1j3wEdO/Tp0eOH0RMvloKi4Mr0Ud9+T9qc1bQO2ctTF6JjV+lhXUmrwvLe Wv2HokDVxel9v8W+Ie+QAhTFrh2BYdoeh94aTNCoss9O7P7VVz1+/KGf5aIIKYAmZ5vVr52w kXuLAdSZi4ZgXUdMOJvX+qcNqcd9WCzfE6ltbQjkt+wJi77LzzuXpy6V1lIc9mA/enfTXnb+ JlsDwJWqcuTgh84VQBCk/VEpFbHs9ID9j+grI0cvih67JHrskmjtRVHjN0XsPvekuFQE8Bs/ kv/no8CT/Zu6Y5jeqnvS1/fUpaz9BcPGOAVmpQZP1urVa5AWmTym11CfF7WNZewj5t9jP/yi QyY7bl4dYEHujA1fwBfKoeHZjF4YhmGjnI6WAADUFSbsNxs4YKCWDplM1hn584hpJ+OWa2HY 6CWX326Jqj5jBxXD+k54fRA/48JC5rCuGIZhHfqaTN587dW6IRg2aNJW9luD/Zra/MvWnTEM +9Zq+Y0qAACNJG6T/reduv9XT19nSNf/9HDYzX57TOCeI4Zh2MT7bW0I5LfsCYu+x887nql8 XCiPiMk0cz60aON1ca08u1bDk6oFShQFEARprzSqsjLx1UcJh0OfHAl9ciT0yYmrT5+94qvk 9b+ZA+BLiAK10vLM9PSSqgbV63vU6urC9PTcokoNqCpKslOSeFwuLyVL2KgBAIU4h5+azONy +YVFxYWF2ekCsVypAVBKBenp6dkFZS09gVxckJXM43K5XF4yP09U3SgRpGcKJDXvHL9Xy8sL 0zNySyqbj6M0iPP4qWnp6enp/NRUfmGFTCpIT88rLZe9vTE16saynPT09NzSisbX99WX5Gam JHG5vKTULIGk4Z0nWlealZmZXfp7rxmJvGdPWPQdviBbocloVJUpVQXltaU1jSK1JleuypOr hGheAQRB2jeNSqFWylpuoFb99jIA8CVEAQT5nY7ee+Gy44L3wWusg1dZB6/5BIbNOhTmdeCa 14GrXgeusg5ec9p2rqL23QiGIAiCfByKAsj/DY1Go1KrVarmm1KlVqre/KtSqVVqNGk0giDI J0NRAEEQBEHaNRQFEARBEKRdQ1EAQRAEQdo1FAUQBEEQpF1DUQBBEARB2jUUBRAEQRCkXfub okBubu6fbSmCIAiCIJ9Bbm7uZ48CYrE4JibmFYIgCIIgX56YmBixuM1LFv01UUCj0agRBEEQ BPlSaTRtTtH210QBBEEQBEH+T6EogCAIgiDtGooCCIIgCNKuoSiAIAiCIO0aigIIgiAI0q6h KIAgCIIg7RqKAgiCIAjSrqEogCAIgiDtGooCCIIgCNKuoSiAIAiCIO0aigIIgiAI0q59IVFA lZWYFSOQyWsr4pIrGprv1IhyC54mV1QpP9tqW2jk+QJxRmljmxM0fxp1VWHBuTtJD1PLq1V/ TY0IgiAI8pn8jVFAXhUVzt13Jnbnmdh9V5N4da0akRrvt+Tanti66ow4U9+XhQAAUFOcu2Pr pYWXCkvlv113o7T0bqxEAfKMZEFEctUn978qyfHAR6uvFf0VqUNTV14QuPqi+dJLtssfnU+u +4viBYIgCIJ8Fn9jFKhOnzrz4sy9UZuDnq7YdMZmU0J8dfMjDYLchDIVAMhyXtotfFXUdG+V hJsrbWirtrfVZsTaLOYpAIqyCp/y/8BX8drLZ55svln8l0SBEl7M5NmxIoCy3FKu4Hc+AwRB EAT5Z/ydUSDDY+mz+BoNAEBdydEDN/0vigAaom5ETV8a5rri4ZVCRX1OvN3CRCmoCzgJMxdd dV5651CcuBYAZEVbNl13Wnpl8qp72x6V1VcJgwKvj190ZeLie5dyGpWamjMbg4c6BDttvrPs XMp9TjVAdWjwQ5dFl6eufcUHtTQva+fJpKPHLtvPD11xK7/1MENjMX/ukitTlpzXn3F5/SMp gPTEwbtOi65MXfvkSe3rQqqqh5EpO/ffn7X6yuTlN4Iz1PWF2TtOJh8JvL7qWpEC6u6cD3dZ cHny0ke3y9SyurzlHkcH2Z8ct/Tq1G0vnpSU3ggJX3VbKFOBSpixelvsqwZ1zos4t/mhDvNv HWFXNv6pbYogCIIgf9ZfEwUqKys5HA7vQzgcTklJCQBAdYbHkugnIhkAAKgF3MR5a59fecrd fvTVfV5h3NPn07Zweclxjkvj2YUZW9c8vcwtjI1PnLcz7nFxwcl1pyYezIhMyA4OuuWwOa1K 3pCbVRSTVBQX9sD0MF9aL0u6e8/IN/IhN2PnwcdrwtLvXb41eW3spdi8s9suWF8UlMQ+0p94 bktUXvjD6CnLH5xMrmlqtrwxb83sIK+LeZEJvCWbHux8knn55PPdd9KfJRU9vRcxbU+GtKmc UrRn3SWHrXE3E/MiQ66MnfXsTmIEyeH06vv5iQJx+JWX287wHvMK4yKjXbYmF8oq7py6bbXk eVQCz2/l3Z1PSvNTY5lTHz2sqTi/8fLap6XspLQtm5+HcQtjXyT4bHsRXdwcBuRyOZfL/eA2 RBAEQZA/g8PhVFZWft4oIBQK+Xx+fRsUCsV7UUCZk8xZsfDRlgs3RlseInsE02YE9jcLO8+N nbD4xZO4xzrGB3Q9gmnuR/oZX9gfHTNxfmSUVA2gyY17Nm1bhhrq7p69y3A+QXU+0Gt6BKdW WZ3xcuKqZAU03A19uvlM3Oo9jw/HlAMA5MRaOD+4GP90yqrEEg2AqmTj9oijL8rVAABQk/XC 1j8mRwMAledDnh0Ii1+x/MyoCUepHsEU58DhTo/jm56eQrhn96M9URIAAFU2y+Hs+rvPJi59 WaAGgPLgHReG2xzGPYJp0wN/Yt6KVCnyXsTM2JEFUHXiSNSecDGAKuXCdZLb0fEnCupBmfzg npbxAT2PYJrb4X6M8wezapoOZ2g0mrY2IIIgCIL8GXw+XygUfvYokJOT09ajzaozPJZEPxU3 jc43JoY/C9gRd/hi1MrzuWU1jZW1spo6RXXWywkLYx/FPHPdwM2vbqysaayuVchTY6h+T17U qgGUmTEx3lteXrx012lrwqvqxooCzsR5T19WystTYh2W8+qg7lbo0y2nYlfsjw5JqAAAyI8f N+lOcMLzaRtTqwBAVrx5Z9TJl6+jQHqc3aJEEQCopaeCovdfjp23NTIkQVxR01hZK6ttUCpf R4Hd+6KOPG8aI8ibM/Hs2lvPndYkVQCAQnRgf/iW24XSpqdQr1CCIuN5U14pPxIYuSe8TA2g SojSGr/X8owYQPbifpT7juSi6sbKGll1rUKmRqcVIgiCIJ9XTk7OFxIF0mfMexSaLC4UVqek vHCbefWiUJN4+87kpdF3s6uLyqqLpI1VmXG2C1/G5yW4e14+yK4uElUXiuvrlKXbfC6seCIu FEqj7kR5bXlx5sazpUF8gag6486dMTMfxVQrqtLi7Wc8jCgTnQ2KWncj9eKJK047kuKLqmKC LhGB6fkvn01am1wJALKiDdsijr8eFWisy5w3LfRgZlVxSurs+aGrn2Sc2nPe5WBGUnF1UVlN aaW8+fRDhXDv3vAtNwX5oqrCh+GU5S9iE587LOdKAQDq74dcm7w+PlpQXVRWXVwuU4Ii/dlT 583paig/dCBid7iouiJvmdfja0L+oumhB7Lrs3nPXb2vn0xqenYNDSoUBRAEQZDP64uJAnWF m9eF0mcEUd2CLeY/Cm86KU9TFXbqNmPqSap7EHXpC04Wb+4efjUo06OjLV1OUNxO6M4Ov1Mo hwLelHnnTL1P6TsdtQoUCIvz1iw9qjs1aOLOB+4bOfw6lUahuLonyCjggvOO2KAICYDk4PYr 9Gkn6ayoF2plSTJn6fHsGgCQl508nXA9uUrd3CaN+GmEgetJy0WhLttfXIyrBBBuXXeJNj2I 4h5ityNV0lRKKT664+Lo8ceoHkFUj8dP5KryTO7CwMyqpkfV0lOHrhtOPUl1D2KsSixUK/M5 7JXBAjVUXQlNvJqUG7zn6op7FTI11MY9tV2ekAsK7oPHZi4nqG4n9P0jo4ToxEEEQRDk8/pi osCfIM4tiIrPDY/JOHX0wZzI8s+3og9TlG7Z+fhwbJsnXCAIgiDIl+zfEAXSHkb5bbrpsfbu sqBs8edbTVtU1eER6U+yatFQPoIgCPL/6N8QBRAEQRAE+cNQFEAQBEGQdg1FAQRBEARp11AU QBAEQZB27QuKAhqVUqlUv/lXo1ap3syw89Y/v49apVJrmpfRqFWKVpX/IWqlUtlS4RdDLRWc sOvbv/8oy1VXslRf5jwEaqVS+bplGo2q1X75DRq1Svmh3a5RKVTqN/+oVOp/bC4mlSRuu6Pr qb/tfFWNWqVQ/mW7WZURaGt/IP8PNkT10XeURq1SKesT9yxdefBm2pd3OW6l8Pn2CdNCpP90 Oz6uThTlTR09JZD3l9Smzjpsa7cv7yMlNCqlQiFvpvjkz1x50oHlK/ddS/nydjf8jlfs76OW nPHAh0wLqpN/kR+2f9SXEwUkJ6dq/TjU50Vt8yR+WQ8PL/JZl9D8mhIfHme+lV3X9uLvq73g 4bjmbpYcAECeE77dfc7Vqk9Z/l310ct9Ntzgln5R+18jrzri8ovrOYlKlXVm29ptZ9iKf7pJ 79G8XEHq/rN5SBEAQGP8cUdnz9MvftcncFnUaivns+/tNQ1ni+Fg37tN/yiSLk2f6nIg8s9d DeuPU5VFrzG2Cfy7Vq8sjdk1lXXhr+rAVGk7CMOtgj+wYCNvval1yEeetrrsydnta9dvW7l4 8c7QpC+vb1CWRK42sTsq+afb8VHquJ32Ruue/lURX52+i6BtbvuzWFn6eOGgb37o3b9///79 +w92PPz0E1OinL3VP2DLxeQ/2c7PoVEat5rpeOlP/9i89sEKgrUvp+zfNuPLlxIFNEVnJk6y 0e8yaPHTKgBQNkojDy12cZh56gWbnZKZzY9cStWffSY6kc1Ny5OqAVR10mwem81JLalVAIBG JhUIpMJcNpvDzSyUqgBqS7nbbAw99lyNYbOTMkpr66UlwloAdY0ol8dhs7lpono1AKgbpQKB uCSHzebwsksq37sMsaZCwGOzObzMopqGOolIUtPYXESlqC7Oya5omihZWVOYXyytVwLU5KZw 2WxOSmZRAwBoGiRCkaS6EQBAUZEvEMsAQKOS5vLYbE5SVnG1/J3VyUr4XDabzeakl1TKABqL M1M4bDY3JbcGAEBRU1leJMjPTmOzuWnCOhUAlKWen6lLWfuIy8/KKxaXl1fJADTleelcDpvN 5qVlFVQrVHUVopKyWg0AqGqKC0S1cpVGVi4QSEqyOalZIgWAskqYwWWzufyyRjUA1Bansdls DjcpJUNQVtWqiTKpIF+qAABQVEtFQkk9QJ2wpEKUn5rEZXOSc6vhQ1S8JSN19IwHLXqsBpDH HPSa7LElvgIAFML0ZA6bnZJeWKMBdUNVgSBHUqsEAKU0N4WfkpqYeGrWaMrSexweP1/a6o2n 5q82GDgnvCnzKBJPz5/itCRaAgD1hfxkNpudzG+6lIWyrloiyMzkJ7F5yenCWsXrT1NVY420 IK9YkMFmc1OKqmTN96sqsnhsNpvDzyuTA4C6TlgsqmpQAICmUSLIL1eCqr5KWijIz05JzpfW ve7bVGVP15raHhYDqOvLc3hsNiel5J39qlHUVJQXCwRZaWw2jy9qaHnhlRVncfi5EiWAvLyI z2GzuekSOQCAolacn1VUXJjM5nCzhHW10mI+j83mZVaoQN1QXlxapQFQ1Uma3gKlb94Czfu0 9aeUXJyVxGFzuCkFFY0NVWXFoho1AKhrSgpFNTKVir+Lztj2Kq/5jSMHAHVNaat9WvO6HmVN WRaPzeamCutUAPIC9gUvXXz1AzabnSoQ1Xyop1LWV0nFJU82+s/bfrklCmiUDdL8vLLibDab w8sVvrlieGVuMpvNSc4orH+vIpkonctmc5L4RVWqppZkctlsbqqwXvV6S4qLs3lp/Jzc3CQ2 m83m8DKEb39t0MgqpeUlgtzMVDaHly6WAYCqJGqNuf2hvKqy0pZ3R6GoVq4CgLqiZA6bw03N Lqt78zVSLslNanp3pmQK6wGgsVxSXirITk9p2XEaRZ00XyAszGKzOUkCcW3zwprqnGQOm81J zSppBABNvaSsQijISEtis3mZFa8/dDTyakEyh81ms3k50noFAFTkJHN4yek5Je9ey1xRkZ9f XiZgszkcfp5IBgD1ktw0DpvNZnOScqQKAI28TpqfV5qfzssqrmz5eqBO302nb2IXpbLZbDab k5xTWvfWR56i4M4Smu7KN0MQ6pri4oqy/GQeL68aANQNRSlsNoeXJ6pp2XEVzTuuqAEA5Inb 5y1eH3g7JZnNScqUvl6xoqYkhcNmc5LypfUAGmluWlpxLQCAWikuTM8re+v5yUTpPDabw+MX VzXWVYhKxXUaAFBVFxWU1SnUalnT7uak5ZTJmpdQSfMzSyoVagAAlay8JLuoCkBdVZrD4zR9 rGkAGrOfB3mQDDc+ZrM56cVlZSJxpSifn8zNlCjVACpROofN5mYUSN75KvWB9ymPl5ySKW1+ i7d0EAVNl5GtLc7kcdicpJxqAFA2luXy2Gw2m81NK6pUagAU5QKBpPnTqUJUUlb7F4xS/EW+ kCigyQ2cNmHb41trCDzgoRygIvfhHINf+vYeoEXCcbtZAa7mWj2//0nLAMeNpiy/XVsrvr9/ pvFoHNcaYrnuVr5MpUzaqDXQwXMajuuPotrNDSusYp9cSPTq1v+/Y0g4lck6HHFzsYXTmYqK 2G3TiWE6OD5iyLidUWKluvrFqlE/27u74rjeCNqUFXcKa1o1SlWV+siL+IWE64ywnXfn4VW/ iQGn4wqbPvXqhVErzMfMDa8DAFniPhPT6UFcsShijv4wMk7SI+tbb0ksB/Wr9Syf9ec4KgDI 2UvWX5GqUpYn3nKjDCLjY4fbLrieKHuzOpU67dEGs0H/xXEcp7sfjS6SJu2w0SfrkXDyMAP/ B0KAohs7vcna5o4OOD5q6Lgt94tkg4j6PQAAIABJREFUqkcrSQO+/2GwLs11FsvDf9HKIy+k grCZZJK+Pk42+LXnd4anCySP9vu5LLjZAADloeONA25mlstSNmn9bD99In1SwIWCysLL65wN tXF8xFC7fc+lKnVSoDNOoepr/fxdL701d0vfNDBlsz5pQzYAqHIvbPSduf4paB7PtHSZZENj GOLkYST/O4XvZhuAxriVo37x2rvPYcLhIpCn7J7pzNoZVQuK/BcnZtIYJBJp6E/aW9PksrSw SYyx864JlWXJJ+cxDSfZTdL9pXPngWQ6BTdz2Xxb0FKhgrNed9QSbvN/+SFznVzWPKxWi9m3 tk60oJNx/L/9zY8Vy0Cee3aF7aCBuI0FPviHH+wOxFU1X9mpIuHsnLFDmc5TcHxoP/q84LQ6 BYAi5/zUEb/iuMFo3NTtZFYNyB/OtPc9+SwfABrZ6/WpO0QgiQycrTfSxMbMZsPt5Nddjars 6Vozu+OSxopHgd4mWjg+erDF6rCchlYfsSrBlS0syhgzRwfcYGBf5tZwsVJd83LVqIG2Ux3o rsuul5TnnV7sSB+D48OGOR5JrNcoCm/PHf4NeaKvNa43TMdx7qJ5/vbGOD5k1IyzvIxHS+nW xyUNknt7PY1H47jWYOaG24VylYK3Qetn+2kT6ZMCzr3ZWFV5B6brjTUw0CfGuO6MjQ2aN9H3 aj0AVIZNMfe/nCxWZe8lj5jiNQ3HdYbrGLufz6uFhnvuLfv0vwYBdwrlAKrqkrDtM4xG4/jI wVZbw0sVxSenGwz4/ofBujhOdVx99kNjUeqSOwcWzvJbtXL50l1vooBK9GTZqIG2blNxXHe4 4bSNj0prAaA679pshi5O0ifrWKyLE78VLCqyt04YoU020KGRvU6UaWqFV7dOY4zG8ZFDrLc/ FilUdfFrRg20nTbF3HnqosWLmTiO43q/DGCujy2UvalHmR60wtPQwMTeFtcb0M9uf2yNRlX6 ZL2t3dqQkwunzr3RAADllx1NAq6nS9Ti1CXmA3Rw/dHGNuuuvfkWKby+xMIQx3ED7dHDxm1M qFTyD8xzN6EYW1vj+LDhk48l1qpleXcXav06bpozjusMM/LeGyNuAFCX3PQeO4SMk3TJ+Phd vApQxa/zmM5kMCwscHzIKNczafUAGlltZJAf7VctHMdx0wV3Mqqqcq9603Vwkh6ub7355duD F7n7DYZO9JyK43pa2np2RzIrgX99iTMVx3F8TL/Bk44Lquuzby/U+pU5aZyJ34HIljEkTfoe Q+rqc3sm4jiOk7UG6tttvV3Yqh9WFNxZYqi3lt9yR+VlB2KKiwPV+H/s3XVcFPn/B/CP3ll3 emeeGGdgsa6BhShlYHehgq0YGICEsXaDWNiB3S1iIYJiIIgIAtLMwhISW2zn+/fH6jougn7v VLgf7+fj/QcuszOf2WV5v+YzM9hvxTOVMu7O6iHMbmambSymbQnJlwKAMO2So0Uns+5denQZ tDGCC5qYXS6Og637Dh5k1smoyYRjbyQAKln69VX9m7c3M+tkbL3gYLSgKMDT6k9Tp3geyFOD Jnc1nneR1h14KdvGMzp272Zq0XP+3qf3di2atvyODAAKzg61XHKXzZdErWP8Pdx+jIWd64WM D88puj2vo+X6FxIVgKzgjqeF6ZJAecGjNXbmbUzNzNoYD9/9vECZtmcss9EftY27mJlZTN17 1nfJ9Bkj+ptbW8y7yZNzXvuO79TJrFv7noMXnE2lH9FoBS9YjKbDJo+2sF92I5ubdtJ9dG/d 5/RQpJjeIAbPOxsO8pxnq8dZ9uxq1qNl5/kB2Wph+gXP/mZmZmbdWjWyXHgtpkidvrNbV1ac BkCbc3fPQrvF14sH37JSPqKAJn3H1Nl7Q3NB+3S6xbzHEgAA6tFhj/kbYj4sUXRoSD+v+A8f berhodnj5z1WAkCwXc9xvmG50titXZtbHqMAgH1sqf2kzY8B4NrM0esCM3UbSLrFGjt9343z ntMdd6YAAPe0dfsJpxJ5/DBW59aDLuQAQOy2OQ4LDrz8NJOpFsd5DWw8+TYACAszsyKuOE1c ejac8/EgUvj6nPNAR38pqF56TRkxf08y9+0yK7PNYQAAyWcduw7ck698571oyZYL0WoASN9r bbE+SVL4cv2g1nMeAkBhVho75dPHUC6IXtqd6XRH/zJSXmNt3C6mAQC88GjbwSNBXnhn4/De 47cnAsD7oz17zr+dIQRI3Nh30DkRAFBHVy7d4Hdhh7314PV3ZQAA/lOMbE9nFgbtd52xLEAK ALyrdoPdAlJ48tjNXVpY+aUDAMSfXT9tzto4AFBf79/B7kzSh09C3DX3idPXhdNmotXx3hZW W9MAQE1d2uayYMszgND5lh1nn0gHAG3gouaWXlnF3tvX6zp1XBmS/3qn3dRLmUkXJg4f7BUs lqWcnGYz9WI6AMCl6XUG+GaDMuWY+zSHRbtWu4+dvv2+BED9Ypn1lKvFsoXi+Qqzal0m++7e 4+vru2+9a7+BA9c8KhIEe/TsNONMphwArs6q3WdXmoIdvKKPycS9ISKAiLUWHace4nzYM2Hk 8SldrZa8lANkXxrX3XbTvXSl+OmcLj33pwKA4P5Wh/6zLwqVz5fYuZx8ngEAsjdbLPruzANe yI6xPYeujZHTx6POe7J2wLiDEa/Ozhsz86EMAEIdLMbteJzxKQtoONdWD7GctDsNAN7tsmgz /EQ8j/+S1bn1wAscANC8PuDmsGQnGwCk53q3nXwjq4hzz7ld29HH3wHA62WD2/ZZ/VAMANGr m5u6P3i4euikoy+fH3e0W/BECQCPxpuN2xv+XvJ2c5cW1scNzgOHuDbouuIdAEDOq6DYJ8fd 7V1uSABAcGvq8KXX4grVSdu7NzM/lAagTd1tbzV05UMlPP3sPbXwzgNV6q1dM+1dwjUAcG9k 1/GHo7kAyRv7DDr75Ykg3V7n3D2wfLHL2pXL6FFAkxfs1tlk5PV8AIhcNdVh6ck3ALzjw7vN up0PAPx7rt1tNiTSk8WdOb912/weACDz1QtuasCOGVPdXwEA3BlmOv7Y20JhxBpTY9tzmfRt p60y67roFvXph0edesKlXz/HE9kAEL2pW8vRl9mCnMfrhg1fe/rk8pket6UAwLs2aYibfzJP em58desjAAAaKib8C39FVPPWd1iXSQ8Kso7NtxrkcjUfAJK2tDJ1eyOTUP5OnTvb3+MDKJ84 jZ264VYyKKOW9Ozh9RoANDF+s8xGHihUJmyzMxu9LlgEANGrmpmuSARNYezNKb2sfSL0raHw yGDTOfcFAJDn79zDdksK/fCd2m/R3HR7DAAIrq8cbDPpEG3vw2cbd9oQJUi/Mb9zl6mBvM9H nuBjQTsfFLzefvT8AwmffuUpOXeXdmgywMPX19fX1/f0Q3bihSndOy2+zgUARW6Yu7XVfg4A ZG6fPmGB7zMZ8PyGdplzjwcA+bedewzweS9P853Re5jnbT6AJnBek2ZznmkU2eH7JvabGiQC UD9fMnSM5/lYLXDODG3eZWnAlVUDhzjezqMP8d7cml03ZAMAZEcFv/bfs9RxzX0ZABReHDvA 40GGQBK1zrRl39MZ8Jn0/d2tN7yTKqWF4W69O2yM4IUdXDB10UE2AOQd69XW7gJbqpZGrRkw +qpuxkz70nNIl4k7IlUAABkbe3VgxQGA4u6maSMXnadHUcHzFZ1bD7yQBbrP6ZQPn9OzvdtN vpXBjfce/KFB5KdRlOCe83D7vaEAAKlbmAynsE+/3bkHxthMOxAuSD1kY7H+nQZAm/vgwNJp 7v4YBT6jTTsxomvXofbz3D3n9qr3l+N9EYA24fbuJbNWPv8w15m9e4D1+pd8LQAAN/Tw3B4m Q+Yvc3PznN7j94YzLqTy3/pY9fPNBQBN2plNrq7eoQCysw7Dlt+IFwMASBJur5kw0tNrw/w5 Pi8AACDDx7Ld7HOZ+S829RlyiAsAqlhfT5fVR8Npv8GVWQ/W9TDp4+S5cveVMC7/+cLxzp+i AKizoy66Dp8TxqG2TRq1YH+kLGGXqeWaN2IFgCYn5vBUs9HXklN2u7psuxijgQ9RIFElTb3J 6tHedpEna9/NiALaGVRenM+glu6v9f/OODF0kMu1d/kAIBM9WGDSZXd0wd3dbgs3B6sBgHtp 7ADPh5lChSSSZdX/aDaA5t3BNcu3rlwysv8M3/BMDYBCdGGiLgocWDpzxV0ZfIoCsjgvy/6+ uQCgzbq+zsG8x+iFnm5unvadKjVa9LAQQC2Muji9/xifyM9O06vjvS36eFNAiwLah7PHLLsZ +x4AhBGbbQbszjZ8b7N9rXtseistpK4usZrqfWPTmN4z7/FUIa49GnYYsMDZw911cX+TZkse FgFoEq9vHdSoXq9VV7KFWgB44mE84ljxM7mpm3u07T127gInJ6eF8+yGdWnVYca9xMTdMwY7 HXspVgMAb9/wuvZncpLves+evpMCAODfnN9n5Lrb+boWruW9PONp53RDBgDA9h3a1/FAlODp qtZW2zMBAFRxt1ZPGuLyLD1iqcPS0y8y4VMUKAg84D5rxYPPzyKp80LXDx616dZl555tBs1f 5ubmMaNnLaMpp+I/zVCrqYvb3Jy9n6gBAGJXte/uejsr/+UmmyGHCgFAk37adXxvqwmLPdzc lk1sT5p6PuexH6waPPGMGADkL9fO99gXkAgAkObb12J1UNDaEeO3XD2zyJwxZIGnm5vn9O6/ Gc28lMaP2W7Vf6/hRznz1gQzC7sFzis27Y0slD49ttRh6S0Z6KNAgSpph2WfXVkAAPn3vV1n LrjAh2DHMctuxr0HAEHE5j4D93GBH7RzllnH4U6ebm6eU7tWM3K8mSkWR7Gs+h/hFHt/9L4c BdS5j9f0H+0nAABllLezy+Zz70Bx376Z2eglLm5uSx2nWTCbjb5M779pFwZ3NLd3dluz3S9O IH20Y7pZ5xG6kXSpYjTPn1MYscVm0IEPPyiCpJv7We7uS4aadPJ4wPkUBVQJh1ctXXnwpQYA INK9ZdcVwfnZj9cPG7729KkVs5bdkcPHKJDEVb47ZNG252z3ZZsPXUv5/Iyw7PUJlrv7wjkT BvWbE5yfvt/DbfOZN1oA4BzuZ7k6ViZKvcMaMvmsCABkz1mznH3vsSFha3uL9fEKNYAmI9x3 isWkgNSErU5ue3XvaeoeG8tNaSCJu75yTF+fT78li66Nb9xjjKurm9vS2Q69OrSyu0FPXel7 ra23pgAAyOPurx3fa1GQCuD9i2Pblrl5LLBt0c37rSDlNmu4w3mDq6s0CT4WVtvSQZ1628vT zc1hoMWkFSdTPv0WUmXdc21Xv+sEJycnJyendafjoo7bj1j9KJMPoM2LWG9Wu/fMFe5u7vMH mTQb5H4rr+iB/d9mY1xc3NyWznHo3aH1lKD8lN2ubtsvxwIASK5P+MvhpoT39sisntOvyAEA BFcW2E5k3cpQAOQETzD/mznKNfzzsALpF4d1Np+8ZOlqryNv+YKA3S5z1wXK4VMUEL/ZbDVg X7GrdLN2WfbcHCXIDfbs0skjSZSy32Xmgv0Ruh+grT1bz71WIHz/dFnfYad1bUoS7DzV42Qo BQCa7P1WNbo5rPRwc1883oZhPnzDq09JVMsL22CjaxCa9FMu43tbf/qcLnshyA5c38Okj5Pn it1Xwnji2FV9+wywd3R1d3NxHdq2iumeLABF3tNTa93dXcZ06zL/9Bth6iEb601JGAVKoInd 72w/beaq7d5eXtu9PEeYz7gpBUjw37Vk1qqwD59mzs7+fTZG6KIA7+lRJ6vOE1g+Xl5e2/cf v/iSI5XGbLOw8WYDgDr19AZnZ+9QAOnpycNX3nr3KQqMXu6zbOqElbeFAADpXr3az72YmR+2 0XrgnhwAUL7d475kFT0KAAAUhZ/ctc3Vwdx8+J7LJ+ZP9Tj3KQqA6n30AZb90k2+m1esPBkn gVSfLsZzbgulANrs6ANTeoy7SaXumTFz2fEXEgDIPtLXcl28FkDLe+a3c+vi8d16jtjxOOvj 2rSFQR5dW7tH6becdXZkF/t9bzgaAJno7ty23ffGFtzd5TJv3QM5ABRcGG3r8aUo4DLGwfNC VA4AKCSX7Y1sT3O4wT4LJsw/nw8AYn/7oR66KGDRx5sNAJB9Y/30vjbT1mz38vLyOXDy2us8 lVYlub60c1+XUIMfU3WcV692buEAoM24vtPTafNT0AbNHuV6KSoHAIQvN1gVjwJp+8ysNiUq 1ZLc2J1jmg6Ysnj8ostC0ZP5w0ZNW7p2u7eXl88ev7P3UpUAwoy73iMbN+jk4hchBgBI2tDV 2je92Km0zJN9mRPPf+hAqugTiwZPP50Td3rIqDlnIvIBAITXRzayPJnBfbJ/3hDWEy0ACO5M 6jVq60Pqwzur5b084z5u7qUiANBErOg91P1mguTV2jYtncMAAJSxN1dNHLI0LPOV26AZOx+n qAA073ZY6aLAftdpuiNI2quS92T94NGbb111s+kwbqWPl5fX9n1+58MyxLTpJeriVmenzUFy AJAHzmwxYGv0e274RuuBe7IBQEudcZ3Uf/Ccddu9vLx8Dp68+bZQyr7PGjD2aCEAyMLWOC7Z cSNeAwApu60tVgc9XDtiwpZrZ136dLHTfwTCs6SS6K0WfbYXv8qL8+jMbq8tM3sb2Sy9GnDE eeyMk7kAILk3c5SHLgp8mOmB/AfbnKfOPy+AYMdRrpfe5ACA4OUG6wH7uCB4tHuudY/Jq3y8 vLx89p+4/CpHJhdFrOg94Fix6PdJiVFgdd/hB/IAQPF62+Ilm869A2Xg1OZWU9dv3ObltX2n 7/l7EdmfzwVRd476bF47uWezEVsD/A8u6Gtuv/rDSK5E5sgE4RutbHdlAYCEClg5o9/YKeu9 ttl37ur5eRQ4wlri4ftMCQAS/0lGA/akcLMfrx82Yt3ZQ652c8/mAYD49pRhHv4JBQAQf3mP 92qXIT3aTzv89lNfSLo2q0ev8du2rFs2Z2T/2Y/y0w+4L1l7/JUKADIO9vkQBVYOmuDHBQDp sxUzl+y5x4aU7R1bzH0gUwBo2C932/d2uJeesHXBx/c0eZel5aY0EL4+6Ghju/PTnI745sTG ltM3bfby8vLZ6XvhQWQufaYkfa+1xdpYJQAIwv1chg3Zlqp4d3zGqAFzFm32XjemTXfvt4KU 2yuGTDxh0Gc1CTusLde/uLt9aI9+zl7bXcYOcFhxIpk2K5Bx28Oy69ok/QOCK+MGut9N4wFA 3uvNlvVtl+709vLy3nPo+MP4fKX4jn1Ty2mbNnt5eW3f6XshMKpA9NZ78ZLN596oAUBybWy9 Sdek/LiD000H7eUAAPAuzh0weZV/phKAfWPoSOthw+c9zgMD7Ht+Ozavt+/197BVVy/tWOTg crkAAIqu2w1aposClv12FI+gOYcHdFweEudtO3hPGmji982aMHnTAxEAQPKm7m0X3CwQvn/s YTPirC5ESEJcHJwPP0rVAmjeH+r3u4XTru1eXt679h3yf5ki+PRbR8sLW/+hQWip066TbIfQ Pqc8LYAo/NSuba4O5mbDdj28uWrI0LELlm3x8vLy3nX8SlCasCByn2s/29EsL5/Zlj2dTkcJ Uw9Zt14cCgCQF3xs+XS3WxgFaNTvfOY5bbsa++GfAr9hTSfek0Je8GGXuXODPmRh+QV744X3 Pny0M4OPzh4/4x4XACDP/1oYN18c62X5WRR4AqAJdDZ3PJ2oAQBQJd1ijZl5MOCMq93kNVEa gNyj5u0nn0/h8cI3lBQFtApp/JWjYQCgiVmzYBprn4/ztGW0WQEAdeGTs57d6/V0O36FUgGo 3i4zbeUSogKAd8endx52gK9O9BppNXbjAzFAom+/pt2WxRQJY6+deAUA8hdLpk9edTVFvzJx xuURTdvOuqqf6uPsHmo68/g7LYA6ZHGLzqw0Re5Nn1KjwEqPTScOrhhn5bjnrRoAMnZbNOx3 OpP/aMOYXiO80wC4txd16DDxZrpQ/ikKKN9d3DRl1rJIGQBA1qUzERIB78GW3iM83hS7Qlb9 dmOHWrbnZQDc1+6DmPY+EV+NAgk7bEyWXJMqQSPMOTm+WtVmth63hZB5vK/JMK9YEQCA7OHx +yLQ5l3Z4DBr+9FDi4Zb2XtF8wFer2rTYXWS4RAg5cCwDlMPsMUaAFC+T9g+1XT6eb769W5r yzHHIkUAaXsGtBm88m0hP+Woc5+1LwEg89zCoX0XHo8Tf+wLWt7LMx4TF/oDAMT5WvWfdTmG q1WEzW9jvDYOAAoD1k/sN/+aWP1iYdeec88nAMCL1Z2b9dmRX2IUWDtg3OHIqIvzxtjfLgAA KAi4GZafQ5udpi5sdXXWTUeFerS2dI8skAgjNnyIAqCIPuox2WlrkgYAIOP8yUhVEftBKVFg 9ZBJfq/CTzlOmPWABwCQd+tqGK9Q9HabZbEokH/31N1sAAD+6QnNJu19vNfezHZ9IoDwgWeX jmMuJvLVSTss++wsAIDCSNfhnaf6xqk0D2d+FgX25IOauuM7Y/KCJ0IAgNzrl14K+XJpzs6R rTfHfdxQ6CHH6a4BSbTrs78xCpyNBhCeHWc6+eKHn/w3V89/+lQA5Nw6epcHAJC8bxRjyZ2M 4P0zHBY/FQEA5Fy7+FLE50VstLLdlQMAybdmDB3geacIIMndzHxpQMan7qlKOMxyYR2JAgB1 oFNTy1VJImnu43XDRq47s3Ny76HbUgF4d5w7dpxwPU1AXTvwUAkAoltrRvZdG6rvC7mHhlbv u1sFIH/lNbD7zOBviQIBKaCOc+/Q0u05AChfH5zSfewxoTpmgyMtClhsTAUV57FP71YWW57q 5+H4J0d1dLiWCwCgUUddv/jZL9D0vdZWmykA0OSeWNJ/yMZIdfx+yz72Z5MA4IlDKzOv6C9H AW3CDiszT1/Xrm0WPQWA+6smjVl0zCAK9O68PFL/APfy+I9RQPI+cnm/nj4JAADy1+FhcW9E wD89upPD1RwAAK0m6sbVbG2c9yJXn+vJAJC8r1/dXuuztaqc8P12PYZe5gHIQ+YNHrvi8jst pB7saz75XGSQU1fm1Mv0/pPrf/RuIQAAdWhc+5l7AzaNtxq/JwMg/7qjSQeHu5yikqIA8E71 aTpi6ki7S0IAkIT4zBw3Y1scAHD2d23ncJUjlRUmbR3TcXey7uch1MX+QxTQanK8bNotDQMA AE5G+JMgWiejRQGQRx91n+y0NUkLAMA+fzJcInj3oUG8XTN3ovvNd6GsUeO3P9Q9M+HcyRhe 7LaJ5qP2UQAFO0f1nXX4tTBlb7eaVsf4AJK0DaPaDV95v/zch1D2UUD55uiwMdOOhX54ulqW tbV/g8kXuRpJ3BEX66bGDEaPBTcTBaLXLLMWJgyG6RDnayKZIOTQAquW7RgMRuOmE65QXFnc lh69tlIAoE45sWbhwq3BSgBpwq5hph3bmDB6Td710H/ZoElnikSvd860+Ls1g9Gst8vtqCK1 hv9itXnfndkAoIzZ6eK0/FDYp1kBlfSdt22dVgxGm47Dl55m8x7MH7X4VFgm7USSNu+5X5/2 Ju5XkzUAABruk2XdmzMYJgwzc6crnCIAOef6mgGdm7RmMCY6TmhtujZByova2KduKwajTecx K08nFtGmorTS+Ic7hzRvymAwGH3nX4wsEqbsG2HasY0Jo4PxhP3pPNBmXN66aNaqe3IAyD87 zNr1QYZQIYlY1tPqUBaAJn6fx0KPIy/zn6ztwWjT2oRhYtW9W+MZD5VqUdTl+VZGzRmMMQ5D 2nR2vZPGk8Vu6dF7K6V7wcW51zc7mLc0YTAYjVpODywQXJxcnVRt1L5De4aFve/DT2f/tbLc i7NM6hszelt3tx42Z8G2Z6ANnDZ08fnX2QAgfLGmp82Oz68ViFvbvfPc84kKLYBG8HzniJYM B38ugJJ3lzWc2bZlOwajg8nEfW+DPPp3HcS6yhZoZA/XdOsy4lBEAQguD6vXyNiEaTNqO+3O pKRtNj1mHn2ju6Q4O3r/WMawc+8BpG+9J/Zq3rQVg9Ft3sFHmRLgp/kNqlm5gTGTweg+efXx mAIJ7V0TRp+Z1aR2k3YMRruW/ZddCJMotAAqzi1HEyMGox3DeuTaoDwJgDjhyJwuJs3aMhgT HB06WvrkQf5938WTXW8ZRIH3ISstB+0vUIhCjy22btmOwWA0aTLufNJ72qFFlv+mUUYNmpkw GG3ajNz+OFmt1up+8HQvl6oo89yKsT1amjAYDKO2js+lIureMpsRhwoAQPZ85Qwn72txGgBI 3mHeY0Xgg+V9hh3hKoSPDsy31H0E/ra7xuZJ327u0Xsb9fmHSxG40tTUpK0Jo3P76SezBbK4 W0tsjJoxGKMmD2rbxfn6u0JNshejev1WDEbb5p37zz+QJtRA0W2HoYvPR2UDgODFGnObHdkA Gknh3V2zLVqYMBiMRs0m38oWaLXqpAv2xk0YjPZDVl++c3FVn+6DNoXl0Q5dNdkBe90XLGJ5 ui3ddj5aHwVygldYDNr7HgAUkZsWOK079VoNIMkNdLViMBiMti0795l2gP4LSXZzkbGJCcOE 0d1sweX3cpAVBOyY2Vs3kub2d3KFwoh1Pa19sgBARp1bN47xdzuGzVDLv03cA2kXsWrSzi0f 3LBhcwaD0brduH0RGaBRZwet7DP8UErK7UVWRs0ZjNH2Q9qYugSk8QVnJ9c1ZjDatbcauTao 4NPvann+2VHNWzEZHZhmg0YOmhGUl7bXxYmlO3hg7+tttuKtTJRy27Pf6COFACAN9ZjitNP/ nQa03EdLuzQ1YbQzMbd2vpktAkXYCv17muRj1mNNghbUCv6TEx5WTVowGAzGqPWRbLk458GS 3m0ZDEabFqYDZh/57OCZOmDRsLExg8Fo3dlm+u54ngrEb7ZO7WPS0oTRZ1S/lh22xQiSb3nY jj1mcOuc5p2Xufnq+y/XmNVYxKpZAAAgAElEQVRr2b67Rde23aauOZ746Veekn3LtTvDPUL/ QOGFUX1dAlK5AKBVq5KCvYa3bs1gMJoZ9d/k/0YJIMm5t8SinQmD0aZF5/5zTkohZe8si/pG LRgMRuNWY4/H5gKAWsG5u2Xo3y0YjFamk7beyBQXXV9k9qf52lwFSBKD7Ds2HOf1WP8qy/2d 27Q3MTEx6dZ93uVcgeTV2Vm9jVowGGOnDmvd2S0wUyCOWm9m6f3ZlSEfiA8P/KP+xNO6j6e8 MGSjfa9mbRiMplbuD2JFWq1WLX7tN77F3wxGp7E+x3cumOl66GGK7tdCXvyJye1bMhgM4ya9 5u68TzurouU+/9ggAFRFGWdXjO3e0oTBYDRs6/hcJEz42CCGLTnytgjU3Ddb7Xp1bMNgtGtv YrOeUhU9OTmng1EbhuWAns3aLzgTzlcU3lnYqW4Lhlmvrv3GzJ66DE8Q0GjlogIuT6r8+JtT C1J+ToFIDaCRCQsy2BSV8V6k0ADI8jLZFMXOyhNpAbQK0fsMiqIodjZXrtaCSlRQIFIDAKgk RQKBSPfXHxTcnEyKojJy+DJ5EZcnBdDKBHkZFEWx3+uag0ZRVKC7MUyrFAsFRRL61KRWLS7M oCiKyiwQygGUAq5AqvjsBmmtUsbl5hfJ9L/2ZfkcNkWxs/S3V6ml3NwMiqLyBEUFBSIVaFWi ggyKoihOYdFnl58BAICKn82mKIrKfF8k0wAoebkciqLYHJ5aty6RgF8k1wKARsotFMrVWq1W WVRQKFEDgEosFAjFKtBK87KotNTU2DvLLa29KQDQqkSFHDZF5RZy8wtFcrVG++nl0q1XkMOm KIpi5/CVGq24kJPF0e13Dl/y2QkTjTgvg6Iys7IK+OIikQJAzucKpEo1AGj1r+QnCv77giKF 7sXRqmTCgoIPt9lpZbzcTDZFUewMrhxk+VmcfN1dW0pxQX6hSK4GUApzOGyKyszi0V4mhSCv oEimu8laq1YWFb7nK3TrExZksSmKyhJqADSi2GPTTBdey2RTFJXFk35+zkfLCz/tMnTS3liK ojLzpaqPIUEjyc2gKCojt/Djx1MpystiUxSVLxQVFoo1oJGLBXyhzODGOY2iqLBQrAXQKsQf fiazuDIVbSk1+9KWBVPdziZRFMXhKg1+8HRvvJire+czcoUqrVYtLyrkSjS6l5UvEOluYVWJ CwqK5PKiQq5YC6CR6z8CPLlaa/Ce6nchl5NBUVRGFl8Nup/oLDZF5RQW5heK5CoNqER5WZm6 QRfq/qSHRqZ/T+mD1MiEufrNabQAoFUWZbMpisoqyH+ydu68zedjDK6ikIuFAkGRUCgUST9F BI2iqJAr1gCAVikSCIo+fkuSpxtG5nv+50dKCmF2JpuiKE6OUKMfyYcfV55Co/sE6AapVUp4 2RkUlfm+IC+/SEG7GV+VeHTl/LlrryRTFJX14fY9tbyokCvVgvqzT4dKA3J+JpuiqIycAvHn 77VKmMOhKHZGdqGAz5dr1GKhoEiiBABQiwsKilRarUomLOR9eOOEfIH4w73H0rxMiqLYH+7p LfaefrxBWVqQyaYoisoqlCm1ACAu6TVJ32vZ3fl+chpFZX74BIBWxs/nsCkqK5+bny9SaT6N 5LM9EBUUilRaaUEmm8rg5OQWCMX0T7hWLRMW5Atp75aUVyiU6/8wj1bJ5ehGlFck+/CzRhuk HEAt4edlZrApimJ/fL8AQC3jc9gURWXzZSoArSgvK4v34fo9UUHWe6700+usLNK93ZnZAg0A aJRFBRw2ReVyeQUFIoVao1WKCgqL/ZwDAIBckJP76eZnjYSv+1X/6VZFjUKYxaYoKpsnFAoE Qolcv+sawYePXzZP/NndMF/5nOobhODDGyTn6T4lVFaBWAugVhTlZrCpzJy89/lCmUIDoJXo XntOgUAiKPbLpAyVfRRA31fc8bm92zRp0qRJ85ZzAhTl868P/lgqUcGJeaZrn5fwbS3/1aXV 01xuGt6r/eOoM67tXO6+M7TYX634f0IZddLFc43/u/L31630VEknNy5beySi/NzG/a+wDw8d tC3x/8nOoHIBowBCCCFUoWEUQAghhCo0jAIIIYRQhYZRACGEEKrQMAoghBBCFRpGAYQQQqhC K/so8PDhwxkzZixACCGE0A8we/bsY8eOKRTF/+/YchMFMjMzg4KCniCEEELoBwgJCQkLC+Pz v/A/bZaXKIAQQgihH0qr1Wq1Jf7NOYwCCCGEUIWGUQAhhBCq0DAKIIQQQhUaRgGEEEKoQsMo gBBCCFVoGAUQQgihCg2jAEIIIVShYRRACCGEKjSMAgghhFCF9p+OAlp5ES83i5OZmS1U/YDV //fFxMQwmUzd14SQmJiYsh3P98JkMv/f7AtCCJW58hAFlPzs9Pi3MVGREeEvw1/HxLIF3zR0 pTBy4xCTOvX+bt2u36aAsLDwV28zhN/0zDJlZ2dHCCGE2NnZ6R+MiYkhH9GbnP5BPz8/+koI IfoeX4pviQJMJlO3iVJWqFvmq5v7KhaLZTAMDoej38fAwMBvWQl9p4D2ErFYLPpiutcZEwNC CH1VeYgCnJPze/9KSM2WnXr2Nq1HSDvH029zvn6Yn3J+SbtK1eYEZANAzsXFg4aOmu8X+9Vn la3AwEB9U2cymbqvde1Q17QCAwP1TbeUBQIDA79LFGCxWPoOamdnZxA44GNGoY/qH9OvxyDr 6BKAbkMcDuer62GxWPpxltTsAwMDMQoghNA3Kg9RIOucc7/fSbWZNzMBlBfGNiSVfrPdEp4d fu3Y2aCMtMTn/vfDcuUAVMCxfT47dvoevfg4XQn5MdsduvxBGgxYtNzrapQsI/LarVv+oS8C j+4/cu7e21wNKKgH1/32HXmYrQSQvL2wf7fPzl37Tt2NzVXSt61SJN85dvxSQBSv9NfpB9C3 YV3f0j/OZDIDAwN17b/4wjrFowD9qFo/8eDn50ePAn5+fgYTEvT2T9+EwTG6rk/TN2dnZ6df WNfg6avVb6h4XqG3Z4Pje/1g6MmDvgv6NegSg5+fn8FMAP01pOcnhBBCpShHUcDhXKwYIMXH jFSt33vB4QeLjQlpNtK2ZwPSyvn2jZMbR/7RxMbZaU5f46pNR3s9fflk63hmLUKM+06afzCU f3IsIcRoyub99m0J+XPy4RfR/itbEtJxzlGqIMxnVq/abUc4O9p1avRH9/knEgo+/e9MYu5e E0J+aeUS+dWX6nvTdz6DNq973KDZ+/n50eNCKVGA/i0mk0mPAvTH6cfigYGBBsf93x4F6Efz LBYrJiaGviqDXYPPo4DBTtGzUUlRgB6bdKcbip9Y0UcEjAIIIfQtylEUmHkzEyDDx7w++fXP OYeiAt07kcqNB85edfTozRu7RjX6hfTeywWAhA2dSFUTjwfZ6WedWpBKk84mAoD62jRS5Y8u q0NVvAdOZn/UMulq2vavFv02hMu00bt6VyO/TbsLALwL0+qRv4b6vfh0MYJKkXL3+InLd978 5FkBenP9LlHA4On6rXzxBAH9eFp/mUIpXbN4FKAPzKDZ0yfwDY77iw/ji1GgFHZ2dvTJD/3y +sRAn03BKIAQQt+inEQB29qkcv02pma9WlUjZODWZ5l52bcWtyO/9d52PwcAwteY161C/jLp 3cu8R8dGVQgxmuQb+Ozk/Bak0rijkQIA1dVppEqtjh4hAKo0/80WfxDScOjxF4VagKtTalf+ 5de/O1n2MuvU8k9CSKdVV9+V+J82/yz0LvXdo4C+WZYUBfTH1iwWS7/a4lfe6ZUSBeiNXz8A +sH6d4wCBidN6KFH/y0Wi6XffYwCCCH0LcpJFOhXk1QdvPHC44jI6Lj4PDmAjLqxsB3508bn fhYAPFttXvdXYrvhyauIiMiot/HxKdlcfui+mc0NosCyUFBzbqzo90dlQqrUG7cznKeBmzPq /PrbH1MORkZEvHodHfsuIT2/SP6Nr84PYjD9btARdXfKGXRfg477L6MAfQpdf6Ve8SN4vX88 K1CcQSIxuFag9JsISokO+hHqb4jQK2UwCCGEoJxEgbNL+tYgVaZcTPjUosXUdac2pKaV910O ACjTjwxoUvOPnltSAUDz/tG13V6XYmKOzm5KyNgjkQIA1ZWp5JdaXVbdzghd1bZq7RGbtrDm mv9WzcwnLlcYvaFd1d/bTTpVCADy2AP79154mKXfjlRwcXQDo24jtr8reXzfV/G75v6nOwh0 SrlWwOBSwZK+1i1MHwy90f6zawX8/Px01wqUcnfDt9xBUNK1AgZZofSLEopvCyGE0BeVhyiQ c3XF6L/rNpp39Z1Y/5gk445nz7rNh+8NygYAAK0q+WC/vxs1NDIyMjL6q3WfFf7vEs+6dKpb b/rpaCGAyt+pbtPmHaYvX9K+ft0eDqditZpn22wZdRt0dosQSrjP13Wq18DIyMjIqGEDU/uT z/L025EKzo+oXb/zEK/4ksf3HekvrdfTPa6/CJ9+mP7Fe+4N1vDF5q2fojeYFdBvpfiFAvTB wOcXIX5xtt/gPL3BYOiD1C1G3xf6bn7xDyp8MQoYnB3Q0V85SJ8toO8FRgGEEPqq8hAFEPq6 Um4dRAgh9G9gFED/DfjHhhFC6AfBKIAQQghVaBgFEEIIoQoNowBCCCFUoWEUQAghhCo0jAII IYRQhYZRACGEEKrQMAoghBBCFRpGgZ9EJlOIJTIsLCwsLKwyKLFMpVKX1KEwCvwkwY/fPAh6 FRgciYWFhYWF9TPrYXCk/53nqWnZJXUojAI/yePQ6IzsvJyCQiwsLCwsrJ9ZeVxeZHRSckpW SR0Ko8BP8jg0upAvKJJIsLCwsLCwfmZJ5LLYd+kYBcre49BonkAolkqxsLCwsLB+ZsmVitgE KjmFU1KHwijwk4SERguKRDKFXCrHwsLCwsL6eaVUq+IT2RgFyl5IaHSRWKpUqxQqLCwsLCys n1ca0CYkZSSV6yjw/smGqebGxsZ2e6OFKghY0r5tF4sdESUubuDN/sk92hjPuyIw/Ib4yYox 5sbGPbe+EgBo81OODjc2tpnt81r+rWv+vkJCoyUSuUajUauxsLCwsLB+XgFAYnJm+Y4CWfcW 9/2LEFLZYhObr7owsWqlWo1WPgEA0KrkYpFIJBJL5GoArUIilkilcpUWQKtWyiRimUIuC1nd uw4hQ/ZnFH1c7oOie7O7/0VIA7dQHoA2N967EyHNB694JgMAUCtkYpFIJBKJpXINAIBWo1bI pFKpVCIWicQSiUxlMEqtWimXSmVKjbbEHSlVSGi0VKbQglajxcLCwsLC+nkFAEkpnHIeBe47 29Qj3S0H1Bt2PLnwjP3vVer8vfq5ViWN3udkU69+46b1a1Uxc4tgx/kOa1KF/N7ZI0gqids1 pknVOiM3sebadqpVmZAadRo3bdq8u+2maP1qi+479mxMSOPlL8UAwE3Z3ZUQ42GrwmRqMe85 q1/nxg0bNW3asM6fppvDuXIQR5yf16LSb43btG7LaFK7+q/GjhdzRfRRcs4utqxMWrJepCpK 3JPShIRGy+XKf/RUhBBC6F9JTs0q/1HgT9J55ZHZHcb5vDow/veq9YzXBxXeXd6dNBhyIgHg jVf3v0jt6TfE8uCFjWvUbNlniffyrlUbTj/0QgbwZmu/hr+SsWfEhqv9EAXq2e+/+/Tp01tn F7YlpPWoTdG5UatsG5J6Dvc5coD33uY1qtSzOpYre3t5XiPyS/91t/kAAfO6/k7IyOM82ury 7vk4mncdffBt1j/r5xgFEEIIlZX/SBRo7xb/YGMP5sxJNpWrN2zjcjJmaXvyG3PoiiPnz3tP +fs3QpisLIlW+mRLp7qEkOpdHffFCQEAwjb1+etXMvo413Divui+Y8+mhFRt2rm3tbW1eXfj mqQSY9y24ODz41uR6mMOpHIBAJK8e5PqjSeeeJ1wY35DUtf+QLAAQHRtbqNalVs6PypxzP87 jAIIIYTKyn8kCrRb/Logcbdluwa1STVdFOhAqjZq33+swyT7aXPmL3HfdDVdCZrUOxNbE0Ia Dt94r1AFAPB8g3WDX8i4k4IvRYHGhDRZHa0FAGnW/u6EtB7vFfzo3NiWpPrYD1Eg5+AgUrXh 8H1PE28uaEjqTNr3iAegebi0yZ+V6s64VeKY/3cYBRBCCJWV/0oUcArPhKyD/SsRUqV+q1W3 M/0mNyWNR5xN1i2Uczs4BSDhYL+/q9TvOmJWz7r1u659wNYAJO0aXLcKsfIt9qeVP0SBRh5P eQDa3Hc+XQhpNWpTeOZrllVd0so5QggAyjMj65DqzK1x/Lgrjn+RutOOvwaQ35vXswr5dfxF +jqF0QFH16zY8TCTW+L/51AqjAIIIYTKSrmPApkBc7sR0njmszQZ5Pt1JYRUrr08VC1IuzzH pl3Dtj2HDx8+vK8xsXHbN4tZmZDeK57mcK6Na0SqNhl3+lWOkv3IsX3VSo16DB8+avqi48n6 1QoDHJg1Cfl9UQgXQJsTu7k1IfVt3MM0mqxXx8catzO1HjB8uFXTX/+acuBxNsgjL8xvTqo0 7mAxbLilEfmtj9up2CL6KDOOTmcQUnPJ46R/djciRgGEEEJlpdxHATk3OSo0+GWSUKoBECY+ eRzy9EWaAAC0gszoh/fu+Pv7+wfcexid+O7xg4dPniUUAqjEmW9DHt5/kZInBoD8uJchD+74 +98OfBzP169WzU2MfB4c/DxVoAIAhSTzVXBwWEyaQAMA6vdxLx8E3Pb3Dwh8HJUPAFAUfn5e Y1LTat6m8/4B94Oes2WGo3yf8uZx8Mt0oVRT4p6UBqMAQgihslLuo0C5UPTy7Ky6pNakg6HS H7MBjAIIIYTKCkaBb6FVyUW8Qm6RTPkP/4TQ12AUQAghVFYwCpQLIaHRCoXhnzBECCGEfoKU tGyMAmXv0eM3+fl8gUCMhYWFhYX1kyv6bRpGgbL3NjbteVjs85dxWFhYWFhYP7mePn+b+55b UofCKIAQQghVaBgFEEIIoQoNowBCCCFUoWEUQAghhCo0jAIIIYRQhVb2USAgIGDUqFH2CCGE EPoBxo4du3v3brm8xP9Cp+yjQEFBQUxMTBxCCCGEfhg+n19SIy77KIAQQgihMoRRACGEEKrQ MAoghBBCFRpGAYQQQqhCwyiAEEIIVWgYBRBCCKEKDaMAQgghVKFhFPj/LCYmhslk6r4mhMTE xJTteL4XJpP5/2ZfEEKozGEU+Nns7OwIIYQQOzs7/YMxMTHkI3qT0z/o5+dHXwkhRN/jS/Et UYDJZOo2UcoKdct8dXNfxWKxig8jMDCw+A6Wgr5TQHuJWCwWfTHd64yJASGEvgqjwE8VGBio 73lMJlP3NYfD0TctXV/86gKBgYHfJQqwWCx9B7Wzsyvej3UZhT6qf0y/Hvow7OzsWCzWFzdd EhaLpV+4pGYfGBiIUQAhhL7RfzoKqLnshPCnj0OCX1DSH7D6H0zfhnV9S/84k8kMDAzUtf/i C+sUjwK6Rqv7Wj/x4OfnR48Cfn5+BhMS9B5M3wR9bfAxENA3p2vh+sEYrFa/oeJ55Yvt2SAK 0JMHfRf0a+BwOLpvGcwE6DGZTHp+QgghVIryEAWknJhnAdevXzp35tTJ0xeu3QrjaL9l6NKc R0vNG9Vr0cWqn73PhcsnT5+7FZnzLU8sJ/T9z6DN6x43aPZ+fn70uFBKFKB/i8lk0qMA/XHd wvqDfoPj/m+PArpv6Xozi8WKiYmhr8pg1+BfRwF6bNKdbih+YkUfETAKIITQtygPUSDzhGNP QshfZsMmTR1hXJk0HrXpQWKJ/4GSXuIZJ2NSc1FIIQDwHm5f7Oy+zT/9q88qJ+jN9btEAYOn 67fyxRME9ONp/WUKpXTN4lGAPjCDZk+fwDc4rw/fFgVKYWdnR5/80G9anxjosykYBRBC6FuU hyiQdc653++k2sybmQBwe9rfhNToszY4JcDHfd3Jt69fXPE95p8mAs2b/Z6LZs9xXOC++VyU BDKfLBtsXIPU7jrSbuauINHb21u2++w6f/2U56Kl6w6HpCpBHO23w3Ohx+kUOQD30aZF82bP mbto9cGQFAl920rpq0Punlv2B5b4GvwY9C713aOAvlmWFAX0x9a68/T6BUqaby8lCtAbv34A 9IP17xgFDE6a0J+l/xaLxdLvPkYBhBD6FuUoCjicixUDJHn3IFXr93Y6EujchpCGlt3a/k5a ud88tdGxdw2G/SHf7dO6VKtj7er/8o3fAou6hJg6rNx9J7bo9HhCKjVz9L2yzIKQaqN23Qs+ 7dyUVLfdeCs39+7iAe3rWyw+7LPctlU14wnbI7I+nYAQc/czCanWdunrr75U34/B9LtBm9fd KWfQfQ067r+MAvQpdN3cPnzpCF7vH88KFPdvooDBC0WPUPoR6m+IKOnmC4QQQgbKURSYfjVd C7Er2v1BavzlcjYx0L0jqdTcbuWRJ0+iHngNbFCZ9D8iBID4TV1JVRO3O1TK6QXNSaWJp+NV AOpr00iVWp1XPdWKXqweZFTNqNnfDWuZ2B16p4Tna5hVfqk5NxAAcs/PMCL1Bx99xtVvW6PK e/v02auYDPFXXqjvxiAHwP94B4FOKdcKGFwqWNLXuoXpg6E32n92rYCfn5/uWoFS7m74N9cK 0FOOwWLFL0ooaVsIIYQMlJMoYFuHVKrZoGnzlg2qkaqTT7AFgsybi9qRmpbe93MAIGxNr3pV Sa2Gxi1bNG9SuyohzafsffDk5PyWpNK4o5ECANXVaaRKrY4ewQCazAe7+tclpOn4y6/5AHBt Wt3KlSvXadKqZfMm9X+vTH7tvubau2+6LvEH0F9ar6d7XH8RPv0wXZcAdOgNm/70LzZv/RS9 wayAfivFLxSgDwY+vwjxi7P9BufpDQZDH6RuMfq+0HfT4CCevlH9qopfBKCnv3KQPltA3wuM Aggh9FXlJAr0q0mqjj8Uyi4o5PEFMg2AhLqxsB35w3r7PQ4AhG20qvcLGbInuZDL4/EFfB5P IJY82zujmUEUWP4UlMkn5nWpXvWXX6rWsGEF5qrhztyGVWr8MfdSXiGPxxfwuVy+SKaibV2t kMnkClVZhQP0jUq5dRAhhNC/UR6iAOfMIusqpNKks7GfZunF6dfmGZPqvbbdyQQAyLsyuWPD aq0XPsrIyKAiTuxZvvxkZMzRmY0IGXX4lQBAddmekBpMj8sxV+b+RepN3n90t0e/GqSVx6NE Ycp+iwZ1mvTdGJWRkZEcsGLlmqMBGfrtSPjHrQn5u/daPHgs5/CPDSOE0A9SHqJA3l1vR/PO PVbcpV3cL80O3jKqs8WsU88+rvb95SnmpgwTExMTRnvz8d6PUtNubBjc2dTterwIQP1wVWdz iwEum1dadug0eunNFICow1MHdGLarHktUsnf7R/Skal7LnPAoquRhfrtyIr853TuOnTmoeSS x4cQQgj9P1YeogBCCCGEygxGAYQQQqhCwyiAEEIIVWgYBRBCCKEKDaMAQgghVKFhFEAIIYQq NIwCCCGEUIWGUQAhhBCq0DAKIIQQQhUaRoGfhC8Q5RfwsbCwsLCwyqDy+TKZoqQOhVHgJ3kU EhX0+HVw6BssLCwsLKyfWSFPo2/fe5GSmlVSh8Io8JM8Do3mvC/I4/KwsLCwsLB+ZhUKBFFv k5NTMAqUtceh0Vy+QCSRYGFhYWFh/cySymWx79KTUzgldSiMAj/J49BonkAolkqxsLCwsLB+ ZsmVirgECqNA2QsJjRaKxDKFAgsLCwsL62eWSqN+l8gu71FAq9Vqtdov/eNblLi89vNV/c8r /q5CQqOLxFKlWqVQYWFhYWFh/bzSgDYhKSOpXEeB7ED3ocY1qle33hjGV8KVaXX+aNRm3bMS FzfwyntQs1o1Jp4VGn6jKNDJ2rhGjZYrn/MBtO8TdpvXqNF+zLow2beu+fsKCY2WSOQajUat xsLCwsLC+nkFAInJmeU7CmTdd+7fiFSrUqXrqmSe4qJ9jV9rN2WFAgDIBdlJCfHxCUkp2UUA ysL0pOQ0KkugAlCJCjOSkzLzcjKvu5vV/YX02/QiLj4+KfW9VL/aovuOZo0IMfJ4ygPQ5r7z MSWk5dCVz2QAAKL3GUnv4uPj3yWnZYsBADQyUX5Ganp6WnJiQnxCckomX/35KFWiwuy01Ayu TPnPJhZCQqOlMoUWtBotFhYWFhbWzysASErhlPsoYFOPmA0abdRvf1zBafuaVeo0W/tcI81/ tMquh1GLjqYtahOTabei3xyZbEwIaTXvWgH/9XqrWpXrjd2x1W20Wd1fK5E/m3U0Ne02cMKu OP1qi+479mxMSOOVkQoAELJ9uxFiPGx1uEyek3Td0ZRh3I5patq2XtWWLjcT+SB5eWbmX4TU b9vBzLKTUTXSYMzOuDx60888PseUkHpuocnyEvekNCGh0XK58h89FSGEEPpXklOzyn8U+JN0 WnV+SfdBqx7tHvdb1Xqt1t7LvTSvDWk89moOQKqveUNSze6SXPN6Q+c6VRp2meg8g/G78ZJL cWqAWO/+DX8lEy6oDFdbdN+xZxNC/hzkufvo0SM+GyY0I6TN6M2v2S+W9qpFmsx9WggAokO2 NUnNrnvSRLFX5jUiVQZvDZQCPFnaqyYhtgfzaKvjPju5zsHO+VLy+2Jb+iYYBRBCCJWV/0gU YCyNf77Tpu3EEb0qVW/YxuVkzNL2pHpL8ynuq1fN61+nMiGt3NIkoIo5aduUEFLL2vNipgwA IGxTn79+JaOPcw3n7T9Egd86DnOYNWvmpLFm9Uglk3HbgoPPjzcmNcYeTOUCAGT49iXVjMYc Dku4uaAhqWt/IFgAIA9Y1PiPXxrPv1vimP93GAUQQgiVlf9IFGi3KDKfc2xwqz9/J9X0UaCV xQzPjes2bPXZfeDYhae5KlC+Od63MSHkTxv382wZAMDzDdYNfiHjTgm+FAUaE9JkdbQGAKRZ +7sT0nq8V/Cjs2NbklxLG3oAACAASURBVOofowB7Tx9SzWjskZcJNxc0JHUm7XvEA1DeXdT4 D2I0916JY/7fYRRACCFUVv4rUcApPBN4p0f9UolUqddq7f3cy04MUqfvgUjdFf9v956NUKnD 13aoX7O57dx1QxvUbON8OVYBQO0fWb8a6emdZrjaD1Ggkf6ywS6EtBq5MbIgcdvgpsRozpNC ABAd7F+T1Ozmmy6OveL4F6k71S8SQHB+YudfyO8zAwpoq+M+Pb5m0thFF5PwBAFCCKH/mHIf BTh3nMyrkuZzXqTJQHSxLyGkeoOVT7WygpA1E0z/bNiyY6dOndrVJ/1ctg5vSkiVgV5xwpx7 s03IL7UHHQjNUHNjlves/cufzTt26mI7biftssE70zvXIaS2yxMugDYnbhuDkMa2y16ogJ9x Z34XRos2jE6dWtetZrzUP1kA0lfnF7Qgv9Ru0qpjp1a1SO1xux9xPrs+MPPEnC6ENHAPTS7x v3YqFUYBhBBCZaXcRwG1lJubQWUVylVaAHkhm01lcHhyAACF8H1aclJiYmJiUkra+8J8KiUt I7NACqBRCvOotJRMrlgBAJL8LCo1KTExMZXK//RXAzTSwpxMisrkyTQAoFYKsymK854n0wIA iPOzUpMSExOTUtm5EgCAovDzjkbkj6GrT4YnJqWkZwrUhqMUc3PZVBZfrvrHNxNiFEAIIVQm yn0UKBdEry4vbPF7kxlHnxb9mA1gFEAIIVRWMAqUCxgFEEIIlRWMAuVCSGi0SmV41gEhhBD6 CVLTszEKlL2gkCiKnZuVXYCFhYWFhfWTK/xVQlIyRoGylpKa9SYmBQsLCwsL6+dXVHRKIbfY /9v3EUYBhBBCqELDKIAQQghVaBgFEEIIoQoNowBCCCFUoZV9FFCr1XK5XIEQQgihH0OlKu3/ zyn7KODv7z906NAJCCGEEPoBRo4c6ePjI5VKy28UKCoqYrPZmQghhBD6ATgcTnp6ulCINxMi hBBC6EswCiCEEEIVGkYBhBBCqELDKIAQQghVaBgFEEIIoQoNowBCCCFUoWEUQAghhCo0jAII IYRQhYZRACGEEKrQMAoghBBCFdp/Ogoo2BFB544eOrD/TAT/B6weIYQQqgDKQxQoin94YffW retXrVjmuXztFp8rscpvGbow+drM9n807j5yxryVh45t91yxeucdnHv4TExMDJPJ1H1NCImJ iSnb8XwvTCbz/82+IIRQmSsPUSDzxNyehJA2oxev3exqVoPUtph7Ilz81aHHn5jbgtRZ+owH AJI3Vw4cPHr5Zd5Xn1Xm7OzsCCGEEDs7O/2DMTEx5CN6k9M/6OfnR18JIUTf40vxLVGAyWTq NlHKCnXLfHVzX8VisQyGERgYqN9HDofzLSuh7xTQXiIWi0VfTPc6Y2JACKGvKg9RIOucc7/f SbUZ1ykACHZqRSr9br3iTsyJRSOmbHzy0H+P69pjsVyQBXuOHWzTp4/t6FleQTxIDphn3qAq +b1lt57WHtf4Tw9Ome3otP3Q9gmDhk1hXYmWAu/JuoVjBo73iZUAZF6cNai/TZ9+Aycvv/z6 s3MJcvEj1ojRc5ZfYJf2Kn03gYGB+qbOZDJ1X3M4HH3T0rXGry4QGBj4XaIAi8XSd1A7OzuD wAEfMwp9VP+Yfj30YeiH5+fn9y17pBuzfpwlNfvAwECMAggh9I3KURRwOBcrBojf0o1UrW+1 2O+hK4NUrtux7d81CGPldd/5Q0xq9Fr2JPAWq9/vNTo6nH6Z4r96WENCrN2P3o3Nlp6fSEiV NktOPN43rib5ZcCmC5f3zGlMGkw/E8bLODOa+XfTsbtC/Y9M6fRLvf4rH6Wp9dsW8w53I6RO 5+VvvvpSfW/6NqzrW/rHmUxmYGCgrv0XX1ineBTQNVrd1/qJB3p/1f3TYEKC3v7pm6CvDT4G Avrm7Ozs9Avrj+z1q9VvqHh3L6k90zdBTx7FI4J+/sDPz89gJkCPyWTS8xNCCKFSlKcocDZe pH0yt2H1X+q0XHOD/cCNSSq1mbPzTkbG+8eb+tSrTIYcKQSQvF7Xjfxq4nIzKfHkvOak0oQT MVIA9dVppEqtTiufguzt7kmtqtT8o9bv1bs6XWGr4KFLs1+r/uF0Xw2K5JNTm5A6Aw89yddv W6sR53M4OXnCb7o84bvSt2GDNq973KDZ+/n50eNCKVGA/i0mk0mPAvTHdQvrD/oNjvu/PQro vqXrzSwWKyYmhr4qg12DUo/j9cMrJQrQY5PudEPxEyv6iIBRACGEvkU5iQK2dUil6n/Wb2hU v07dhosDpCoJ+8bCdqSW1fb72QDwfE2velXJb3UbGRk1/KtenT9rd553OCjkxLyWpNK4o5EC ANXVaaRKrY4ewQDarCDfgfUIaTb5RrQAAK5Nr1e5UuVa9RsbNfyrft3afzbot9k/Qfttr86P Q2+u3yUKGDxdv5UvniCgH0/rL1MopWsWjwL0gRk0e/oEvsF5fSj1kgV6+CiJnZ0dffJDv2l9 YqDPpmAUQAihb1FOokC/30k1h/Nxn64VFFM3FrYjf1hvv8cBgEifAfUrkcH7snXf1ChEApHk xd4ZzT6PAp1WPgVZ9I4JrWvU+bNWzaqd5l2i1BC0tEWVKrXm35TpniuViEQSlX47Wo0oN53i 5PAVJY/vR6B3qe8eBfTNsqQooD+2ZrFY+tUWv/JOr5QoQG/8+gHQD9a/JQoUnzz4IoOTJvTQ o/8Wi8XS7z5GAYQQ+hblIQpwTi3oTQgZfyqmSP+YOP2qYzPyq9mWgEwAAEGg64A2VRqMORoU FPTgwlqP2YuPhsccnl6fkOEHI/gAqosTCfm19WK/R7tGVid/zTl949zGYb+Reg4nn3E5FyYw m9btOPdyUFDQnb1TZi3ee/PTNYJi3qEuhPzZcVlUyeP77gym3w3avO5OOYPua9Bx/2UUoE+h 66/bL34Er/ePZwWKK96e6XGkdAYvFD1A6EeovyFCr5TBIIQQgvIRBbihx9faj5u0OzRDpn9M nhd+dPG4KatvRRV+eET0aMXk0QNtbW1tBw6e4Hz8JYfz6OC8ceO3B6VJANRhvuPsp8zZeshn 0vAxLjsecwCSrrHmjh5mvytOApB1Zf7IoQNsbW0HDBo2c1NgvODTdsQha8fZLVh1OaPk8X1f BjkA/sc7CHRKuVbA4FLBkr7WLUwfDL3R/rNrBfz8/HTXCpRyL4DBjnwxB5R0rQA95Rgs9sV5 BZwVQAihb1EeokAFor+0Xk/3+Bdvr9clAB16w6Y//YvNWz9FbzAroN9K8QsF6IOBzy9C/OJs v8F5eoPB0AepW4y+L/rdLP4gfaP6VRW/CEBPf+XgF+cVMAoghNC3wCiA/htKuXUQIYTQv4FR AP034B8bRgihHwSjAEIIIVShYRRACCGEKjSMAgghhFCFhlEAIYQQqtAwCiCEEEIVGkYBhBBC qELDKIDQz5ZO5WJhYWH9zEqjcoqKJCX9UsIo8JMEhbx+8iLmWXgsFhYWFhbWz6znEXF3A18m p3BK6lAYBX6Sx6HROfmFhQIBFhYWFhbWzyxeUdGb2JTklKySOhRGgZ/kcWg0ly8QSSRYWFhY WFg/s6Ryeey7dJwVKHuPQ6P5wiKJTIaFhYWFhfUzS6FSxiVQGAXKXkhotFAklisVMgUWFhYW FtbPK9X/sXen4TGdbRzAn+wIiRBZ7UQwqFga1VqKaotaiqHW0trb2tdRu1qr1FZlbLXUvhOD bAghyESIJCKyCCF7JpnJbPf7YfQ4JplINTLjnf/vuj/kPXPmOc+Zq9d7/885zwyN+v6Dx6Yd BTQFuZlpqampWflqLZEi+/nzF2kypcHd9SjzMl88T82Sa/Rf0BbkZKSlpqblKrVEpFHnZaSm pmXJlNqSjly6AoLDc2T5SrWqQIVCoVAoVNmVhrRR0QnRJh0Fks7+0LEaY0ww/VKGgvb1t2YV 3WYHGdxdz82l7asw1mtXoe9I5Jwd2aIaY85TgjOItCn3VjRhrMbns67ISzpy6QoIDs/LU2g0 GrUahUKhUKiyKyJ6EJNo2lEg2W9iZ3fmYG/fcNrdNPn+wRVsnGrMvUxE2szHYWdPHjt28sz5 sGSi/Jigs+cuBoQ+ziOSP3tw5dzZa/fCQ/8Y3czRivn+sPvo0ePnLt3N4IbN8Rvl68GY+/TL GUTap/dX+zBWt7voipyINE8jrp49fuzo0ePnLoWlEhGpsp5GXbkQEOB//vSpY6fOnQ+Jz399 loqn0WGXLlyNy8ovdP+hRAKCw+XyAi1pAQAAyhIRRccmmXwU6FCF+X49uE6bVWHPd39T0cap 5sKr6szY/SM6feD1Ybderauzml9svHRj36SWVox5DhLHPQ2ZIrCyrTV065YV33Vyt7Ng7j7d evX+euTEnbHcsC+jgOfcO2oiykva0Iqxuj3m3ZTn3g9a37Nuw5Ydv+jdu2MN62qD1vsnk/z6 rqGVGXNu1q73oK8aVWIV2032f8R/lpCwdVhDxux/CoxWGDyT4gQEhysUJX7sAQAAUHpiHiab fhRwZE1FJ+d0+OSHoyu/LmfnXG/uycStQg9Wd9DZLKKkLR+7M4tefykpdutnnsyxXsd+n9ep +sF8v8dEdHdlF1dr1v9AoWv1HL9Rvp6M2bcSjps8efLo4e1dmEWDPr/ceOA/rrkt85oclk1E qj29nVi5xr/czYw8NMaNleux2r+A6NbPHR0Ya7eW/6llR5zdvvDntZcSM9QGz6Q4iAIAAGAs 70kUaDg5MnxL97o9O7WwKOfqNWmndGoTZuPm3aF3/35dm5RjjNX8KSqPtI/8vvFijFXrvuR8 uoqI6NqSji7WrPf2dP3lgC+jgEPH8QtXrVo5b1oPT8a8+y7399/Xry4r12fTw3Qioqd/fM5s XXtsCH5wfJwrqzJok38mker8ZE9HK+eRxw3O+d9DFAAAAGN5T6KA94Sw1PT9/eva2zE7V69J O6VTGrMKTXr8/Ofhg4ePnT57MfDag0w1yfyXNHFijJVv8f3vEdlERFcXtXexZl/vzCwqCngw 5iG6pSSi3IT1rRir33e5v//evrwo8GDFR6ycx8Cdt6OOjXVlTgM3XMokyjs22r0Sq/2Tv8E5 /3uIAgAAYCzvSxQYfz1Rk39kiJ0Vs65ad9HFtHOiNqzCh0slT4iIFBemrDifm+s3xs3BWTBg /rZhnrYe3265mkv0ZNsA9wqs+cII/WGLXDbYY9FtWeImYSOLyt+cSZQTPV3hW97Wuf32Z4qI g6NcmdOgP0I0lLzhc29rVm1iYDZvuNSzK79r/UHPTdKkt+vniAIAAGAsph8Fzk/q6GTZaML1 R3JSnvra3ta2aq15V7VqecSm8e0cK1fz8PT0dHW07jZ1fgcXG7uqff9ILHgWNK2ttV2lzmsv xWvlias+r2lfydnDs2bLzovDuWFzzo/+qLqlpeeMl1Hg15aWlvV7zL1WQIqc0Hmdm7u7uHl6 ujhVbrHsZqaCZDf2javDLMs7Ont4ulS08Rxz8H72a4sCkvf+1M6a1Zsb8rDA4JkUB1EAAACM xeSjgFajKlDIC1QaLRFpVQqFQqFQaYiItGplfn5eXl5eXl6+vECplOfLX76kVSvl8nyFUq0l Io2yQJ7/cife6kGNskAhlytejqtVF8jlCqVuYNIoFbqB8xVKDRFRzvU931VlFb9efTo5Ly9f rii0NlCr5s3yLSAKAACAsZh8FDAJMukpUZv6LSftuZb95p3fBqIAAAAYC6KASUAUAAAAY0EU MAkBweG6X38EAAAoYw8fpSAKGN/FgFuR9+IfxCSiUCgUClXGFXxFiihgfE9SXsQ+TEahUCgU yiiVnVPo3+37B6IAAACAWUMUAAAAMGuIAgAAAGYNUQAAAMCsGT8K5ObmJiUlPQEAAIB3IDk5 OSMjQ6s1+Gu5xo8CZ8+e7du371AAAAB4BwYMGPDbb7/JZDLTjQL5+fkvXrxIBwAAgHfj6dOn ubm5phsFAAAAwIgQBQAAAMwaogAAAIBZQxQAAAAwa4gCAAAAZg1RAAAAwKwhCgAAAJg1RAEA AACzhigAAABg1hAFAAAAzNp7HQXypCfE86dM/PGHeadT3sHw7z+pVCoQCHR/M8akUqlx51Na BALB/825AAAYnSlEgYxre1dOGD58UP+ve/fqM2D4qDVBBv/JBL60W+Kva9h595y0bO32/b9P 7NV34E87I0ryRuMSCoWMMcaYUCjkNkqlUvYPfpPjNorFYv4gjDGuxxejJFFAIBDoDlHMgLp9 3ni4NxKJRHrTEIvF3DkmJSWVZBD+SRHvIxKJRPzddJ8zEgMAwBuZQhRI2jX2IwvGPvxx7f5j m3tVY+UbfblUkvHGqd/ZOrImc5l+JZWICh6HXrjof/1h9hvfZVwSiYRr6gKBQPd3UlIS17Qk EgnXdIvZQSKRlEoUEIlEXAcVCoV6gYP+ySj8Wb01bhz+NLjpiUQifjYqhkgk4uZpqNlLJBJE AQCAEjKFKJC8d2Ine2Y37FCshihkWiNm5dB++uHrq3s1/njcsb/Fs/qOWhn6hNIPfdNS4OXl 5e3TeeKBZPXdg4ObVrRitlVr1K4/cveL0z+3/qTDF1OWzv64YeOPh/9xJYuenhz1VXPvtqJb OUp55O9dGjbw8mrQ8OPBG/xfe5Ygzzn+beNmXYduii7+c3oHuDas61vcdoFAIJFIdO2/8M46 haOArtHq/uZuPIjFYn4U4C7BucPx2z//EPzR6J9AwD+cUCjkdtY1eP6w3IEK55Vimje3Mz95 8E+BG0F3/0AsFuvdCeAIBAJ+fgIAgGKYUBQYsu9ePtHt+c2ZbdWOk3dfnNaM2VSuX9vD0brV 4kNLevt42HffkBJ3d3Pfyla1v9h4PeXKmoGejHVbeTYqTVZwYBBjFZrMPBR5bIIHs/hk1qZN Cwa6M69ZATHZ0et8Xao2GHcs5d75qW0t7VqPPxWl4o6dl7mzI7Oq/cmCsn+0wLVhvTav267X 7MViMT8uFBMF+C8JBAJ+FOBv1+3MXfTrXfeXPAroXtL1ZpFIJJVK+UPpnRoZjgL8UFJMFODH Jt3jhsIPVriIgCgAAFASphIFKjLbrzcGPUw50LucRfmaLddcSDk3pTGzaDxpx42CAlXIwk+q WrEv18U8exIrmfYBs/CacCAicsfoWsyi37bbOUSqw8OYTaWmsy6T8uGu8S3LWVta2th3mncp VU2nR7nYlHcYfejps/jLa/u5sYqfbrjEvzGgUSmVKpVa+4YPqpTxm2upRAG9t3NHKfIBAf96 mlumUEzXLBwF+BPTa/b8G/h6z/WpUHsufEeheEKhkH/zgzs0lxj4d1MQBQAASsJEokAXJ2ZR ybVG3fpe3k1bLA4hUsQfm+DNHNqv9ksmostzfavaMgdPL6/69b0aNBQ0+WLO3sv+4tF1mEXf rWFZXBSY7k+kSfT79dPKjFXvdyAsg4iODKtiaWlVtaZ3/fr1vbwbN/H5ZsOF2DJu/IXxu1Sp RwGuWRqKAty1Nf8JfeGVd5xiogC/8XMT4F+sFx8F+Cf4xuUIeg9N+KGHe0kkEnGnjygAAFAS JhIFOtkzu+FH4l51aNnLKLDqXBIRRW7p48rYp6v/WWGuzHjyIvv6hm9rvhYFHJrPvazNvTKn s4djndrVXcvX7bcxUknXFja1sagw8pD85cDZaWmZBdxx1Kqnt/0DQm7F5xqeX6nTu/2u1+Z1 35TT6756Hfc/RgH+LXRu3X7hK3jOW98VKKyY9vzGzq33QfEjFDdD7gsRnGImAwAAZBpRIHHn aF/GWJ+d4Tnctty4gyM9GGux5FQCEVH+jV9H+NpW+Gjm+vXr1y0c/k2f0VtCpX8McWLsy42h mUSq/f0YYzW+X7t/8oeMVZ94NFiytl9FZvPpwqMpz85P6dqoome3xevXr/910qc9hv927DF3 HFn6hsaM2XpNuWV4fqVLLwfQv/wGgU4xawX0lgoa+lu3M38y/Eb7dmsFxGKxbq1AMd9u4J+I VCrVW3tY+G/+6fBTjt5uhRclEO4KAACUjClEgezw0+IFc+YdDH/26mq9IOPeyd/mLNp6OSbr 5RblnS3zpv8wbty4cRN+mr3m9L3U1LBjK+eI9t5MlhNpIg/NWbBw2a6je+ZMmbXu7/AXRMlB f66cOVm0L05BlBG0cvqkCePGjRv/4+TFO27Ev/rdAqX89rY5c1f9ecng7EsV/2v0Orrt3CNz /mW6LgHo8Bs2/+1FNm/uFr3eXQHuKIUXCvAnQ68vQizybr/ec3q9yfAnqduNfy780+RfxHMn XmQU0Hs6oMOtHCxyqQGiAABASZhCFAB4s2K+OggAAP8FogC8H/BjwwAA7wiiAAAAgFlDFAAA ADBriAIAAABmDVEAAADArCEKAAAAmDVEAQAAALOGKAAAAGDWEAXKyMO4JxGRj+6iUCgUClW2 FRH5SHo3Lj0922CHQhQoG5cCbl8Pux8W/gCFQqFQqLKsW9KYCwFhMbFJhjoUokAZCQwOf/Yi IyM7G4VCoVCosqxsWa408mFMbLKhDoUoUEYCg8PTM7Ny8/JQKBQKhSrLylco7t5/hLsCxhcY HJ6ZnZMnl6NQKBQKVZZVoFJGRsUjChhfQHB4dq5MoSyQF6BQKBQKVXal0qjvP3hs2lFAmZ0Y LQ0LC4tJlau1lB5369adiCe5BnfXI0uJDr8V9vCFSv8FdfbjKGlYmDQpV01ESvmz+2Fhd2OT czUlHbl0BQSH58ryVWqVUoVCoVAoVNmVhrRR0QnRJh0Fkk6PaevAGPMcezJNTnt6MWZdeXqA wd31hC1qU4Gx7rsK9F/IPj2kSSXGKv4YmE6kTYn8pQFjLp9OC5aXdOTSFRAcnpev0Gg1ag0K hUKhUGVXRPQgJtG0o0Cy38RObsylSpVaP9x4nrd/cAUbpxqiy0SkSr51fM2KX5au+PX3Y3e1 lHVt529rN287dCuDKCc66K+1vx0M8DuyQOhlb8kafy1asnTZ739eSuGGzfEb5evBmPv0yxlE 2qf3V/swVrf7nCtyIlJG+e1bs+yXpUuXrf3jaKyGiAqexQT+tfHPbX9u+HX10lW//b7vZubr s5TFXD7+x8a9oc+y3+62QkBwuFxRoCUtCoVCoVBlWUQUHZtk8lGggxP7cOhoQfNFl1N3Daxk 41Rr0VXl0xtrP/dp+lHfiTP6NLNzbTXz76tnV3erxJhrz1VhD/1HVWeVfX46cvyvOX3qVrBk Xt1+mjFz9tLfzrw60ZdRwPPncC0R5SdvbMVYnR7zb+enX9k3s41Lk+4jfpg5c0Qzu4qfTd8d pSkI3TXUgTH3T/pNnj/1U3dLO0G/vVI1b5aP/xzqzVj5HwMfKAyeSXECgsMVCuVbvRUAAOA/ iXmYbPpRwJE1nXNpafdWQ7cv6m1nV63+7CNxv31RmTUeeUFG9GRrO0/GuomV9OTksIasnKvg o+bVa3b4LeQFEUlXdna1Zv33F1orkOM3yteTMbu6H3Xt3r1blw6NHJhFwz7LrknPjRRYMh9R RA4R0fEhbszOa+711HuHx7ixCr3XBhQQRS3/vDJjbVbF8YbLiw+78Pfek9IXb7nYAFEAAACM 5T2JAg0n3Y3eM7Bu1zZNmJ2r16RdEdM+YFaObt4+rVo29rBmjNX8ISKPtE9vTGjGmEVN4dqQ PC0R0bUlHV2sWe/t6Vq9YV9GgSp9V/59+vTpvzZ/V4+xBn2X+wfs71+Pleu9MTadiOjFth7M xvXLdf4PToxzZVW+2eifSaS5NN3T0brysMMG5/zvIQoAAICxvCdRwHvCzad5J0fWLWfF7Fy8 Ju+KmNaE2bcctPlChDQiMupBzMP41HyN+sXh8W4VGGO2DfrOu5JKRBSyuIOLNeuzI6OoKODB mMfs0Hwiyoxb15Kx+n2XBwT+LazPyvVcH5NORBS+sAWrUOPbvyPvHxvrypwGbriURZS+d5ir PWs446rBOf97iAIAAGAsph8Fzv3UrhLzGns9QaX2G1vBkllWrrUoIOvy6s9t7JpM/ut2gUql StzZd/Lfz57s6W1nV913/KbTk+pYOvb65fRztfb53pG1KrKG0wJleflyhfLV3fucc9+3dmPM dVqwbtngqg8Yq91t/h3l8z2jfO0qfLU3IiU//96sJraVan91IFMpPTDKlVXu/9uFzPyI+b61 7Gzq/XwjjzfLlEOze7hWbvnLjfhC31UoEUQBAAAwFpOPAin+c3t7uX4881aCgsh/dG1PT2+f 5TeItI8PL+xT3c3dw8PDw93NddDchR1rudZqNOrvNHp+45fe7q5u3dZdiidt5vbBLWu6uXt4 1GzRafEdbthc/6lffuDq2mzh9SwibWrMpi6urh8OXnZTQaSNXv9NxzruHh4e7jXqfb71kYYo J3TfuDrMsrxjVTcPdzfXZnMDn73et1OOzO1do1qbFWGP366fIwoAAICxmHwUMAk51/4a7sDK 99sQUOIfN/p3EAUAAMBYEAVKIv+B/28Dun79y4k7iAIAAPB/BlHAJCAKAACAsSAKmISA4HCN 2kj//gEAAJi3uPgURAHjuxhwO/Rm1K07MSgUCoVClXFd8L9l2v8yoXnIyMx5+iwdhUKhUCij VH6+wd/NRxQAAAAwa4gCAAAAZg1RAAAAwKwhCgAAAJg140eBZ8+eXbt27SYAAAC8A6GhoXFx cRqNwS+0Gz8KXLp06bvvvvsRAAAA3oExY8Zs3rw5JyfHdKOAUqnMzc2VAQAAwLuRkZGRl5dn qBEbPwoAAACAESEKAAAAmDVEAQAAALOGKAAAAGDWEAUAAADMGqIAAACAWUMUAAAAMGuIAgAA AGYNUQAAAMCsIQoAAACYtfc6CmQG/jFvUI8vP+86dGfcOxgeAADADJhCFHguWTvxi7ZtfVu1 aN7cp/XHn04++rwkU38a+GuXqlatx/1+9Hyw3+qBzVu17fdbaEneaD6kUqlAIND9zRiTSqXG nU9pEQgE/zfnFBgcvQAAIABJREFUAgBgdKYQBZJ2T2hnw9jny07cvCcZU49ZuTefeNjgaP9Q X9swtDpzn+r/iIjUGY8fPIiOf27w31owHUKhkDHGGBMKhdxGqVTK/sFvctxGsVjMH4QxxvX4 YpQkCggEAt0hihlQt88bD/dGIpGoyGmIxeLC52gI/6SI9xGJRCL+brrPGYkBAOCNTCEKJO+d 2Mme2Q35O0pBdOvnZsymSvvJe4N+/sixTp9tG5YP9+0pCn6YF7+lY3U3N1dXZ89GAzZH5d3a K2xYzpJZVnBydh24LfXvsdVq1Gk6fNZEQRXH2l2XnX+hid/Ts4VLlSaTb2TLnl/+uUmVam6u LlXrd5p39KFa++rYeVl7ulWsLOi6LPJNn1SpkEgkXMMTCAS6v5OSkrimJZFIuKZbzA4SiaRU ooBIJOI6qFAoLNyMdRmFP6u3xo2jNw3d2RV59CKJRCJuT0PNXiKRIAoAAJSQCUWBoQeilaS5 MlXArJ26zDhwcYYPs61ct3692h6fr943s10tx6rDj5Ey89j3rszl45UhaRF/jqjJLL7eciND o1UdGsqsHXzmnkm6uqCxnUWLcYsW/NjNvbzvb/dSs27Nq1+uUosFtyg7Ytln1qzx8EN3ldyx 87MP9HOv4dv71/tv/KhKG9eGdX2L2y4QCCQSia5BFt5Zp3AU0DVa3d/cjQexWMyPArqLb/4N CX4D5h+CPxr9Ewj4hxMKhdzOugbPH5Y7UOG8Urg9i0Qi3SfAzYSfPPinwI2QlJSke0nvTgBH IBDw8xMAABTDVKJAJWbTdf7ei1dWfcxYleZf7Qh5dnZyI2bZbPaBKCIKnf9RFWvWaf6lK0Hn t4/wYqz2qN03w7ePrsUs+m4NyyJSHR7GbCo1nRlM6icn5n5W2ZIxG+f+625maujYcCfr8pUG bQi5cnHP7M+qMNuP1/gllvDTeae45qfX5nXb9Zq9WCzmx4ViogD/JYFAwI8C/O26nbmLfr3r /pJHAd1Lut4sEomkUil/KL1To0JRgLtvUcIowI9NuscNhR+scBEBUQAAoCRMJAp0qcwsXRq2 aNvu08979d16j0gZf2yCN3PssNovmYiCRR9WsWFuTTt2aNe+Y5cve/Ue+/uZMP+to2rrRYHp AUSqh8cXtbFnzOVL8dUXWqLDQxwtrWxqt+zcvn2HTl179Ok/Y9+1BK3h2ZQNfnMtlSig93bu KEU+IOBfT3PLFIrpmoWjAH9ies2efwNf77k+FWrP3ALAEj4gEAqF/Jsf3KG5xMC/m4IoAABQ EiYSBTrZM7sRxxNebZPFH5vgzRzarzqXRERxfw+vbsE+nBele1GT+/jeoxc3No2o+VoUcPD5 OViVfnZ0C2f31q2aNXB077jgmlwb8Xs7O1Zu4I4M3XtTU+IfP3m1ulBV8ODkH1v2Hg9LNzy/ d4HfpUo9CnDN0lAU4K6tRSIRN2zhlXecYqIAv/FzE+BfrBcTBSQSSfErFfToPTThv4V7Sfe4 ofCxAADAEFOIAok7RrVmjPXeEZ7DbcuNOzjCnTGfxScTiIiU0Qfnd69o5dV33LhxYwd/2rHT d3/eiNg82JGxLzaEZhKp9vVljLkNXrKuf13GvGb7Rd4SD3VirPHIPx6l3Vj3fVv7Ss2Hjhs3 blTPRm37/XriVeaQpa9vyJhVvUlhhudX6vRuv+u1ed2Fsl731eu4/zEK8G+h6+7tU1FX8Jy3 vitQmF4GYq/jfw5FHou/Az9CcTPkvhDBKeFqRAAAs2UKUSDv0Q3Jvt17Lj/KVHHbVLmJocd3 7z9/j7uC18b77RFvXL9+/foNm3ccu5GYlRV77cju3YGxaUoibcKV3fv2H7x09dLOrTtPXo7P IUqPPH9kx587A1KURPn3joi3bFi/fv36TX/uvxCTKn91nIKHkt1/HfWTZhqeX+nSywH0L79B oFPMWgG9pYKG/tbtzJ8Mv9G+3VoBsVisWytQzLcbDF2pl2StAD/l6O1WeFFCMccCAAA+U4gC ZoRbWs/RbecW4fMv03UJQIffsIu8jGZFfYNA764Ad5TCCwX4k6HXFyEWebdf7zm93mT4k9Tt xj8XvdPkBiw+Cug9HdDh7isUeTsBUQAAoCQQBeD9UMxXBwEA4L9AFID3A35sGADgHUEUAAAA MGuIAgAAAGYNUQAAAMCsIQoAAACYNUQBAAAAs4YoAAAAYNYQBQDK2vUb91EoFKos6+q1yGfP DP5jO4gCZcQ/8PadyNi7Dx6hUCgUClWWdS/mccCVOzGxSYY6FKJAGQkMDk9Ny8jMyUGhUCgU qiwrJ08mvRcXE5tsqEMhCpSRwODw9Mys3Lw8FAqFQqHKsvIVirv3H+GugPEFBodnZufkyeUo FAqFQpVlFaiUkVHxiALGFxAcnp0rU6gK5EoUCoVCocquVFrN/QePTTsK5D+9HXB8//79AQ+y lFpKCDl44MiJiOcGd9eTdu/SsQP7Lz8q0H9B9fSG5Pj+/cfDnxcQkTw7ym///lNBES/UJR25 dAUEh+fK5Cq1WqlCoVAoFKrsSkvaqOiEaJOOAomnRrWxZ4w5Dt3/Ik/7V0/GLBym+hvcXc+t Rb7lGOu2W6X/QvapwY3tGavwQ0A6kfbJ3SX1GKvaYUpQfklHLl0BweH5+QVarVajQaFQKBSq 7IqIHsQkmnYUSPab+Kkrq+VR3W1U0LPcvYPtbZxqiC4TUX6U3+9jvh06ZMSo8esCCjTPTy0Y N3bSjFXnU4hehP69YOzY1Qd2rhv7efVyFqzGR8IhQ4b/OHt/HDdsjt8oXw/G3KdfziDSPr2/ 2oexut3nXJETkezqtqVjhg8dMmT4uCm/3VAQkfxx2N8Lfpw2c8ZPY0YPHTlm/JIzT16fZVbY kd+n/Lj4THza291WCAgOlyuURKRFoVAoFKoMi4hiHiabfBToUJm1HjPZt/Esv5SdAyrZONVe fFXxyG/WB/U+6DN1887JXZyc63yzIfDaodE1GHPuPOd8+KmBlVmtLxYFXw9YP0LgYMVafL9x 567dh06EveCGfRkFPObeVhORLHFDK8bqfrUgPO/pyVWDvRxbjvll/a5dSzs72vkM/CVUpbz5 1/DKjNX96qeN+7YNbWxv69nm1ytK3iwTtn0rYMxhUlC0wuCZFCcgOFyhUL55PwAAgNL2XkQB R9ZkVsi6b5r1+m1OTxu7avVnHIhe8kk5G5/Rkmyix1s+qcFY180Kdcb1Gb7MppJ7neoegl7b I2REdHt5J1dr1nevXH/YHL9RvtUZs3au27hp0yYNvdzKM4tGXy+7cvPEUG9m8cnS+9lERJIx tVi5OlP9k+8dGePKKvX7PVBO9GhdzypWrNXS+7zhCtISom6GSpNzFVqDZ1IcRAEAADCW9yQK eE+UJhwbXb9DMy9m5+o1aVfEDB9mWd7BtXrNmu5OtlaM1Z94J0+rSbs/sxVjNvWHbb6t66vX lnR0sWa9t6frd+iXdwWqfb/vZnR09NWzMxsz5tV3uX/A/v71WbleG2LSiYjSt/di1q6f/3bx wYnxrszpm42XMogoYGb1ytaVBh8wOOd/D1EAAACM5X2JAuNvPlFd+snL1oLZuXhN+StyVnOL Ch9+dzAyK1eWly/LTkuXaUgRv7lveRsr2/J21TtNOJOgIaLrSzpWs2a9tmfoD/vPWoGZIdlE 9Dx6TQvG6vddHnjl8DcNmO2Xv0VnEBFdm9mYVag55njs/aNjXJnTN5sCZURPtg5wtmM+C8J4 w2lVinxZbl6BWmPwRIqFKAAAAMZi8lEg6eyEtuVYndEhj5V0eZojY8zeY0GQ7M72QU4V6g9e fiw6NjY2eNGHQzY/uL2yLbOo22XeoZAFjSyt203cESdTZhyf0siR1Ri5/0F0zKPHL149J8g5 O6KFM2NVJwdlEGlT7q0QMFa969zb2uyTs750KvfpGr8bMTHnv69t495ixJk8VfiB0e7Msfu8 fZExZ8c2cK3k3GZNJH9VQNJfP7RlrNacqw8LfW2xRBAFAADAWEw+Cjy/9uuYT1v3WxH5pIDo xrx2H33UucfmcCJ6HrB53IfNmzVp0qRJ0+YtJ65a3ad1y/ZdRedklB7553jflj5DtgYnEMmP T+3V1qdZkybNO/f59S43bN61pSO6tW795e/hOUTatPg9Q1q37j15k1RBRE/2Txno26xpkybN Puww8ugLIsoJ3TeuNrNy9KjTqEkzn1bd1ktlerM8v2bsJ637brmb/Hb9HFEAAACMxeSjgEnI Dtk1pAKz6bf5SqEfKCgdiAIAAGAsiAIloXgctn/OjzN2BEfnvZsDIAoAAICxIAqYBEQBAAAw FkQBkxAQHK5+228fAAAA/Bdxj1IQBYzPP/BO0GXp5ZC7KBQKhUKVcZ07Hxobl2yoQyEKlJH8 fEVObh4KhUKhUMaofKXK4D+hgygAAABg1hAFAAAAzBqiAAAAgFlDFAAAADBrxo8CMTExf//9 9xEAAAB4Bw4ePBgaGqpWm/CywZCQkDlz5iwCAACAd2DevHm7d+/Ozs423SigVqsL/o8YOk0A jrH/IwUA86JUKmUymUKhMPR/SsaPAgAAAGBEiAIAAABmDVEAAADArCEKAAAAmDVEAQAAALOG KAAAAGDWEAUAAADMGqLA/zOpVCoQCHR/M8akUqlx51NaBALB/825AAAYHaJAWRMKhYwxxphQ KOQ2SqVS9g9+k+M2isVi/iCMMa7HF6MkUUAgEOgOUcyAun3eeLg3EolEetPgjq73gRSDf1LE +4hEIhF/N93njMQAAPBGiAJlSiKRcE1dIBDo/k5KSuKalkQi4ZpuMTtIJJJSiQIikYjroEKh UC9w0D8ZhT+rt8aNoxcFJBLJvxpHJBJx8zTU7CUSCaIAAEAJvddR4NnRed+2bSpo3KjL2rvv 3y/+cm1Y17e47bruqGv/hXfWKRwFdI1W9zd340EsFvOjgFgs1rv+5rd//iH4o9E/gYB/OKFQ yO2sa/D8YbkDFc4rJYkC/OTBPwVuhKSkJN1LencC+MPy8xMAABTDFKLA06PzBgo8PT09q1ev 7ulZs96AP+NKMvXEMwvbVLT4bMmJu/GJ11b1qFGn4WdLr5bkjSaCa8N6bV63Xa/Zi8Viflwo JgrwXxIIBPwowN+u25m76Ne77i95FNC9pOvNIpFIKpXyh9I7NSoqChR+MlJMFODHJt3jhsJv 5yICogAAQEmYQhRI3vNjx3LMuv+2G89yo+b52DGHGkN3JKjkuVk5eSqVUi7Lk6uJSCXLykhL S8/IyslXEallF1b0d2eePxy/kZqn1MjSkp+kPMvIkWVmZOXkFaiJSJWXm5WRKVNpiaggJyM9 LT09I1v30itarVKWlZ0jUxj8txvfDX5zLZUooPd27ihFPiDgX09zyxSK6ZqFowB/YnrNnn8D X++5PhV7S5+LFMUQCoX8mx/cobnEwL+bgigAAFASJhEF9k7sZM/sBu+9m0d0d3ELZuvc7qcd F6cJWOUOy+ZN+rz2J1MuRiTdXNrUqVqtmjWqVnHrsuTq8xv7hzStaM1YharuNYftSN01iJWr VEM4bbLAnlVsMet4kuzeH+1q2FZqOjUs88X9w+Oq27vUruHu4PbBuG23ZcpXx87L2PYRY26t 54a/6ZMqXfwuVepRgGuWhqIAd20tEom4YQuvvOMUEwX4jZ+bAP9ivYRRgErwvQC9hyb80MO9 JBKJuNNHFAAAKAkTigLDD8cRKfxGNWCWDt3nnbw4w4fZVvH+oPUnbUZs2jnhg6rlqk8KIaLA STWZY4tFV9Kjd46uxSyEuyKVROrDw5iNY8v5F9Ijf//YybLBwB/Gf/Oxu0u3XUm5zy9NcLOo 0GF9ElHixp52rO6AfXfk3LHluWd/aNuu77jtZbmsUe/2u16b13VEve6r13H/YxTg30LnLsQL X8Fz3vquQGHFtOc3dm69D4ofobgZ8p84cAsmihkTAABMJAp0dmDWbUYt3rhtvDdjNbr+cFKa emZiQ2bdYv6Jx0R042dfJyvmO3bLti3rf+7uwZjHsG1Xb+0YU4tZ9N0alkWkOjyM2VRqOiOY KD1ozUBPK8bs6k7460E+0ZEhDlbl7LvN2rFt06Lhrcoz1mrZqUcl/HTeBb0cQP/yGwQ6xawV 0FsqaOhv3c78yfAb7dutFRCLxbq1AsV8u4F/IlKptPAdfjK8VoCfcvR2K7wogXBXAACgZEwl Cjgyq3odeg8ZMeqH6bNOJRIpHx2d4M0cO/zql0xEQbNbOVkzr8+++27EyO/HTZo5a9XhkCj/ Ld/X1o8CgUTyu3umCGwZq9x21fknaqLDgx0sbex8eo4dOeK7MT9MnT1304V7z7Ql/HhKG7e0 nqPbzi3C51+m6xKADr9h899eZPPmbtHr3RXgjlJ4oQB/MvT6IsQi7/brPafXmwx/krrd+OfC P03+RTx39CKjgN7TAR1u5WCRv0mAKAAAUBImEgU62TO7EccTXm2TxR+b4M0c2q86l0REKX4T 61uzxhNefkEg58mtwDvJYZtH1nwtCji0mB8oT97ft15l7x7dOvu6V2k6/nyOKm5v74rMtvua l3cCou6GhUdncccpyL+xYdKURb/7pRieH5iCYr46CAAA/4UpRIHEnWN8GWN9dobncNty4w6O 9GCs5ZJTCUREmqch20a4WLi07tKlS+e2DZu2+X57WMQfQ5wY+3JjaCaRan9/xpiLcM78dlVY ueZLgpLiD4zxYMzt86X3MqKPL+5Rybr6J126dPnUx7VpzzWnE7njyNI3Chgr5z31luH5gSnA jw0DALwjphAFCl7E3wu9dj32Rd6rb/RpFOmP7ly7ce9JJvfbQen3rl/2v3jx4sVLAVdux2fk 56fG3bp2LTpVpibSpj+8FnojLOrh/SvBIdLYNDlRXsq921eDrkZlqYlUKbevBF66ePHiRf+g 0HvPcl59hUCjen7v2vXbkUl5hucHAADwf8wUogAAAAAYDaIAAACAWUMUAAAAMGuIAgAAAGYN UQAAAMCsIQoAAACYNUQBAAAAs4YoAAAAYNYQBQAAAMwaokAZuRH2ICDoTkBwOAqFQqFQZVwX /W8lJT831KEQBcpIQNCdezGPY+KTUCgUCoUqy3qY8ORK6N3Yh8mGOhSiQBkJDA5/np6ZlZuL QqFQKFRZVm5+XsS9uJhYRAFjCwwOT8/Mys3LQ6FQKBSqLEteoLh7/1FMbJKhDoUoUEYCg8Oz cnLzFQoUCoVCocqylGrVvah4RAHjCwgOz87NK1ApFUoUCoVCocqu1FrN/QePTTsK5Dw8t/vX BQsW7L76TK6hyMNLFi1f459gcHc9ScE7Vy1a8PedfP0XCh6e3PrrggWrJQlyIsp9EfLHggXr 9l5KVJV05NIVEByeK5Or1WqVCoVCoVCosistUVR0QrRJR4HE06M/qsgYs/tanJqr3dOLMUvH af4Gd9dza3Gb8ox1212ow2efHiKoyJj9jwHpRNqUu0vrM+bccWqQvKQjl66A4PD8/AKtVqvR oFAoFApVdkVE0bFJph0Fkv0mdnRh3vUaVh127knWnsH2Nk415l4hosxru6Z3bte2bbuOXaYc zC5I+mtU187d+kzY85C0yX5rhnXuMnnT6jn92jrbWLAq9Vt/1LZdzyEb7nPD5viN8vVgzH36 5Qwi7dP7q30Yq9tddEVORC9OzB/12cdt27b9+LOek/yyiCjvgf+6YZ/36tf/q66ftW3fqct3 2x+8PssXAX9M7/H5yN33U97utkJAcLhcoSQiLQqFQqFQZVhEFPMw2eSjQIfKrOXEnz/z/ulI wnZhJZsqtZdczovcO8LDrdW4Df7X1w2uXqVK+4UXokIXN2fM+aOxewP3f1XeqsWIzffiYw5N auVkxTrMlVwPDb0dkSjjhn0ZBTxmXZcRUXrs2haM1f1qoTTn8c4pnZzt2y8+cD409MAgD5va 7X64KFfd2juiKmNNhi87F3ZlTjtXW4daM84peLNM3DmmFWNuM67EFhg8k+IEBIcrFMq3eisA AMB/8l5EAUcmmHFr2yhB5wVTuluXc/Gauve+qKVV+Q9Hn0ohilzXpjpjn66VFchifv3C2tqm gqODZ9sRR+JURHTzl09drNnXu3P0h83xG+VbnTGris5uHh4ebi4ONsyiUd/lQVcPf+PFrD9b /SCTiOjylAasfK0Jpx/dPzrGlTkKNwTIiJ5s6edsx5ovCOcNp5HnZDx79iJXqdYaPJPiIAoA AICxvCdRwHvinRTJFO82DWoxO1evSbsiZvgwy3IVq7q6u7m5VK3qXK31rDv5Wk169OzWjNk2 +HZLuO5GfcjiDi7WrM+ODP0O/fKugNvkiyn5+Xnxt5d9wFj9vsv9A/b3r8fK9doQk05ElL69 F7N27brmwoMT412Z08ANlzKIKHBW9crWFQcdMDjnfw9RAAAAjOV9iQLjbyRrr81ubM2YXTWv afujFvja2rX47mSibqeC52l5RDl3Fna0sKlUzdOxWstv9j1QEFHYLx2rWrHu29L1hy1qrUD9 r5cF3zz1bWMrq47Lo7KIiAJ+rMvK1Z54PuHekdGurMrgLVcKiGJ/61nZkn20MpI3nCrneVJM dHyaXIm7AgAA8H4x+SiQdGbsh9asxndX4wvo9nwXxphttXlB8ujjE+s71/5swq+nzpw5s31U 7Z4rrx7/yYuxhl+v849Y08KaNe6/4lZqXs6lpb7OrGqPZadOn70UrOvvRESUfWZYM0fGHCYG phNpUyKXeTPm1mlWGOUHrhleq4Lv1M37zpzZ3NPZtlG32ZcLVHf+Hu3BKrYft/L4mY29XCu7 Cr7e9Yi/QDBx+3cfMFZlSnCMovAplACiAAAAGIvJR4EM6e7F3w+auiM2VUl0/48RQ4eO+uFg NBHlhh9dOqD3V926devWo7dw+Q7x+P79R4zdeF1JOY+OLRvc/+sZB28+IdIEr5k0pG/Pbt2+ GjpeHM0NK5dunTdh0KDx+x7IiLSZyWfmDBo0aeWB6AIiyrywZrrwq+7dun01YMSCoDwiyg7d N64Ws/EQ+H7W7auvB0w4GK/Wm+XV3YuHD5p6KDb1rb9BgCgAAABGYfJRwCRkX9052I5Z9t18 VfNuDoAoAAAAxoIoUBLKZzEB2zdsOx+R9Hb3/98IUQAAAIwFUcAkIAoAAICxIAqYhIDgcKVS /eb9AAAASlts3BNEAeMLuiy96H/rUuBtFAqFQqHKuM74XY+LTzHUoRAFyohaozH6P06FQqFQ KLMtrdbgz+IgCgAAAJg1RAEAAACzhigAAABg1hAFAAAAzJrxo8CtW7dWrFixFgAAAN6BVatW nT17VqUy+Lv5xo8CUql0w4YNfwIAAMA7sHnz5uPHj2dlZRlqxMaPAlqtVv1/xNBpAnCM/R8p AJgXjUZTUFBg0ncFAAAAwIgQBQAAAMwaogAAAIBZQxQAAAAwa4gCAAAAZg1RAAAAwKwhCvw/ k0qlAoFA9zdjTCqVGnc+pUUgEPzfnAsAgNEhCpQ1oVDIGGOMCYVCbqNUKmX/4Dc5bqNYLOYP whjjenwxShIFBAKB7hDFDKjb542HeyORSFR4GmKxmDvNpKSkNw7CPynifUQikYi/m+5zRmIA AHgjRIEyJZFIuKYuEAh0fyclJXFNSyKRcE23mB0kEkmpRAGRSMR1UKFQqBc46J+Mwp/VW+PG 4U9DLBbzI1FJiEQibp6Gmr1EIkEUAAAoIUQBo+HasK5vcdsFAoFEItG1/8I76xSOArpGq/ub u/EgFov5UYC7/uYOx2///EPwR6N/AgH/cEKhkNtZ1+D5w3IHKpxXCt/2KHwngJ88+Keg9xax WKx3J4AjEAj4+QkAAIphClFAq1GrlEplQYFCoVAUKJVqbcnmro0Xj+lax9XN3f3DpdfT5ApF gUpTsneaBK4N67V53Xa9Zq939VxMFOC/JBAI+FGAv123M3fRr3fdX/IooHtJ15tFIpFUKuUP pXdq9HoU0HVrDneCxUQBfmzSPW4o/GCFiwiIAgAAJWEKUSB53+TPq1nbVKzi4ubuUqlCxU9/ uZmjeHMciD86s7mdVd+tYdka9b3fe9as16jrL9fe+C4TwW+upRIF9N7OHaXIBwT862lumUIx XbNwFOBPTK/Z82/g6z3X15sGP0ZQofxh6Oz4Nz+4Q3OJgX83BVEAAKAkTCIK7J3YyZ7ZDf07 uoCer+1QidlV6b0hWvbs4b3opNyczKfxCU/zNES5jyPDw8Ju3YmMeZKjpfxnh+Z86cI8vt1y 9FpMqir7WezDh3HJKQl3pZHRCel5RJqcxLh74REJuRoidXqM9HbYrdvhUY8z8l8LGRp15uN7 92PinyuK/5xKG79LlXoU4JqloSjAXVuLRCJu2MIr7zjFRAF+4+cmwL9Yf2MUKGYoPXoPTfih h3tJJBJxp48oAABQEiYUBQbvvSsjilreitk6fzxhq2RifWbbfPKYb3wqNfvJLyTsxMSajrV8 W/nUrOLQYtKxuNBj49pUs2Oscm1By4kHnu/ox5iVa/+Zc3wdGaszYX/0s9DVH1RiVT6ZF5ER f3GdsKpjfV+fRs7Otfotv/Q879WxZembmzFm33j67Td9UqVI7/JXr83rvilXfJv8j1GAfwud uygvfAXPeeu7AoUVfkDATaDIdYt6x+J/UPwIxc2Q+0IEp/gxAQDAhKLAt8cSiLL/7leLWVbq u+zSxRnNmbWzz6c9hw2Zt/PP4fUrWHrPjyaiW7PrswpN5gamxe0ZV5tZDNwbTUTqI8OYjUOL +f6yx7t71LTx7NK/bxeBh9fwk+kFCYcHOLDyPfbIiF7sENozzz67br7KAgV5l5cPHzlt6fE3 f4mtlBS+Df6vvkGgU8xaAb2lgob+1u3Mnwy/0b7dWgGxWKxbK1DMtxv0TkTvHHXjGForwE85 ersVXpRQ+FgAAFAkE4kCnR2ZVaNu3/44pZsLY02G/xYS++zUTw2ZbevFZ5KJ6MbPvk7WrHHP yVMmTRjLeEw8AAAgAElEQVTc2pExl0GbAm/sHFObWfTdGpZFpDo8jNlUajojiEh2e/uEhraM VWyx8FSiiujw4EqWtuXaDJox5cdhXepZMvbBwmMxJVyYWOr436HX0W3nFuHzr5L5q+r4DbvI pXasqG8Q6N0V4I5SeKEAfzL0+iLEIu/26z2n15sMf5K63fRWCHKnyd/Of35ROAroPR3Q4VYO FvmNREQBAICSMJUo4MCsfb6Zsnjlmo3btt9IJyp4dHSCN3Ps8KtfMhEFzW7lZM1aDF+xeuWq X3//Y/vOoyEPEgI2j6xVRBTIvrZxeC1Lxio0nnHooUIXBewqdP5h3aqVq9du2LrrrzPhiZkl /HTAdBTz1UEAAPgvTCQKdLJndt8effRqmyz+2ARv5tB+1bkkIsq4vqBZBYuaA46qiIgoIeLs wYCHt7d8V/O1KODQcv7FrJjNn1Zz/PC7kQO7eVWq3v/A8/yn575zZrbt5oQSEVFu4KWzAWEv uOMoZBdmftljxPS98YbnB6YAPzYMAPCOmEIUSNo9oZ01Y8LdEbncNtmjI2PqMLuPlp9JJCLS 5sT7zaxv61irYcOG3nVd67Qet+dO5NYRboz1/ONmFpHq4DfM0s69//QpTe2ZS/vfQrPST0/1 rsAcWs+6k5kStvPbalZO9Ro2bNighoN3z/Xnn7w6TsafrRir0nz2HcPzAwAA+D9mClFAnZ+d 9jQlJTNf9eoRvlYtz3qe8jRNplD/s0melpKU8Pjx48ePE5JTs+UqVV5WakpKRp5SS0TyzJSn T5+lZ6YlJz15kSlXE6lkaalPkpLTFVoirSw1OVH31sSUtLyCV79EpNXkp6WkpKblqgzPDwAA 4P+YKUQBAAAAMBpEAQAAALOGKAAAAGDWEAUAAADMGqIAAACAWUMUAAAAMGuIAgAAAGYNUQAA AMCsIQoAAACYNUSBMnIl5O75izcll8JQKBQKhSrjOuN3Lf6xwWaPKFBGAoPDYx8nP37yFIVC oVCosqzEp6nXb92PfZhsqEMhCpSRwODwFxlZ2TIZCoVCoVBlWTJ5/t17cTGxiALGFhgcnpGV LcvPR6FQKBSqLEteUHD3/qOY2CRDHQpRoIwEBodn5eTmKxQoFAqFQpVlKdWqe1HxiALGFxAc ni3LK1ApFUoUCoVCocqu1FpNVHRCtElHgXTprqXjBg4cuPhkfJ6aQn4fNuS7CQeiDO6uJ+bY ojGDB/4amKvVe0Eu/XPuuIEDx+19ICPSZiafnjVw4MQVB6KVJR25dAUEh8vy5GqNWqVGoVAo FKrsSkv0ICbRtKNA0pmxn1RmjFl9+XtKtmbv14zZVp0RYHB3PTcXt63IWPed+fovZJ8Z1qwy Yw4TA9OJtCmRyxoy5tZ5erC8pCOXroDg8Hx5gZa0Gi0KhUKhUGVXRBQdm2TaUSDZb2LHaqxp k1aVBxxJyPhrsL2NU425V4joyZlVQ7zr1qlTt179ARtTch5u7tOkXkOfXmvDSRm3f3qH+t5D Vswb17W5g5UFq1CtVp06Xh99sUzKDZvjN8rXgzH36ZcziOjp/dU+jNXtLroqJ6J48ajujevW qVOnbsMP+u19QkQy6amfO3o18/241QfN6tStV/+zZdeVmtc+ilNLBgvqf7b2TuLb3VYICA5X KIx0RwIAAMxbzMNkk48CHRyZz/RlfRp8vytmW/9KNlXqLAnKCV3/VYWqHy88lZB2dJJ3VVvv yedSEsRdGavSfODaY390si7fZfahlNxs/7kfO1uzL9dFpz5/npYhU3HDvowCbpMuPMnLkz26 vewDxur2XByRGb12SFM7+y+3XYt+/vz6xAY2VRsKj+Wowvd/78LYhxPFkS+SN/aqV87GfuTh PP4s90/pZG/VcP71uAKDZ1IcRAEAADCW9yQKCKZF7J/cpM3UsV9YlXPxmrz77oymzP7Db3ff Tky8tKC5K2MfLc/IL3j217DKdoxZ2tbpNu3SEyKi60s7ulizPjsy9IfN8RvlW50xq4rO7p6e Hm4ujjbMolHf5QFBBwbUZ3Y9fo9JJyIKm9uMVajx3aGo+0fHuDKngRv8s4me7xrsUoE1mRPK H0+r1Wg0Gv0VCSWGKAAAAMbynkQB759upV6d18ynljuzc/WatCtienNmVdG5llcj74aNmzZr 0brXirty0qSGT/ZhzKru4A035FoiopDFHXRRQL9Jv7wr4DHruoyI0h+ubcFY/b7L/QP29avH yvXeGJtORJQm/orZuH6x9tKDE+NdmdPADZcyiChgZnVHq0qDDxqc87+HKAAAAMbyvkSB8TeS 6O7SFpaM2VarP/NQ7IpOlSwbDz3x8seRFLGPM4meXxjnw8q5N2xVvUqDLzffyiKi8BWdqlix rlvS9Id9ba2AVrdWoF6fX67evTiuuR1rPf9uDhHRmRGezK7erMtP7x0Z7cKqDN12nYjuLPjM nrHOG2N4w8lTokLPnwuOzczT6B+pRBAFAADAWEw+CiSeHt2SMY8RVx4pKGZVLcaYlZMoqCDp 8i8f163t03P8ylWrVs36wuGzeSfW9anKWNMR++7E/tmuPHP/ZMqFuMz8G39+7snKfzhq5cpf N+8MfHUq2acHCyoyZv9DQDqRNuXu0vqMOXeYfoOUd/bN9KncbMDU+atWTfG1L//xmI3hauXt /WOqs/LN+4xfvmrSh+XtvT6bdDqF3/QTtg5ryJj9T4HRCoNnUhxEAQAAMBaTjwI5D/12rVi0 8Wxypooo4eSyJYtXrvVPJKKCR5f/+nnmtMmTJ0+eMvPnPWdOrhT9vGz1sSgN5T+7snfR3Nkb Lt5/QUR3D61fPGfa5MlTF6w8mcANW/DwlHjNokVrLiTIiSj3Rcifixb9vs8/UUVE+bcPbRJN nTJ58tSff9lxV0VE2df3ja3Bynl/2nfs5Kmz560JfKE/y7vndy1dtCEwKUNt8EyKgygAAADG YvJRwCRkh+wcXI5Z9d10RfXmnd8GogAAABgLokBJqLOf3g+6EBCRmP6O2jWiAAAAGAuigElA FAAAAGNBFDAJuh8e1mi0KBQKhUKVcZn8Dw+bh5BrkRf8wy4G3EKhUCgUqozrnCT0cYLBNo0o AAAAYNYQBQAAAMwaogAAAIBZQxQAAAAwa4gCAAAAZs34USAoKOjHH3+cAQAAAO/ApEmT9uzZ o1Qa/G0b40eBuLi4o0ePngIAAIB34MSJEwEBAZmZmaYbBYhICwAAAO8GEWk0Go1GY6gLm0QU AAAAAGNBFAAAADBriAIAAABmDVEAAADArCEKAAAAmDVEAQAAALOGKAAAAGDWEAUAAADMGqIA AACAWXu/o4BaqcjLzcnJkRVo38Xw/1cYY0lJSUQkEAgkEomxp1M6RCKRWCw29iwAAN5vphAF 1HmZL54kJSXEP4p7GPc4MTktv0RTV8vvru7r41zZxaP6R4suRj2Me5RUwneaBpFIxBhjjAkE Av529g9+kxMKhbqNQqGQv7Nuu67HF++NUYCbTzED6vaRSqUlOcFiSCQS/gkmJSWx1+mdpiH8 qXIfkd7nKRaL9T5MAADgM4UokLR7fPvyjFVwq9uwcT0HS9Z88sn4DPUbpx53YHJjK9vhRx4R 0eMdw1u3af/N+ttvfJeJkEqlIpFI97dQKOT+FggEuqal6466pisSibjWqLeDrqf+9yggkUi4 DioWi4vsxNzh/mMU0J2vUCg01J6FQmFJ7ltIJBJunoZG031KxRwLAABMIQok753YyZ7ZfXv0 MVH+ju5VmVXFL1bdeXEv4OT5m8+eJERcvh6ZpiR6evXkob179x04ceFOipoyYzaPaevEXHvN +3WX/4OCZw+Crly5Gh4Revzw8fPX49K0pEoJDTx16FjocxWR4uGFw3/v3bf/0NmQR+mvhQy1 MjHk5KmLV6Ozi/+c3iWu9er6FrddJBLpIoJAIOC6L79nc2/hRwF+sNBdEOuuiflRgNteZPvn H4I/mo5eFODHFKlUqjcst6VwXjHUnnVv4Z+d7nC67XpnqksMUqlU704Af3q6xIAoAABgiAlF gcF778qIYla1ZrbObcdvOf9jXWZRb1DvTjWZ109n/E5sGFS1ms/Afr1beJSrN3jzresS0Zd1 7RnzbNW17zK/9B1fM8Zcvpm/srsnY9WGb78dc2GhlyWr0++3mLTw7VM7V67+yTe9u9Rzqdpx 2sFHGa+OLUvf0Igx6/qTw970Sb07XMvXa/O69qzX7PmdkoqNAvyXdDf2uSjAjcDvkYwxkUjE 7770b6IA/41isVgikfC36J0aGY4C3KdBxUYBfmzS3aso/GCFiwiIAgAAxTChKDDieBLRs82d 3JhlpaG/X78w/QNm5dZeOGHpku0H1/erbsNa/vqUiO4taMzsGs28+OzRnvG1mcXAvdFEpD4y jNk4+MwLKkg9MbxpBacW7T9pXqOG7/QgmSZqS5fyrPzAE0SUuXdwZebaY/v1HO7YSnnE3mUr Nu258rz4z+md4TfsUokCem/n/meRDwj499jpn2UKxXdNQw8I9IYqcnC9yFL4QMWcTuGz49/8 0LsPwZ2pbqqIAgAAxTCRKNC5MrP09On4RfcPKjD2yewTD5JTTv7YkJVrs+xcChHd+Nm3ijWr 0bpH926ff1LHjjGXAesvhuwcW5tZ9N0alkWkOjyM2VRqOiOQqCD68NxW9oxV/XRjUKqW6PBg B0trmwbtenX/on2Taoyxpj8fiTKdLxzoNebSjQL8C/oiowB33ay7sNZtFAqFhu63k+EooHc4 4j2eKPIZQZHt2dAyhcL4D0303qV7SSKR8FdjIAoAABhiKlGgErPpOG3DoVPnLgRdfpRHpIg/ NsGbOXZY7ZdMRMGiD52sWfuZR8+cPn32vP/lK7din74I2jiill4UmBlMmlS/JT2qWjBm6zl8 izRHS0eHOlqXr9hvud/p02f8LgReDZEmpOeV8NN517g1gDp6bZ77phy/++pdav/HKMCNprdS r5hL87e+K6CnyPZcwjWJeh+UXoTSDcL/QsS/+lYCAIC5MZEo0KkCsxt2MEbFbZPFH5vgzRza rzqXRET5Ues+cS5XtfOmVCKivJsXt288ERm+9fuar0UBhxbz/J6F/dLcvvJns2dPHNLC3uHT Px5lZFybWcui/AejTiiIiB7v27PzWFAKdxx59tFh3o07D9oQbXh+74heDtDb+MZvEOgUs1aA f6uc/51D/loBbjT+mgB+o327tQISiYRbK2AoUhSOAoXXExhaK6CXcopflFDksQAAgGMKUeDJ /ildnWwrDd8fmcttkz0+8VMTW+fOa84nExGRMvfOqtZVnKq5ubm5uVSp9dGUw3fv7xxXz9Zu gPhWFpHq6EhbR+e6A6f96F3J1rvXn3eUBf4L2njaOTSZciMrO+n8tHoVHF3c3NzcnB0a9f0z 4NUJ52Xu7GRhU7f9ogjD83sX9Fa6cU2O/w17/mW6rn/rVvbptvAX5+vothf5DQJdg+TfFSh8 ocwfqvCywcJf/ecWJPK/eqB7qchvEHAbuXPRO83C2chQFOA/HSj8eRb+tBEFAACKYQpRgLQa jVqt1mi1r2/U36ZRq5Q6KrVGS1r+HlqNWq1WqzVqlUqt0fyzSaVSqXV/q1Uv36tSqYs6jsZ0 Vg9A8Yr56iAAALwFk4gCACWHHxsGAChdiAIAAABmDVEAAADArCEKAAAAmDVEAQAAALOGKAAA AGDWEAUAAADMGqIAAACAWUMUKCMqlbqgQIVCoVAolFFKo9EY6lCIAmUkMDjc78KN85duolAo FApVliW5dPPkmatxj54Y6lCIAmUkMDg8PulpcupzFAqFQqHKslJepN288yD2YbKhDoUoUEYC g8PTMrNy8mQoFAqFQpVl5Snkd+8/iolFFDC2wODwjKxsWX4+CoVCoVBlWfKCgrv3H8XEFv1P xhOiQJkJCA7PysmVFyjyFSgUCoVClV0p1ap7Dx4jChhfQHB4jiyvQKVUKFEoFAqFKrtSazVR 0QnRJh0FnoesHv9lq1atRm+/n6MiyZyP23Tqvvm2wd31RIjHdPVtNe1ktlbvhbyQJd9+2arV F+vuZBNp0x79NbhVq16TNkkLSjpy6QoIDpflKdQajUqNQqFQKFTZFRE9iEk07SiQdHZCB2fG mEXHFYlZ6v39rZi966xA7mWtfo9/3dUFH1dmrPvWNI1W+9quOWdHtHBmrOrkoAwibcq9FU0Y q9515mX5q4G1RY1d5Mb/LiA4PF9eoCWtRotCoVAoVNkVEUXHJpl2FEj2m9jBmbX8sINT77/i 0v4abG/jVOPnK6RRRe+a8bmLs6ubs1OljgvuP4ta92X1ihVdPpp3RSWP+mNog0rVei+e/d2n TStaMmbn6OLm5tm846I73LA5fqN8PRhznxmSTUTPo9e0YKxud1GIXKuUhy//ytezmoubW7Vq bp+suydXkyzs4I+N7KvVaeRV38u1ikPFppPPZCn4s3zy97TPHO2aLAp99Ha3FQKCwxUK5Vu9 FQAA4D+JeZhs+lHAkTWfvX5oo0EbpH/0q2hTpe5i/4xLiz6xqNplU5iKQhb6VGOu35/Myjk9 tLKNo/eXoj+WtrGuIlxzKYfo5pKOLtas9/YM/WFfRoFq3+298eBB1JUzMxszVq/XEunziMXd a7DK/Y8/zCKKX9jCrrz7Z3+9KJAeGO3OLDqIjjwj5cHhTSsw1u+vbP5JnFg4oEGtjmtuJ7xd P0cUAAAAY3lPokDjqZEnf/ZpPnZYZ8tyLl6TdkVMFTD75n1XHPO/tH18fUfGmi94lqfOPjuz rgNjzFYwePnNdCKiay+jQLr+bf0cv1G+1RmzrlavcbNmTRs1cC/PLBr1Xe4fsL9/PVau98bY dCKiyKUfsvKeQ/ZIo46NdWVVvtnon0WUdWCkW0ULr6lBBuf87yEKAACAsbwnUcD7f+3dd1yU Z7738TFlc84+z3n27G52Uzbn7JOzydmT3c1GjEbJMcWGCiIdARUUQRnAXrEXRKo0GxCIYAso CnZBpYP0AYY+M5ShTJ+7zQzMDNznD44ssRHZrGDm+379XvkjEbwuMa/rM/cN96ytlNWETv/z 27/mvPHWhxtO12z+mPPam+9P/cpizryFi+2XLNuQ1NLPDnTmeX7E4XB+Zx+aSxpZlmWLDn75 29c49qfVT0qBdzmcd3dXGVmWZTqPTeVwPnAIvn//nMP7nH+yOyFQsizLSuMtOa+/ZRmT25TB fYvzS5dj91Qsy97b8rtfvPKv7pefuubnhxQAAIDx8rKkgG+ZmBVFzZzE4fzszQ92ZrQft/0t 5/87prUP/SJVYYWYZdvO2n7wyi/+6yvbv/zy3c+D83oHWbYhYt6vXuPMOv7Y7/7wewW2FqhY drC3IdyMw/mD7eEHguIt0/8f56OtVRTLsgNpTm9y3vjjgSoF/9Lq33J+5Z5UwbKG3A0z3+BM sk7uGPHp6Ka8S8eikkt6CeNTd/IsSAEAABgvEz4FOq95T+Fw3llRKOxju0/8icPhTPpFQJ5B wU90nPqH33+6YKWnp6fjX1/5elvSphk/43Cmbbgj6jhv9SvO//1w+cUaaX9zhusHr7z6H/NW rvTavDdNNPxpyWtL//R/OJyf++coWXawuy7wDxzOr7/c8mDQKLwfZfHuf31h6+rpafPB6/9q ezhTNNhfccHn3zlv/Ie51UpP6/c5/zzNM/KBauSFhvb45X/kcP55bW5z3+Nb+AGQAgAAMF4m fApoe6vuX069WalgjCwrL0+/mHblWq2cZVmjrCn33OnE+Pj4+G9On8utKE1POZeeUdrNsv1E U37q2eTrvE6SZdnO4hupKUnx8d+cu1QqG/60ht7yu1dTUzN58n6WZXVk053U1Ov5tXIjy7KG tuKbZxIT4uO/OXvpfifLsixZen7N7zg/n+a2KSo+MeV8Zj396Co7qnMupd6sUzBPfZfHZ0IK AADAeJnwKTAhkCUp7v/C+SenEwVje9E/KqQAAACMF6TADzHQR8vaBCIJoR3bi/5RIQUAAGC8 IAUmhJx8Xn+/YbxXAQAApggpMCHcz6tWE7RW24fBYDAYzAsefkMbUmD8VVa15Bbw8gpqMBgM BoN5wXM/t6qrW/60EwopAAAAYNKQAgAAACYNKQAAAGDSXlAKiESip/1XAAAAGEcikegfngIS iaSoqKgGAAAAJp6ioqJnH+I/QgoYjUYGAAAAJiqj8anvtffjpAAAAAC8pJACAAAAJg0pAAAA YNKQAgAAACYNKQAAAGDSkAIAAAAmDSkAAABg0pACAAAAJg0pAAAAYNKQAgAAACYNKQAAAGDS kAIAAAAmDSkAAABg0pACAAAAJg0pAAAAYNKQAgAAACYNKQAAAGDSkAIAAAAmDSkAAABg0pAC AAAAJg0pAAAAYNKQAgAAACYNKQAAAGDSkAIAAAAmDSkAAABg0pACAAAAJg0pAAAAYNKQAgAA ACYNKQAAAGDSkAIAAAAmDSkAAABg0pACAAAAJg0pAAAAYNKQAgAAACYNKQAAAGDSkAIAAAAm DSkAAABg0pACAAAAJg0pAAAAYNKQAgAAACYNKQAAAGDSkAIAAAAmDSkAAABg0pACAAAAJg0p AAAAYNKQAgAAACYNKQAAAGDSkAIAAAAmDSkAAABg0pACAAAAJg0pAAAAYNKQAgAAACYNKQAA AGDSkAIAAAAmDSkAAABg0pACAAAAJg0pAAAAYNKQAgAAACYNKQAAAGDSkAIAAAAmDSkAAABg 0pACAAAAJg0pAAAAYNKQAgAAACYNKQAAAGDSkAIAAAAmDSkAAABg0pACAAAAJu05UkAqlb7I lQEAAMALIJVKf1AKeHp6yuVyDQAAAPy0yOVyT0/PUVJg+vTp1tbWgYGBewAAAOCnJTAw0Nra evr06c9KgaELAx999NGfAAAA4Kflo48+mjZt2ueffz5KCsyYMeNTAAAA+CmaMWMGUgAAAMB0 IQUAAMbB1KlTP/300ykvLdPc2pDxXuDYDX91HoEUAAB40czNzdeuXcvlcj1eWlwud+3atY+f DjNmzPD39395t+bu7s7lctetW2dubv7I1qZPn+7r6+vr6zveaxwjd3d3Hx+fDRs2fP75549/ 1ZACAAAvzuTJk7lc7sGDBxsbG2mapiiKoiiapjWMVsPotEyflunTavq1jI6hGWpComm6oaEh KCjIx8dn8uTJI7e2Zs2aAwcO1NfX/21rDENrtbRO973RaMZ3C09D03RTU1NwcLCvr6+Zmdnw 1j755BMvL699+/bV1tbSFKVhaO0zR8PQw38CEwTDMC0tLaGhof7+/iO39ilSAADgBTMzM3N2 dubz+RRFEQRBEGqKopVKlUDc0NBR2tBRXNeezxPmNHVUK5RKmtKo1Wpi4qEois/nOzo6jjxU zMzMHBwceDzew60RJE0re3ul9bXS2mopr1JSXSGpKu+tKpeJBCSjIYgJurXGxkYXF5eRW5s8 ebKNjU15efnQ1sRSRXOXtKFTWtshqeuU1nVK6zr+9s+mLml7r1ypVpPjvZdHUBTV2tq6dOnS Kd+/D4IUAAB4oaZMmWJtbS2RSEiSVKvVFEn3SLvyatMvV+xOKV2cUDwzOvfjI7c+DLsxL7Xo SFt3K01qJ+CRSZJkT0+PlZXVIylgaWnZ1dVFURShVhMUpZDLRVcvtW5eJVi6oMVlbpPTrCb7 LxqcZtcf2SMRCUlmIoYOSZIymczGxmbkeWlmZmZhYdHW1kbTdGevPDKvdU+24FihILG0LeGB KKFEFP9AFF8iTHggii8RBt5vDc4VVgp76PHey+NUKpW9vT1SAABgPE2ZMmXx4sU9PT0kSVIk 3SPrvloWe7PJL6fD+lrTJ5fq/pBW+35qze+TSt87dP296NvLBeIGLd033ifIo0iS7OrqWrRo 0SMpYGVl1dnZSVHUUAcIM9M7Dm2V2H3WO++PkkWfSCz/Kln4ce/sD4XLFvBD9ve2tlIa7Xhv 5VEkSUokEltb20dSYP78+UKhkKYoXlPb0ouNc5P4txslEoWyuUcu6FUKehSCXoWgVyGSqLyv tM5KrLtcISTkcpKcWJcGFAqFg4MDUgAAYDwNpwBFUXKF7EZFfAZ/+f2O2fElbxwr4Bwr4Bwv 4Jws4sSVvJpS+U7InX87le3bI+2myYn1CnOUFKBppVzemn6hfc96qc1UqeuXErvPehd83Gtl 1jv/z3LvxZK5fxQsmVN3eJektYVkNP+QJVKafr2Wev6PGzUFqhuErmkNf46svFojbuDXVfAb +a1tDyp5LR1dZbxaYZfE4VzjxzGVl8oESql07ClAjnH9z4YUAAAYf0Mp0NvbS5EMv7UyIc8+ u/3rkyWvnyjixD/gxD+YlFD6yvHiSUll7yaU/TKp4q1D1/4zu/IcTepIYgyHippkdHq9wWAw GPR6HUOqCYrRarUMRajVakrTr9frmLGcVc9KAbGYVKlaL55rC/CVO5gr/Rz76yt1WRky+xmS WR/Q3xw1tAvIsACZ5ScCp1n8kP2y9jaSflLoqAla26fX6+gxnKYkTbfdiQi73Kx87hv2o6ZA Vb3QJbXpqwvd1/k95WXlBWXVpTX8qobmvNLKovLqlk6J102J+beCC0VNKplsZAqQFKPT6/u0 9Og3fEia7siODE9vUtL9fZof8cICUgAAYPwNp4BCqbhcFH26bPp3de8eL+EklL8SV8ZJKHsl toRztuZjOVNZ3L79VPmrR3N+c+oOV9zbSVPPfWGA0hq6syK8ljrY2dk5LPOOvCtlmearyQmn M6sUhgFjzQW/lUuCbvYQz3/WPjsF1ApFTUSgxM9ZufAvxKGNAzTBDgxor32nOR07qGVYltVc iFcumiJ1/KLaz0NcW0094cIAqelXFCbtXbkmrLBNQlLP+fKY0jCNSUtdwivlqh89BSrrhc6p TfMuSrKbFa0CAa9JxGtsbe2SlNc11jUL2yUqbpbsv5MFZwu/lwIURfa05hxZvergmRJl/2in O8ek8t0AAA+YSURBVKXRNJ92dwvLK/l2595L7Vr6x7o8gBQAABh/D1NA0ivrjr6+8hzvr0nV b5wo5RwvmxRX8crxB5wzNX9SauqMg/157etPlnPiHrx1JGNhvbCaoZ7vQjql6e/OPrp8+bYL hZWNzfWlOUc9FqyKu1N8MSowJLlco84PXOq242xeS++Pf1VArZDzwgMlvs6ky5dKB3P66J4B QskaDWx/PzswoLucrHKeSbrNkrl8Xe3v0VXLe0IKUFqDrCB05ybX2fZReS0Kgn7SKp++ckrD NCWvdI+qkqse65xR9jtqClTwhY7fNdpckd1vkbc0N1U3NOcUFjUI2kqrayp5tZ0S5eZc1Rdn hMkFjSNSgKQJWcO9o7ZfL9myL6pEbnjk0v+ji6Q0mpYzqzwiy8TtQmG38sf7jgOkAADA+BtK AUmvpFfWHZbpllTxYVz1pIsN/92kSEzm/SW55kOllm8c0BZ0bI4ufS2R91p8+dtBGRZ8YeVz pgDTZ6iL53rvP/Ogm9QyDKMlO4vSQnfsjIlPiIyJjT28fvWeM8Wd6jG+3hw1BapDDki5zvTy ecSyeSqbz/rvXRs6VoydQsJtFuE6i15pKXedU+XnLq55wlUBSqvvuRuzPeJsfIDrirAbPXJl e9FJz2UH9vnPmmk+3XlHUlVdzsFtUUEbbS0XzJpnaRN1t70oLXx3+B2J0Wjovr17U3R2VsxK z9gaeW/DjSCH2bNnfTXfOyi1qS0vKCAqcIPd4kXbb8qUTzxfR02B8nqBU1qj/WXJLQFN9hnE jL5Xq+9mDD1ag0RnEBF6vyzZvPOibwsaVfKHKUCShKT9ZiTX/8jZ0G3ecYUEK793YPvuda6L LC1mz5tvFX6ns/J6uLvjypUOs7/8fJpHWLagNnXNysi8/GPc9ec6jZLSK4ddpn85e/bM6VY7 b92L8/M9XiFRaoju8oyj2w7fUlK1yfu85n89e84sh+Cslq6qRM9lh/dzF3hsO9Ng0DEjdocU AAAYfyNTIDTD7UTRv8XzJmW3eRgH+7vpYoW2Xm9kCsWbo8s5cdWTEmtfP1X2VlDGAv7zXhWg tPruO7vXH8koE5IMTRAko5HV5ScHrtgVdmb7oimz/SOvN6u0DDXGV5ujpkBV8H4Zd4luxUJ6 uUVfyvFBnZbV9w/qtCzLGvKzaM9FWk8r1fIFldzlT0oBStffcyvqYPjZfBnv9BK3Q3liadv9 w7YLlqfwWbbz3uGtu4+fP7V9ueWGpFqZihClBdhxoy9fCg84clMyMGDsurHdP/z2nWjPVTGF Dec2LtieLhC28a4Hb993PDE2wNN6bVxFj0rztBfao6ZAGV/gmtbklCG1TBVbpYmtLnZbpXVZ XhRbpYkt08SWaV2LL/U4XepIyGtUP0wBkiQkontH1uzIbROkB2/ZfLKQUefuXrIs8CpfTlGd l3daLdp66vyeFV7hJQTLtqT5LubGpId6eMXk5UZ5+ScWl5/b5b3+civLyrL2bAy/diPayyu6 TKLUEN2l6eHbg5LS4kP37EsqamsT5Me6OR3OzglznGt/vESre+yeElIAAGD8Dd8gkCsVibf3 Bt3+TUrDr49VvV7We2BgUK8f0OR3bYmu5MTXvHKqmvNt/b8czftNVMaKNrHo+b5XgNLq5ff2 ++69UCQgGIYgSI1GUZ//7YHVe8Oid+3etN1v496j16vUDD22GBglBeTyykM7Fdwl+hULddEH B/u0rNGgT0/pj48YZGiWZfXXUvtXWJIrrCpXu4h5VZTm+ylAa/u7C8K2btgdlZpfmeL/1eLA LJEwN8p77XmxUW+Ul504HJ58JnrTpqjs+k6KJtoKYn250emXwncG35IODAz03NqxNmIoBfLv hyz+YqGTi5Ojk4Od3cbE1Jj1WyNv8toI5qkXQ35QClxsXnpNvjlbktmgzmxQZdQrM+tVGfWq 643q2FKFc4bE5UpnfG7D31KAUAtuHXBwCbxdmRW/f82qtXF1wpw960Ju1LSRGkrSdXnX3CU7 j0ftCrohNej1bH289+qg6P1uK2LzcqO8/U9k5yXu9UmsZ9nBnocp4B1TLlFqiO6yjKiAncdO H1tvOcvKcYmTo5OTq+vha/lRK7yThLonXPFBCgAAjL/hbxskSfpBbU7Ad/+ZXPvvcfyfxfJe Le3Zk9+1LraaE1c76VQtJ77u1eT6d/ddeT+zIIFQMc95v5jWGjsyd3qtCcoQUnrjgKGPqD17 cOP2kJSUk2GRqXx14/lV3pvOF7TptGP5McVRUkClrDgZ1bTSvt/XUb/Pz8grNebc7PNx0C2d azgfPyhqNsQcMqyxb3OaXbzNv1vQQtEjr2ETtK6vMzdpy/JF9u7c1d4+fq4WVnuu1+dGefmf adfrjfLS44FhyWeiN22MuF3XQdFEW34Mlxt18dzhTQduKFmWbU3zX334RlaMp2d0XknMStdQ vvHhqabM3ukXlFkl+ntSoJQvcLnY7HFTnlxH9XR2RUVEZWbe6JHS7d2q7h41T0y535QtzeiM G5ECBNFzbbvFXBffNavX+C63X+S5/0pW6p5NEVnNUiNrVPHjVi1cE/5t5O6QLIpl2b6SQx5+ 0YmH3VfG5OVGefvH3S9IDPAKLTewLJV/cMvRa9cj3J1DHlC6QZ28IGnXhv0nEo/vO3g8j364 S3XFCY9VCS0apAAAwIQ04rkCtFQmjb+2a0/GO+cbfp/U+PPYGk5MDedkHecUn5PY+Ma5pveC s94LubhU1CFkvn9Y/qDTmu5T198K2uAbEBIeeyw6LMR3zbpTObyK86H7Ar8pIFhd7eWdbm5b ku4KnvczE6M9V4CkKJFAUBhyoMnDRs91HAhYbdjkoV/nqt+4XO/vYty31sh17FgyN9fHvf5B ierRxqH7mParsTu2BqW26ViWZQcFiY5zuEnpwcu9ktoMhgF5ceSew98khflyj1yvaadoQpQT 5u51Iv9e0tZVPntPnDoZ6DPXOuDa7QhXt4jSrvz4dS4rtpw4cSwy4uSl8uIzG30OXa4Q/p0p 4Hap2TdbeaFFW9vQsHLNupj4ZJFM1yCmmrvpcjHje1ex4nrXydzhGwSUUnjZ387zsohlWZbV 1ccHbNgXfHCdz/pt+4NjYmMi1q4LuJCVn37AzXljRHzciR2bfILOVpSfWuYaeu9eiKtnAr89 9/g2D9/dJ+Mitzi67M0svBW7xmv90chjUSGbvd1WHbpYVXJy6yr/HYEnjh+LijmdXV8U4ex2 ohkpAAAwMX3vaYME3SpqCbu4KuDSO6cq3jnT9M7Z1rfPtr59pvntBN47+6+9vf+cVQW/hCbH 9hAeNaUzEvW3E44dDQ+PiD75bUk3O8iIKwpy8isEKkbTZ+zKT4lLuduifv4nFoz6tEGSpttF ovzDexuXWRvXu7HbPNkdXuwOb3a7F7thWcfShfdXL60vfUBoNI+WAEkxqo7y/NyCqnZSSxEE STCCnOTv7pUXXr1RKdVoNCpRSU5+RWXRrVsFjWIpSRKS1sKMGzy5qqs081RIcOipC9+dv1jY 0lx0JaNYrCaVorzEiPCIiLCQmHP55cVZdwrqOyTE0++LjJoCJbUtLumtG/Oo9Ha9QNi6fuuu b89dkmsGxOoBCTlYJzNszCe9bveezKlXy6UkSRIkqWorvJhRJdOQJEHSOll94b38a3HrV/lu 2h0YERUZm3C3Ry8tPb93ieO6kNijoaEpBUIJrajJvFLY0lJ45WqFQqMSVVw/ER4RE7zR3jng Mq9Hzr92IioiKjY2OTP7bk4j0y+tyroQHRoWERF+9JvbTa1FVzLLeqgnXEdCCgAAjL+RKUAQ BEUywnZB0o3A3We+Crj43q6MN3dnvBmQ/vauc9OPpW+ubaqiCGYszxb6X997xJCWVv/vI4Y0 FKFWEwSt7df3j+mJdqM/eJggCJpuFwkLD++ttJ3VYD+bbz+Lb/s13/armkUzc32WN5SXqp/y nMERixz6F7RO369ltH19DKlWqwlKo9VqGI1Opx36TgeS1vTpGJKkNH16o8Gg7+vv79fStKav T0MRBElrh/4ADPq+kR/1jK09KwVoWiTu2Zn+wD25JDabV1pWcfZ86pUbWeW1jSVVDWW8ppsl dSvOFG9MfZBX00KTD58lRGn6hp8UpCaZvkFWenOjV+CtRomBHdAb+vvU7TlnDm04eIti2UFj v5amCJLp69PStLavT0MSJK3p0w+yLJGzy/dAWkkL1W/QGwwGvb6/T6fT0gRBaXT9Q7s0PNz7 EzeJFAAAGH9Db0fU29s7/GqYphipVM5rLL9899uUq5EpV6NSb8eV1xZ09/RQ5HPfF3gxSJLs 7u5+4tsRicXi4XcmJGims6Wl6HzKvYSTOYlxOYlxOQmnchPjmstKiee/5fFikCQplUofTwEL CwuRSDS0NWFnd1VLe1NbZ3d3j1Qq7e7pFXd1d4q7xF1dbZ1iXmt7Y5tYoXjG4wBISinm1zR1 ShVDnUcSyu62prrGTtUTH6Aw/FEqcX1tY0evfAxPhRqiVCqRAgAA48zMzMzFxaWqqmrkOUFR FE0xKiUhl6nkMpVSoaZImnr+xwu+MCRJVldXOzs7P5ICTk5OZWVlw1sbujyuUKlkCqVcqZQr lTKlUq5Uqklyor1PzzCKompra11dXR95k2I7O7vi4uKhhdMUpaEpmnoyDU0xNDXKBkmKYZgR l/BJimaYUX+4c+ij/o4fAW1oaFi2bBlSAABgPE2ePNnHx+fAgQO1tbUKhUI+gmIE+QSmUChq amoCAwNXr149efLkkVvz9vbet28fj8cbuQXFk4zj+p9BoVDw+fygoCAfH5+RKfDJJ594enru 2bOnsrJyvNc4RgqFor6+Pjg42M/Pb+TWPkUKAAC8eNOmTeNyuR4eHvYvLQ8PDy6XO3Xq1Ee2 NnXqVB8fn5d3a3Z2dkNbmzZt2uNfuNWrV69YsWK81zhGdnZ27u7ufn5+n3322SP7QgoAAIwD MzMzMzOzKS+tofVjay+Xp23tB6WAubn5NAAAAPgpMjc3Hz0FAAAA4KcNKQAAAGDSnpoC5uYz xnttAAAA8A/31BSYM99q5syZ5k/xOQaDwWAwmAk/o5o5c+ZTU8DK3m2BjfN8a0eLRQ7zFtnP tbSbY2k3Z6HtnIW2cxbazF4wPIsxGMx4j81EnIU/1bHF/CRm3P8i/WPmsf8T5ywcHtu5lnZD p/lcK7t5i+wtFjnMt3ZcYLPkqSlg7bTcymGZpf1SSzu3BXauC2yWzLdZMn+xs8ViZwtrJwtr p3nDs8gRg8E8Yaxf/Di9+LHAYDATf4aO78XO822WzLdZssDWZYGtq6W9m6XDUivHZU9NAQAA ADAF/wNMqHIUx0EwlwAAAABJRU5ErkJggg== --------------7E05D27D981DE1695B9825F2-- --------------50D3CEC31698762AE7DF69F1-- From nobody Fri Apr 21 11:56: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 0CC6F127286 for ; Fri, 21 Apr 2017 11:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 qI1oBP3iLSsC for ; Fri, 21 Apr 2017 11:56:44 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A89612EAD5 for ; Fri, 21 Apr 2017 11:56:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 6B02C1A071 for ; Fri, 21 Apr 2017 18:56:58 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <6213fff1-f92a-d80b-e2b7-aec51f2c7467@gmail.com> Date: Fri, 21 Apr 2017 19:56:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3DDE532F-B701-4CB6-B917-AE468887979C@thehobsons.co.uk> References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <8C1286A4-F56E-4200-9A22-116F4A1616E4@gmail.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <5c1c487f-730f-dea0-b3e0-1a47e33fafac@gmail.com> <20170418233550.830F86BFE8E6@rock.dv.isc.org> <6213fff1-f92a-d80b-e2b7-aec51f2c7467@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 18:56:46 -0000 Alexandre Petrescu wrote: > My DSL operator "free" 'delegates' my DSL box a fixed /56 and provides = me a GUI, shown below, to manually configure 8 /64 routes towards the = IPv6 address of in-home routers. >=20 > It is great that I can have many /64s in-home. =20 >=20 > But I dont like that I have to manually configure these route entries, = even though it's a GUI. >=20 > And I dont like that there is no freedom in deciding maybe a /63 = towards an IP (GUI form hardcodes '/64'). If you don't define any routes, do they just route the whole /56 to your = router, or do they not route anything ? If they route the whole /56 then = you can do what you like on your own router. But down't forget that if you route two adjacent /64s to one router, on = the other side you can combine them into a /63 (with the proviso that = they /64s are both from the same /63). Upstream, addresses are just = addresses and the routers have no knowledge of whether any particular = address is part of a /64 or a /63. From nobody Fri Apr 21 12:00: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 57E2F12EB1B for ; Fri, 21 Apr 2017 12:00:31 -0700 (PDT) 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, 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=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 iJwmFo02LWit for ; Fri, 21 Apr 2017 12:00:28 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 CEF9D12EAF6 for ; Fri, 21 Apr 2017 12:00:24 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id k87so132006512ioi.0 for ; Fri, 21 Apr 2017 12:00:24 -0700 (PDT) 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=5s7eGK2VkH3U/QQv84/c8psAX+9QxGmoA58/ZqvkTNk=; b=dwiKNGcA8+DsRMhpmqbSx1LgWpmkfsbeKYKnchXjFJixVm2q9diw1vsrZOggNLqcYj Be4Mbcj066co66p1y2ULhgrQPJ9w1BQMpCaJBtVoRV2jGe4QSW4c6q/QBG9Wg+R+/ERJ TvD585s3ak3boXsYhNqOgMdxek4NVGUe8tKz0gZ+2oJpwrOBtNuClNPIqN2DJegebDKo 2rcu+UnhLglaaoH/VEHmW5Jxb9aMK7tPsWOuCvURqw/IIpJgQrVasKpdTppxzcIYb/qP rmyWIiYs0Bh0QWAyyv7ncR35Qsek7mlYLzJBHllAhODWQeTUhzLXbkrV84Cl0aAgH4aU E24w== 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=5s7eGK2VkH3U/QQv84/c8psAX+9QxGmoA58/ZqvkTNk=; b=o97jEnTu73OeugcTMN19BW+5x2Y9205osGvyV5NunhY4aMkrVhKcDV2CGJ/hA/SqNd V+CTtM2EoQGjfzBMg5mHW7CfB2MhIiVUATKT5Q696i8wSiRGq0T4bzx8GZG+D5RCBJq4 YAqBtybpPDkD82+gYmGhBX5/uHOc9/Svop6D7Ta9o2/1XF3vJr3hfjOk7cWJ6iR0mUor oY43f/jVH9sfbav0RkH8GLl/itCK/2QMytXrTy2HXpI4Q+VrU+dbSU+AJuCX185UmnAA U+rPnqCuY3212lAcae2KE23uYC09L/6O8WZVk/WXbZFKIyF4Lav/hiVB+4asZlbY0tas 1PeQ== X-Gm-Message-State: AN3rC/7oT2a7grbft7edWgCpzY2tjsoTyik5o8ShdMgS6hrsbWAbNUx1 U3C57fofBQTtuA== X-Received: by 10.99.3.212 with SMTP id 203mr13860496pgd.0.1492801220077; Fri, 21 Apr 2017 12:00:20 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id w129sm17371313pfb.130.2017.04.21.12.00.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 12:00:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Fri, 21 Apr 2017 12:00:17 -0700 Cc: IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <401B16AB-4480-486E-9579-313940BE5A53@gmail.com> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 19:00:31 -0000 > On Apr 21, 2017, at 6:54 AM, Mikael Abrahamsson = wrote: >=20 > On Wed, 22 Mar 2017, Ron Bonica wrote: >=20 >> 3) The title of Section 5.3 is "Maximum Transmission Unit and Jumbo = Frames". However, there is no further mention of Jumbo Frames. Could we = explore Jumbo's possibly with an eye towards deprecation. >=20 > I am strongly in favour of support of jumbo frames. >=20 > I would like to see the document specify an L3 MTU of 9180 as its = SHOULD requirement. All major core router vendor supports this today. = The reason for 9180 is that this is what RFC2225, RFC2492, RFC1209 = mention. We may need to clarify the meaning of the term. RFC 2460 removed = references to Jumbograms (from the RFC 1883 text), moving it to a = separate document. That document is RFC 2675, which says: The IPv6 header [IPv6] has a 16-bit Payload Length field and, therefore, supports payloads up to 65,535 octets long. This document specifies an IPv6 hop-by-hop option, called the Jumbo Payload option, that carries a 32-bit length field in order to allow transmission of IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in length. Packets with such long payloads are referred to as "jumbograms". =46rom that perspective, a 9K byte message is a "normal" IPv6 message - = the payload length fits in the provided 16 bit field. Yes, I'm in favor of 9K byte messages too. But they are not "jumbo" from = this perspective. > Other comments: >=20 > 3.3 It would be good if the draft referenced for instance RFC8071 for = Netconf-call-home and draft-ietf-netconf-zerotouch-13 for zerotouch = plug'n'play provisioning. >=20 > 5.4. The ICMP ECHO/REPLY requirement here opposes what's in RFC4890. I = prefer what RFC4890 says. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 21 17:18: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 D2891129BD7 for ; Fri, 21 Apr 2017 17:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fsXRX0pfLsXc for ; Fri, 21 Apr 2017 17:18:54 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 004FB129BEF for ; Fri, 21 Apr 2017 17:18:52 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id w50so39495297wrc.0 for ; Fri, 21 Apr 2017 17:18:52 -0700 (PDT) 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=GZanizeEj8Ar5giq+OrCErmXibQUHbN0NwKtPv/WTZ8=; b=JLF9n8ocWau5MYy2jSI+GmkDFxK2wz7uw7mK6JzAJaJYJ/JKHi0YNfHHlRRt6/y996 rtVbOy+cf4W9UI4dPt2tqJEQMiIgZ76WFAwSexu3B3RhChIKkRkjM8pWoOEiiaRiJxZL ubS4dJrc4BkxQ4Ssd5tSuJwfkJIRmrvl2uHrmYi6zqvhenM7NtvhpeVU4AO/Yd1olLhi LI8Lig3P0L8f2J7QYE/6Qatt8DQKr60aVGeXz/eHjUgZAbK1MKwAvOsMu3xXS/T9JasN NqB7pFVy2y+YTwQgHI8fLL9+M+wxRkKaGx9FON6gxj3BmADR3mX+7BjvEFiJIBG1Pie8 9JKw== 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=GZanizeEj8Ar5giq+OrCErmXibQUHbN0NwKtPv/WTZ8=; b=kCopG3pL7Mk1FeSggwdpimUFVV8m9mhs8WU34DdZLA+su1cUN8d6qvbOuSC20BWyKR y+88GkhfjcsEOBW/P9zdTC3N8AJjudE26ma8YzhglewH9DQrxudNGYX+WW7i33D0c4YO sF0iGSUzxCtG+NDoQn+hoAMatk5HE4m6iNA/WU9kohKCdpCzdoRXa79Qwx91Ta31EsSw fBfF8lU2ZF/Tb4t+pYRn6Nz3gYxScfD0tcS/CbFPsI7JBUQOxz2HvULOmZ77Lvo3XW5G 8957jwFiN6o3DDLk4sacH4t6lOJV1LWx7REzmuFWx9PfWVUhwT48zvyO57R2S+KtZYeW mSSA== X-Gm-Message-State: AN3rC/5tH6QyhmlmWis4RbEeCr//SnMq7fE6GqG9MVVmYTyW/X6rBqOK jBX7RQ3HHEyCIvWAVP0= X-Received: by 10.223.151.141 with SMTP id s13mr15390479wrb.39.1492820331474; Fri, 21 Apr 2017 17:18:51 -0700 (PDT) Received: from 226.66.20.149.in-addr.arpa (226.66.20.149.in-addr.arpa. [149.20.66.226]) by smtp.gmail.com with ESMTPSA id 133sm3700722wms.22.2017.04.21.17.18.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 17:18:50 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <078F0C07-F3F6-40C4-A143-6476F66CAAD2@gmail.com> Date: Fri, 21 Apr 2017 17:18:18 -0700 To: IPv6 Ops WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] RDNSS Hum, v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 00:18:56 -0000 Speaking as co-chair. I said that I would report what came to my inbox. I have to say that the = outcome was inconclusive. The question is in = https://www.ietf.org/mail-archive/web/v6ops/current/msg26251.html. = Unfortunately, I put as a "reply address" v6ops-chairs@tools.ietf.org = rather than v6ops-chairs@ietf.org. AMS tells me that 77 messages were = sent to the "tools" address that I didn't receive; there is some = interaction between Outlook at the tools.ietf.org server that has that = effect. Major grump. What I did receive was replies from 20 people. 16 favored option 1, six = favored option 2, and some obviously favored both. There were also a = couple of folks who said "anything but 2", preferred option 4 if they = couldn't get their own way, or something else. With 276 messages in the = archive on the general topic "Making RDNSS a MUST?", wow... I think it would be fair to assert that there are differences of = opinion, and that any suggestion I might make that would trend toward = "implement both so that Microsoft-centric shops and Google-centric shops = can both operate" is going to get shouted down by proponents of one side = or the other. That remains, however, the only *operational* sense I can = make out of the conversation. Operationally, very few shops don't have = both Android and Windows equipment, if only as BYOD. As noted by Tore = Anderson in = https://www.ietf.org/mail-archive/web/v6ops/current/msg26265.html, if a = shop has both platforms and doesn't have both options, it's kind of = stuck. You don't have to turn it on. My two yen.= From nobody Fri Apr 21 17:26: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 6F41A127058 for ; Fri, 21 Apr 2017 17:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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=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 OVclLl3xNnSI for ; Fri, 21 Apr 2017 17:26:32 -0700 (PDT) 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 3C9EA129BD8 for ; Fri, 21 Apr 2017 17:26:30 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id j59so45846741uad.0 for ; Fri, 21 Apr 2017 17:26:30 -0700 (PDT) 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; bh=Hh/bC4lWTyTtXtwvwlaBoCHKJz/EYjyMYFTTHj3bY78=; b=q5MX2sOv6cbJWbg+hT2R8thj1s6+p1CEq3RQjwJirXiWyuH5Zc/kuCPX64mqkv2C0t NNjChFPfZVXxmuWW8q5JRDszJQCiYP2CnGPL2I1SkSbezuzhwFRUGc62f8mFhwm0fSvq GwQG04tZE1yrMP2ORpVzv19ZmuBT6aHZYtBEl0YR21lA7JMMjg0/0khiWWvwef0Qh+ZN cPmiVrM8TKO6zzbmlgRlOCmDeGLLiZ2vv4XEpDguJO1TMFZ7y4YXZWEqQXgqyJfBB1F/ wj3nIhSm3uvu3lkvYEgL5H/ZpSc97k4rU+DdMCmR8JZVLLGopSBQTyoc1Cma6ybyK9F4 zjnw== 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; bh=Hh/bC4lWTyTtXtwvwlaBoCHKJz/EYjyMYFTTHj3bY78=; b=nO5nvnYoT4CwCEacd3dq8FohbyTOlM3Wex4VvQP68lAvgPC/2FjUmgV3Q4DPMu7Rs3 B63BJZX2G4F9yg6FquZcmEGRr7TYyNgKM80XICi9iQrcIx7JpsbjuzH+ekWOknJL746G AWwLSGYookYwx5i7aRns3Ivgjr526wmHq+UuMa7FrFfZMlfnexCV2sjbayuKL48mZQFw HSp1nPXb+x3t8xBCKhj8zx7blDbU5dRib+plR2rzwMqKpqjmVq1J4bG/4FZ7VJfKDmPN QKLqSLh0kYVarEJUXlSlAmoBQvg8VI7gy5V0IDLTUn84Skscc8Nuc/2hnARxKBCWTx3o 3hXw== X-Gm-Message-State: AN3rC/7RcZgXhHdrIelkgp8/n6KfcW8koOC3S+c3p/Ru0JH85fefE7AW iyh9NLf2Y5voRmEZ1mPpTVGDbmzq4v0XGe0= X-Received: by 10.159.40.170 with SMTP id d39mr8141359uad.122.1492820788764; Fri, 21 Apr 2017 17:26:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Fri, 21 Apr 2017 17:26:27 -0700 (PDT) Received: by 10.31.110.200 with HTTP; Fri, 21 Apr 2017 17:26:27 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Sat, 22 Apr 2017 09:26:27 +0900 Message-ID: To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=94eb2c123e20d44e52054db66c49 Archived-At: Subject: [v6ops] Windows Creator Update supports RDNSS? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 00:26:34 -0000 --94eb2c123e20d44e52054db66c49 Content-Type: text/plain; charset=UTF-8 These links: http://qiita.com/ip6/items/a6bd67938f15662ee862 http://www.myzaker.com/article/587b33d11bc8e08375000004 seem to suggest that Windows 10 Creators Update supports RDNSS. I don't have a Windows box, so I can't confirm. Is there anyone on list who can confirm or deny this? If it is indeed supported, is it enabled by default? --94eb2c123e20d44e52054db66c49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://www.myzaker.com/article/587b33d11bc8e08375000004<= /a>

seem to suggest that Windows 10 Creators U= pdate supports RDNSS.

I = don't have a Windows box, so I can't confirm. Is there anyone on li= st who can confirm or deny this? If it is indeed supported, is it enabled b= y default?
--94eb2c123e20d44e52054db66c49-- From nobody Fri Apr 21 18:11: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 E9E2C1293E9 for ; Fri, 21 Apr 2017 18:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 tY1lgPJCq2_8 for ; Fri, 21 Apr 2017 18:11:05 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 26053127698 for ; Fri, 21 Apr 2017 18:11:05 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id g66so5005833ite.1 for ; Fri, 21 Apr 2017 18:11:05 -0700 (PDT) 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=bHwoVZXG4Yd6FAghvUrwxF/1oSzOdAAFhr7BDJ3No+w=; b=lv76AaO8t53rmaryuLuniScgJBRkXWJ4zBX/pUT5IJLwr8MGWd6+PhQjsVNEc8FaC0 BDOFVu0QsUQWh23Kj4mGgfRkYeXGNWEhe9oDkcHb4xaGNqJFsR/qhr20FofbZYBmyVzl YQFSwF2W1oMoD89bNyvpcKY7ZUOhXKzG9a+jPb78j4AiAlmRnQR1lb2L27IJScOpiWBU KCEnP+BBpimBQtvf8L4m1t/E/2B1XCJAF7YnClJEiWl/oJbLE2r2W198NHOuCuJE4UYO RU14DbZjJJMQaK+34/QxAecab1J0ERXleuivM1oQo1QE/BiwkIJLWxWIC0frWCoaG+bB YoyA== 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=bHwoVZXG4Yd6FAghvUrwxF/1oSzOdAAFhr7BDJ3No+w=; b=oeCb6Ru1u0CZnPRj11pcTm9t7As4zZG03gJu2bCJLqW61fhabezTXF7QwjWSWrueY1 odcLfbqTkd+6rqpudhSnkfyPA/xGovwMRVyxWkmE0RbtXIAMRu3ie/+jin7O0ky8nhlR WnFd/WObsKlX1PlqfUIBE7RXc7P0p5ht4e7FQHeuDhFH7ISODpeGU6vOeVEVNduk4J2S VHW9Lfwn9VetzAownXXL8L6FGnwoG6e16k91ZgBI8r6Xj5GNOOkI13p0oPTKpmSZOlDG IZ2B0l++uTgxIhPGk1W46GaFr2KtiDvN4AVVnpa3Sj3HJpa9xAJ39105Bwnn1Tm4UGu7 KRPg== X-Gm-Message-State: AN3rC/70nMLbyT8PlFJya2Vc6g/PKSAkRazeYzrkDCaYIFtKB8hxyxB7 GrL2L045h648ug== X-Received: by 10.84.197.3 with SMTP id m3mr19158158pld.3.1492823464477; Fri, 21 Apr 2017 18:11:04 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id r73sm18043578pfa.65.2017.04.21.18.11.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 18:11:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Fri, 21 Apr 2017 18:11:01 -0700 Cc: "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 01:11:07 -0000 Here's another link: = https://www.theregister.co.uk/2017/01/19/windows_10_bug_undercuts_ipv6_rol= lout/ I don't think the issues are limited to Microsoft.=20 > On Apr 21, 2017, at 5:26 PM, Lorenzo Colitti = wrote: >=20 > These links: >=20 > http://qiita.com/ip6/items/a6bd67938f15662ee862 > http://www.myzaker.com/article/587b33d11bc8e08375000004 >=20 > seem to suggest that Windows 10 Creators Update supports RDNSS. >=20 > I don't have a Windows box, so I can't confirm. Is there anyone on = list who can confirm or deny this? If it is indeed supported, is it = enabled by default? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 21 18:13: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 A54B61293EE for ; Fri, 21 Apr 2017 18:13:17 -0700 (PDT) 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 tLjHKPobQC1c for ; Fri, 21 Apr 2017 18:13:16 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 D85DA127698 for ; Fri, 21 Apr 2017 18:13:15 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 70so5020137ita.0 for ; Fri, 21 Apr 2017 18:13:15 -0700 (PDT) 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=byBin6aukkkueVvvU8bQbintP167UQHcLWJQtNhazQQ=; b=YtMy9i/KUvpjK8VVxtpDJCEjzZDJ2YFBIaXjv66WmbyKUJSVMRr2SNbd2AhnYp83UA T7jDqXH5ZfI62tM/nLGOneAqVbLLJ2WkjoQNZnhZ12CZIc1zlIvoWQ6d51ZDNXsw6loR vQoVb/OKcY1JLAc3uE6nHIlnGeoeiNMBDoHV8CGkjoTHSYhmevSev8X4oUaw0GH1poE0 f4N+tDQAC013BX9GEDlKU5BSGFJ2nN6ygYhOunlJ81z6I0L9mMZqdrbhuX7TWaP7Begk Uri4g0cp6jPiLqIfIw3IyGyxnKFJRI8oxRYHN3p8mf2U3YGaSDnbN0TJH+m+DwVuDKPE 0ZCA== 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=byBin6aukkkueVvvU8bQbintP167UQHcLWJQtNhazQQ=; b=erT5Li7BZRh18UyG4RVNtkUNwNmFdz0KVs52J8Yfz0GxJiq/DjP7CQ/KdUrkEx8K/j wckK8eeW0I5kgV8B64Jh/ab5kMAevu1uXHk0djPIla4oW/yl0oiK+VaaO6v3uxEc2dww LlhB3tH48kWX/l4Suo0iMX6FxRSUmraAS8XzUM3vSZ0kQ54Oh94dvM4WScmEfOSAijbS 0lqVPZ9dO8zNdXRU2TzGnAEKVkS6CiSVAp7cTOmzh1JY/Z1JWEAan9Lh65PUlFp5h3Zo 2C+Wr4JRVyIVmUYxcKS6JgxKbKfk4PGPAPRFUWx7luFf04+6UJJ2kkAJ2P8bLHpGgJZm AnDQ== X-Gm-Message-State: AN3rC/4J88mXukbXOicAjEo4FmDklG0WtKVy8Ev7GfVZf7HXwsmtApnA cGJabQvGP3soMQytdeA= X-Received: by 10.99.158.2 with SMTP id s2mr14624337pgd.15.1492823595261; Fri, 21 Apr 2017 18:13:15 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id m72sm1126961pga.15.2017.04.21.18.13.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 18:13:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Fri, 21 Apr 2017 18:13:13 -0700 Cc: "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 01:13:18 -0000 Another link for you: = http://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-poses-= security-and-ipv6-deployment-issues/ > On Apr 21, 2017, at 5:26 PM, Lorenzo Colitti = wrote: >=20 > These links: >=20 > http://qiita.com/ip6/items/a6bd67938f15662ee862 > http://www.myzaker.com/article/587b33d11bc8e08375000004 >=20 > seem to suggest that Windows 10 Creators Update supports RDNSS. >=20 > I don't have a Windows box, so I can't confirm. Is there anyone on = list who can confirm or deny this? If it is indeed supported, is it = enabled by default? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Apr 22 00:26:24 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 50903128BB7 for ; Sat, 22 Apr 2017 00:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 tpIE-drcwJ54 for ; Sat, 22 Apr 2017 00:26:20 -0700 (PDT) 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 A3257126DED for ; Sat, 22 Apr 2017 00:26:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EF1BAAD; Sat, 22 Apr 2017 09:26:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492845976; bh=Qc4Y4w53Q63yAT+bSJr7NYEVjZZ2vUe0PzzRX3ghg7k=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=gAMkidR5jSc53zoMGmWnrqOioqSxLjpPp65z4lotjHO7tst0lctVniT+WAwETV4KF P2X1NvnoiAsiV/aBEoebffLT3ynZ8yog+sA3XQNNE5LSBhxKMtmplR1eSFEfD9YGAO Ik5AYTskCLZRSvtopIF5mDPsWnCsoROu9xmOHtLk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D573FA6; Sat, 22 Apr 2017 09:26:16 +0200 (CEST) Date: Sat, 22 Apr 2017 09:26:16 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti cc: "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 07:26:23 -0000 On Sat, 22 Apr 2017, Lorenzo Colitti wrote: > I don't have a Windows box, so I can't confirm. Is there anyone on list > who can confirm or deny this? If it is indeed supported, is it enabled > by default? I tested this just now, on regular fully updated Win10 Home-something (still trying to figure out if this would have "creators update" or not), on my NAT64+DNS64 Omnia Turris setup. No IPv4. As far as I can see, it doesn't pick up the RDNSS, but it does use some DNS resolver it learnt using other means than DHCPv6 (because I disabled that). Win10 is using DNS resolver address my router allocated to itself out of ULA. So... If not RDNSS or DHCPv6, what can it use? mDNS? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Apr 22 01:49: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 364C5129C4B for ; Sat, 22 Apr 2017 01:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 H2YER_qeSovq for ; Sat, 22 Apr 2017 01:49:48 -0700 (PDT) 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 93C8C129A8B for ; Sat, 22 Apr 2017 01:49:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 07EA7AD; Sat, 22 Apr 2017 10:49:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492850985; bh=ROFfqObLLiuRhgNytg4AakrYh0FwnsnqXcyAb1oiBK8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=duJVwcrG5VlJuJYoiM3/us4dmboaau+QE4i9Nuep44XxJSVJkRnBUIrOVIDI7NpTz TafCaIMHKcWaFgKzk/IPCDLwC0JhgJ/KbZ8rF2CDHjJsOjtT7NN7BeW8NN6yYUPQ9I 1GwgB5LECHt3xmLoexbWnC4Fm/hKaYVT9qWbeZFA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E2945A6; Sat, 22 Apr 2017 10:49:44 +0200 (CEST) Date: Sat, 22 Apr 2017 10:49:44 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti cc: "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? (yes it does) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 08:49:51 -0000 On Sat, 22 Apr 2017, Mikael Abrahamsson wrote: > So... If not RDNSS or DHCPv6, what can it use? mDNS? Disregard my previous email. It seems I am unable to make my Omnia Turris stop speaking DHCPv6. I did manage to stop it from handing out DNS resolvers via DHCPv6 though. I have now updated to Win10 creators release, and yes, indeed it seems to support RDNSS. My Omnia Turris announces RDNSS resolver in RA with its GUA LAN address and windows configured its resolver using that GUA address. It didn't before I updated to the creators release. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Apr 22 02:06: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 D2CF41288B8 for ; Sat, 22 Apr 2017 02:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rtj7RoR_pnN3 for ; Sat, 22 Apr 2017 02:06:34 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC3F12947B for ; Sat, 22 Apr 2017 02:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1492851992; x=1493456792; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=WN1dO6bxifZRY0RX/Wu58Z4WV mffZpq9IvbmiVDj/yU=; b=B/YE5TboK0tb2oDPHwhri3BQdRqhpDdu9u2ytMRTz +7b6SwWrkYtG4RbZ0tU6OuRbprD4fvtcOWpyvAq80JI5XOYzJPFWeFqnilMLk3E+ DoKN/f3xNmr2ClCfEb88oNmAMKVgdG6irucKltVShbUOyynuEP6H5nB/xAO1brBj xE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=V2b38vfXYL280zfF6eYc5hslFmDnVBizcIMc5ico0oqyNFuRxCOz1Kfmgj3Q Bo72ha+8+clALtsDMZOoDfkmq1AsbuxfDjOYO7AsOJ113WkLHcqSwpORO 3XlpJWNCmv54sGAl/LgQ30hHbqzCCK5EfzYxdfckoASrn01VjWUWvc=; X-MDAV-Processed: mail.consulintel.es, Sat, 22 Apr 2017 11:06:32 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 22 Apr 2017 11:06:31 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005412792.msg for ; Sat, 22 Apr 2017 11:06:30 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170422:md50005412792::6laAtGj+bhDHtDy2:00000Y2f X-Return-Path: prvs=12855c1f01=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sat, 22 Apr 2017 11:06:26 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] Windows Creator Update supports RDNSS? (yes it does) References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? (yes it does) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 09:06:36 -0000 Hi Mikael, I believe this product is based in OpenWRT and also uses Luci as one of the= possible interfaces. If this is the case, to disable DHCPv6, you go to the network/interface/you= r-LAN. In the lower part of the screen you can see DHCP server and one of t= he sub-sections is IPv6 settings. One of the drop-boxes there is DHCPv6-ser= vice, that you can set to disable, save&apply. I just tried in another hardware suing OpenWRT and it works for me. You could also modify the /etc/config/dhcp. Under =E2=80=9Cconfig dchp =E2= =80=98lan=E2=80=99=E2=80=9D, you will find =E2=80=9Coption dhcpv6 'server'= =E2=80=9D, just delete that line. Regards, Jordi -----Mensaje original----- De: v6ops en nombre de Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Responder a: Fecha: s=C3=A1bado, 22 de abril de 2017, 10:49 Para: Lorenzo Colitti CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] Windows Creator Update supports RDNSS? (yes it does) On Sat, 22 Apr 2017, Mikael Abrahamsson wrote: =20 > So... If not RDNSS or DHCPv6, what can it use? mDNS? =20 Disregard my previous email. It seems I am unable to make my Omnia Turr= is=20 stop speaking DHCPv6. I did manage to stop it from handing out DNS=20 resolvers via DHCPv6 though. =20 I have now updated to Win10 creators release, and yes, indeed it seems = to=20 support RDNSS. My Omnia Turris announces RDNSS resolver in RA with its = GUA=20 LAN address and windows configured its resolver using that GUA address.= It=20 didn't before I updated to the creators release. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Apr 23 00:28:34 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65919128C81; Sun, 23 Apr 2017 00:28:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen To: Cc: v6ops@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149293249738.25897.290627174722663000@ietfa.amsl.com> Date: Sun, 23 Apr 2017 00:28:17 -0700 Archived-At: Subject: [v6ops] Intdir last call review of draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 07:28:17 -0000 Reviewer: Jouni Korhonen Review result: Ready with Nits I think the document is close to ready but some more meat in still needed. Similar type of configurations have been used in other types of link with success. A couple of nits and questions. Line 157: "hosts/subscribers devices connected to the provider managed shared" is somewhat hard to parse. Does it mean to say "hosts'/subscribers' devices.."? RFC6106 reference need to be replaced with 8106. Line 259: Retransmit timer is the "AdvRetransTimer" or "restrans timer"? Be more specific here. Section 4 talks about unicast RAs. I think it would be good to mention also RFC6085, which allows unicasting an RA to a host on an Ethernet link, while RAs still use layer-3 multicast addressing. Similar goal, different approach. At least I would welcome text why RFC6085 is not endorsed or applicable? Section 5 gives some guidance regarding unsolicited RAs. However, it does not say anything about PIOs, although the context of the text seems to assume the presence of PIOs. I would mention those explicitly. I would also be more clear and state the unsolicited RAs are again unicasted. At least the current text seems to assume so. What happens when RSes get lost (all MAX_RTR_SOLICITATIONS)? How shared links with multiple first hop routers are supposed to work with the recommendations of this BCP. Current text seems to be only considering a single first hop router deployments. From nobody Sun Apr 23 06:46: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 48B5912947C for ; Sun, 23 Apr 2017 06:45:59 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 o74JcBLfOGoU for ; Sun, 23 Apr 2017 06:45:58 -0700 (PDT) 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 5BAC1129477 for ; Sun, 23 Apr 2017 06:45:58 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D2F55A5; Sun, 23 Apr 2017 15:45:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492955155; bh=KjT5ZqbEIue95Sge1uEXCsVrqJSEUcAqg3C1/QUpDVw=; h=Date:From:To:Subject:In-Reply-To:References:From; b=W1lBdMdoOPNcceYCd19e6Zv9sL8oI0ut5L/jQPmmJ5m/RGO5TP2zF6v4dNGniJRen bmahm+mh+Mb+4hYVcCTnQmR9o2bC2978lgm2Quhcao5+en5wb0PgdDk6qzjYLepPLJ aEyDHjCzfLhaI+HwWx4OkwmXfC2+TDuT7ZrCh5is= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CDCF5A4 for ; Sun, 23 Apr 2017 15:45:55 +0200 (CEST) Date: Sun, 23 Apr 2017 15:45:55 +0200 (CEST) From: Mikael Abrahamsson To: "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? (yes it does) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 13:45:59 -0000 On Sat, 22 Apr 2017, Mikael Abrahamsson wrote: > I have now updated to Win10 creators release, and yes, indeed it seems > to support RDNSS. My Omnia Turris announces RDNSS resolver in RA with > its GUA LAN address and windows configured its resolver using that GUA > address. It didn't before I updated to the creators release. I have now received information that indicates that it will only use RDNSS if there is no DHCPv4 or DHCPv6 provided resolver. Can someone confirm? Isn't there some Microsoft knowledge Base article that describes this? I can't find any anyway... Perhaps someone from Microsoft would care to comment? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Apr 23 07:24: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 9FACD12948A for ; Sun, 23 Apr 2017 07:24:54 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 odpVlYE2v4mr for ; Sun, 23 Apr 2017 07:24:53 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 3732C12943B for ; Sun, 23 Apr 2017 07:24:53 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id 198so7283201vkk.2 for ; Sun, 23 Apr 2017 07:24:53 -0700 (PDT) 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=ZSpiYyaDwTwqw72eOAQ/Pp4OVrkffWrYMAixqvazu5M=; b=fx1niOeldbyluaAPHqoogpgg3eiDE16Gjj35NGNJBik349da2SL4Oqc1Mh8wf4TXbz nKQE28RlWjUOdSr9O8mjEfuseMlb2UOVaHumOcqsdF3ur15SAPRjCr1Md/qWHXXae6mh KMLFVrcIYwJKkHdVnTbwrPQZ6zN1xxBB4/m8pGIV3cY9xtZ6SkAdg7R3VF8hw1vNDoPo C90xbcWq6KDpHpSm7x6TXkhdHfN8sU/sJ1mT/2qnWc4UeiabHYsX54clJvFgDPH61VZL rB5xz2zi7tNMc0sa+AQIlNtY4mwQNkY65RLxP0Qxk13zf5vPkV+cbsex+a10OAoDp+92 Augw== 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=ZSpiYyaDwTwqw72eOAQ/Pp4OVrkffWrYMAixqvazu5M=; b=ZD2dSZh5YPiegypZ6FEk4rTTpezsYFaMEeP7ea7l7sNGj1xkrYWCi3sc5GUh2Exjru 36KFJYuD1aQe0ECmHfYHm/4E/AEYGNnK6e29mCrcG5FWbf2bQJB156KemOkGrWzUK52w b4Wq1Z0s4gBd9GsobxWqmvWHXyDNrOxZs/ELz4NyjVFMdEgKNC7rrNzw3BnS2OUFhqwt wC8qTKYGM9G9RQDZOdNM1IMACfA9uEGhj9fJL2SFhg29fIYUHBX4ks7kU+HTAbOAwOU5 zFPAryW4qBMZGyiWjJ5KExij6Ryl97daqLXhvWbNc7UMS7fCffBiXdYSQEeO4Be42Yp2 BNNQ== X-Gm-Message-State: AN3rC/6vzAqczN2NAeUIlZZPRkHN5UmVFtAxByMn9A3xiKe10iE4Jkvx 6cI/8GAcSdu+3sJ9CG/VITas7THZGC0C0TrSWg== X-Received: by 10.31.16.200 with SMTP id 69mr622385vkq.45.1492957492081; Sun, 23 Apr 2017 07:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Sun, 23 Apr 2017 07:24:31 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Sun, 23 Apr 2017 23:24:31 +0900 Message-ID: To: Mikael Abrahamsson Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11431e98fb4b58054dd64067 Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? (yes it does) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 14:24:55 -0000 --001a11431e98fb4b58054dd64067 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 23, 2017 at 10:45 PM, Mikael Abrahamsson wrote: > I have now received information that indicates that it will only use RDNSS > if there is no DHCPv4 or DHCPv6 provided resolver. Perhaps it implements this text in RFC 8106: The DNS options from RAs and DHCP SHOULD be stored in the DNS Repository and Resolver Repository so that information from DHCP appears there first and therefore takes precedence. Thus, the DNS information from DHCP takes precedence over that from RAs for DNS queries. --001a11431e98fb4b58054dd64067 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Apr 23, 2017 at 10:45 PM, Mikael Abrahamsson <swmike@swm.pp.se><= /span> wrote:
I have n= ow received information that indicates that it will only use RDNSS if there= is no DHCPv4 or DHCPv6 provided resolver.

= Perhaps it implements this text in RFC 8106:

= =C2=A0 =C2=A0The DNS options from RAs and DHCP SHOULD be
=C2=A0 = =C2=A0stored in the DNS Repository and Resolver Repository so that
=C2=A0 =C2=A0information from DHCP appears there first and therefore take= s
=C2=A0 =C2=A0precedence.=C2=A0 Thus, the DNS information from D= HCP takes precedence
=C2=A0 =C2=A0over that from RAs for DNS quer= ies.
--001a11431e98fb4b58054dd64067-- From nobody Sun Apr 23 11:17: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 BAF2D1270FC for ; Sun, 23 Apr 2017 11:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 mNRhdLr6O-cg for ; Sun, 23 Apr 2017 11:17:09 -0700 (PDT) Received: from mta02.svc.cra.dublin.eircom.net (mta02.svc.cra.dublin.eircom.net [159.134.118.53]) by ietfa.amsl.com (Postfix) with SMTP id E6A14127342 for ; Sun, 23 Apr 2017 11:17:08 -0700 (PDT) Received: (qmail 47071 messnum 7121048 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 23 Apr 2017 18:17:06 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (HELO avas00) (213.94.190.11) by mta02.svc.cra.dublin.eircom.net (qp 47071) with SMTP; 23 Apr 2017 18:17:06 -0000 Received: from [192.168.1.3] ([86.45.37.230]) by Cloudmark Gateway with SMTP id 2M4Id6l1bo6Li2M4IdasCK; Sun, 23 Apr 2017 19:17:06 +0100 X-CNFS-Analysis: v=2.2 cv=TIk1cxta c=1 sm=1 tr=0 a=kvhl2hrZG42DSHFjhA0PKA==:117 a=kvhl2hrZG42DSHFjhA0PKA==:17 a=IkcTkHD0fZMA:10 a=1XWaLZrsAAAA:8 a=2hpeBx9Dved9izAXHSwA:9 a=T-D_-WBXgJvgQrTo:21 a=_W_S_7VecoQA:10 a=QEXdDO2ut3YA:10 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: text/html; charset=utf-8 X-Apple-Base-Url: x-msg://5/ X-Apple-Mail-Remote-Attachments: YES From: Ross Chandler In-Reply-To: X-Apple-Windows-Friendly: 1 Date: Sun, 23 Apr 2017 19:12:31 +0100 Cc: Mikael Abrahamsson , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <93C88966-D925-47C3-8F37-59F763FEA8CD@eircom.net> References: X-Uniform-Type-Identifier: com.apple.mail-draft To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfKr2GpG+bp9mHN3MdoKdi0LaIpDQTvxU/nE2NinEoUoQ9xD8hSA8nNiy08Kj2KkdLLy5uxnSBGGwjB64jWN93qubnPaUagB/rwptPJ35I1B3xeiVjrsH 37umGRBKXfqpmCHu4beqGkoE5R3U/qr2gh4ri3Mfsn8wP9sHlmtdkrL+DfU+znSiufX1caVP9GXRAjhwApJ/Ytir7fBsenMe/mc= Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? (yes it does) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 18:17:11 -0000

On 23 Apr 2017, at 15:24, = Lorenzo Colitti <lorenzo@google.com> wrote:

On Sun, = Apr 23, 2017 at 10:45 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
I have = now received information that indicates that it will only use RDNSS if = there is no DHCPv4 or DHCPv6 provided resolver.

Perhaps it implements = this text in RFC 8106:

   The DNS options from RAs = and DHCP SHOULD be
   stored in the DNS = Repository and Resolver Repository so that
  =  information from DHCP appears there first and therefore = takes
   precedence.  Thus, the DNS = information from DHCP takes precedence
  =  over that from RAs for DNS = queries.

I can see that it does maintain a = Resolver Repository containing RDNSS and DHCPv6 recursive DNS = resolvers.

With = my router configured to not advertise resolvers in DHCP and different = resolvers as RDNSS and DHCP6 it is possible with =E2=80=9Cipconfig = /all=E2=80=9D to see it immediately start using RDNSS upon issuing an = =E2=80=9Cipconfig /release6=E2=80=9D.

Ross

= From nobody Sun Apr 23 11:56: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 4734A128D19 for ; Sun, 23 Apr 2017 11:56:38 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rAcpECBYV86E for ; Sun, 23 Apr 2017 11:56:36 -0700 (PDT) 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 4399C1279EB for ; Sun, 23 Apr 2017 11:56:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 09475A5; Sun, 23 Apr 2017 20:56:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492973793; bh=MOqGRnpP+UdWF0bROgHPiTsIjgLLOtZqtZID2Z4Nw5Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=P33vKPVrfogfBG7ULOTHl/AIX9YoBcw0wgb88BJzJrvtzYJua8j8AxvtjshRM8t4M 9eV6oqGlFhh3I9t1gvOLdJj/QOwG+ClvHdV+kSTmH590orF5BsR6aecJ009l6wCtzd gqZFpImS44mK8kJqRP0/j95Viry4REt3yNa9M2gs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E5D01A4; Sun, 23 Apr 2017 20:56:32 +0200 (CEST) Date: Sun, 23 Apr 2017 20:56:32 +0200 (CEST) From: Mikael Abrahamsson To: Ross Chandler cc: Lorenzo Colitti , "v6ops@ietf.org WG" In-Reply-To: <93C88966-D925-47C3-8F37-59F763FEA8CD@eircom.net> Message-ID: References: <93C88966-D925-47C3-8F37-59F763FEA8CD@eircom.net> 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-534457625-1492973792=:5591" Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? (yes it does) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 18:56:38 -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-534457625-1492973792=:5591 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 23 Apr 2017, Ross Chandler wrote: > start using RDNSS upon issuing an “ipconfig /release6â€. aaaaaaah. I was not aware this command existed. That would have helped me a lot. I just took for granted "/release" and "/renew" would act on both DHCPv4 and DHCPv6. How silly of me. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-534457625-1492973792=:5591-- From nobody Sun Apr 23 18:10: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 26503127071 for ; Sun, 23 Apr 2017 18:10:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 WfxTaXkPRSvf for ; Sun, 23 Apr 2017 18:10:56 -0700 (PDT) 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 62C7C1204DA for ; Sun, 23 Apr 2017 18:10:56 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id f10so104042151uaa.2 for ; Sun, 23 Apr 2017 18:10:56 -0700 (PDT) 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=kb7+TXlYzWgSghCcETNFQ8d0JruBQsbKg9jPbQf2Oas=; b=K5KfSsvFL78nx0AJa+95U7pKRX2nAbuqnkrxgWpBXZSBadfatyLj2YMyqSH3AT7yvf XQQ6v0MDvllRSMMEcRppZY3+mPr3Fe4aw45dVGrYtW0c2MduCNo8LlNw0x3Z/lLzk92X 2QswwRcaIx8G8RDyJcvyDKXhCpQQTqg+pp5uit10hRI8PSNTMgHl7kc/xjtxdDclmoki mXS9tF07d/rPJ9LGxoFXPNB99R56qj0jU1GduvqpzMYEr+QoFHBBtyfgvtlqendpheQr apWPpyeJq86T63nbYnBtQGO8/8YD+RPIIEHlUDtaZJH1Vp1QEcuzUPceGR6g5MFdm+SB EViQ== 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=kb7+TXlYzWgSghCcETNFQ8d0JruBQsbKg9jPbQf2Oas=; b=CoTuHjDaVXRIo5e8xi1/yCoFeiAKona5lECz/zt/K88NQJ1Hs2ye+/5wCkC/ml+pw4 mhJR22qpVIrcSI7IH0ZT2sAawu6KfTNClZpe60z+pYQ45LtRRr2Rq3PUPaQ3KK4mO4PC 2kmk7k0g8Ke7xzP33H80zt6hP+b1mSeEBAkVN4UyoDfWFRUh6AomWrLExQpZusVnC0rS gFb4JjQjCgfnMki40JkmmdMmOjKNSibDL1zmZp2veOOS2vTBbHIKIgAz30x8zPLhZwAw WMzgt3u5/+FOshOkDZMcG0RzzvSrtmhDoPAzbwYcSS7/mbvJB1/nr8+0G9WsX36SzqER fI9w== X-Gm-Message-State: AN3rC/7xxGgwOGSUoXQNAiR5Dz8ammiLO+cB1PK7Bvvlf/LU7nC5VJTG eU/Vbpc4hGqNQyhHzeELftm8gqe4YAvIg2iTxw== X-Received: by 10.176.2.84 with SMTP id 78mr10746385uas.30.1492996255337; Sun, 23 Apr 2017 18:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Sun, 23 Apr 2017 18:10:34 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 24 Apr 2017 10:10:34 +0900 Message-ID: To: Mikael Abrahamsson Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11376f00739710054ddf476c Archived-At: Subject: Re: [v6ops] Windows Creator Update supports RDNSS? (yes it does) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 01:10:58 -0000 --001a11376f00739710054ddf476c Content-Type: text/plain; charset=UTF-8 On Sat, Apr 22, 2017 at 5:49 PM, Mikael Abrahamsson wrote: > I have now updated to Win10 creators release, and yes, indeed it seems to > support RDNSS. My Omnia Turris announces RDNSS resolver in RA with its GUA > LAN address and windows configured its resolver using that GUA address. It > didn't before I updated to the creators release. Time to update https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems ? --001a11376f00739710054ddf476c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 22, 2017 at 5:49 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
I have no= w updated to Win10 creators release, and yes, indeed it seems to support RD= NSS. My Omnia Turris announces RDNSS resolver in RA with its GUA LAN addres= s and windows configured its resolver using that GUA address. It didn't= before I updated to the creators release.

--001a11376f00739710054ddf476c-- From nobody Mon Apr 24 04:24: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 134E2131453 for ; Mon, 24 Apr 2017 04:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.067 X-Spam-Level: * X-Spam-Status: No, score=1.067 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 iSIdGCNtLCCA for ; Mon, 24 Apr 2017 04:24:28 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 866C012741D for ; Mon, 24 Apr 2017 04:24:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v3OBOQTw021493; Mon, 24 Apr 2017 13:24:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7EE56206D65; Mon, 24 Apr 2017 13:24:25 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2C0C8206E56; Mon, 24 Apr 2017 13:24:25 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v3OBONvM002293; Mon, 24 Apr 2017 13:24:24 +0200 To: Simon Hobson , IPv6 Ops WG References: <2D09D61DDFA73D4C884805CC7865E6114DB21FEB@GAALPA1MSGUSRBF.ITServices.sbc.com> <0166BF40-2A23-46A3-BAA5-FE5510736763@google.com> <8370648f-faab-1d47-f5fe-836917ff780d@gmail.com> <39EE6EBE-CB02-4E55-8074-5C1A7E558F62@thehobsons.co.uk> <5c1c487f-730f-dea0-b3e0-1a47e33fafac@gmail.com> <20170418233550.830F86BFE8E6@rock.dv.isc.org> <6213fff1-f92a-d80b-e2b7-aec51f2c7467@gmail.com> <3DDE532F-B701-4CB6-B917-AE468887979C@thehobsons.co.uk> From: Alexandre Petrescu Message-ID: <04103526-aa82-a436-4def-c2c902e2f9c4@gmail.com> Date: Mon, 24 Apr 2017 13:24:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3DDE532F-B701-4CB6-B917-AE468887979C@thehobsons.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 11:24:30 -0000 Le 21/04/2017 à 20:56, Simon Hobson a écrit : > Alexandre Petrescu wrote: > >> My DSL operator "free" 'delegates' my DSL box a fixed /56 and >> provides me a GUI, shown below, to manually configure 8 /64 routes >> towards the IPv6 address of in-home routers. >> >> It is great that I can have many /64s in-home. >> >> But I dont like that I have to manually configure these route >> entries, even though it's a GUI. >> >> And I dont like that there is no freedom in deciding maybe a /63 >> towards an IP (GUI form hardcodes '/64'). > > If you don't define any routes, do they just route the whole /56 to > your router, or do they not route anything ? If they route the whole > /56 then you can do what you like on your own router. They route the whole /56 to my DSL box. I think they route so somehow with IPv4 tunneling, or maybe what is called '6rd'. There is no option to stop IPv4 (whereas IPv6 is optional). > But down't forget that if you route two adjacent /64s to one router, > on the other side you can combine them into a /63 (with the proviso > that they /64s are both from the same /63). Upstream, addresses are > just addresses and the routers have no knowledge of whether any > particular address is part of a /64 or a /63. Ah, that is right - it is possible to route two adjacent /64s to one router and then combine them there into one /63. Alex From nobody Mon Apr 24 10:04: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 EA02B131889 for ; Mon, 24 Apr 2017 10:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 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_GREY=0.424] 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 uxlnwLjE9dHT for ; Mon, 24 Apr 2017 10:04:15 -0700 (PDT) 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 80CC4131857 for ; Mon, 24 Apr 2017 10:04:15 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id v14so11519599pfd.2 for ; Mon, 24 Apr 2017 10:04:15 -0700 (PDT) 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=1oqyXZ/E1Lz0TIYfSjpOhBSnMSNTD7Qv/Kp44HUK3C8=; b=m5SUMFewOp/WaGBS4oS/LLNnrNiFLmSVSMMm2ewhKpzJID327RrZ4J7DgoAD/M8fG4 VQJiuoCMqm5fFOmvM931WK94/QlQrRZYYMe1DPqYNyEWBpbZjzSxoUVY8MhC6HMy/4bi GtFbmuwq1eK8EOfRG+fGSbWNgAkfWqmELIUkGA1q8/6TUpAZpTiX5bgYoALzN13j29+s nVveIZB3SgDkYsA7un0Jwny9Q4rxuYgH0pSJcngiaL1SZo9sLnx+7YKtgbES04A3En1/ vxPssg5gRSURIyVWLOiFTlP/pxAOiMYWYbLvRrGWvqnBGC64KBsdqQ7OSHCswfow/fY+ zYeQ== 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=1oqyXZ/E1Lz0TIYfSjpOhBSnMSNTD7Qv/Kp44HUK3C8=; b=cNcJAvD6D1xyM1ZWjsuH409n6RgpLHtmaiqGPN8ngwJMgI0j7TRSFfM0Xa3Xgj73w9 I80HWtS1Cj1OKWTuHmkEDYHIKrKBSdkzefPs5GRjrh1Luua1Nvl3kazNe5IQnpEGCMVx Vj0t+Dp2hIoEaqSEoE6e9nPQMAJ/5hNch8fzjjuhvduI1Gl6JlUOi5GwxxSc1TDWzdZ3 GQx2K4Vey1wtgLxeg27ZOEp2KT4dboizS+ebIFJChdZntsEt+ZjtlBPNUguMSS7Wu2f6 un1zRXSSYA6QcpNeAm97uhWRr595wXlSS7W51YcuTJIBm5yIm7F05C7seGUAFgw8LHP2 Kbew== X-Gm-Message-State: AN3rC/5IjP/3VuMpskuwXS9oFphUDfagnojlauurJTgwSAXsGtXroQgd sUycUlqKWZ38bbDod70= X-Received: by 10.99.232.69 with SMTP id a5mr25947151pgk.167.1493053454702; Mon, 24 Apr 2017 10:04:14 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id v12sm32039197pgn.5.2017.04.24.10.04.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 10:04:13 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <4E3BE0F1-C20A-4E8F-A42F-C34D4A1E9794@gmail.com> Date: Mon, 24 Apr 2017 10:04:12 -0700 To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Thoughts on email reputation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:04:17 -0000 Raising a new topic... I recently read https://sendgrid.com/blog/where-is-ipv6-in-email/, which = expresses concern about using IPv6 for email, specifically in the area = of blocking spam. He notes that most reputation systems today block an = IPv4 /32, and is concerned that blocking an IPv6 /128 will be = ineffective. His proposed solution: block a source domain, based on the = reputation of the domain and the fact that we now have domain = signatures. He notes that blocking domains will be a big step for = reputation systems, as they don't do anything of the kind today. I'm with him on blocking domains that originate spam. I do note the = fairly common practice (of porn and malware shops) of reserving a domain = and using it, deciding whether it is worthwhile, and then releasing it = before it has to be paid for. I'm told that there is an entire industry = that churns through domain names pretty rapidly, and consider that this = might simply flood the reputation systems. I'm also concerned about = proportionality, as described in = https://en.wikipedia.org/wiki/Proportionality_(law)#European_Union_law. I'm also with him on blocking /128s; my biggest issue is with temporary = addresses, which I understand Windows and MacOS, and probably Linux, use = for sessions they originate, reserving permanent addresses for DNS and = services one might access using it. If we are blocking addresses that = send spam, it seems like they might change every 24 hours. However, it seems likely to me that a system that changes its address = daily likely changes its /64 infrequently, when it moves. If it is = fixed, the /64 will be as well; if it is used by a human being, it is = likely to use a relatively small set of prefixes, not just prefixes at = random. So a spam source might tarnish a prefix at home and another = prefix at work, but not an arbitrary number of prefixes. So, just a thought, how about we ask the reputation services to talk = about reputations for /64? That would be a relatively small step away = from their current model of reputations for addresses, and might be both = (more) proportional and equivalently effective. From nobody Mon Apr 24 10:52: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 167B012948F for ; Mon, 24 Apr 2017 10:52:31 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 Bnhb3mQbIuTc for ; Mon, 24 Apr 2017 10:52:29 -0700 (PDT) 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 2E4EB1293E0 for ; Mon, 24 Apr 2017 10:52:28 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 417F660B0D for ; Mon, 24 Apr 2017 19:52:25 +0200 (CEST) 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 E393F604B2; Mon, 24 Apr 2017 19:52:24 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id E097125DEC; Mon, 24 Apr 2017 19:52:24 +0200 (CEST) Date: Mon, 24 Apr 2017 19:52:24 +0200 From: Gert Doering To: Fred Baker Cc: "v6ops@ietf.org WG" Message-ID: <20170424175224.GP25069@Space.Net> References: <4E3BE0F1-C20A-4E8F-A42F-C34D4A1E9794@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E3BE0F1-C20A-4E8F-A42F-C34D4A1E9794@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [v6ops] Thoughts on email reputation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:52:31 -0000 Hi, On Mon, Apr 24, 2017 at 10:04:12AM -0700, Fred Baker wrote: > So, just a thought, how about we ask the reputation services to > talk about reputations for /64? That would be a relatively small > step away from their current model of reputations for addresses, > and might be both (more) proportional and equivalently effective. My thinking has always been to do a staggered approach - start with /128s, if you see "more than one bad egg", down-rate the whole /64, and trickle that upwards - so eventually, a whole /32 would have a bad reputation if the spammer decides to just rotate addresses in that /32 quickly. For a start, reputation for /64 is better than /128 :-) - but I think it's not sophisticated enough. 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 pch-b7900FA3D@u-1.phicoh.com Mon Apr 24 11:10:24 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 D5C4313190B for ; Mon, 24 Apr 2017 11:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_GREY=0.424] 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 u_nUFgs0movD for ; Mon, 24 Apr 2017 11:10:23 -0700 (PDT) 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 6D8D4129418 for ; Mon, 24 Apr 2017 11:10:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1d2iRF-0000EHC; Mon, 24 Apr 2017 20:10:17 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com In-reply-to: Your message of "Mon, 24 Apr 2017 10:04:12 -0700 ." <4E3BE0F1-C20A-4E8F-A42F-C34D4A1E9794@gmail.com> Date: Mon, 24 Apr 2017 20:10:16 +0200 Archived-At: Subject: Re: [v6ops] Thoughts on email reputation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:11:30 -0000 In your letter dated Mon, 24 Apr 2017 10:04:12 -0700 you wrote: >I recently read https://sendgrid.com/blog/where-is-ipv6-in-email/, which expre >sses concern about using IPv6 for email, specifically in the area of blocking >spam. He notes that most reputation systems today block an IPv4 /32, and is co >ncerned that blocking an IPv6 /128 will be ineffective. His proposed solution: > block a source domain, based on the reputation of the domain and the fact tha >t we now have domain signatures. He notes that blocking domains will be a big >step for reputation systems, as they don't do anything of the kind today. > >I'm with him on blocking domains that originate spam. I do note the fairly com >mon practice (of porn and malware shops) of reserving a domain and using it, d >eciding whether it is worthwhile, and then releasing it before it has to be pa >id for. I'm told that there is an entire industry that churns through domain n >ames pretty rapidly, and consider that this might simply flood the reputation >systems. I'm also concerned about proportionality, as described in https://en. >wikipedia.org/wiki/Proportionality_(law)#European_Union_law. I'll stay out of the blocking domains can of worms. If we look at IPv4, you can block individual /32s. But if you get a lot of spam from a certain network, then it makes sense to look at announced prefixes and block those. The thing here is that it is the local policy of the block list. Lists that want to be conservative block a /32. Or maybe a /24. Aggressive block lists block everything related to an AS, or possibly even an upstream AS. Or all resources allocated to a country, etc. This is exactly the same in IPv6. Except that a /24 in IPv4 might be a /64 or a /56 or /48, or even bigger. That requires some experience to figure out what is what. Where IPv6 creates a new technical issue is if a spammer can allocated arbitrary new IPv6 addresses in a /64. If a spammer can assign a new IPv6 address to each individual spam, then it is possible that the DNS lookups overload caches, resulting in more load on the DNS servers of the block list. There is somewhere a complex proposal to encode prefixes in DNS and use that for block lists. For myself, I implemented a scheme that first tries to look up the first 64 bits of an address and then the full IPv6 address. Then any /64 will result in a cache hit. >So, just a thought, how about we ask the reputation services to talk about rep >utations for /64? That would be a relatively small step away from their curren >t model of reputations for addresses, and might be both (more) proportional an >d equivalently effective. So the technical challenge is to implement a DNSBL lookup scheme that scales. We should leave the policy of what to block exactly to the individual block lists. From nobody Tue Apr 25 06:38:55 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45ECC1270A7; Tue, 25 Apr 2017 06:38:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: v6ops-chairs@ietf.org, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149312753419.20766.14280373593100047269.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 06:38:54 -0700 Archived-At: Subject: [v6ops] Suresh Krishnan's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:38:54 -0000 Suresh Krishnan has entered the following ballot position for charter-ietf-v6ops-04-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am highly supportive of this charter but I want to make sure that one item is addressed. v6ops has traditionally worked on CPE router requirements and I do not see any mention of this in the charter. I would like to see some verbiage added in this regard. From nobody Tue Apr 25 10:46: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 61894129577 for ; Tue, 25 Apr 2017 10:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 p_XPFZIj4WT7 for ; Tue, 25 Apr 2017 10:46:39 -0700 (PDT) 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 C1DC9131714 for ; Tue, 25 Apr 2017 10:46:15 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id c45so146190997qtb.1 for ; Tue, 25 Apr 2017 10:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HhB3jzCSWlNe5NxVCmhQWXIIb/k38Z2wTDniB2E9E6s=; b=oTEzGuO14hI+vut0UMJrQEdkxuiDW/FIabtXejcUew7rX/sYtS2SFMzGBta0p7FBBZ Y2eUdV6yKHchf/w4bXoyiF6bbkroMb88JxPx2bpHdRgKOOHBtyqa9PiHH8fBGyE3uyNl o5VeaRaY+DatmaNMpGuYd9uFn9bszKCgYAHzdDxw6N9ydjYNLOLHdfM0UE4AxS/aieTf yVfqoYJvpPgSgCfo6VCOumjU75ykNYNExc8Fj5ZFzTwe7L6/JstCLYpZzWsZW5v09yLk HXF/91Pcvvw0eqLpRxHdgwXskVugAWs3dpc0F+qpJgietMKRQeoaML+znyBZqtbuYeLj 3y1w== 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=HhB3jzCSWlNe5NxVCmhQWXIIb/k38Z2wTDniB2E9E6s=; b=QXsxyqDWN9aBiXDK4lLmfKT8C0ruCfILBxR5FgTvuijsWmvTdUS2l8R7yceNA0gsDD Etmb8fhRdni7zfuGf8CMYMLiCq+BSmNASi2tAw7bjvz0gU6HVrNIdm2S+a7+kEIKF3fP u63oBv/mddFoowI0Gp8w0AusIyYPqQZCTVGI5cCYg0+CqhMJE5T+cVVbWa0fkfad81UW mA9cEUvKN7Yh5rXSdnJl3TlWxAHi066DOuXc/yBqeibuabcn7JBFBO3Q6SusvcwSgPNH 5PpxcJH4NG1hbT22c8UpXXQNpPhaLm1ys16teEef9+V3Dkg6y3avwcEOVq5t7H1Kmn0c mUaA== X-Gm-Message-State: AN3rC/6Hy06fqIPivG2UOd2vhA37lVoJYLvGzXRKUp65WrSXZKeWbx17 0hc2B2YVchgLTqNXNCDZr/UfQtTq46g4C8lZDg== X-Received: by 10.237.39.146 with SMTP id a18mr32103654qtd.5.1493142374001; Tue, 25 Apr 2017 10:46:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.154 with HTTP; Tue, 25 Apr 2017 10:45:33 -0700 (PDT) In-Reply-To: <149312753419.20766.14280373593100047269.idtracker@ietfa.amsl.com> References: <149312753419.20766.14280373593100047269.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Tue, 25 Apr 2017 13:45:33 -0400 Message-ID: To: Suresh Krishnan Cc: The IESG , IPv6 Operations , V6ops Chairs Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:46:41 -0000 On Tue, Apr 25, 2017 at 9:38 AM, Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > charter-ietf-v6ops-04-01: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-v6ops/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am highly supportive of this charter but I want to make sure that one > item is addressed. v6ops has traditionally worked on CPE router > requirements and I do not see any mention of this in the charter. I would > like to see some verbiage added in this regard. > > Thank you. Good suggestion -- I tried to find a good place to add this. How about I add: "The group will also document basic requirements for IPv6 CPE" to the end of the "IPv6 operational and deployment issues with specific protocols or technologies... " paragraph? W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Apr 25 10:55:18 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B09D131734; Tue, 25 Apr 2017 10:55:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: v6ops-chairs@ietf.org, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149314290921.17908.16961040643792713229.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 10:55:09 -0700 Archived-At: Subject: [v6ops] Ben Campbell's No Objection on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:55:09 -0000 Ben Campbell has entered the following ballot position for charter-ietf-v6ops-04-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think this is ready for approval without external review. I stumbled over the same sentence as Spencer. Since I went to the trouble to compose proposed new text before reading his, I'll include that here--but I'm okay with Spencer's suggestion as well. Last sentence in the first paragraph: OLD: An important aspect of IPv6 deployment has been the shutdown of IPv4 in some networks, and issues and opportunities from these shutdowns have resulted in innovations in network operation NEW: IPv6 deployment has resulted in the shutdown of IPv4 in some networks. These shutdowns have resulted in innovations in network operations. END. From nobody Tue Apr 25 13:03:43 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA47F129487; Tue, 25 Apr 2017 13:03:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: v6ops-chairs@ietf.org, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149315061780.11971.14347323560495712687.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 13:03:37 -0700 Archived-At: Subject: [v6ops] Deborah Brungard's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 20:03:38 -0000 Deborah Brungard has entered the following ballot position for charter-ietf-v6ops-04-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I still find that last sentence difficult to parse "issues and opportunities from these shutdowns have resulted in innovations in network operation" e.g. if take the first part, "issues in shutdowns resulting in innovations in network operation" is doublespeak. I don't think ops folks see their issues with such rose-colored glasses. And the sentence seems opposite of the charter of the working group, e.g. item #1 and #2, as the charter is about identifying operational issues. If issues resulted in innovations, we wouldn't need this group:-) I'd suggest instead of "selling" the innovations of global deployment in this sentence, rephrase it to be specific on the charter goals. How about: "An important aspect of IPv6 deployment has been the operational issues with the shutdown of IPv4 networks and operational interaction issues with IPv4 networks." From nobody Tue Apr 25 14:01: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 09ABB128B8F; Tue, 25 Apr 2017 14:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 w9Z4-V4yMZD2; Tue, 25 Apr 2017 14:01:33 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::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 E9C821252BA; Tue, 25 Apr 2017 14:01:32 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id w50so22353690wrc.0; Tue, 25 Apr 2017 14:01:32 -0700 (PDT) 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=r1uR8d3ZtCkDqMegARFyBw9+3uq6Or+sLllPJgHEjuM=; b=qZr01aj9vjIf/pmTDdX1yLq2gujfpHIukS7kl+XPaMBO73nxDguOqsVWn/7RMIaRmM NSwsljjPYEftHJPezLlaAdxZ7DIaHhmfzlsHVEMUU+YrybafZwcsHCb+phLTyznC1f1F qKi8dj6qFa7RFyLjT8/p3y2P3V6WQgVFOfEjFdYIwEJ0YgsDKD8apXEXzb2NCUxCXsgW fHBdHOKOeGmiykEQq7Su5cMGPQw5DC9/SjkrK6YP2mzUpsa2QIBAdRNrpzZmKTA1ePQn dvTWPQVR1XUuL6dMetl3TYrxQ2tFSFYyoiT2Hq9GR8YEWQpabSx9P5zxnmsg025Ec0AF oHbQ== 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=r1uR8d3ZtCkDqMegARFyBw9+3uq6Or+sLllPJgHEjuM=; b=SNFq6UE7z5A361yJ6G1WLg0ioJMbQ9vMlBm++xuOrfW04UCdA4SXBtwwNhrNA+eQqG BH4TZXXc9oWKpThXHgc4pVN8dQHC9QVeGxu0SKvKLMNBUVb4TMD50c9ae3ygbvVRRG1G YKCJOVhXlxuEfpPdNrnFCHh8vqo/rEnEZA+SEAunYDKg6u0AWuv3hhpRhoA6OhBfPj7q pIpZ1HA4p4uvXRLWoNro45CfSMGNPD9zdhL0YIOTE2g3EefuR9F9GVW3cTBUQFv4It2D EiJUCoSEwqyCeBfls4VPlNr1sFVet6WNNfdowSuT1KhDlEWkbXJoDM+48ZQ9KZ9AwZsI bwVw== X-Gm-Message-State: AN3rC/5NpaAxCVExyoRDbTL/TYK/ZZ7THlD3ULt3CCF+RI91UksH892J nTyjc3I/CM/c7f9Q1Rc= X-Received: by 10.223.149.33 with SMTP id 30mr6192747wrs.61.1493154091455; Tue, 25 Apr 2017 14:01:31 -0700 (PDT) Received: from 201.66.20.149.in-addr.arpa (201.66.20.149.in-addr.arpa. [149.20.66.201]) by smtp.gmail.com with ESMTPSA id m139sm6521365wmb.27.2017.04.25.14.01.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 14:01:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <149315061780.11971.14347323560495712687.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 14:01:27 -0700 Cc: The IESG , V6ops Chairs , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149315061780.11971.14347323560495712687.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Deborah Brungard's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:01:35 -0000 Warren: I need some advice from you on how to proceed. Ben, Spencer, and = Deborah have commented and suggested text, and Suresh has suggested an = additional charter item. https://datatracker.ietf.org/doc/charter-ietf-v6ops/ballot/ Ben's suggested text is closest to the meaning I intended. An example of = the kind of thing I had in mind was the concept of routing a /64 to a = chassis (and routing to it using BGP as opposed to Neighbor Discovery), = which is conceptually thought of as having an internal (or tethered) = virtual LAN, and the containers or applications having addresses on that = LAN. It is not that we have interesting opportunities in dealing with = IPv4 networks, as Spencer suggested, but that we have new and = operationally interesting network models that might not require the = physical host to be different from a router, and might treat a container = or an application the way we have treated a host in the past. Suggested text for the interesting sentence: NEW: IPv6 deployment has resulted in the shutdown of IPv4 in some networks. = Removing IPv4 constraints has resulted in innovations in IPv6 network = operations. END. To Suresh's comment, the working group has not discussed this amendment, = but I suspect would be agreeable to it. We have two drafts in the mill = that would align with it. NEW: 5) Document operational requirements for IPv6 networks. END. What do you want me to do? > On Apr 25, 2017, at 1:03 PM, Deborah Brungard wrote: >=20 > Deborah Brungard has entered the following ballot position for > charter-ietf-v6ops-04-01: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-v6ops/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I still find that last sentence difficult to parse "issues and > opportunities from these shutdowns have resulted in > innovations in network operation" e.g. if take the first > part, "issues in shutdowns resulting in innovations in > network operation" is doublespeak. I don't think ops > folks see their issues with such rose-colored glasses. > And the sentence seems opposite of the charter of the > working group, e.g. item #1 and #2, as the charter is > about identifying operational issues. If issues resulted > in innovations, we wouldn't need this group:-) >=20 > I'd suggest instead of "selling" the innovations of global > deployment in this sentence, rephrase it to be specific > on the charter goals. How about: > "An important aspect of IPv6 deployment has been the > operational issues with the shutdown of IPv4 networks > and operational interaction issues with IPv4 networks." >=20 >=20 From nobody Tue Apr 25 14:32: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 69B77129436; Tue, 25 Apr 2017 14:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 52Mj0HNnKZIJ; Tue, 25 Apr 2017 14:32:15 -0700 (PDT) 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 65FA7126B6E; Tue, 25 Apr 2017 14:32:15 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id 81so71521196ybp.0; Tue, 25 Apr 2017 14:32:15 -0700 (PDT) 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=Oba1Rb2bboVpBp6Ylp5nSBRAbbzcNsT4G/63fTWdIw8=; b=UMhXoxvaRJuopK+B/pDkHoWAlosbmWzjXLaX8eFFOiZna7ojGQxELF/0H8Hso3q/sS Ipg48BWQPuaBWpQH5OyVWQNmTFm/domekmZFJEx7fTBWm//BUpSlXFt8UwocLVnMzEcJ FAwopfqFFyK1/7yRv0f9MP8Tk6B/GoeIo9Ys6uDeK2E6ECd1riI1FhZIGJztn1uBPYnq GK1vohhloBfcEmowTfLD1CIfJDZkxBTXozV7wrxI3y67gGovAmSKyWLivaGyu3BJ8Rgc Fp1Zfm8PC42dsZmkqvQee15iiQtjCYWQrq92Kvk+G9kzX8fH1E700f3cJy4bkQAQ01XJ K/mA== 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=Oba1Rb2bboVpBp6Ylp5nSBRAbbzcNsT4G/63fTWdIw8=; b=neaaMxT//92TBpLN+/9UViu8N0QzIfgWNPYX9ppdjEwjSZ2JDRQpKweKDFduB7pTW1 M2JzHsBpPzNvT8f2SzAHohxDzkckVav6sefreszCgkcumDRC1C+SzA3pDzu8nLQ64OAM s3KKIWofFoNvmTBN1Nxo0rQ8pQxR5SQ2dv5lBlX7MH66YFygVTbx9m1nuU9V7EICikiH 1drWHjjFKtE56vaoW21c9zWDsXR1a2auZ7pazrOA91EflpO4OPif6o3VxfWfQD5Waswx Y16VsvBvM0owrFs7wFgFuUBuh6vH76STdMLzjIOam5dmQO11gKQWoQIGHkWCuC10K2IH UN0A== X-Gm-Message-State: AN3rC/6NH/MmSnKRQkR6U6aOEioOGzcugqf5JqcNcvpZ/0J0KOY9UCxw bSk2vBw6u3wz7z1f1WrmQ/BO58gi7Q== X-Received: by 10.37.72.3 with SMTP id v3mr11446566yba.198.1493155934654; Tue, 25 Apr 2017 14:32:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Tue, 25 Apr 2017 14:32:14 -0700 (PDT) In-Reply-To: <149314290921.17908.16961040643792713229.idtracker@ietfa.amsl.com> References: <149314290921.17908.16961040643792713229.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 25 Apr 2017 16:32:14 -0500 Message-ID: To: Ben Campbell Cc: The IESG , v6ops list , V6ops Chairs Content-Type: multipart/alternative; boundary=001a113e905c14a0de054e0475bb Archived-At: Subject: Re: [v6ops] Ben Campbell's No Objection on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:32:18 -0000 --001a113e905c14a0de054e0475bb Content-Type: text/plain; charset=UTF-8 Just to square the circle ... On Tue, Apr 25, 2017 at 12:55 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > charter-ietf-v6ops-04-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-v6ops/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I think this is ready for approval without external review. > > I stumbled over the same sentence as Spencer. Since I went to the trouble > to compose proposed new text before reading his, I'll include that > here--but I'm okay with Spencer's suggestion as well. > > Last sentence in the first paragraph: > > OLD: > An important aspect of IPv6 deployment has been the > shutdown of IPv4 in some networks, and issues and opportunities from > these shutdowns have resulted in innovations in network operation > NEW: > IPv6 deployment has resulted in the shutdown of IPv4 in some > networks. These shutdowns have resulted in innovations in network > operations. > END. > I'm OK with Ben's suggested text, as well ... Spencer --001a113e905c14a0de054e0475bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to square the circle ...
On Tue, Apr 25, 2017 at 12:55 PM, Ben Campbell= <ben@nostrum.com> wrote:
Be= n Campbell has entered the following ballot position for
charter-ietf-v6ops-04-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ie= tf-v6ops/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I think this is ready for approval without external review.

I stumbled over the same sentence as Spencer. Since I went to the trouble to compose proposed new text before reading his, I'll include that
here--but I'm okay with Spencer's suggestion as well.

Last sentence in the first paragraph:

OLD:
An important aspect of IPv6 deployment has been the
shutdown of IPv4 in some networks, and issues and opportunities from
these shutdowns have resulted in innovations in network operation
NEW:
IPv6 deployment has resulted in the shutdown of IPv4 in some
networks. These shutdowns have resulted in innovations in network
operations.
END.

I'm OK with Ben's suggeste= d text, as well ...

Spencer=C2=A0
--001a113e905c14a0de054e0475bb-- From nobody Tue Apr 25 23:23: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 DEE6012F24E; Tue, 25 Apr 2017 23:23:50 -0700 (PDT) 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 8IkBK_oGspTm; Tue, 25 Apr 2017 23:23:49 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 8FF4A13180E; Tue, 25 Apr 2017 23:23:48 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id r190so115473834wme.1; Tue, 25 Apr 2017 23:23:48 -0700 (PDT) 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=fD5M/UeMRVUFTiNEC1EY7ug+aOAEA/KEMRQOIwa4rpg=; b=EPS3nl8hO2zprADC+MVlPfqXt4asBLzMf9SSJnhKJB22MyZmEgXxeIZn8kOIYEC9Ta O8L/ekAJ1As8aH+1nziBMt5c/Kvnok1pLbTw+TQqss4Q1W/OXhU6nBXLjU+eS95pUUfL uuFmMQxTztjc3zP/Aue3q0Ynv4Y1oyW13DvVFCxNPBW5neGSpBPvJO9AuC8oiSzDQVRJ AQ7sBt/hKNoznA0Aty+e7NrfktUDxb4RAUacoKELXDxQnj/iUOSUvIVPfUntcptu+jWE SjIduBXPrZKYwsy6tKMaq4sX3/XmflUpXiHlgibU2N9GUuSIwI75rLya5XsAn/720IUy DqBQ== 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=fD5M/UeMRVUFTiNEC1EY7ug+aOAEA/KEMRQOIwa4rpg=; b=Po5Nrdfp0CcG12+swSDJmGC0iLNHXMRFpweBc/TeYQX57PuUBbJ0NThRA0Kn/JLgfe sC4otaCWTQF3NRSHXhbbubpC8Apc6ZFMiZCXcJehyD8YAroI3QP3lKzosJvICvyQzg7B caazPChZgOuYCQ9BAvWfLnZWgSBOl/DtCaFOJlo1gi0Wdznxy8BjPtJ1huPNaGWFjttc wxlUGeYp8myhLQk2pHI0/vKuzGcJZ8Hd4/d0OQ3AjmM6bBa2zhgY9JJ+HTJzyVViARC+ jmv4a13/Ymjz3HPL/FvyBqHkDFEdbw5mUcgB/mGUzSfWkO2J9T62p45pXrTqLaeqml2k /hfA== X-Gm-Message-State: AN3rC/7NpXVxEoPKJE46IVgL4zyv0qyi/dIWXEDVf0O0MohDIbHJARr2 x9CF26mUrQ/Q9htT0jo= X-Received: by 10.28.167.18 with SMTP id q18mr3957436wme.82.1493187827066; Tue, 25 Apr 2017 23:23:47 -0700 (PDT) Received: from 207.66.20.149.in-addr.arpa (207.66.20.149.in-addr.arpa. [149.20.66.207]) by smtp.gmail.com with ESMTPSA id a5sm5540498wma.28.2017.04.25.23.23.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 23:23:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <6D1DEB90-C956-4740-B54E-384927527D6B@gmail.com> Date: Tue, 25 Apr 2017 23:23:42 -0700 Cc: draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <277203FC-4585-41F5-9717-4D29A88AC329@gmail.com> References: <6D1DEB90-C956-4740-B54E-384927527D6B@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] WGLC for draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 06:23:51 -0000 Two weeks is up. This WGLC is closed. I have seen no comments, so I assume that the comments made before WGLC = is what we have to go on. Any disagreement, let me know. > On Apr 11, 2017, at 11:33 AM, Fred Baker = wrote: >=20 > This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-v6ops-v4v6-xlat-prefix. If you = have not read it, please do so now. You may send nits to the author, but = substantive discussion should go to the list. >=20 > Note that we have one comment from Jordi, who considers it ready to = go, and my sense of the list discussion prior to adoption was that the = working group is OK with simply doing this. >=20 > I will close the call on 25 April. From nobody Wed Apr 26 07:57: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 E1CAC12EADF for ; Wed, 26 Apr 2017 07:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 c6zwDpqevqv1 for ; Wed, 26 Apr 2017 07:57:08 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 7C59D12EBFF for ; Wed, 26 Apr 2017 07:57:05 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id m36so2804145qtb.0 for ; Wed, 26 Apr 2017 07:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=f7N7cfADHX/U2Z6T53cOY+iPWErxYeStpwxOr3+LWt8=; b=JHjoy6LhkdorEvfuxa4sFOBJMO+F1f0+nVjbOjoOPMgNvMdG8CeyM2DfDYrisdXHr/ rcGzpXr/60WiSAnqWgowBulzum435Fd8iKdVETw81tjTi4lY79+y/YuYejyXOAYP4rsh f6KaTWxVTwnq7dkBtFvH6+7NkWqkMlnadDfHJCYcsxmuK6sD8iTXC0UR3KqvNaiMUbxt PWCWe6BcVzUbmkAf1BEquH6P+08o/8EIAsnxYwLhPDoOcvUy6edrMj6yWHfiEhITAnOj CTkD4cE2lPkTDsSN86d8+v0nFIZ8cDvEnSCNlVSMlJEKhEWBdr1mw2ll6FvVnsfwN7aH HAtQ== 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=f7N7cfADHX/U2Z6T53cOY+iPWErxYeStpwxOr3+LWt8=; b=Zh3ifuyLfe7v/ROZn75Qu7ZpfqlVfGMttmenGxjktf8ut0WBeDt5ZLHXyDPS2dxci/ atkFyt8LEaAZZzO+iXMhvlpKOouAL/1RWHMlh/rfRnqJnl0jSKJ9qs7714CJBAczQXB9 kOUWnXfLIbox5XN1uve+cttVgGDtE4K+BmqvUhxI/ernGVW6DOr3JSQfPKtYB6NDHxMo GE49GaF2uPcvAfGeLRfmUdyGy562/kwys5qUnKSJWcBXl2XqCivuu+GEuN7QR8XsEPst RkpqzTaJbDIZnMZ2Fd87t5c0u2KXAtYMRDUbajEReYhrnJ8CR+dZJs9Am4W3r4l2eVWB XBGg== X-Gm-Message-State: AN3rC/5/PnVbrNa7wcK/Slke0CD9J2k+3rqboZOy7L5ggBAStUEQ+mS6 oDyEWmwyvZHkTNOWVLl0iP50Z8b0TTSy X-Received: by 10.237.57.71 with SMTP id l65mr158206qte.101.1493218624499; Wed, 26 Apr 2017 07:57:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.164 with HTTP; Wed, 26 Apr 2017 07:56:23 -0700 (PDT) In-Reply-To: References: <149315061780.11971.14347323560495712687.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Wed, 26 Apr 2017 10:56:23 -0400 Message-ID: To: Fred Baker Cc: The IESG , V6ops Chairs , IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Deborah Brungard's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:57:10 -0000 On Tue, Apr 25, 2017 at 5:01 PM, Fred Baker wrot= e: > Warren: I need some advice from you on how to proceed. Ben, Spencer, and = Deborah have commented and suggested text, and Suresh has suggested an addi= tional charter item. > > https://datatracker.ietf.org/doc/charter-ietf-v6ops/ballot/ > > Ben's suggested text is closest to the meaning I intended. An example of = the kind of thing I had in mind was the concept of routing a /64 to a chass= is (and routing to it using BGP as opposed to Neighbor Discovery), which is= conceptually thought of as having an internal (or tethered) virtual LAN, a= nd the containers or applications having addresses on that LAN. It is not t= hat we have interesting opportunities in dealing with IPv4 networks, as Spe= ncer suggested, but that we have new and operationally interesting network = models that might not require the physical host to be different from a rout= er, and might treat a container or an application the way we have treated a= host in the past. > > Suggested text for the interesting sentence: > > NEW: > IPv6 deployment has resulted in the shutdown of IPv4 in some networks. Re= moving IPv4 constraints has resulted in innovations in IPv6 network operati= ons. > END. > > To Suresh's comment, the working group has not discussed this amendment, = but I suspect would be agreeable to it. We have two drafts in the mill that= would align with it. > > NEW: > 5) Document operational requirements for IPv6 networks. > END. > Yeah, I'd suggested (yesterday): "The group will also document basic requirements for IPv6 CPE", but yours is (IMO) better. > What do you want me to do? Nothing -- I specifically hadn't made the changes to the posted text, because that would create a new version (04-02), and we would lose all of the current ballots - seeing as we have 5 "Yes" and 5 "NoObj" that would be sad. However, your proposed solution for Suresh involves adding a whole new bullet point, which is (IMO) a significant enough change that it probably makes sense for a new version to be pushed. I'll explain the updates and assume that people will be happy to click the ballot buttons again. This is the first rechartering I've done, so I'm still feeling my way around the process... W > > >> On Apr 25, 2017, at 1:03 PM, Deborah Brungard wrote: >> >> Deborah Brungard has entered the following ballot position for >> charter-ietf-v6ops-04-01: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-v6ops/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I still find that last sentence difficult to parse "issues and >> opportunities from these shutdowns have resulted in >> innovations in network operation" e.g. if take the first >> part, "issues in shutdowns resulting in innovations in >> network operation" is doublespeak. I don't think ops >> folks see their issues with such rose-colored glasses. >> And the sentence seems opposite of the charter of the >> working group, e.g. item #1 and #2, as the charter is >> about identifying operational issues. If issues resulted >> in innovations, we wouldn't need this group:-) >> >> I'd suggest instead of "selling" the innovations of global >> deployment in this sentence, rephrase it to be specific >> on the charter goals. How about: >> "An important aspect of IPv6 deployment has been the >> operational issues with the shutdown of IPv4 networks >> and operational interaction issues with IPv4 networks." >> >> > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Apr 26 08: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 69BBF12EC34 for ; Wed, 26 Apr 2017 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=kumari-net.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 ZF5lrzZaemap for ; Wed, 26 Apr 2017 08:04:30 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 EE10912EC3E for ; Wed, 26 Apr 2017 08:04:29 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id y33so2939857qta.2 for ; Wed, 26 Apr 2017 08:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uSyvQd49sPMabnrKQpUIvuOJFbUaDNSErE1HBfSlEEA=; b=hzhnCvd7VXhqjMSAZRus5IDZXqSQTktsEk+KcCSRdJuDZbq/nKLpfRvfgw8nwaLg3N MAAE914+eWZfDtVHParC+7SnytT+NIqeKtdZYbJafV0RxlhOROsQNNhTrHxxiZtZNc3L w+ocAzI2d/lJunrT+eXkozh08lGFu+wjsUNfwVuhDEF+s8aZC2TD4EE5Vf2Mu2xoTf8B 61UvgH4BmDcpLBH6mWY6hyyIPSar7AIoxSKyYpQNH5Ac04MZlydsLcrU5fCd8S6uGPT3 IVl5/1Svh0y4chwxbUvqQYqDNvtlf4wurHEw0p1zKlmE0br6bvsd2RHfLE9hNbzwM66l p80Q== 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=uSyvQd49sPMabnrKQpUIvuOJFbUaDNSErE1HBfSlEEA=; b=HfpKNOBjD/s2idNND+DBS6OEpAePwL2HwQCaOIifK97BKG4CxqUf9esFcyBIwPoo3/ q2ntUVq34gwD2XD1Dmk5Rg8vMtXjQ6yl76ZoeRF5qosgwSeaUCGI2eTkozN9NY2vsygf FMi3JhiOD7FHWdQTJWBYdtii2huNaIqfxetWrITr5Biy5jRhCNlVC2nXcowJxHkhVFYX AfZiAUFv3XbvIKQhrblnHtpjqNI+mVXZH4F2HMrRXaVFHBsVD+mTMzghnk1nObpWy8iI 5kOl2DkakIo0bjSVwBnmUqvZB/KZzI73XqnIWkJ1uFiDgpzejzlxGoB067/cbr5LCySn 5RAA== X-Gm-Message-State: AN3rC/5kZr5lJElPf/rIgFMHjC0+kMaXLb06YK0/V5UbRRkOR1FFWoAl s38h9ZevxciY5gKCsU6pmYK73Y2Yvbfa X-Received: by 10.200.38.132 with SMTP id 4mr198004qto.99.1493219068873; Wed, 26 Apr 2017 08:04:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.164 with HTTP; Wed, 26 Apr 2017 08:03:48 -0700 (PDT) In-Reply-To: References: <149315061780.11971.14347323560495712687.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Wed, 26 Apr 2017 11:03:48 -0400 Message-ID: To: Fred Baker Cc: The IESG , V6ops Chairs , IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Deborah Brungard's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:04:32 -0000 On Wed, Apr 26, 2017 at 10:56 AM, Warren Kumari wrote: > On Tue, Apr 25, 2017 at 5:01 PM, Fred Baker wr= ote: >> Warren: I need some advice from you on how to proceed. Ben, Spencer, and= Deborah have commented and suggested text, and Suresh has suggested an add= itional charter item. >> >> https://datatracker.ietf.org/doc/charter-ietf-v6ops/ballot/ >> >> Ben's suggested text is closest to the meaning I intended. An example of= the kind of thing I had in mind was the concept of routing a /64 to a chas= sis (and routing to it using BGP as opposed to Neighbor Discovery), which i= s conceptually thought of as having an internal (or tethered) virtual LAN, = and the containers or applications having addresses on that LAN. It is not = that we have interesting opportunities in dealing with IPv4 networks, as Sp= encer suggested, but that we have new and operationally interesting network= models that might not require the physical host to be different from a rou= ter, and might treat a container or an application the way we have treated = a host in the past. >> >> Suggested text for the interesting sentence: >> >> NEW: >> IPv6 deployment has resulted in the shutdown of IPv4 in some networks. R= emoving IPv4 constraints has resulted in innovations in IPv6 network operat= ions. >> END. >> >> To Suresh's comment, the working group has not discussed this amendment,= but I suspect would be agreeable to it. We have two drafts in the mill tha= t would align with it. >> >> NEW: >> 5) Document operational requirements for IPv6 networks. >> END. >> > > Yeah, I'd suggested (yesterday): "The group will also document basic > requirements for IPv6 CPE", but yours is (IMO) better. > >> What do you want me to do? > > Nothing -- I specifically hadn't made the changes to the posted text, > because that would create a new version (04-02), and we would lose all > of the current ballots - seeing as we have 5 "Yes" and 5 "NoObj" that > would be sad. > > However, your proposed solution for Suresh involves adding a whole new > bullet point, which is (IMO) a significant enough change that it > probably makes sense for a new version to be pushed. I'll explain the > updates and assume that people will be happy to click the ballot > buttons again. Oh! I just made the edits and it did not lose the current ballots, so that's all good. I could have sworn that I'd seen the balloting get reset when others updated charters under discussion. > This is the first rechartering I've done, so I'm still feeling my way > around the process... As above :-) W > > W > > > >> >> >>> On Apr 25, 2017, at 1:03 PM, Deborah Brungard wrote: >>> >>> Deborah Brungard has entered the following ballot position for >>> charter-ietf-v6ops-04-01: Yes >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/charter-ietf-v6ops/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I still find that last sentence difficult to parse "issues and >>> opportunities from these shutdowns have resulted in >>> innovations in network operation" e.g. if take the first >>> part, "issues in shutdowns resulting in innovations in >>> network operation" is doublespeak. I don't think ops >>> folks see their issues with such rose-colored glasses. >>> And the sentence seems opposite of the charter of the >>> working group, e.g. item #1 and #2, as the charter is >>> about identifying operational issues. If issues resulted >>> in innovations, we wouldn't need this group:-) >>> >>> I'd suggest instead of "selling" the innovations of global >>> deployment in this sentence, rephrase it to be specific >>> on the charter goals. How about: >>> "An important aspect of IPv6 deployment has been the >>> operational issues with the shutdown of IPv4 networks >>> and operational interaction issues with IPv4 networks." >>> >>> >> > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Apr 26 08:07: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 9C9FF12EBDE for ; Wed, 26 Apr 2017 08:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 nOoJW_spyIot for ; Wed, 26 Apr 2017 08:06:58 -0700 (PDT) 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 316D812EBD7 for ; Wed, 26 Apr 2017 08:06:58 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1d3OWu-0000ETC; Wed, 26 Apr 2017 17:06:56 +0200 Message-Id: To: v6ops@ietf.org Cc: "C. M. Heard" From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com In-reply-to: Your message of "Wed, 26 Apr 2017 07:51:29 -0700 ." Date: Wed, 26 Apr 2017 17:06:55 +0200 Archived-At: Subject: Re: [v6ops] Destination options and denial of service attack X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:07:05 -0000 In your letter dated Wed, 26 Apr 2017 07:51:29 -0700 you wrote: >and the default SHOULD >be to accept all standard extension headers, including the Hop-by-Hop >Options header and the Destination Options header. That advice puts extensibility ahead of security. That's very rarely a good trade-off. So it wouldn't surprise me if most people will decide that it is perfectly reasonable to violate this SHOULD. From nobody Wed Apr 26 08:10: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 6699D12EC52 for ; Wed, 26 Apr 2017 08:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=kumari-net.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 H28iRZfbedkX for ; Wed, 26 Apr 2017 08:09:47 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 62AE012EC4A for ; Wed, 26 Apr 2017 08:09:47 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id m36so3167452qtb.0 for ; Wed, 26 Apr 2017 08:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ODH27WXn7uwNgrtlISgUZO9hAgYR+Gj46biQmNWSaQE=; b=CSsnBKNZKCYA/Ob6oFZp0KokzUlmumvJPeB/quq+dRVAjUvKgiK9yTvSfgBPcsfY2o Js8pK+6H+6nIaJ6VvSuOTsAloJWZ/svE6K6TTy3C4jEwFiz2QBE5Rmcl33OSiGGLwJtY /ZV72PkE9fnQBhD5UoJIqBZ+9vpQjF72hE6gi6ubCGB5h2A2akJWRviba3SPN5Va9eD8 2Y0LaxL2ocKeOVSYlBDyFFUijm5tF/oV/4a1RCse8BYP87GjJYVFGhmp/NH3RWbTl7lq pM3b/l2eEdRtBdUg4E8ncRPSUzhSUd/jPqQPM4dD/4KlOOOWiRaTFHMvjfEYn9BNR7++ GiEA== 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=ODH27WXn7uwNgrtlISgUZO9hAgYR+Gj46biQmNWSaQE=; b=RkpWbzyP/ngQnXayQT8o9d1vMctWrtJc3OR69KlDRJ0cGoQyT7cVrZb7oyuYW+dt4D 6lhq/YNFMj1kUTLKDRsAI97G/3bwc281NYFjLjxYxTF1Ek5semV2g7x68XSSa/zc3K2o 0FIYAfWpF/Uy636n2EpmOci/2LYZWIgnRvFcaNnrekOsae24rnJM/QrD3vqLEm2QSHg5 UQQtkeHCyUXyuThC7LwwmIztTla/bJtuR3qOlIYbbTlg0yJj14ESOMr+DIcEF6RpFsue 0jeeb4TkCoqhnWrW8oAx5v5/jOlsDr3NpXpmmOII9Q0iAI5IR1NRDf4mjiLqJHYmdbBI UryQ== X-Gm-Message-State: AN3rC/6ezDpdYGskHPKs9F+5NY9tNop4wVaJDwPwc9xW2xY3FhYa80fz DjAv7prU8PCgJQoXRp0kGqptGNPVmdwq X-Received: by 10.200.44.36 with SMTP id d33mr260921qta.51.1493219386129; Wed, 26 Apr 2017 08:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.164 with HTTP; Wed, 26 Apr 2017 08:09:05 -0700 (PDT) In-Reply-To: References: <149312753419.20766.14280373593100047269.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Wed, 26 Apr 2017 11:09:05 -0400 Message-ID: To: Suresh Krishnan Cc: The IESG , IPv6 Operations , V6ops Chairs Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:09:50 -0000 Fred suggested: 5. Document operational requirements for IPv6 networks. I just updated the charter text with this (and Ben's improvement ("IPv6 deployment has resulted in the shutdown of IPv4 in some networks. Removing IPv4 constraints has resulted in innovations in IPv6 network operations.")). Hopefully that addresses your comment -- it covers (IMO) CPE as well as other operational bits -- I could also make it something like: 5. Document operational requirements for IPv6 networks and CPE. W On Tue, Apr 25, 2017 at 1:45 PM, Warren Kumari wrote: > On Tue, Apr 25, 2017 at 9:38 AM, Suresh Krishnan > wrote: >> Suresh Krishnan has entered the following ballot position for >> charter-ietf-v6ops-04-01: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-v6ops/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I am highly supportive of this charter but I want to make sure that one >> item is addressed. v6ops has traditionally worked on CPE router >> requirements and I do not see any mention of this in the charter. I would >> like to see some verbiage added in this regard. >> >> > > Thank you. > > Good suggestion -- I tried to find a good place to add this. How about I add: > "The group will also document basic requirements for IPv6 CPE" to the > end of the "IPv6 operational and deployment issues with specific > protocols or > technologies... " paragraph? > > W > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Apr 26 10:35: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 4FFAE127843; Wed, 26 Apr 2017 10:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 VFhJWet6Yyuu; Wed, 26 Apr 2017 10:34:56 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::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 8552F131564; Wed, 26 Apr 2017 10:34:26 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id g12so950212wrg.2; Wed, 26 Apr 2017 10:34:26 -0700 (PDT) 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=IFrCe2eiZxItQ7KxNbE7r4kL3zAkis4DLxomPBE5g/M=; b=VXWZESuZ+x9lxmEkfbfqt0sSxG3H9uia2sd3dPV5mi3bTrqQ3e8sIjNGp+Q5n4hf83 NVrp4VwGvKbaLqxSTVZ7cIKrNmm5pBiZjmuxEyVdcEC7HrcjPKgM4taEEIUrip1Cac51 pSRpbXfVQKm4oxQ7V91jVG3YsfnG+L4LFcxo44otPX/pPpJobMdet1+mmDC9f3eQw00H CnvenY8+F5dDWG1yM3LRNG7lAIE/FmhawUW5YVKsxoefTLtZMm8w79M6U8PNgCvE5hwj 15NTb+CuxtUR1RadCq+gN3eg4okbMl2efli+KRvTZmybjMHLWqotOvUtlKQ7JiOSb87q NeeA== 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=IFrCe2eiZxItQ7KxNbE7r4kL3zAkis4DLxomPBE5g/M=; b=CS2Hb/djPQC7Eq6yuViVYHfy1mrvPfAMM92+2MvkZMvx2pmtQZPQQYkB4lJqKFswKW HvvSiI5ci4fXNdlEgRBBxtilqOEG9RX2Usb8Z5j7qCuDUpNoNbYB3SeF9MI3r/BA5Pmm PoTXTn3lgo/wdbAkKgEnFoqNtzCAha/ajo0pQz/4/p0i9Q5Nh95gaQFMRUvnFw8/2cE3 DjGIQkFpFKZ5OPI2BCe6PrYBmCdQmdieBH7mAmnnixAaK6U4h8VFLOHkzsO7NOthus3a GN0ekqagTHICaEr42f2V28GXm5l9nQIZQLkyMuVr3sPkVBRlR66abvMYmWjU2CLKT9sj +JBw== X-Gm-Message-State: AN3rC/7QveXm8XlxMcBSL8icAAIQiXHjR/gE4pQQiE7qxdTquTXj4YuK GrEdtzfuO5xvVbf7x8Q= X-Received: by 10.223.153.195 with SMTP id y61mr694701wrb.96.1493228064803; Wed, 26 Apr 2017 10:34:24 -0700 (PDT) Received: from 211.66.20.149.in-addr.arpa (211.66.20.149.in-addr.arpa. [149.20.66.211]) by smtp.gmail.com with ESMTPSA id l68sm1003826wrc.52.2017.04.26.10.34.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 10:34:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Wed, 26 Apr 2017 10:34:23 -0700 Cc: Suresh Krishnan , The IESG , IPv6 Operations , V6ops Chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <149312753419.20766.14280373593100047269.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:35:00 -0000 > On Apr 26, 2017, at 8:09 AM, Warren Kumari wrote: >=20 > 5. Document operational requirements for IPv6 networks and CPE. My opinion, which could be wrong, is the the network starts at the host = and extends to other hosts and services, and has a variety of = interconnected networks in between. The CPE is a specific node in that = graph, not special other than its place in business or security.=20= From nobody Wed Apr 26 13:50: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 CCF231294A5 for ; Wed, 26 Apr 2017 13:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 vxIc-a0-U8-a for ; Wed, 26 Apr 2017 13:50:47 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 3370F129464 for ; Wed, 26 Apr 2017 13:50:47 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c198so5692041pfc.1 for ; Wed, 26 Apr 2017 13:50:47 -0700 (PDT) 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=s7UON/5MCzKoa2zejvGh8xOL1liDPzSTH4PnPsWgKs0=; b=EBAJhSv0ihjfpO7o8ec+aPw0TquSSER3fj6/VYGRNkmBIY2WquXOge/+2UAx2XcjBB 5CnMUK10KzaF1fNOmfOy9KS/ULisoz834rZlniA9HOZaeD2CrKJJ1Ebgd3ISsT4aMNbg HAUEAWigg1BqmZdXWv9DgbEgB66x1nckH9ZsS9oTHRqkEjLLzw9JPd64tP0JQtsDUxKm 8wjmo0PtHUzKBVVG41ncbJUGsa72VXgTMGPv/Z07ndtGB6ULFF0jtnz8oW8X7XNubfD0 9zGHBlFZJOLUTwNMuStIXOySwMtPrurdgAPeIc4InTbonPTHBrp74RZCfvjFNlD63Eue lEVw== 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=s7UON/5MCzKoa2zejvGh8xOL1liDPzSTH4PnPsWgKs0=; b=SVerS3/2KQv+KhbsTGxsODavpI8R0y3CiNkmKTBlAGkbiQiLPsUs4ukzOQkjCJZhTJ VqA5cMLoDko/u2KPBd1PJ0mZYopqMnGVCLWJ4aIb7Owr6WUpIl2EQwk9YgvXmVrQs5UX drVqQe3lCvyw3AwX1WtFllnetkkfekycPo1TG/oYCc5SjX9Qn9yvOhQFyMLr60NMtKR3 YA3H0HADrirYviEjSmIEC3scBY6S10tvjKwHZ/0LnqjUxKGP6FR8tFQluwzQ/QluDU/A IlB9YmbjZxhrPAWLQd+4wRflowKgDdE4FaclrIuzhfIv+YveOAmAXkuTYZ1lkq1b7nya Cqiw== X-Gm-Message-State: AN3rC/7dBNuN7kuAeJjKEk4OnhHUOdzUncVKP4ZPthUKanUYTUxwBQXn +Y5WVyZANmyD0p7c X-Received: by 10.84.214.22 with SMTP id h22mr2336429pli.96.1493239846688; Wed, 26 Apr 2017 13:50:46 -0700 (PDT) Received: from [192.168.178.21] ([118.149.100.28]) by smtp.gmail.com with ESMTPSA id d83sm340238pfe.40.2017.04.26.13.50.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 13:50:46 -0700 (PDT) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <5975bd0d-213a-821a-957e-c567312eef38@gmail.com> Date: Thu, 27 Apr 2017 08:50:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Destination options and denial of service attack X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:50:49 -0000 On 27/04/2017 03:06, Philip Homburg wrote: > In your letter dated Wed, 26 Apr 2017 07:51:29 -0700 you wrote: >> and the default SHOULD >> be to accept all standard extension headers, including the Hop-by-Hop >> Options header and the Destination Options header. > > That advice puts extensibility ahead of security. That's very rarely a good > trade-off. That is a very debatable opinion. In any case, this is *exactly* why RFC7045 is written the way it is - make this a configurable choice per extension header, with reasonable default settings. (Also see the recent draft-ietf-opsec-ipv6-eh-filtering discussion.) > So it wouldn't surprise me if most people will decide that it is > perfectly reasonable to violate this SHOULD. Again, RFC7045. None of which adresses Tom's issue. Brian From nobody Wed Apr 26 15:24:06 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 228371292D0; Wed, 26 Apr 2017 15:23:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: v6ops-chairs@ietf.org, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149324543804.2903.16576417261346249231.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 15:23:58 -0700 Archived-At: Subject: [v6ops] Adam Roach's No Objection on charter-ietf-v6ops-04-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:23:58 -0000 Adam Roach has entered the following ballot position for charter-ietf-v6ops-04-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- On the issue about whether to rewrite or omit the text regarding innovations resulting from v4 shutdown -- I agree with Deborah's position here that this kind of spin seems awkwardly out of place in the charter, and is unrelated to the work the WG will be taking on. My preference would be removing it. From nobody Thu Apr 27 08:00: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 20B64129AFA; Thu, 27 Apr 2017 08:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KAXO99Z9hpTE; Thu, 27 Apr 2017 08:00:13 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 A29B9129AE3; Thu, 27 Apr 2017 07:59:13 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id g60so28156478qtd.3; Thu, 27 Apr 2017 07:59:13 -0700 (PDT) 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=9a2zLwbifz7rchrXhtSP2DDI3zv3y1Qdso48AH/SQWA=; b=ul89nyEBnpE0hQRRtlfzngVBln/naeuORDK0r4lrTtawwsIhXxkfqDbFDWtlRJWQ+A u3ARYXhHucwMAvp2PdFX+RO23uhlO451/cppWgRe6CM4Q8n7KEe3EZhBk7n2Wcj90zgV nEZsYJ2fBOHLgDX742Lsyct90S9BB8vcIxEfBgLou5U0zXreop2bRgGlfE8xAUKuqIxn 7noBzZUx/jYoG1Dk/TT5QA+wkwspjgopGhxjpR7nCQRKzurNRJum1pp9ON69BzTF/jUj 2UWmO78yisveQlEE14z/32N86NWNB9mY4SWr1wF/25YocX6RGp1ub6Oe/fKQNHiMuora xFBA== 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=9a2zLwbifz7rchrXhtSP2DDI3zv3y1Qdso48AH/SQWA=; b=pvRkAN9PAen2CQEgGko+CwByQVvTSmhB8Ck2pCtbBElOvbgar39h51ybF87LHMutPC rXE0DutukR7G5J49CiUnNzG0BWsyH9pZCK/C6Fjks5swtV4pirnNnQEssM20A9Wofp5o YicaRuETAORxmHCAgKxqZ/rHUu6/ceiSM6RAVnOgc/WlNrOhIs8MHConOdg5V0nRL7Dt i9s55elC/rBr1uMkpm7YCilJtIcLxz9BCYt1TxSXMBRLTkFYfsJIFsm/mgbjGpcFzdzr 9dQnN8E+/yMG0LBLlQeu2nWrIOSw2Ju9MH8T9lvCfdTYyuqszZKXMEp0Ur5EVmlEB/ec q/mg== X-Gm-Message-State: AN3rC/7j/bIVvrQ+SYMkkqYasPfc1v61saw/pMemw3ZaGdDBAUyEs4Dx 3UaqblopQTyEMe3eC0g+T/nxwZAM+Q== X-Received: by 10.200.35.27 with SMTP id a27mr5417470qta.2.1493305152624; Thu, 27 Apr 2017 07:59:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.166.130 with HTTP; Thu, 27 Apr 2017 07:59:12 -0700 (PDT) In-Reply-To: References: <149312753419.20766.14280373593100047269.idtracker@ietfa.amsl.com> From: Suresh Krishnan Date: Thu, 27 Apr 2017 10:59:12 -0400 Message-ID: To: Fred Baker Cc: Warren Kumari , The IESG , IPv6 Operations , V6ops Chairs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Yes on charter-ietf-v6ops-04-01: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:00:24 -0000 Hi Fred/Warren, I am happy with either. Thanks Suresh On Wed, Apr 26, 2017 at 1:34 PM, Fred Baker wrot= e: > >> On Apr 26, 2017, at 8:09 AM, Warren Kumari wrote: >> >> 5. Document operational requirements for IPv6 networks and CPE. > > My opinion, which could be wrong, is the the network starts at the host a= nd extends to other hosts and services, and has a variety of interconnected= networks in between. The CPE is a specific node in that graph, not special= other than its place in business or security. From nobody Fri Apr 28 05:54: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 DB0B6124D37 for ; Fri, 28 Apr 2017 05:54:38 -0700 (PDT) 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 1XsA2q8sD5so for ; Fri, 28 Apr 2017 05:54:37 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 87E9F12EAA8 for ; Fri, 28 Apr 2017 05:50:58 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id u65so41390782wmu.1 for ; Fri, 28 Apr 2017 05:50:58 -0700 (PDT) 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=prm2FRPOPYeqJcjpxvEY4Wl40KmqIGRfvJB/8SGxBF8=; b=I4Fv5ZD0O7FOLHuovUCYi/b4pDfQ9iFxtV3jRKZrN/9k8dfNFP8wT7FgqASjuhpL63 jyv0BbsvCU1FxmRkhUr2RSwj2qinlaFZTjmTu3Pp2y4p+uIardL6Pb9xqVYryfvnyxfh eLtGFEXMGT0qMGVpI0hYPwlWKQnacoCwxCxmrJ11l1JkTelT6bjr6vG/fzqP6U4AhLQv KqUWbYJcuoO8iMT152xBj63bqzdknl1hdTb7AKTz9K8VR69p4H0A4k6/0rlTnYItIZTV o+qAyZeKo9iYvmMGu+oIHZC2M0mF4+tPJ7fdqHKRqqjOjrWk7VhY1nA26zaYrtqPwI+6 By/A== 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=prm2FRPOPYeqJcjpxvEY4Wl40KmqIGRfvJB/8SGxBF8=; b=olfina2mmQ1w0G4ivSaKCmiulQ5Ib6IZn0vR9djrgoiofxm3QHx7sGilZKwHIBZKBZ 7dkjPq1mstfVunvxkBOs/lWVakG7JYV6vp8x6LLnDfOjOrKnlt5xkzOhzsbtCtVO0pQV PzD653rTtwZImb7CNFm7dULMHj5eYlqYBBm2xYVYVoYVjykKn5JEY/5HaqnNui77OJt0 CDd8cjptrqb9SPtIIE9T3jr5e0zf3iSuBvtVmY4o3fjYc+PoQDPQl13zoe7iwdiVmJlC JYmvTMHHvzC/TgNXHO6PzFyo+LMRcq217S8o0OpIMQHlSXkvvw/lTjPYFQjcp/qEOGDn bbag== X-Gm-Message-State: AN3rC/6KJSt6EB1wYnrmfnuCjOfB+P7GTTWSGEfHdzb6wi5Zfb8dXLQy g0hp6KmcFtFpn7oH+9E= X-Received: by 10.28.37.4 with SMTP id l4mr5751655wml.100.1493383856990; Fri, 28 Apr 2017 05:50:56 -0700 (PDT) Received: from 205.66.20.149.in-addr.arpa (205.66.20.149.in-addr.arpa. [149.20.66.205]) by smtp.gmail.com with ESMTPSA id a5sm5153210wma.28.2017.04.28.05.50.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 05:50:56 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <47F6DC23-1D05-4DC7-BD6C-363E61B11435@gmail.com> Date: Fri, 28 Apr 2017 05:50:53 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] State of play in v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 12:54:39 -0000 WG: Unupdated WG Document 2017-03-13 draft-ietf-v6ops-ula-usage-considerations 2016-11-13 draft-ietf-v6ops-design-choices WG: Updated WG Document 2017-04-12 draft-ietf-v6ops-rfc7084-bis 2017-04-10 draft-ietf-v6ops-rfc6555bis WG: WG Consensus: Waiting for Write-Up 2017-04-25 draft-ietf-v6ops-v4v6-xlat-prefix 2017-04-11 draft-ietf-v6ops-unique-ipv6-prefix-per-host Individual Submission: Unupdated=20 2017-03-27 draft-templin-v6ops-pdhost 2017-03-13 draft-gont-v6ops-host-configuration 2017-03-13 draft-petrescu-v6ops-ipv6-power-ipv4 2017-02-24 draft-shi-v6ops-caba 2017-02-18 draft-ali-ipv6rtr-reqs 2017-01-28 draft-xli-v6ops-cernet-deployment The authors tell me that draft-ali-ipv6rtr-reqs will be refiled as the = working group draft draft-ietf-v6ops-ipv6rtr-reqs next week.= From nobody Fri Apr 28 09:17:40 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 202F612EB5D; Fri, 28 Apr 2017 09:17:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , v6ops@ietf.org, v6ops-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149339625012.2979.13024303398972922004.idtracker@ietfa.amsl.com> Date: Fri, 28 Apr 2017 09:17:30 -0700 Archived-At: Subject: [v6ops] WG Action: Rechartered IPv6 Operations (v6ops) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 16:17:30 -0000 The IPv6 Operations (v6ops) WG in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. IPv6 Operations (v6ops) ----------------------------------------------------------------------- Current status: Active WG Chairs: Lee Howard Fred Baker Ron Bonica Assigned Area Director: Warren Kumari Operations and Management Area Directors: Warren Kumari Benoit Claise Mailing list: Address: v6ops@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/v6ops Archive: https://mailarchive.ietf.org/arch/browse/v6ops/ Group page: https://datatracker.ietf.org/group/v6ops/ Charter: https://datatracker.ietf.org/doc/charter-ietf-v6ops/ The global deployment of IPv6 is underway, creating an Internet consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and IPv6+translation networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks, ensuring addressing and connectivity for all IPv4 and IPv6 nodes. IPv6 deployment has resulted in the shutdown of IPv4 in some networks. Removing IPv4 constraints has resulted in innovations in IPv6 network operations. The IPv6 Operations Working Group (v6ops) develops guidelines for the deployment and operation of new and existing IPv6 networks. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with IPv6 networks, and determine solutions or workarounds to those issues. 2. Solicit input from network operators and users to identify operational interaction issues with the IPv4 networks, and determine solutions or workarounds to those issues. 3. Solicit discussion and documentation of the issues and opportunities in IPv6-only operation, and of the resulting innovations. 4. Operational solutions for identified issues should be developed in v6ops and documented in informational or BCP drafts. 5. Document operational requirements for IPv6 networks. These documents should document IPv6 operational experience, including interactions with IPv4, in dual stack networks, IPv6 networks with IPv4 delivered as an overlay or translation service, or IPv6-only networks. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Future work items within this scope will be adopted by the Working Group only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. Milestones: Jul 2017 - Describe routing choices and trade-offs for enterprise and service provider networks Jul 2017 - File recommendation on how to build a commercial WiFi network Nov 2017 - Prefix for use by IPv4/IPv6 translators in a network Nov 2017 - Advice on use of ULAs in networks Nov 2017 - Update RFC 7084 (IPv6 CE Requirements) Nov 2017 - Update RFC 6555 with experience Nov 2017 - Requirements for IPv6 Routers in a general purpose network From nobody Sat Apr 29 23:45: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 634181294FD for ; Sat, 29 Apr 2017 23:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 qpw95_Jl49Gk for ; Sat, 29 Apr 2017 23:45:06 -0700 (PDT) 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 B3D9E129AB7 for ; Sat, 29 Apr 2017 23:43:08 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id q66so20372172pfi.3 for ; Sat, 29 Apr 2017 23:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=GtcOy9KSsHaUzXlSX8BtaGWT/pdSo24/We7JCQoQptw=; b=CCR/IKk6zJVj9+qKehXVBzkqxQnG5j1PLUWlbnqW48Q+W2jXxVl4Sag1sKu7gQ4uge uk98pSReEurg2/Fr6ZXuVrTxQ2fmqEKCt61ZjUzYwN1w9IB+DahwZ2V6uO8db6sTrDC/ kOkA4pmpNdT/PrTG18w+hoZVbgdd4yKhpd13ndoP3tt31a8PG4X934dnym1zWOs1BOui j6ikuoVtAkYoy7LqNSu4Gz2WQgdQQCE0wMuX5dVddN14/NW3Huqj9i1P2zYmEg5jBiP8 RUmRJs7WxAyZ599fqbg0Dx6oDb7aamGCV974zmeWRcFVlAiz4DzofNOBjwI4Ty6ETy4k SsQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=GtcOy9KSsHaUzXlSX8BtaGWT/pdSo24/We7JCQoQptw=; b=fvSk3A8BTlBZDszM9aMlVTm/U65oUjWhmCmj0/LmQ6Xxo1Ghdn5DIn/eZLiZyYCB1C kHI5Qk1VptZk3Ys/AUce4LXG0EL2/fURL921Qzd0bapy+83dfDechAi2EE7jPvVB3cHa 7BEIl7fYGWPW9d0+GjJ+rsNGQxZQB80jPSsRKZP8dCvYy+6KcJDXVoOYDi368sNA6az/ jgMjkXok2kBt23xFl2DaiTFBDXqz7eL7mItGvOcS8d3iFykk3l6gJAcXkt/4J/8jQ7oy N87R63uAmOdFfMd9nKUcXpNWXa6SRXY39S4gGBXwluFPB/Y4Z2Vge55II6wXCnAarCt+ cFvw== X-Gm-Message-State: AN3rC/7GIbsSEKLbskhJv+BZr0Pvgxi2+Nq79/HVB/FELfh4hfPRDn1u OXk4qahXWwylMoPHh/I= X-Received: by 10.84.236.79 with SMTP id h15mr25965319pln.110.1493534588025; Sat, 29 Apr 2017 23:43:08 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id k69sm17037036pfb.43.2017.04.29.23.43.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Apr 2017 23:43:07 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_7D8579D0-4018-4DE0-A435-0352EF8634DB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <9D598DD3-53BB-4C72-A89F-52299ABFF39B@gmail.com> References: To: IPv6 Operations Date: Sat, 29 Apr 2017 23:43:05 -0700 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: Proposed revised Extension Header text for rfc2460bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 06:45:09 -0000 --Apple-Mail=_7D8579D0-4018-4DE0-A435-0352EF8634DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I sent this to 6man, but v6ops might be interested as well. > From: Fred Baker > Subject: Re: Proposed revised Extension Header text for rfc2460bis > Date: April 29, 2017 at 11:40:20 PM PDT > To: Mark Smith , Robert Raszuk = > Cc: 6man WG >=20 > On Apr 29, 2017, at 8:07 PM, Mark Smith = wrote: >> On Apr 29, 2017, at 6:45 PM, Robert Raszuk wrote: >>> Maybe it is time to open the windows and ask yourself why IPv6 = deployment for end consumers is really not happening (except very local = markets like Japan). Maybe IPv6 did not come with suficient reason to be = deployed ??? >>=20 >> You're out of touch with IPv6 deployment status. >=20 > Robert, you might be interested to poke around on the current status = of IPv6 deployment. Here are 36 countries, of which Google says that 5% = or more of the traffic from them uses IPv6. Consider the implications of = that, if you would; it means that someone had a computer that was = attached to a network attached to an ISP attached to another ISP that = went to Google to a computer, and every step along the way IPv6 was = deployed and working, end to end.=20 >=20 > = https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe,us= ,gr,de,ch,lu,in,br,ee,ca,ec,jp,gb,pt,my,fr,tt,no,fi,pe,au,cz,nz,nl,ie,ro,h= u,si,zw,gt,pr,kr,vn,sa,at,ax,pl >=20 > That includes countries on every continent, including Zimbabwe in = Africa, six Latin American countries, Saudi Arabia, Malaysia, and India. = And, oh yes, Japan. And the US. >=20 > Heck, look at Trinidad and Tobago, a Small Island State in the = Caribbean, someone that the UN considers to be seriously back woods. = Google says that 15% of the sessions they have in T&T use IPv6, and = Akamai says that 20% of the traffic they deliver there uses IPv6. This = isn't just the big countries, or the well-connected ones. >=20 > https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dtt > https://www.vyncke.org/ipv6status/project.php?metric=3Dk&country=3Dtt >=20 > At F Root, about 11% of our DNS accesses come in IPv6 packets. >=20 > http://rssac-stats.isc.org/rssac002/2017 >=20 > Several companies are taking serious steps toward turning IPv4 off, or = have already done so. Where is IPv6 dominant? The Mobile networks are = among the biggest there. >=20 > https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft > https://blog.apnic.net/2017/02/02/addressing-in-2016 > = https://blog.apnic.net/2017/02/07/reliance-jio-boosts-india-past-20-ipv6-c= apability > = https://code.facebook.com/posts/635645183305089/legacy-support-on-ipv6-onl= y-infra > = https://conference.apnic.net/data/37/464xlat-apricot-2014_1393236641.pdf=20= > = https://www.apnic.net/wp-content/uploads/2017/01/vzw_apnic_13462152832-2.p= df >=20 > Performance issues that were there historically, largely due to = substandard routing, are a bad memory. > https://blog.apnic.net/2016/08/22/ipv6-performance-revisited >=20 > You might be interested in Uber's viewpoint. >=20 > https://eng.uber.com/ipv6 >=20 > "Having deployment problems" isn't a very accurate statement. >=20 > It is fair to say that the deployment started slowly. It started in = 2006, with ICANN ratifying a policy for the allocation of IPv6 prefixes, = and the limited-IPv6-capability Windows Vista release in the same year = (other platforms all had it, Windows was the laggard, and killing off = Windows XP has been an quest worthy of Arthur). By 2009, 4000 prefixes = had been allocated world-wide. IPv4 exhaustion at IANA was predicted, = although there was a lot of discussion between Geoff and Tony, and = finally happened in January 2011. April 2011, APNIC entered their final = phase of IPv4 allocation (by policy, they now only allocate a /22 to a = new member, and none at all to existing members), and at this point all = five RIRs are in their final phase of IPv4 allocation. The IPv4 Market = Group says that they expect the price of an IPv4 address, which right = now varies between about $6 and $15 per address depending on the block = size, to start to decline in 2019, because at that point more than half = of the users in the world will have functional IPv6 capabilities and it = will be in corporate interest to look forward rather than back. Swisscom = says that by 2024 they expect they won't have enough IPv4 traffic to = justify continuing to route it. >=20 > https://www.icann.org/news/announcement-2006-09-11-en > https://www.oecd.org/sti/ieconomy/44961688.pdf slide 16 > https://ipv4.potaroo.net/ > http://ipv4marketgroup.com/ipv4-pricing-in-a-post-arin-runout-world > http://ipv4marketgroup.com/q42016-update > = http://www.ipv6conference.ch/wp-content/uploads/2015/06/B10-Swisscom-Statu= s_Roadmap_and_Outlook_IPv6.pdf >=20 > In other words, it didn't start until the IPv4 address space became = exhausted at IANA and the relevant RIRs, which was 100% predictable. At = this point, smart companies are starting to use the speculative asset of = IPv4 address space to finance their IPv6 deployment, and some companies = are starting to charge for IPv4 address space while leaving IPv6 free. >=20 > https://gist.github.com/simonster/e22e50cd52b7dffcf5a4db2b8ea4cce0 > = http://www.networkworld.com/article/3191503/internet/mit-selling-8-million= -coveted-ipv4-addresses-amazon-a-buyer.html > https://www.mythic-beasts.com/order/vps >=20 > If you are on a major broadband service in the US and don't have IPv6 = in your home (go to http://www.kame.net, and see if the turtle dances), = ask your provider about it. There's a good chance the issue is at your = residential router. >=20 > You're welcome to your opinions of IPv6; if it were mine to do over = there are some things I might change. But it is what it is, and it's out = there. Get used to it. Resistance, as they say, is futile. --Apple-Mail=_7D8579D0-4018-4DE0-A435-0352EF8634DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I sent this to 6man, but v6ops might be interested as = well.

From: Fred Baker <fredbaker.ietf@gmail.com>
Subject: = Re: Proposed = revised Extension Header text for rfc2460bis
Date: = April 29, 2017 at 11:40:20 PM = PDT
To: = Mark Smith <markzzzsmith@gmail.com>, Robert Raszuk <robert@raszuk.net>
Cc: = 6man WG <ipv6@ietf.org>

On = Apr 29, 2017, at 8:07 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
On Apr 29, 2017, at 6:45 PM, Robert Raszuk = <robert@raszuk.net> wrote:
Maybe it is time to open the windows and ask = yourself why IPv6 deployment for end consumers is really not happening = (except very local markets like Japan). Maybe IPv6 did not come with = suficient reason to be deployed ???

You're out of touch with IPv6 deployment status.

Robert, you might be interested = to poke around on the current status of IPv6 deployment. Here are 36 = countries, of which Google says that 5% or more of the traffic from them = uses IPv6. Consider the implications of that, if you would; it means = that someone had a computer that was attached to a network attached to = an ISP attached to another ISP that went to Google to a computer, and = every step along the way IPv6 was deployed and working, end to end.

https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&co= untries=3Dbe,us,gr,de,ch,lu,in,br,ee,ca,ec,jp,gb,pt,my,fr,tt,no,fi,pe,au,c= z,nz,nl,ie,ro,hu,si,zw,gt,pr,kr,vn,sa,at,ax,pl

That includes countries on every continent, including = Zimbabwe in Africa, six Latin American countries, Saudi Arabia, = Malaysia, and India. And, oh yes, Japan. And the US.

Heck, look at Trinidad and Tobago, a Small Island State in = the Caribbean, someone that the UN considers to be seriously back woods. = Google says that 15% of the sessions they have in T&T use IPv6, and = Akamai says that 20% of the traffic they deliver there uses IPv6. This = isn't just the big countries, or the well-connected ones.

https://www.vyncke.org/ipv6status/project.php?metric=3Dp&co= untry=3Dtt
https://www.vyncke.org/ipv6status/project.php?metric=3Dk&co= untry=3Dtt

At F Root, about 11% of our DNS = accesses come in IPv6 packets.

http://rssac-stats.isc.org/rssac002/2017

Several companies are taking serious steps toward turning = IPv4 off, or have already done so. Where is IPv6 dominant? The Mobile = networks are among the biggest there.

https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft
https://blog.apnic.net/2017/02/02/addressing-in-2016
https://blog.apnic.net/2017/02/07/reliance-jio-boosts-india-pas= t-20-ipv6-capability
https://code.facebook.com/posts/635645183305089/legacy-support-= on-ipv6-only-infra
https://conference.apnic.net/data/37/464xlat-apricot-2014_13932= 36641.pdf
https://www.apnic.net/wp-content/uploads/2017/01/vzw_apnic_1346= 2152832-2.pdf

Performance issues that were = there historically, largely due to substandard routing, are a bad = memory.
https://blog.apnic.net/2016/08/22/ipv6-performance-revisited
You might be interested in Uber's = viewpoint.

https://eng.uber.com/ipv6

"Having deployment problems" isn't a very = accurate statement.

It is fair to say that = the deployment started slowly. It started in 2006, with ICANN ratifying = a policy for the allocation of IPv6 prefixes, and the = limited-IPv6-capability Windows Vista release in the same year (other = platforms all had it, Windows was the laggard, and killing off Windows = XP has been an quest worthy of Arthur). By 2009, 4000 prefixes had been = allocated world-wide. IPv4 exhaustion at IANA was predicted, although = there was a lot of discussion between Geoff and Tony, and finally = happened in January 2011. April 2011, APNIC entered their final phase of = IPv4 allocation (by policy, they now only allocate a /22 to a new = member, and none at all to existing members), and at this point all five = RIRs are in their final phase of IPv4 allocation. The IPv4 Market Group = says that they expect the price of an IPv4 address, which right now = varies between about $6 and $15 per address depending on the block size, = to start to decline in 2019, because at that point more than half of the = users in the world will have functional IPv6 capabilities and it will be = in corporate interest to look forward rather than back. Swisscom says = that by 2024 they expect they won't have enough IPv4 traffic to justify = continuing to route it.

https://www.icann.org/news/announcement-2006-09-11-en
https://www.oecd.org/sti/ieconomy/44961688.pdf slide 16
https://ipv4.potaroo.net/
http://ipv4marketgroup.com/ipv4-pricing-in-a-post-arin-runout-w= orld
http://ipv4marketgroup.com/q42016-update
http://www.ipv6conference.ch/wp-content/uploads/2015/06/B10-Swi= sscom-Status_Roadmap_and_Outlook_IPv6.pdf

In = other words, it didn't start until the IPv4 address space became = exhausted at IANA and the relevant RIRs, which was 100% predictable. At = this point, smart companies are starting to use the speculative asset of = IPv4 address space to finance their IPv6 deployment, and some companies = are starting to charge for IPv4 address space while leaving IPv6 = free.

https://gist.github.com/simonster/e22e50cd52b7dffcf5a4db2b8ea4c= ce0
http://www.networkworld.com/article/3191503/internet/mit-sellin= g-8-million-coveted-ipv4-addresses-amazon-a-buyer.html
https://www.mythic-beasts.com/order/vps

If you are on a major broadband service in the US and don't = have IPv6 in your home (go to http://www.kame.net, and see if the turtle = dances), ask your provider about it. There's a good chance the issue is = at your residential router.

You're welcome = to your opinions of IPv6; if it were mine to do over there are some = things I might change. But it is what it is, and it's out there. Get = used to it. Resistance, as they say, is = futile.

= --Apple-Mail=_7D8579D0-4018-4DE0-A435-0352EF8634DB-- From nobody Sun Apr 30 18:57: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 D85E5129A99 for ; Sun, 30 Apr 2017 18:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 l6nb0atXW47E for ; Sun, 30 Apr 2017 18:57:43 -0700 (PDT) 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 224641294D3 for ; Sun, 30 Apr 2017 18:55:21 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id y4so34440980pge.0 for ; Sun, 30 Apr 2017 18:55:21 -0700 (PDT) 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=E5SNWjZmQZfeneFrHNE2QQDIhrfjDFlTjVdfivivLWM=; b=qHhbmYwGr/sOWwn1NydxYSCH1a4DvfT0v8y/lZKNA79f7SPAO8KbtB7J5ZMvm8/EbS oryexqFHw3gCTrRrjd5iET22GrT4kPeitr7RfhimRfew2dXOQIOkYH/YOdAcOMlS1qKQ k0yLJRwF6+2ag365BsBFRiqcS33pU7GSKd1yWxmnwXs4M1yOtnjt13bp5nqXx8BcWVmD Xbe4BAycaL/aQmuLzU41HbiciIs8IJagwPEoADjwkd0qQnoBLaMwb6ci46EeBuuPRGSk 7/3+e9FWI1Y78NlYvVPvDEyB5/yz3Rki2laMYVsV19IwXPM1WFyzAyK9OLehnLAYZqRm pp/g== 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=E5SNWjZmQZfeneFrHNE2QQDIhrfjDFlTjVdfivivLWM=; b=J20LgDhlg6MK/S1f2YoGGFMAzCs8Tw1SC5RgSxLdn/lt/KolLTa8+E+IWG4gbD8UCu wu/hqEFXb+vcY+D4NBVtgwpekOeiJ4UGqoF/kwAnBTJDdhNqpbKZb+/5G8NLSJqI+zjy 6nGFYDq36ACFV3pdmI5AX8uNPVJCYzwZMk4IpmIaVWoOaEIFh0ry+xFsbwjaCRUFzn1b i0Zh4MYoWzD9xjs9hAXB0LyIoUhrjYQBf3MHml3FcX3TgH2KLcPjc816xntT0AY7XMj9 hcyxKN0u9ck864J/Fs8XFJ3Nuz3/BdPbcHyl+cg4cxxPOIQeq/LhV7cq75P8z77djh+R AhCg== X-Gm-Message-State: AN3rC/76HahcaF06tgQ6SbzBd6J0bnD37hggQ02WU1F5jDMtYa74c86/ NVtQ7jMxC5pao4il4yI= X-Received: by 10.84.196.100 with SMTP id k91mr30943691pld.165.1493603720419; Sun, 30 Apr 2017 18:55:20 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id 25sm22130141pfr.61.2017.04.30.18.55.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Apr 2017 18:55:19 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <5149F9F2-5E83-42E1-9852-4CB593F3823F@gmail.com> Date: Sun, 30 Apr 2017 18:55:18 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 01:57:45 -0000 Just before IETF 98, Bing updated = draft-ietf-v6ops-ula-usage-considerations. If you look through the diffs = (https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ula-usage-consider= ations-02.txt), you will see that he has put a fair bit of effort into = this and responded to several comments made on the document in the past. Could I get a couple of people to review this and post to the list, = please? I'd especially like to hear from people that are using ULAs, for = example in Cable and Mobile networks.=