From nobody Wed Feb 1 03:16: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 3D6BB128BA2 for ; Wed, 1 Feb 2017 03:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZROc_zNMPYR for ; Wed, 1 Feb 2017 03:16:32 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 17D54129CF0 for ; Wed, 1 Feb 2017 03:16:26 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cYstk-0000GiC; Wed, 1 Feb 2017 12:16:24 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <4cbc3c52-504f-7282-3e74-75772aa59094@gmail.com > In-reply-to: Your message of "Wed, 1 Feb 2017 08:23:05 +1300 ." <4cbc3c52-504f-7282-3e74-75772aa59094@gmail.com> Date: Wed, 01 Feb 2017 12:16:23 +0100 Archived-At: Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 11:16:34 -0000 In your letter dated Wed, 1 Feb 2017 08:23:05 +1300 you wrote: >On 01/02/2017 07:36, Philip Homburg wrote: >... >> So realistically, every environment should run both RA and DHCP[v6]. > >It seems to me that there are plenty of running proofs that this >is not true. What I see is that in plenty of cases, a host gets quite a few more parameters from DHCPv4 than from IPv6 equivalents. If you know a write up of a largish organisation that is IPv6-only and doesn't use DHCPv6 anywhere, then I'd like to know. Did they ever provide hosts with hostnames and what do they do now? For example, did they ever use PXE boot and what do they use now? Do they run ntp servers in house and if so, how do they inform hosts about them? I seem to remember that Windows put some parameters in DHCP, but maybe that's thing of the past. From nobody Wed Feb 1 11:06: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 AA94D129532 for ; Wed, 1 Feb 2017 11:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 G9pAeWKb3ywK for ; Wed, 1 Feb 2017 11:06:49 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7E012954A for ; Wed, 1 Feb 2017 11:06:49 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id 194so111322400pgd.2 for ; Wed, 01 Feb 2017 11:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2DpNm9UpY6KSBpy7PjRc/yPS3X7f5MFWt0JJmXXt/tE=; b=enIys+4gifwtSSnL7VEXMahoxEFVr6zkr3z4iNJB/dXjf23KkOQtKFW+gs+oBI7ZcL FN8rdc8ZixT+rByaAr5dZevdRNRH7W9VifslYd9lgOv8a8RVvEyLJHyBAnduKsfr7fmq ihK0A2YwM+YJO6Red2hzkJYPJqEKmWOWN9kKthyNH0F9M86+KNEhDBIA6ntqXArrhLh/ a6+j/lKLDdwHqSsSi5q2pAIoag16bL1AL5boQPqEPuqy++BHJ76mQ8fi9Bupo8oD4U+9 P9daXsebaO6YlEKrseuldkp1LUweClbHCprN+HiQeyMrAx39gsftW1Shr4wwSt60pIt1 AEOg== 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=2DpNm9UpY6KSBpy7PjRc/yPS3X7f5MFWt0JJmXXt/tE=; b=RdLVIdsEajlN2HI5YupsgsygIBaKAw9mHx6BdhGuX9jQzVH4bE76Y658w0kNUYvQ6q iUWHYTUoW8rgRbJnMKn3Ewcwx4TJx+zmgg487rE7ZfMmf2VHUIadS6kj7xtzCQ6M08qC DTKcrA2wbjiIqUURokI9INe7GvpXQTUXRmtRTzl7RAxUy2YHu5Wk6UdfNXpmcmHbE90C v4LjlnI1B+ZYNiYnuCM0FDPqGdNXVOIDGwtZc0BsqpJQbn1ra78X4OJqrSX6UnIi2QwQ Ip843wTFjxYJcZk+XPw0kr0ZcrtPuHq+qqKB3zuIG/BvIHMlIpeTNesu9fd+EvoNPFfi mQtQ== X-Gm-Message-State: AIkVDXIT9EBboCR3xVrT4UiwMkvILGiiO1Nhzcns/Vn+9JGeRTLdQAKb5kAaPflNsPXnGA== X-Received: by 10.84.217.68 with SMTP id e4mr6522212plj.99.1485976008470; Wed, 01 Feb 2017 11:06:48 -0800 (PST) Received: from [192.168.178.21] ([118.148.120.107]) by smtp.gmail.com with ESMTPSA id f191sm52043376pgc.12.2017.02.01.11.06.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 11:06:47 -0800 (PST) To: Philip Homburg , v6ops@ietf.org References: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <4cbc3c52-504f-7282-3e74-75772aa59094@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <01b6f842-7f6f-b5f0-3e51-c417f0d88a7f@gmail.com> Date: Thu, 2 Feb 2017 08:06:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:06:51 -0000 On 02/02/2017 00:16, Philip Homburg wrote: > In your letter dated Wed, 1 Feb 2017 08:23:05 +1300 you wrote: >> On 01/02/2017 07:36, Philip Homburg wrote: >> ... >>> So realistically, every environment should run both RA and DHCP[v6]. >> >> It seems to me that there are plenty of running proofs that this >> is not true. > > What I see is that in plenty of cases, a host gets quite a few more parameters > from DHCPv4 than from IPv6 equivalents. > > If you know a write up of a largish organisation that is IPv6-only and > doesn't use DHCPv6 anywhere, then I'd like to know. I don't. But then, I think that being IPv6-only is not very appealing for the next ten or twenty years. Of course, I've been a true believer in dual stacks since 1994. Brian > > Did they ever provide hosts with hostnames and what do they do now? > > For example, did they ever use PXE boot and what do they use now? > > Do they run ntp servers in house and if so, how do they inform hosts about > them? > > I seem to remember that Windows put some parameters in DHCP, but maybe that's > thing of the past. > From nobody Wed Feb 1 11: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 25F74129565 for ; Wed, 1 Feb 2017 11:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB_8LJWNevsJ for ; Wed, 1 Feb 2017 11:10:10 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B454C12954A for ; Wed, 1 Feb 2017 11:10:10 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id 3so52707899pgj.3 for ; Wed, 01 Feb 2017 11:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WLOXPgvEmEVEbFTuBwZKBkwBgXekjAyg5OcjBYikc5s=; b=PGSiMNQorC5tGUS+0vYovp3VHFpuSaOi/jHTQ8TMmWqSxw8hrZponjzi3chyTZYn0Z AzWcGvE0sh4JvdXanpsn+hatMPuq5pgAONJEYYXVlzCcHfz9C3KApgdngl8B80fqT1Pb OinMQVepAiQaNl20cCWaXLi/ZCyDIZuurasoOLDroltmNBuswqmmvooR4n7anEeK8KDP Relwz4iLmm895PiyUeoBQCkvYuIxIk1YAmWrAUgRmjth4GmRdQKAnzkaxDJpsSsnfE1M ZSDbMFlnffC//uWMlqT2zLDM+JxePHbF68yid1L6OZvVYkuQEVQbEgUOxPMkvGleGP2e IXbw== 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=WLOXPgvEmEVEbFTuBwZKBkwBgXekjAyg5OcjBYikc5s=; b=OSBpxt8EpwdEjHb355kGnHukJX/0mdVIHq02MZit7upVw4/rNxn3rzLm5cqjjdUmgx O/+fnjdGjuIbudTEJkSyQFTsvkZq8yobY545fZrIURJ98omoWX1KiOxXs9juncbmn3FN toum1LAzlIWPPtsmfNB753ePwsit6dVJ5ua5QeNU2yrp6kxSq2N9TiKNwGga17RRNWyp GRBcL0lYHj4wWQ+/sSgEqTiqgWCc85w6VsRSAHPb04Sp9ZdPOlgDzLKlRr9l6+FrwXMz +mlmxF+qW4LlbYAL8gTtkcROnD2uHL5HrqMg7K9On33nqrpRDsuWgzAwwhG3tiDumCEB tR5w== X-Gm-Message-State: AIkVDXJ+2m9OeFcXAXD9AhQklV4+LLxFYskQGdGiGcgqR3k8VznM4cOaa+7YlHdNZKKlHA== X-Received: by 10.84.229.143 with SMTP id c15mr6590875plk.177.1485976210321; Wed, 01 Feb 2017 11:10:10 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id w16sm52107315pgc.15.2017.02.01.11.10.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 11:10:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <01b6f842-7f6f-b5f0-3e51-c417f0d88a7f@gmail.com> Date: Wed, 1 Feb 2017 11:10:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4CE62996-2415-451C-B7FC-37204FC510D0@gmail.com> References: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <4cbc3c52-504f-7282-3e74-75772aa59094@gmail.com> <01b6f842-7f6f-b5f0-3e51-c417f0d88a7f@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:10:12 -0000 I have asked Xing Li about CERNET2. CERNET2 has been IPv6-only since = 2008 or thereabouts, and posted a blog on its upcoming planned expansion = to 1200+ universities at = https://blog.apnic.net/2017/01/31/chinas-first-ipv6-backbone-network-conne= ct-1200-campuses/.=20 > On Feb 1, 2017, at 11:06 AM, Brian E Carpenter = wrote: >=20 > On 02/02/2017 00:16, Philip Homburg wrote: >> In your letter dated Wed, 1 Feb 2017 08:23:05 +1300 you wrote: >>> On 01/02/2017 07:36, Philip Homburg wrote: >>> ... >>>> So realistically, every environment should run both RA and = DHCP[v6]. >>>=20 >>> It seems to me that there are plenty of running proofs that this >>> is not true. >>=20 >> What I see is that in plenty of cases, a host gets quite a few more = parameters >> from DHCPv4 than from IPv6 equivalents. >>=20 >> If you know a write up of a largish organisation that is IPv6-only = and >> doesn't use DHCPv6 anywhere, then I'd like to know. >=20 > I don't. But then, I think that being IPv6-only is not very appealing > for the next ten or twenty years. Of course, I've been a true believer = in > dual stacks since 1994. >=20 > Brian >=20 >>=20 >> Did they ever provide hosts with hostnames and what do they do now? >>=20 >> For example, did they ever use PXE boot and what do they use now? >>=20 >> Do they run ntp servers in house and if so, how do they inform hosts = about >> them? >>=20 >> I seem to remember that Windows put some parameters in DHCP, but = maybe that's >> thing of the past. >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Feb 1 13:12: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 10B77126FDC for ; Wed, 1 Feb 2017 13:12:09 -0800 (PST) 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, 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 jcyIE0AQHA5W for ; Wed, 1 Feb 2017 13:12:07 -0800 (PST) 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 62F5D1299F5 for ; Wed, 1 Feb 2017 13:12:07 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id t8so268724879vke.3 for ; Wed, 01 Feb 2017 13:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JQqMyvv4CxX90DIkmfvAgEtrjkUnw00jLoRLccafcmc=; b=pGiKnerVgTs4KW3qiPz6WeiiXx1HHZJgIujbr7dvxg83W9LU+y1Xc1zinUrBY5hhNS 211ZFbA6aKBkiANNICk7mrM49VOiT3xlHBMIZ1uLkixDPdF60SOgUkemRqRnmEDlwPUF NqXs0KRszirCG8SpTLWz8ucLGqS2unPL9Cek+TIRjVzfhAU9Ywn/hpimKmVOnjZ7DR/A opbuVXiNIo9qZiiWljVxSaLjSs3yoXYxv9L3M95GXMbjruaItIJaMznzmn7J8kP2Xm4N oSuYEAJRdiUpEYnA08s/hBx3cRjpdhqNAQRt5K/9Xt7m+sKN2OcVQPRy9olczYdBiMtY gX3Q== 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=JQqMyvv4CxX90DIkmfvAgEtrjkUnw00jLoRLccafcmc=; b=tpnf/QfJr85DYsT4I+yWSdwfacr26OrJ/pp8YUUX5ZHTKO0dmAMUpLpMxkVeXzBiAD VYzlXKqGH5YWVivlcNvmkAeuavLjXdjtgxWaVJBHNUsbJ3CHzKDWsroUGFpEzXuUmMk9 5Cz2T0yi2/G5lVdHGWBeEYqbOuvH7RIyZ3h35ceh5CS9K3oSZgCWd09SGbh92gGTZrZ1 o+XImgLpJ4kDtGVMB1uY8eXhMiIq3xuJ/13ziBg+1+vSogoQJ1UD+nCPAzF6Nt5/rQjm VLIPZmRy/AKPKSX2/xbDfbmjHzsi9y0InVesmmNew9Qjd/73TXIzME3zGrbNMnbk+ulq S9IQ== X-Gm-Message-State: AIkVDXLQ4COVQFmN1ZTPRzMKamX7TIWVa2LqsnPtlVr5kyq/c8SCCF/riwhHKL8SN4IoZAugDgAaFscVpHbvFw== X-Received: by 10.31.54.85 with SMTP id d82mr1937114vka.25.1485983526402; Wed, 01 Feb 2017 13:12:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.173 with HTTP; Wed, 1 Feb 2017 13:12:05 -0800 (PST) Received: by 10.159.33.173 with HTTP; Wed, 1 Feb 2017 13:12:05 -0800 (PST) In-Reply-To: References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> From: Mark Smith Date: Thu, 2 Feb 2017 08:12:05 +1100 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=001a114384ac3bbee905477e804d Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:12:09 -0000 --001a114384ac3bbee905477e804d Content-Type: text/plain; charset=UTF-8 On 1 February 2017 at 05:36, Philip Homburg wrote: >>* Unnecessarily increasing the attack surface: two protocols, two pieces >>of code -- not to mention protecting both, if you happen to care. > > I'm not sure this is correct. > > At the moment you always need RA. Of course, if somebody just goes ahead > and does a default router option in DHCPv6, RA could go away, but that is > not the case at the moment. > > Unless we duplicate lots of DHCP options in RA, you probably need DHCP > as well, for example to specify NTP servers. > > So realistically, every environment should run both RA and DHCP. > > Ideally, all hosts should support getting address both using SLAAC and > using IA_NA, so hosts have to deal with the attack surface as well. > > Migrating to just RA will at some point replicate statefull DHCPv6 in RA, > so that's certainly not ideal. > > Getting rid of RA is realively easy (that how IPv4 works) but will not be > popular. > > So the dual attack surface seems something we just have to live with. > I think whether or not one protocol is the right number depends on the type and number of problems to solve, and the best place to solve them (when there are a number of possible places). I think the problem space for hosts is: - Internet layer interface specific IPv6 protocol configuration (e.g., addressing, default router, ND params.) - Internet layer protocol general or non-interface specific host configuration - Application layer service discovery - Application layer service client configuration In IPv4, all of these problems are primarily solved with DHCPv4, even though there are a number of dissimilar problems. I think IPv6 provided the opportunity to have another go at solving these problems separately where useful and where they could be better and more reliably solved. For example, I think it makes sense to have an on-link authoritative device provide link specific IPv6 protocol parameters to hosts, as the problem and the parameters are local to the individual link. (RAs are perhaps a bit misnamed - they're advertisements from a router that advertise link configuration parameters, which may include the router offering itself as a default router, rather than just an advertisement of the router itself. Link Configuration Advertisements might have been a better name.) Regards, Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a114384ac3bbee905477e804d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 1 February 2017 at 05:36, Philip Homburg <<= a href=3D"mailto:pch-v6ops-6@u-1.phicoh.com">pch-v6ops-6@u-1.phicoh.com= > wrote:
>>* Unnecessarily increasing the attack surface: two p= rotocols, two pieces
>>of code -- not to mention protecting both, = if you happen to care.
>
> I'm not sure this is correct.>
> At the moment you always need RA. Of course, if somebody just= goes ahead
> and does a default router option in DHCPv6, RA could go= away, but that is
> not the case at the moment.
>
> Unle= ss we duplicate lots of DHCP options in RA, you probably need DHCP
> = as well, for example to specify NTP servers.
>
> So realistical= ly, every environment should run both RA and DHCP.
>
> Ideally,= all hosts should support getting address both using SLAAC and
> usin= g IA_NA, so hosts have to deal with the attack surface as well.
>
= > Migrating to just RA will at some point replicate statefull DHCPv6 in = RA,
> so that's certainly not ideal.
>
> Getting rid = of RA is realively easy (that how IPv4 works) but will not be
> popul= ar.
>
> So the dual attack surface seems something we just have= to live with.
>

I think whether or not one protocol is the ri= ght number depends on the type and number of problems to solve, and the bes= t place to solve them (when there are a number of possible places).

= I think the problem space for hosts is:

- Internet layer interface s= pecific IPv6 protocol configuration (e.g., addressing, default router, ND p= arams.)
- Internet layer protocol general or non-interface specific host= configuration
- Application layer service discovery
- Application la= yer service client configuration

In IPv4, all of these problems are = primarily solved with DHCPv4, even though there are a number of dissimilar = problems.

I think IPv6 provided the opportunity to have another go a= t solving these problems separately where useful and where they could be be= tter and more reliably solved.

For example, I think it makes sense t= o have an on-link authoritative device provide link specific IPv6 protocol = parameters to hosts, as the problem and the parameters are local to the ind= ividual link. (RAs are perhaps a bit misnamed - they're advertisements = from a router that advertise link configuration parameters, which may inclu= de the router offering itself as a default router, rather than just an adve= rtisement of the router itself. Link Configuration Advertisements might hav= e been a better name.)

Regards= ,
Mark.





> ________________= _______________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6= ops
--001a114384ac3bbee905477e804d-- From nobody Wed Feb 1 13:34: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 6E44E129A5B for ; Wed, 1 Feb 2017 13:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn9Eg64D3LZJ for ; Wed, 1 Feb 2017 13:34:34 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5D5129A5A for ; Wed, 1 Feb 2017 13:34:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7935E4A; Wed, 1 Feb 2017 22:34:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1485984870; bh=1zXZDvv1BJXFudGWYR9kAHs0U+dL meG3JACEhFvzTvo=; b=bcNPqehJM8chidPWtwrHM5nAbW/cJEfvfAKlfBfgQOiP GFd8ujvsZqtld2Uu0IhsDQMuJhlBhE0yrqlSZZiV8QeMJYYmSDDHyFwphg3D5eDe thi3gVB9dBYu5ZYBAKQT/w8S6aEm/QTdRcIc+HYcShWedx2FPUvQw1rfHgGmr3s= 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 zzla-flZkjjx; Wed, 1 Feb 2017 22:34:30 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:28e7:2c56:ea4a:d3d3] (unknown [IPv6:2a02:a213:a300:9300:28e7:2c56:ea4a:d3d3]) (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 0AE5D48; Wed, 1 Feb 2017 22:34:29 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_8083A458-DE13-4E42-8DBF-339B7C5DF7BE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Wed, 1 Feb 2017 22:34:29 +0100 Message-Id: References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> To: Mark Smith X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:34:36 -0000 --Apple-Mail=_8083A458-DE13-4E42-8DBF-339B7C5DF7BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Mark, > I think whether or not one protocol is the right number depends on the = type and number of problems to solve, and the best place to solve them = (when there are a number of possible places). >=20 > I think the problem space for hosts is: >=20 > - Internet layer interface specific IPv6 protocol configuration (e.g., = addressing, default router, ND params.) > - Internet layer protocol general or non-interface specific host = configuration > - Application layer service discovery > - Application layer service client configuration >=20 > In IPv4, all of these problems are primarily solved with DHCPv4, even = though there are a number of dissimilar problems. >=20 > I think IPv6 provided the opportunity to have another go at solving = these problems separately where useful and where they could be better = and more reliably solved. Thank you, this way of looking at the combination of requirements makes = sense. There should be an architecture RFC about this stuff :) Sander --Apple-Mail=_8083A458-DE13-4E42-8DBF-339B7C5DF7BE 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----- iQEcBAEBCAAGBQJYklRlAAoJEKAtA7D+JBO5azwH/3xYDkhf7DxEusQD+lHaMdaq AlXV7XrTjpzNaJ3cEMaq2Zjc8hjMsOXyB1DJNYFFPph2med/VGggvPOVU87cb4Mv BF0C6cKQ+610/fuPlzQNgg7mdjtKd/8T/33yWXB38Hu9TPT7TGGs76XEQLjnYx1c Os7s4M9WuGMpSP7XRITBCRtzoWNlfXdNhxAxxbwp22bf3lO0clxCTR0VsjQaZcIK J7zLZw4uhRi3bFguRrNImZ4r/5agm2woXnJy13zPCeezrwPtw6Hu8NdLJCR7yz9W MfzUipXV9ulOHhfIRXVmDcbS7IRY2FxxCaecXptl/wtSEDLOwyKIWhH8a4p8BcM= =w9ah -----END PGP SIGNATURE----- --Apple-Mail=_8083A458-DE13-4E42-8DBF-339B7C5DF7BE-- From nobody Wed Feb 1 15:42: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 DFA971295F8 for ; Wed, 1 Feb 2017 15:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 Gxl2aPB5Y79c for ; Wed, 1 Feb 2017 15:42:20 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2779112952F for ; Wed, 1 Feb 2017 15:42:20 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id y9so310005153uae.2 for ; Wed, 01 Feb 2017 15:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=26gfZfwGH0nWElWXHQa/SGtBs5xbUsvXwXPyIf8Bql8=; b=hdZP2trxnCOJBpZ0bhm0FQwfHY5uzPpGJaJ9hUGu6Du0PnxnTh1BWnX74sH/RfdanN Lfe4KGBmtF+hKmsaK7UWZGZEIGbwhJx9mdBm2NNQGNL3DIaaD/jL8llenNSmr49SBhRo zm3xfZBuuRGtq8Na3yv7BY1nyDpXu/9BxjUlurJJnqLB2UsAwaIyyJT+cfFY+zeoLE0M TU+OaUFpleDztfzLcBWd5zfEa2o09RmM6/mS7IbmNK/gAE0xnRYNEy+SNpPXMxg3dQXh cEKBD2Xc7P0MmompVTYvnRfeHD4wPGQ+IAleyqHj2oLx/VsBiauRpe0RwG5CN+rhEp6S wOzQ== 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=26gfZfwGH0nWElWXHQa/SGtBs5xbUsvXwXPyIf8Bql8=; b=mHnoaW6mvfanxjvR0UmXb9R6knGaQMcEdRUGm6fMDCGDpXyhh+sT2tguVzsv825P2b w+aHTXQc8WprtfC7cX8U9nbKCucfLJAT6VcvjLU31LY/ETQENsQX2vULfYecnlhSYVL4 AXI3/GxDeRfSTIvCrmmZnojZqL0CU9+gTAb7dOYxi/zPyKrwDRid8a3As8GZTMCbnXme IkktIOCuEmlnQI+oZmuiOjQxIowhlXEw6Av4meEHmX2QP3C6uViLZWOX3mLCQtuNHwX1 +l6eCPmI3a1K1i76PnnNDiMWH9uFrLM0J+AaVfE/WE9W/PTNCubUW+IOsb1a6ZuGzEGi g1Fw== X-Gm-Message-State: AIkVDXL0L0c/oheYub8w8Te07pilsh2eBxCnLQki0x9SrPbJh46kcs22Sf66oiJ4zHGhjvUReW/B7TqJexv4aw== X-Received: by 10.176.6.167 with SMTP id g36mr2737737uag.97.1485992539196; Wed, 01 Feb 2017 15:42:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.173 with HTTP; Wed, 1 Feb 2017 15:42:18 -0800 (PST) Received: by 10.159.33.173 with HTTP; Wed, 1 Feb 2017 15:42:18 -0800 (PST) In-Reply-To: References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> From: Mark Smith Date: Thu, 2 Feb 2017 10:42:18 +1100 Message-ID: To: Sander Steffann Content-Type: multipart/alternative; boundary=94eb2c047d427013ff05478099de Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:42:22 -0000 --94eb2c047d427013ff05478099de Content-Type: text/plain; charset=UTF-8 On 2 Feb. 2017 8:34 am, "Sander Steffann" wrote: Hi Mark, > I think whether or not one protocol is the right number depends on the type and number of problems to solve, and the best place to solve them (when there are a number of possible places). > > I think the problem space for hosts is: > > - Internet layer interface specific IPv6 protocol configuration (e.g., addressing, default router, ND params.) > - Internet layer protocol general or non-interface specific host configuration > - Application layer service discovery > - Application layer service client configuration > > In IPv4, all of these problems are primarily solved with DHCPv4, even though there are a number of dissimilar problems. > > I think IPv6 provided the opportunity to have another go at solving these problems separately where useful and where they could be better and more reliably solved. Thank you, this way of looking at the combination of requirements makes sense. There should be an architecture RFC about this stuff :) RFC1958 and RFC5505 cover these sorts of architectural topics. There is also a bit of architecture discussion at the start of RFC1122. Regards, Mark. Sander --94eb2c047d427013ff05478099de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 Feb. 2017 8:34 am, "Sander Steffann" <sander@steffann.nl>= wrote:
Hi Mark,

> I think whether or not one protocol is the right number depends on the= type and number of problems to solve, and the best place to solve them (wh= en there are a number of possible places).
>
> I think the problem space for hosts is:
>
> - Internet layer interface specific IPv6 protocol configuration (e.g.,= addressing, default router, ND params.)
> - Internet layer protocol general or non-interface specific host confi= guration
> - Application layer service discovery
> - Application layer service client configuration
>
> In IPv4, all of these problems are primarily solved with DHCPv4, even = though there are a number of dissimilar problems.
>
> I think IPv6 provided the opportunity to have another go at solving th= ese problems separately where useful and where they could be better and mor= e reliably solved.

Thank you, this way of looking at the combination of requirements mak= es sense.

There should be an architecture RFC about this stuff :)

RFC1958 and RF= C5505 cover these sorts of architectural topics. There is also a bit of arc= hitecture discussion at the start of RFC1122.

Regards,
Mark.


Sander


--94eb2c047d427013ff05478099de-- From nobody Wed Feb 1 16:43: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 5B447129600 for ; Wed, 1 Feb 2017 16:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqnyF-rVBrKi for ; Wed, 1 Feb 2017 16:43:39 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0379012959A for ; Wed, 1 Feb 2017 16:43:38 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id y143so83729pfb.1 for ; Wed, 01 Feb 2017 16:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RlxRXmHZQLanLAqOaWwgIsXApE4w322jm++hJLs6fKE=; b=R62wQZw3JKhgFHU+QuSdILPYFd4nQGJrs4KNbVN+DnKwNOFLc7xjZ39YH0ZqoT9v6h qh0+plb0JevK8HVYifC0KGIO2xeGsQZ3HHcmdE3P42BW28akubMD2Ufx/NbH6svZ3z+Z kho7Hw+lXegIFxSyz8OVLD4Kljab0tzHLS+IXTvxqfyPH/aIL9KLCR9X7DqJbE4y3klF xQWr/IDDX6Bk5eYXahJkH94D5VOP8Ci3WuTLGqOnxxyayYVq6ORwcORnMnMpd+bO/90V TUmOEfkbC7erzWJy68h1vy3HhtJ4LMBlbO5k4eokIXEqd1ThdOtYoiI/Qg6i0wvB9slA K6zA== 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=RlxRXmHZQLanLAqOaWwgIsXApE4w322jm++hJLs6fKE=; b=BqEb4Ys95hp8Cwf21iOExT4tY8Ts4kOzc2DoRsdr+0TGTuK68Jse8+zu2ceId0Ovzo UcEK4NjJHKkiduWGFVfSSMalTZq9ePVe8DpYQor7e1i35YirpMv7Acz9MzSwSmzcWrCf RdiszcJh/Fiyv3k1cBp6eP6HkZqDGfzXp9fisBkDJgzB4UjScPsSKPdAMpq6qt25ikIb okvJFr3FV6e0ZV1gz+QSs2CG9w+EzGr1WUjwEpzDasBnsFbJlUgwVclU9L+AbEydtu21 pQU0tFRiqyKe2Y7D/5Sgja1q7C64Tjx9hpBPujOmDtUmfn4nDDnJMtdDOqQ4h/aP8RzO pD6A== X-Gm-Message-State: AIkVDXI8V0IaP5SkDftdfY2KrM4w+cEeOjpDxYPMy9nZqJ89R2yMXxQZA8oRDojhL0IT+g== X-Received: by 10.98.49.198 with SMTP id x189mr7148309pfx.20.1485996218523; Wed, 01 Feb 2017 16:43:38 -0800 (PST) Received: from [192.168.178.21] ([118.148.120.107]) by smtp.gmail.com with ESMTPSA id m136sm53132103pga.22.2017.02.01.16.43.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 16:43:37 -0800 (PST) To: Mark Smith , Sander Steffann References: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1ff3efa4-9cd3-878a-aab7-8cde35e93feb@gmail.com> Date: Thu, 2 Feb 2017 13:43:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:43:40 -0000 On 02/02/2017 12:42, Mark Smith wrote: > On 2 Feb. 2017 8:34 am, "Sander Steffann" wrote: ... > There should be an architecture RFC about this stuff :) > > > RFC1958 and RFC5505 cover these sorts of architectural topics. There is > also a bit of architecture discussion at the start of RFC1122. The thing is, we are talking here about fixing up a confusion created by our own history -- the fact that DHCP was immature technology when IPv6 was designed, so including a stand-alone autoconfiguration mechanism was, truly, a great step forward. So now that DHCP(v4) is a great success, and DHCPv6 is a bit of a poor cousin, there's a little cleanup work to do. That certainly isn't what the editor of RFC1958 had in mind. I can't speak for RFC5505. Brian From nobody Thu Feb 2 01:23: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 D1372129422 for ; Thu, 2 Feb 2017 01:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ivDQkrYQOb4y for ; Thu, 2 Feb 2017 01:23:03 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 572AB127078 for ; Thu, 2 Feb 2017 01:23:03 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 02 Feb 2017 09:23:03 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id CC537D788B; Thu, 2 Feb 2017 01:23:02 -0800 (PST) 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=ptAwNSpn23dqGp/zkvWjQ62SAUY=; b= U9eez1Q4fLtwis6RaiimQIlfFno6Sd3JUmHbbNxlCVP472k/U6qDa4VPxz+hBJX9 nueFK4zx7wr9xwDCcuhPnjDYOu/XrIyVMy4YKtobDnawBFuUVLResGbEPDw9zAG/ 0AS9o+uT4YFB9EpELdrHTUVs5d9QslEdQUeBkfNYIDY= 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=fRRIsGskTV1Hr73Y6gzqXj6 JfQPr31tRJdktlS0uxgWSYpfgNnrp2AlMRnCOp1uTdC2yi83RNvC6G+13/o2zC56 FnhABqDuplMV7lKg4cxmBAOvuEJ8iIiN+0CFzenVc1ETwCXqj4msoOPIYEQ+7RT3 ZySOvmmaoWDOHLKIMBr0= 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 0F9C2D788D; Thu, 2 Feb 2017 01:23:02 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 76480826B25D; Thu, 2 Feb 2017 10:22:59 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A7A9AD36-E27E-4395-B169-C51D8FDA141F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 2 Feb 2017 10:22:58 +0100 In-Reply-To: <1ff3efa4-9cd3-878a-aab7-8cde35e93feb@gmail.com> To: Brian E Carpenter References: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <1ff3efa4-9cd3-878a-aab7-8cde35e93feb@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 09:23:05 -0000 --Apple-Mail=_A7A9AD36-E27E-4395-B169-C51D8FDA141F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> There should be an architecture RFC about this stuff :) >>=20 >>=20 >> RFC1958 and RFC5505 cover these sorts of architectural topics. There = is >> also a bit of architecture discussion at the start of RFC1122. >=20 > The thing is, we are talking here about fixing up a confusion created = by > our own history -- the fact that DHCP was immature technology when = IPv6 > was designed, so including a stand-alone autoconfiguration mechanism = was, > truly, a great step forward. So now that DHCP(v4) is a great success, > and DHCPv6 is a bit of a poor cousin, there's a little cleanup work to = do. Fate sharing was one of the major objections to DHCP. It was I think also felt that a service discovery mechanism was the = correct way of resolving many of these issues. Only DNS recursive resolvers in addition to addressing was required from = the network. (Now I'm even less certain that DNS recursive resolvers should be = configured by the network, but oh well). Another data point on history here is from: https://www.ietf.org/proceedings/52/141.htm Using DHCPv6 for DNS Configuration in Hosts, Ralph Droms -------------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Questions about some of the assertions in the intro, asking to clarify = some of the statements. Nordmark: Cost benefit tradeoffs. Steve points out that without state = sharing problem is an improvement. Is this enough of an advantage to be = worth the trouble of deploying? Deering agrees. The real question for = the w.g. do we need anything beyond DHCP for client configuration? Soliman: Thinks being able to do discovery and configuration without = DHCP servers is good. Has always been a goal of the w.g. Thinks fate = sharing is a significant issue with DHCP and other server approaches. = Thinks claim that DHCP server can be combined in same box may not be = enough. Need to have discovery mechanism in same function (process) as = the service. Thinks this is a very important and DHCP doesn't meet this = requirement. Austein: Disagrees about the fate sharing comments. Could put DHCP in = same process. It is an implementation issue. Doesn't see that anycast = helps with the fate sharing. DHCP approach is better in the long term = because it handles other information. DNS is staring to have a = dependency on NTP. Doesn't want to define a special configuration = mechanisms for every service. Thinks DHCP is a better solution. Zill: If you send out one of the DHCP information requests. Will one = server know all? Narten: Not a problem that you learn an incorrect list = of servers. Suggestion that level 1 compliance is OK. Could use DHCP for level 2. Huitema: Thinks original requirement as stated by Steve Deering is = correct. Limited fate sharing is better approach. Thinks we need a = simple solution that work in simple networks. Thinks this DNS discovery = approach provides more flexibility the just using DHCP server. Nordmark: What is the extensibility in each approach? Talking about = these as one thing is part of the problem. Could separate anycast to = reach server from getting service information. Deering took poll of room: How many people think w.g. should continue = work on stateless DNS discovery? Consensus to continue work. --Apple-Mail=_A7A9AD36-E27E-4395-B169-C51D8FDA141F 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 iQIcBAEBCgAGBQJYkvpzAAoJEL7aWKiYQt92crUQAIhHc5PR87oUytmj5uPofJOD 9/bswsSoSxCjrsF0tHTRJJZ1eY/eBcduJBod3UJyoqbo+XelFa47XEBtbsu7Um5y vdSu29d4H+V85XcVGEggUGVPtjsoGc42vbQUP115Z0R4xhN4b871rvEeu6rZyfaO M44cA7kSmAX/rTTzv+j0m+mRAu6oojBiEGquK2y3W/QfKwPddyFYN15btcnPXrGl IQG8Aj9xg2+VkoZLyVFG4MN3hPIo4+E9EEJ6a+5qbAy1iKyVYGZmGvrdSnAs0B8x 6FEFXqTGBWJqzw8GObiqSyEPrubuaUf2cC92QyT/prkUqF+s6MxhtVyLwiuHSatv y5qbtzXccUGNTNuskPSPmnPk0k+PnbBsn8LKjqgoxj1A/HmcoQliKMMKBm5LWSR8 eF6g9Rs3XNvXPxND9WYV/JyWUJnZ47V84OSRHN8y4rAUy6xRqjjeu2DVAqYjDSGt I+p1mIxwXTkn1ll+ThocXu3CY4JrfL0FZCylKQHHVfsSvwlsycWPX2mTtFWSxYU4 8YAn+lTmZ44yW3MR8vvQFNC313KS9c5snoMRpya+Z3Yd6MwsVEeRV5Sn7JcngjxO 3JE1ipzS4uC5lBm+q2z7ZWja/yZ5sUJDe+HYWZ5cQu1dWC7/izjr59k3E43hK6YB e4i01ivvI3CsimaQLvMB =XbCK -----END PGP SIGNATURE----- --Apple-Mail=_A7A9AD36-E27E-4395-B169-C51D8FDA141F-- From nobody Thu Feb 2 02:16: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 8768B1293E4 for ; Thu, 2 Feb 2017 02:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heQMx5mAkFLl for ; Thu, 2 Feb 2017 02:16:44 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6561127076 for ; Thu, 2 Feb 2017 02:16:44 -0800 (PST) Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (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 EA13982BA4; Thu, 2 Feb 2017 11:16:40 +0100 (CET) To: Philip Homburg , v6ops@ietf.org References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <1b913d3f-cdfe-4156-8389-b1ff2d2db726@si6networks.com> Date: Thu, 2 Feb 2017 06:44:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 10:16:46 -0000 On 01/31/2017 03:36 PM, Philip Homburg wrote: >> * Unnecessarily increasing the attack surface: two protocols, two pieces >> of code -- not to mention protecting both, if you happen to care. > > I'm not sure this is correct. > > At the moment you always need RA. Of course, if somebody just goes ahead > and does a default router option in DHCPv6, RA could go away, but that is > not the case at the moment. Agree with this. [...] > > Getting rid of RA is realively easy (that how IPv4 works) but will not be > popular. > > So the dual attack surface seems something we just have to live with. Yes. But that doesn't make it a nice outcome. :-) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 2 06:40: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 BEB13129416 for ; Thu, 2 Feb 2017 06:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjbAz-rvLFC4 for ; Thu, 2 Feb 2017 06:40:38 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D92F1293E9 for ; Thu, 2 Feb 2017 06:40:38 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id x49so33507265qtc.2 for ; Thu, 02 Feb 2017 06:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JggOZhLMkQOvHlqRD/sJ3RfeV19cQqA+B9+lr4qqbes=; b=J/VvkSb6+VYZAYdJ3Z+A+RBH5JrcPEdFI5n8/Ap2bSEnnHjXoTKJaTEqtu2//URaQf GMwcO23dwKDGN87GAnBNhyciRs9m7nsdW/W45iZDvptM1joJE5LezJfNT1bg/J9BSByO CjC5G53Bh09odt9lqKNewIhdQQrfTKgxbTX4vHUepA5gB+SdLqAacxXLffB0CCCtbXXo dnZTzzJRyB3cGGcGoVe/5YkKCyIK55tgrgvYfErXvV8dpNuE0+3kFCNS6X9DrTOq44gR qWUr5KeQo7SuaVjs7rM9krwUFp6B21m/eCSQ0lktpfTqwZaRJN19/il8MRyzOmjgB3DS v0cw== 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=JggOZhLMkQOvHlqRD/sJ3RfeV19cQqA+B9+lr4qqbes=; b=egDm8Nq9kZosnwynyAphlXPu90/2P1MIQ7SOxre/0G4o+Ym3U/9ZLta8QXlIfor3dB g5eek63Z/iJZ5pOJW44w+O1imIni3LRvWKT/4vBltQcm3CeS4a7xqrR1g0B62Tzrlzs7 d5KW0Nr38JbNiJpYbqp9PQ9gg5HRHtXsX6MZ7VRzq7T7buF3kY1yhpjcIyAEg+l4ZseS RgvEWxZ6RKeP/qekaoECgseGjQ8ZwgFf3s7el+1F4AXvDbDropkgN/tSW5ryCvfoV2YP dau0AmnO5ezbVa8zuuUemscQnFaBSTkl54sFZVMcKRMeja1k3PFvbxmzy7mweQckB4Gr AeDw== X-Gm-Message-State: AMke39kniUfyMes1DEUn424uzgoNbhjJZPQn3LpSj3hCUZfvoPxF9+ivAI7xyIVW1Cgq5w== X-Received: by 10.55.23.92 with SMTP id i89mr7831963qkh.289.1486046437240; Thu, 02 Feb 2017 06:40:37 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id g32sm21696578qtd.28.2017.02.02.06.40.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 06:40:35 -0800 (PST) From: Ted Lemon Message-Id: <6A4D9A2B-3CAD-4EBC-B807-39A9FFF849C2@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A3B77560-E91F-4C67-8E3B-22716D1F1EA9" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 2 Feb 2017 09:40:34 -0500 In-Reply-To: <1b913d3f-cdfe-4156-8389-b1ff2d2db726@si6networks.com> To: Fernando Gont References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <1b913d3f-cdfe-4156-8389-b1ff2d2db726@si6networks.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:40:42 -0000 --Apple-Mail=_A3B77560-E91F-4C67-8E3B-22716D1F1EA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 2, 2017, at 4:44 AM, Fernando Gont wrote: > Yes. But that doesn't make it a nice outcome. :-) There's a pretty easy fix: make sure that your vendor supports the rdnss = option in RA. If they don't, ask them to fix the problem. --Apple-Mail=_A3B77560-E91F-4C67-8E3B-22716D1F1EA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 2, 2017, at 4:44 AM, Fernando Gont <fgont@si6networks.com> wrote:
Yes. But that = doesn't make it a nice outcome. :-)

There's a pretty easy fix: make sure that your vendor = supports the rdnss option in RA.   If they don't, ask them to fix = the problem.

= --Apple-Mail=_A3B77560-E91F-4C67-8E3B-22716D1F1EA9-- From nobody Thu Feb 2 06:56: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 26C9312944A for ; Thu, 2 Feb 2017 06:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVQMkD29rG74 for ; Thu, 2 Feb 2017 06:56:35 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id ED1871293E9 for ; Thu, 2 Feb 2017 06:56:33 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cZIoJ-0000FfC; Thu, 2 Feb 2017 15:56:31 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <1ff3efa4-9cd3- 878a-aab7-8cde35e93feb@gmail.com> In-reply-to: Your message of "Thu, 2 Feb 2017 13:43:39 +1300 ." <1ff3efa4-9cd3-878a-aab7-8cde35e93feb@gmail.com> Date: Thu, 02 Feb 2017 15:56:30 +0100 Archived-At: Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:56:37 -0000 In your letter dated Thu, 2 Feb 2017 13:43:39 +1300 you wrote: >The thing is, we are talking here about fixing up a confusion created by >our own history -- the fact that DHCP was immature technology when IPv6 >was designed, so including a stand-alone autoconfiguration mechanism was, >truly, a great step forward. So now that DHCP(v4) is a great success, >and DHCPv6 is a bit of a poor cousin, there's a little cleanup work to do. In my recollection, IPv6 SLAAC is a departure from how IPv4 ever worked. Before DHCPv4, RARP was commonly used on ethernet. And ppp had its own way of providing hosts with addresses. For some environments, SLAAC is obviously a step forward. However, many implementations mistakenly assumed that not implementing DHCPv6 IA_NA was OK. And we never managed to create a strong encouragement to implement it. Worse, not implementing DHCPv6 became so fashionable that long after DHCPv4 became completely standard for IPv4, we added the RDNSS options to RA. And when it is clear that operators use the DHCPv4 default router option in ways that simply cannot be supported by RA, this use case is actively suppressed by not standardizing a default route option in DHCPv6. The thing that I think is worst is actively breaking things. It is safe to assume that some extremely limited devices cannot implement both SLAAC and stateful DHCPv6. However, the devices that mostly common cause problems by not supporting IA_NA do so for political reasons. The same goes for the DHCPv6 default route. Technically not hard to implement, but rejected none the less. From nobody Thu Feb 2 11:57: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 B7EAA1299A0 for ; Thu, 2 Feb 2017 11:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYsOAyeDi750 for ; Thu, 2 Feb 2017 11:57:52 -0800 (PST) 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 DB2C112951D for ; Thu, 2 Feb 2017 11:57:51 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id k127so18603012vke.0 for ; Thu, 02 Feb 2017 11:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ohlfGxlatOMNbkaTINTtf39Iv8dKVpTjKdjpzj6vjoQ=; b=un4t+68KpOlBavE74s8R193DYPe7hXpfWYurPWMZfStkHDlXaGnXscEgG8tNmT8EcB W8EE++rjIO53RhWY2tg+08kOOrhl12p+Qkf8N6wNQ+cMldD7iA1gQFBMmPMLzuaNNV0w QcVtEOJei+DLyvyPrXxu4b0oYXnvE5ui344ivZZQWirAFjHDAecbGscnfX/aWXFuIqfp Hk2BTFofdi+4sovnXyos3qKdRFV0wgS9jSxUwTzzl63BCnjZ0UV2Kkb3mW+6R/04nltS B+QJkeyqSEdC0Y3vVaVd06is642lZnJnkFnEQ13NTxR69y10kGrAiI1AUeVhIoIMDTdI txDw== 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=ohlfGxlatOMNbkaTINTtf39Iv8dKVpTjKdjpzj6vjoQ=; b=pT8IGquzBhdj1FyzSrVrm5f6xdKE6RFg0wY4YVn6dBeS/z30N9Yvy7zJRBKu0eGFVf KBB5oxG7xe7et79n/z9XmGNU0d56jZEtePmPVlcBshweDisLEv7eNs+3Y9AVriGo8g+k inEwy1AQFbq16Pu27xtyIPVFhHAJUZPFq/fRUb8zAuIpFIl7ZUCtm6BjU1QiDbz+h7IL DJ4jhr0d6nYJRNutc+wPJNNeZm4F8fI1xPeKq98rCt64ao9BekOmQwq3eAylb9w9Q6w9 RSNK3BRK0n4pZTgdw0h0gfHCN5qCR+DVNlFvzzVbjP0WIg16prz1QQHoxvnapR68S3aE ypLg== X-Gm-Message-State: AIkVDXJhQw34K5jRwDev+dNIFWqdRAafjWgoz6TJZGCvsmxJZS1xKp8F8f/xO/2KzVgCPrVfQOcLcXdAiagElw== X-Received: by 10.31.49.81 with SMTP id x78mr4827530vkx.82.1486065470791; Thu, 02 Feb 2017 11:57:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.173 with HTTP; Thu, 2 Feb 2017 11:57:20 -0800 (PST) In-Reply-To: References: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <1ff3efa4-9cd3-878a-aab7-8cde35e93feb@gmail.com> From: Mark Smith Date: Fri, 3 Feb 2017 06:57:20 +1100 Message-ID: To: Philip Homburg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:57:53 -0000 On 3 February 2017 at 01:56, Philip Homburg wrote: > In your letter dated Thu, 2 Feb 2017 13:43:39 +1300 you wrote: >>The thing is, we are talking here about fixing up a confusion created by >>our own history -- the fact that DHCP was immature technology when IPv6 >>was designed, so including a stand-alone autoconfiguration mechanism was, >>truly, a great step forward. So now that DHCP(v4) is a great success, >>and DHCPv6 is a bit of a poor cousin, there's a little cleanup work to do. > > In my recollection, IPv6 SLAAC is a departure from how IPv4 ever worked. > > Before DHCPv4, RARP was commonly used on ethernet. And ppp had its own way > of providing hosts with addresses. > So I started working with IP in around 1991, and here is what I remember. Firstly, this was before DHCPv4. For automated address configuration, BOOTP was being used. BOOTP is a simplified version of DHCPv4 (or rather, DHCPv4 is (literally) a more complicated version of BOOTP), which doesn't have pools of addresses or lease times. The BOOTP server has a list of link layer addresses and the corresponding configuration information. It is centralised static configuration, DHCPv4 added dynamic allocation and a new name for BOOTP. BOOTP was developed to overcome RARP's limitations (from the RFC951) " However RARP had the disadvantage that it was a hardware link level protocol (not IP/UDP based). This means that RARP could only be implemented on hosts containing special kernel or driver modifications to access these 'raw' packets. Since there are many network kernels existent now, with each source maintained by different organizations, a boot protocol that does not require kernel modifications is a decided advantage." My focus was desktops at the time, and the IP stack we were installing on them didn't support BOOTP, so manual address configuration was the way IP addressing was handled for them. PPP was also in development at the time, and SLIP was the way people were doing dial up IP. The first networking protocol I learnt about and worked with was IPX, IPv4 was second. IPX was so much simpler than IPv4 to learn and understand (no subnets, subnet masks and classes, IPX has fixed length network and host/interface address fields). I started teaching IPv4 a few years later, and given how complex IPv4 was in comparison to IPX, I was curious why. One of the things I've come across is how addressing and address resolution looks to have been performed prior to ARP and Ethernet. From RFC796, "ADDRESS MAPPINGS" "Internet to Local Net Address Mappings -------------------------------------- The following transformations are used to convert internet addresses to local net addresses and vice versa:" I think we'd describe the original ARPAnet protocol as a link-layer protocol today. Here's how ARPAnet addresses were mapped to IPv4 host addresses: ARPANET ------- The ARPANET (with 96 bit leaders) has 24 bit addresses. The 24 bits are assigned to host, logical host, and IMP leader fields as illustrated below. These 24 bit addresses are used directly for the 24 bit local address of the internet address. However, the ARPANET IMPs do not yet support this form of logical addressing so the logical host field is set to zero in the leader. The network number of the ARPANET is 10 (Class A). +--------+--------+--------+ | HOST | ZERO | IMP | ARPANET +--------+--------+--------+ 8 8 8 +--------+--------+--------+--------+ | 10 | HOST | LH | IMP | IP +--------+--------+--------+--------+ So in that regard, the original IPv4 addressing model was the same or similar to IPX's - embed the node link-layer address in the IPv4 address, and use that information directly to send to the node, rather than having an address resolution protocol. SLAACs almost obsolete current model of using link-layer addresses to generate IPv6 IID is closer to the original IPv4 addressing model (and IPX's) than the DHPv4's pool allocation model. Ethernet addresses were too big to do this sort of mapping with, and the above is also network number specific. So ARP was developed. This also explains why the ARP RFC has an RFC number in the 800s, a number of years after IP was developed and deployed. > For some environments, SLAAC is obviously a step forward. However, many > implementations mistakenly assumed that not implementing DHCPv6 IA_NA was OK. > And we never managed to create a strong encouragement to implement it. > > Worse, not implementing DHCPv6 became so fashionable that long after DHCPv4 > became completely standard for IPv4, we added the RDNSS options to RA. > > And when it is clear that operators use the DHCPv4 default router option in > ways that simply cannot be supported by RA, this use case is actively > suppressed by not standardizing a default route option in DHCPv6. > I think the trouble with this view is that they only think that RAs are being used to advertise a router as a default gateway. RAs do a lot more than that - announce prefixes for SLAAC, announce whether the prefix is on-link or off-link, announce parameters related to mobile IP, announce ND parameters hosts are to use, announce the IPv6 layer MTU. All of that can be announced in an RA without the router being considered a default router (the router lifetime field value would be zero in this case.). RAs are an advertisement from a router rather than an advertisement just for a default router. This is not to say that all couldn't be ported across to DHCPv6. However, it is important that people realise that RAs aren't just announcing a default router, and that therefore eliminating RAs would not be as simple as creating a DHCPv6 default router option. > The thing that I think is worst is actively breaking things. It is safe > to assume that some extremely limited devices cannot implement both SLAAC > and stateful DHCPv6. However, the devices that mostly common cause problems > by not supporting IA_NA do so for political reasons. Stateful DHCPv6 is optional, SLAAC is mandatory, and therefore the support for SLAAC is universal and ubiquitous.The decision to support an optional protocol when there is a functionally equivalent mandatory protocol is not a political decision, it is a technical and operational one. > The same goes for > the DHCPv6 default route. Technically not hard to implement, but rejected > none the less. > Rejected because DHCPv6 is the wrong place to reliably and accurately solve a link-specific parameter advertisement problem. IPv4 and it's models have worked and been successful, however is a long way from the pinnacle of layer 3 protocol design. Other layer 3 protocols have done things differently and better than IPv4, and IPv6 has adopted some of those ideas instead. Regards, Mark. From nobody Thu Feb 2 12:53: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 21DA21299F3 for ; Thu, 2 Feb 2017 12:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZpiz0-nVjJt for ; Thu, 2 Feb 2017 12:52:49 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F241299D9 for ; Thu, 2 Feb 2017 12:52:49 -0800 (PST) Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (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 4FAC480110; Thu, 2 Feb 2017 21:52:45 +0100 (CET) To: Ted Lemon References: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <1b913d3f-cdfe-4156-8389-b1ff2d2db726@si6networks.com> <6A4D9A2B-3CAD-4EBC-B807-39A9FFF849C2@fugue.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 2 Feb 2017 13:06:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <6A4D9A2B-3CAD-4EBC-B807-39A9FFF849C2@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:52:51 -0000 On 02/02/2017 11:40 AM, Ted Lemon wrote: > On Feb 2, 2017, at 4:44 AM, Fernando Gont > wrote: >> Yes. But that doesn't make it a nice outcome. :-) > > There's a pretty easy fix: make sure that your vendor supports the rdnss > option in RA. If they don't, ask them to fix the problem. I'm not a MS Windows user. Besides, the same can be said for android, and IIRC there's a bug report for that, and didn't work out, either. Probably we could help a bit in tis area, so that people submitting bug reports have something to point vendors at (not that they don't about the issue). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 2 13:39: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 C01C61299FB for ; Thu, 2 Feb 2017 13:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2P3IbKgMsea for ; Thu, 2 Feb 2017 13:39:16 -0800 (PST) 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 2E218129A88 for ; Thu, 2 Feb 2017 13:39:16 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id 14so200615pgg.1 for ; Thu, 02 Feb 2017 13:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=UNcB6MLr1LbTn6YegS8ylKS++/3JLNcsWAF96OMVZBA=; b=AZQS8HxStK7uNuwzNL+nsuu2SwetXxH4+OITvd3BmPuZB03mlIA0Ju1pS9QGSUupVm 2iLhqicyzEK0jw0Ub2ci4cCtZ/qDe1CaEty8F+iP8vT7csSUXY9LP8sC1dB6YnPGwbCQ 8UV9tPMWnLv+VvqsiJ6tYDj/ANOBkFlG/q9cRaWRYnAC7FQhvdJ6ycsDyRAtp1anxaAV 9hO76vIf9eXsCuYbHGYZ6Edyug6lgzas+w/NmC9q8It2PMHdlTwtqKzu0pjx8pxfa/NB 0mwGEI06H3o2hoDyFI3HLd/Ial96nRH3KkgxxnfsyiJHQf4VuUxRcCMTjSeqzOtAUYcC VrGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=UNcB6MLr1LbTn6YegS8ylKS++/3JLNcsWAF96OMVZBA=; b=qwmIHnaQ7Tb5If+thPJjMDUbjrr9EGnT5oAy2wEVOliVLd0ZYYTx5xLQNhKbKkgf8c CxELYQg3IQPzMEOCtnXEX8HBNTFvHt92nLI8wyglmCo/fiinK7LZWi7XJjfiDvfZVqma kCMzvCjbfzjt3+CLAIweEBR1xb1xWvVKl0fUvb76HKYIUiGvKdhiE1HRFPZ8Kut/4RZl Z8Rh4cgd8vCDR+qEIWfWloSPk6Qshgfjl3xMmPm54CzNXripGB+JePJ5FV5qFpqpXtDX RrZOjUKuWmoh15vzOuj1O1DMziG4mu8ehEd2A5VYKTMPehgrjMkA35iXj7604zMuc0Ef iRkg== X-Gm-Message-State: AIkVDXIRrZ1FaIkKm/b9mx3F7S57xQvM3lop9+3beLCCP5dQMAf0QUjzitSqwXAAFuhYIerC X-Received: by 10.84.217.18 with SMTP id o18mr15648390pli.51.1486071555514; Thu, 02 Feb 2017 13:39:15 -0800 (PST) Received: from [100.107.34.10] ([100.107.34.10]) by smtp.gmail.com with ESMTPSA id 88sm60913095pfr.41.2017.02.02.13.39.14 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 13:39:14 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_1A2FCDB5-FB95-4D55-B110-31441473C3CF" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 2 Feb 2017 13:39:13 -0800 References: To: IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:39:18 -0000 --Apple-Mail=_1A2FCDB5-FB95-4D55-B110-31441473C3CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 31, 2017, at 12:46, Ron Bonica wrote: >=20 > Ack. ULA-only is OK when disconnected from the Internet. When *persistently* disconnected from the Internet. I suspect there = isn=E2=80=99t consensus about what to say for networks that connect to = the Internet intermittantly and ephemerally. --james woodyatt > --Apple-Mail=_1A2FCDB5-FB95-4D55-B110-31441473C3CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 31, 2017, at 12:46, Ron Bonica <rbonica@juniper.net>= wrote:

Ack. = ULA-only is OK when disconnected from the = Internet.

When = *persistently* disconnected from the Internet. I suspect there isn=E2=80=99= t consensus about what to say for networks that connect to the Internet = intermittantly and ephemerally.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_1A2FCDB5-FB95-4D55-B110-31441473C3CF-- From nobody Thu Feb 2 16:44: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 770E7129A53 for ; Thu, 2 Feb 2017 16:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 R3v53il5o4Kz for ; Thu, 2 Feb 2017 16:44:09 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E46D129A4C for ; Thu, 2 Feb 2017 16:44:09 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id 19so292215pfo.3 for ; Thu, 02 Feb 2017 16:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=f7gK6A+0MSmP/a2MB/Ga7o/5iCqEwh6eLFhJKvLOQx4=; b=GpuzmL4HvI49p6oLV+GAUDLB6e2WpEqSSnH+ClFRD8/imB6WUkI82IE1U7rWSZE2aK TSbS+s1evKVELQLdYEHZG1R2ZnfZQi4OgEuiPAOb6L0wS8QHe9FR+Ms2QOEOaXeEa4OZ IJZE61z+F5i8HaCqPdch3GQdP0nZGKtO6XkoigEP3is2La8bQU2+rrY0CpMNbBVOiwyd n/VtyylKHgDOBjt5B5SpwohYK+1JcAFRf+xMB2ZQh/bPOBi/NWq5/dtTju/2aomYxDVS 0ld7ps2QUqH3lERvkuw1ytCNJGvU8FjE6Pi0VSSRNl69Jt6GW3F8SDgbfumwNaNrwqZ9 drUw== 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=f7gK6A+0MSmP/a2MB/Ga7o/5iCqEwh6eLFhJKvLOQx4=; b=Nh6PTJk8gcQ+A9ncdi6y63rzRSGC4cI7WZrnJJZHOAHCO2F6z8WCCVQMfnebv4BL0g /MhOmbNfNnX0cHpR5BUZekgZryK50zYUgefjovkhqKO/vANskIx0rzh0bdAv9xqNaLSm uO4r4pvS58Yh1RyJhYQw7c5TtHlUd3DtuMcUl7Vmzn6eu7D1dQ6/SRDktE3ygChZ5FK3 4KNrMkjYcnFS0ndvAwudxUmoukWJ0dt4vYcoEhB+0juEqiGB6xBn3oQI3l3t0pR2vU/J 5VCzBHDCnWjST1CSmyZpZ2UrPQpNR4kto4xBaMig/PDWMq44GMJ1Hs319vLHzSjKoXq8 q+Zw== X-Gm-Message-State: AIkVDXLxAR1ZxvjKcLvjPZImlcCiCzHVWSA9RIe4O6J7RFKsCwNniY+UIgxpPg2ZN7zRSA== X-Received: by 10.99.170.70 with SMTP id x6mr14363834pgo.14.1486082648920; Thu, 02 Feb 2017 16:44:08 -0800 (PST) Received: from ?IPv6:2406:e007:7909:1:28cc:dc4c:9703:6781? ([2406:e007:7909:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i10sm61941230pgd.37.2017.02.02.16.44.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 16:44:08 -0800 (PST) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <4a14a949-b739-e37d-1c5c-c9aa91796fb0@gmail.com> Date: Fri, 3 Feb 2017 13:44:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:44:11 -0000 On 03/02/2017 10:39, james woodyatt wrote: > On Jan 31, 2017, at 12:46, Ron Bonica wrote: >> >> Ack. ULA-only is OK when disconnected from the Internet. >=20 > When *persistently* disconnected from the Internet. I suspect there isn= =E2=80=99t consensus about what to say for networks that connect to the I= nternet intermittantly and ephemerally. Why not? My ISP sometimes fails to give me an IPv6 prefix when I reboot t= he CE. On those days, the CE announces a ULA prefix. Everything works just fine. If a GUA= prefix crops up later, the ULA is quickly depreffed and everything still works j= ust fine. ULAs are basically harmless domestic animals. NPTv6 is a Frankenstein mon= ster, of course. Brian From nobody Thu Feb 2 17:22: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 7DEBB129A67 for ; Thu, 2 Feb 2017 17:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5hvwMOsAFND for ; Thu, 2 Feb 2017 17:22:36 -0800 (PST) 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 4DD92129A66 for ; Thu, 2 Feb 2017 17:22:36 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id r136so3692336vke.1 for ; Thu, 02 Feb 2017 17:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A+xOQ/+F28HFdNE3we5YzCUMrN2HL/s76zb0DZWvdig=; b=WPzFsjWVchuBe/dHw+fkmU3M8Qc5w1HIGAFrgEFy8U2/Z5/zZWTbDhQBSxZknE1p4+ 4OGZjlANgdeixmmAnkLQDw2mdln1GhcVcmOsyrkrjSp8bvjLK8mxk8vH4KOzMj4yRERr wQhCt4QehBaBiTcuUy580cdalGLkdD7swuYafJ07vnXKrcpjdQOAk3+kEp07tD17B1qa wTQwFMrnVuqxjpx3vbVY7bo0/wJnRhP/ziiw2qPuodahgLeH3iec4VXskmVo2MLJaBXo /Qwy8hCV3LaqUxGGYyxNdI7/Rtf/IETlCPN64F5IW2Rl84Q9Ox0W5McONNlDbnzyjBik S56w== 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=A+xOQ/+F28HFdNE3we5YzCUMrN2HL/s76zb0DZWvdig=; b=S2Ou5eg1Ot/YeDtCkSKFVKfeQDgFrYKnHHIliVa32Ic3JY+OSA2+8qMOk1XHrv3iev SqzIDbGJEXcjKL2zVit46CpM6FsSG55zaFKy6THDSeJmefkg6HlZRKKFGTtXLHOr7pbY Z4EYHU5t89GOb3INVaV8NNqxEgX9L9YF1RaTUmd08yhaefbLfBFSzUqfcXLHTsPqDpUr NvSBvsxfMXoNjBiCoLVEfT0ULNebJQwciu718/qnGtpre78TsTyQ/GIMiHCJj9C9pvb9 xQepRBrbzzLdP1w3b/rG5KztO77cws4eYlHfO/KbQcD871GSjCPWC0KrsnLklX9GwGCQ M9cw== X-Gm-Message-State: AIkVDXLRCtzB/gKc64HkszfK9yTU58Pj0cpRSsPrBBEPVO0w24KEl34j4T57V+75mExnP6jJboCI7gA4Zye9ejyN X-Received: by 10.31.170.15 with SMTP id t15mr4675489vke.6.1486084955212; Thu, 02 Feb 2017 17:22:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Feb 2017 17:22:14 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 3 Feb 2017 10:22:14 +0900 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=001a11432250dd01240547961d86 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 01:22:37 -0000 --001a11432250dd01240547961d86 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 6:39 AM, james woodyatt wrote: > When *persistently* disconnected from the Internet. > ... and where any access to resources outside the ULA domain does not occur via IP packets but by higher-level intermediaries such as application-layer proxies. --001a11432250dd01240547961d86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 3, 2017 at 6:39 AM, james woodyatt <jhw@google.com> wro= te:
<= div>When *persistently* disconnected from the Internet.

... and where any access to resources outside the = ULA domain does not occur via IP packets but by higher-level intermediaries= such as application-layer proxies.
--001a11432250dd01240547961d86-- From nobody Fri Feb 3 20:14: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 7BAAB12969E for ; Fri, 3 Feb 2017 20:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24sz2XIcX0sB for ; Fri, 3 Feb 2017 20:14:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0357129695 for ; Fri, 3 Feb 2017 20:14:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZZ54337; Sat, 04 Feb 2017 04:14:36 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 4 Feb 2017 04:14:35 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sat, 4 Feb 2017 12:14:08 +0800 From: "Liubing (Leo)" To: Ron Bonica , IPv6 Ops WG Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-considerations Thread-Index: AdJ71bub1L6aUKYaSxmQB+Og32Va4wCxu9Aw Date: Sat, 4 Feb 2017 04:14:07 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E9DACD@nkgeml514-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5895552C.013E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 55cb737b513464200f2a73b855324ae7 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 04:14:39 -0000 Hi Ron and all, Sorry for the late reply, I was just back from the Chinese New Year holiday= s. I'll make a new version to see if the WG could make a final consensus.=20 Thanks much for all the comments in the mailing list and your guidance on t= his work. Best regards, Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ron Bonica > Sent: Tuesday, January 31, 2017 11:23 PM > To: IPv6 Ops WG > Subject: [v6ops] draft-ietf-v6ops-ula-usage-considerations >=20 > Folks, >=20 > Some time ago, I queried the WG's disposition regarding > draft-ietf-v6ops-ula-usage-considerations > (https://mailarchive.ietf.org/arch/search/?email_list=3Dv6ops&index=3Dx6O= mZJ > 1n2F0rBX6iq5GHRBHWRO0&gbt=3D1). I think that the consensus was: >=20 > - Continue as informational > - Recommend against ULA-only > - Attempt to find some set of recommendations upon which the WG can > agree. >=20 > So, if the authors are so disposed, I encourage them to produce a new > version of the draft, leveraging what we learned during this email thread= . >=20 > Ron >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 6 08:52:01 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 5A50F12943A; Mon, 6 Feb 2017 08:52:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148639992036.18922.16491568324350116420.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 08:52:00 -0800 Archived-At: Cc: v6ops@ietf.org, v6ops-chairs@ietf.org Subject: [v6ops] v6ops - New Meeting Session Request for IETF 98 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:52:00 -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: 1 Length of Session(s): 2 Hours Number of Attendees: 100 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 Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Mon Feb 6 11: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 D463D129478 for ; Mon, 6 Feb 2017 11:39:10 -0800 (PST) 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 4c-Z6C9PeiP3 for ; Mon, 6 Feb 2017 11:39:09 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B423D129469 for ; Mon, 6 Feb 2017 11:39:09 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id f144so26207765pfa.2 for ; Mon, 06 Feb 2017 11:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=+xCfG2QGrgZZXaB6ieyFiBTAt7DQL9l4pUMcEsPasyg=; b=YcuS48cG90hNL6e1kFs7OFjhfz3KlCrXP3tXxdV/XjFpmHIm5sVn3QdvWB2hGxnZ7n JTlu7+7cn2iKusgqKjSrmItPASH2LbDI8oABOL/ySr1I+5C2JEmb5whztfFR1NR9kMBx 1YGDwqUrGFKfwGByNSyz94Jy9qNl8pU5xUQ0mKlZ1eArw+r88joJVvyxa+3kW00gDDoA 7cmshMVDFFmAA0qmQNLSQEZf+jB/v0tDk5CwvLiVJzAl+osu4M9n4QuZc1H38MhtTDNS uk/XBA+lZE1a9h9O3DaD1+BfDO9SnOrC8C7oPx6iU9nbH4RGiT37SdlH2CUpyqTExgh5 tu8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=+xCfG2QGrgZZXaB6ieyFiBTAt7DQL9l4pUMcEsPasyg=; b=EkblSZ/YraMz/WTkylKYSL62McGh00x9LUEjSvpo4dL7ln01ldRTLUypMrfx748rfR NjmxxN2WqnBqdk3KRSEih80B2sr7q+1gFiHpZQUDlZMkxtYsP8zg1aqj2hp1NRr8CKZt OGqBNaipluhyzL3ekKPuYaHJwI4t2YRik1O34Jt+f8tr8EzvbBYrMspp5RAJBdFE3sys b43GVsz4E3898OkDqeRQgcwtmB8/JEhX6qkXLAZY+DdJVDvSTsyiBrEzSgmalb/d4aRR umujEiNqoUoqogFau3ee/kNM+la7T1KWF3DlWaOKiSwBKHj9/D63rDrIAIz6WZw8YGhc blmA== X-Gm-Message-State: AIkVDXKkcmiKDGPm1gGZZ8QXd0Ho/aPQrM8N/hdLv/4Szr9k4as3rhhD614ZKkPnq5r3Doxn X-Received: by 10.99.158.68 with SMTP id r4mr15250210pgo.153.1486409949076; Mon, 06 Feb 2017 11:39:09 -0800 (PST) Received: from [100.107.14.163] ([100.107.14.163]) by smtp.gmail.com with ESMTPSA id 199sm4557784pfu.91.2017.02.06.11.39.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Feb 2017 11:39:08 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F85CDD9D-7CF2-4D31-B2BC-DD2F0EBD1A6E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: james woodyatt In-Reply-To: <4a14a949-b739-e37d-1c5c-c9aa91796fb0@gmail.com> Date: Mon, 6 Feb 2017 11:39:36 -0800 Message-Id: <223206E2-DEBF-4CE2-93D5-52138E1B0508@google.com> References: <4a14a949-b739-e37d-1c5c-c9aa91796fb0@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:39:11 -0000 --Apple-Mail=_F85CDD9D-7CF2-4D31-B2BC-DD2F0EBD1A6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 2, 2017, at 16:44, Brian E Carpenter = wrote: > On 03/02/2017 10:39, james woodyatt wrote: >> On Jan 31, 2017, at 12:46, Ron Bonica wrote: >>>=20 >>> Ack. ULA-only is OK when disconnected from the Internet. >>=20 >> When *persistently* disconnected from the Internet. I suspect there = isn=E2=80=99t consensus about what to say for networks that connect to = the Internet intermittantly and ephemerally. >=20 > Why not? My ISP sometimes fails to give me an IPv6 prefix when I = reboot the CE. On those > days, the CE announces a ULA prefix. Everything works just fine. If a = GUA prefix > crops up later, the ULA is quickly depreffed and everything still = works just fine. >=20 > ULAs are basically harmless domestic animals. NPTv6 is a Frankenstein = monster, of > course. Do we really think we have rough consensus that ULA-only in the = *temporarily* disconnected state is OPTIONAL as opposed to NOT = RECOMMENDED? Enough to make an assertive statement to that effect? I remember a debate during the predecessor to RFC 7084 over the language = in requirement L-13, and my recollection is that the tortured language = in that requirement is the result of a compromise about this very = question. Some participants wanted to zero the Valid Lifetime of the = withdrawn prefix delegation, while others wanted to leave it valid for = up to two hours. We ended up allowing both and not making any statement = at all about what is recommended and what is truly optional. --james woodyatt > --Apple-Mail=_F85CDD9D-7CF2-4D31-B2BC-DD2F0EBD1A6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 2, 2017, at 16:44, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 03/02/2017 = 10:39, james woodyatt wrote:
On Jan 31, 2017, at 12:46, Ron Bonica <rbonica@juniper.net>= wrote:

Ack. ULA-only is OK when disconnected from the Internet.

When *persistently* disconnected = from the Internet. I suspect there isn=E2=80=99t consensus about what to = say for networks that connect to the Internet intermittantly and = ephemerally.

Why not? My ISP = sometimes fails to give me an IPv6 prefix when I reboot the CE. On = those
days, the CE announces a ULA prefix. Everything = works just fine. If a GUA prefix
crops up later, the ULA = is quickly depreffed and everything still works just fine.

ULAs are basically harmless domestic animals. = NPTv6 is a Frankenstein monster, of
course.

Do = we really think we have rough consensus that ULA-only in the = *temporarily* disconnected state is OPTIONAL as opposed to NOT = RECOMMENDED? Enough to make an assertive statement to that = effect?

I remember a debate during = the predecessor to RFC 7084 over the language in requirement L-13, and = my recollection is that the tortured language in that requirement is the = result of a compromise about this very question. Some participants = wanted to zero the Valid Lifetime of the withdrawn prefix delegation, = while others wanted to leave it valid for up to two hours. We ended up = allowing both and not making any statement at all about what is = recommended and what is truly optional.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_F85CDD9D-7CF2-4D31-B2BC-DD2F0EBD1A6E-- From nobody Mon Feb 6 20:43: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 71BB41299B8 for ; Mon, 6 Feb 2017 20:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8Gv42wcT1i5 for ; Mon, 6 Feb 2017 20:43:05 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFC11299B9 for ; Mon, 6 Feb 2017 20:43:03 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id 194so10957525pgd.0 for ; Mon, 06 Feb 2017 20:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=D0b8NE92+6lvlVtSX3XmiHp+LnGhbOmLGao5pz3naDQ=; b=S6kEWJauEh0/aY2qhFWmHofJs/5XOm12TmjkiCEdhzFCElvDZ/FkPlz6HJNbd/zzPl 9bz4nPZdSYTyULofiEKIlege7bZF5+OabFeoenv6hytKVAS9bRcI55E9uO40420sePUB 6qEBZuayxACTAm3qMhx7HxoqDc481WeKc0in6bTvt2lzTZmZ+u8iDFOVAGXWiyVcx8Ho ZXexo/Xg0Q0/oC7Jyi5zL3R0P80GNeUsNP16MyQRAyaORFYcmeHNx4jmeIN04QW5pwzZ X6gwIdrRTSfkvAMy97CTvbRJBU8P9/UxocEyMLPeoiibEkwAWIzyqP4RLb567F3JqCf3 Thpw== 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=D0b8NE92+6lvlVtSX3XmiHp+LnGhbOmLGao5pz3naDQ=; b=VDOdhXvNiDnLxq/bjrCyFp0CqmJikbVgrw19DqbXLegqxRjX503jCXWIuLLhLVLdmK 05wpzvq90/j/0mjdVU0dQfJ/sMpybZScXT734+pu4qz9TmGEWdHejmf1TE9iUgTeuFbp YtsUTANCQP0/zpkZRnrjvfKWhB1aAH4CwL/uXqSKutZ0mJoniQ+wE7JvfbJzKhZb44EF ogCxRgEgYa0InvGm5qD3VZuRaJ7v0PKLbuX+WsZOaPT3s312gGm2JakffLx49XIeSxo3 /W4JktPyuTuq0wP4aD0V8JjXyHrt2eLPOq2TI1XW2dD+S4OvQahIsTdZkzOvfUUcnvTU 4oNQ== X-Gm-Message-State: AIkVDXIFgfeZYpXOPdeAiVnHMWV+agfqPkIIflUl+UsOqh6k13YkXQ2vsGUg+BrCNrSiJA== X-Received: by 10.99.60.76 with SMTP id i12mr17516376pgn.170.1486442583443; Mon, 06 Feb 2017 20:43:03 -0800 (PST) Received: from ?IPv6:2406:e007:6fdd:1:28cc:dc4c:9703:6781? ([2406:e007:6fdd:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g28sm6599291pgn.3.2017.02.06.20.43.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 20:43:02 -0800 (PST) To: james woodyatt References: <4a14a949-b739-e37d-1c5c-c9aa91796fb0@gmail.com> <223206E2-DEBF-4CE2-93D5-52138E1B0508@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 7 Feb 2017 17:43:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <223206E2-DEBF-4CE2-93D5-52138E1B0508@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 04:43:06 -0000 On 07/02/2017 08:39, james woodyatt wrote: > On Feb 2, 2017, at 16:44, Brian E Carpenter wrote: >> On 03/02/2017 10:39, james woodyatt wrote: >>> On Jan 31, 2017, at 12:46, Ron Bonica wrote: >>>> >>>> Ack. ULA-only is OK when disconnected from the Internet. >>> >>> When *persistently* disconnected from the Internet. I suspect there i= sn=E2=80=99t consensus about what to say for networks that connect to the= Internet intermittantly and ephemerally. >> >> Why not? My ISP sometimes fails to give me an IPv6 prefix when I reboo= t the CE. On those >> days, the CE announces a ULA prefix. Everything works just fine. If a = GUA prefix >> crops up later, the ULA is quickly depreffed and everything still work= s just fine. >> >> ULAs are basically harmless domestic animals. NPTv6 is a Frankenstein = monster, of >> course. >=20 > Do we really think we have rough consensus that ULA-only in the *tempor= arily* disconnected state is OPTIONAL as opposed to NOT RECOMMENDED? Enou= gh to make an assertive statement to that effect? Yes. If I drop off the Internet for X minutes, why on earth would some RF= C tell me I should not use a ULA during that time? Its lifetime will be renewed as necessary, whereas any residual GUA will eventually vanish, and probably SHOULD NOT be used anyway, because it might already belong t= o someone else. Note that the value of X is by definition unknowable. It might be 1 or it= might be 100,000. > I remember a debate during the predecessor to RFC 7084 over the languag= e in requirement L-13, and my recollection is that the tortured language = in that requirement is the result of a compromise about this very questio= n. Some participants wanted to zero the Valid Lifetime of the withdrawn p= refix delegation, while others wanted to leave it valid for up to two hou= rs. We ended up allowing both and not making any statement at all about w= hat is recommended and what is truly optional. Indeed. Just like trying to define 'temporarily', because it's unknown an= d unpredictable how long the disconnection might last. It's going to be a pragmatic implementation choice. Brian From nobody Tue Feb 7 08:19: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 B8D39129D2D for ; Tue, 7 Feb 2017 08:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, 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=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 1GNinYGa7edI for ; Tue, 7 Feb 2017 08:19:42 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0095.outbound.protection.outlook.com [104.47.33.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9861E129CFD for ; Tue, 7 Feb 2017 08:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fMx2NvZo/IuiAg53JtTOt0zWszAv50NwYe8XDknFSzU=; b=Kf7AfDQEQ1NTw71INANDMztjY9nF32484uV76G7cILf3QR361poHjEMlfLj78EyOI2sdQTIJLUxiBo8Qqs25WOwdHRbCx6SnDJPP3ebOXc+8vVJXwMUDRmwaOmPkxYQXMubP3TCNaooqgkLjqZUZcXlgo+dYnoFX/ZtlzLt5Q4Y= 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_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 7 Feb 2017 16:13:51 +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.0888.026; Tue, 7 Feb 2017 16:13:51 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: Draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdKBXSTt7udNQXgRSLKwo7BNm53uFg== Date: Tue, 7 Feb 2017 16:13:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 291d2434-47f5-48e5-4c61-08d44f744e9e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BLUPR0501MB2052; x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 7:tKNhZC1/pYWp5iW3LxqM808u9zE5QhXu1Ym073SDUD0SGuT2ZKhcgCHPdrBXZCIhdMz//e+jXvgIXkM8SQzAdpyVLdi7Pas5pAqVTt5r3aEJD3Y14LEFG47Z3AcVS1/hW5/3+H6V61NwIYrIShFjlpaD4OMuwP90zC7VlwxDNQ5zuj2PnEAQf4PDeKCOb737/iXlGxg9ozvIOG73yZXazpZftXs4OwMze9o1VbmTy7lAkOb1GwIcmGcaFyWfbys7CWRcjWBh3TC8fQgPlt0EZTX09W0UbiNkSvF77HTGSkci61CPkrJi+myEPEUkgZIJrC7+RxT/J978Sn6DqFfyYRdZmtd6E5+1HJpVbPAh4ndCM0rVwV7gSsE7pIj1Haoongu+DzrXScSoBSH9ZRnPHnMVG/Ff+RgP+BGQbl06heIdwWyjJUBkqHOcaUCzpX/lMSUUJNOvB8BzhBgqVM6z80rYKWlUfFFRKFL1ZjwriacJ5z/aYX+HfWxk1iSSugcd5O/jrlu9Xjb477n4CQZxgA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(2017020603029)(8121501046)(5005006)(20170203043)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39860400002)(39450400003)(39850400002)(189002)(199003)(33656002)(66066001)(122556002)(230783001)(92566002)(53936002)(73180200002)(86362001)(450100001)(189998001)(3280700002)(2900100001)(97736004)(7696004)(68736007)(8676002)(6916009)(5660300001)(8936002)(81156014)(81166006)(102836003)(3846002)(6116002)(305945005)(25786008)(7736002)(99286003)(6436002)(110136004)(55016002)(9686003)(6306002)(38730400002)(3660700001)(101416001)(2906002)(74316002)(77096006)(6506006)(106356001)(54356999)(105586002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 16:13:51.8786 (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: [v6ops] Draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:19:43 -0000 Folks, Some time ago, I queried the WG regarding their disposition regarding Draft= -ietf-v6ops-dhcpv6-slaac-problem (https://mailarchive.ietf.org/arch/msg/v6o= ps/Tg87y6ImgSRENfeXDPLUxGweWRE). I read the consensus as being: - Continue to work on the draft - Update for Windows 10 - Reframe the draft, as suggested by Ole, Brian and Lorenzo So, the authors will work with Ole to respin the draft and possibly present= it in Chicago. Ron From nobody Tue Feb 14 09:32: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 84B721296DC for ; Tue, 14 Feb 2017 09:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p47f7kaxOA-l for ; Tue, 14 Feb 2017 09:32:40 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 177681296CE for ; Tue, 14 Feb 2017 09:32:39 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id 73so99304004otj.0 for ; Tue, 14 Feb 2017 09:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=M1nuw1gQwqo3mHXvBMIKS4Rp5tql5EkJqnIewV5ht/s=; b=Q9ecsUq2yLMj4zB58/q8/JQFmG7Nin/Q59b/Xr+M8TeQwqNQbt9etJN1f6OJXqip4X m8uJhKbrxW+jVaeH3alYvjnRSlQQHPzzV48lZlBkM0ViFghnTImB6PLNUY2lhelG4X66 AbSTW/o1sDwpEPN7KUAXLAYs74/EBdAenwPrVPfIlMILLAaZbqyufruuvwk7Nh9O0sgq niXdLxwRzixvs9oJljqpOPf1aKVHhLioasmH3I9OioQuOQXWJGsc4sTyxvpdSEvrc3zG wOAR5cNxVkCI1wXzmbCrNl+TiqRQoJQKUHt5sB+c2vKfxrUFmQoPz0GwDjAzjvixAoHW nzgw== 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=M1nuw1gQwqo3mHXvBMIKS4Rp5tql5EkJqnIewV5ht/s=; b=gBwsNFqHmREUF+4W4XW1mNrNuq+lu6TUky+4CY7MLAawukAWh+06Zp5Sf20//tXNfe ErMr2JVwowrK1oUPSM+rRWf3V6GZtUOvks1sW+fIRGYBIxbRTC25WCJpfGF7uxbDan7t Ul/AqFx0J9IEAIHPVkG4+N86AESxtrFTqLFlYcZ8rpCj10Xc9yyxxA9zQueMaLS496ge 03ma9o0p5mFshwpwG6/LObVYxTIPnQCXG+XcaYt8UMVLxwUQev3UW/8vyoHSYY5Jimdv +Ser/c8Wy50ULlQggbMUrtnbytiP7Rqqeh+iH03yX05EOKj+HeFC7q2ZCNKMx8pPLorb LVsw== X-Gm-Message-State: AMke39kyPofLZaw8J2FxkhDrNBrL5ezfGYY5QqFPI+9IV7IN2dHVuew4GRCZ/YpQ8kquZw== X-Received: by 10.98.75.156 with SMTP id d28mr32857165pfj.59.1487093558190; Tue, 14 Feb 2017 09:32:38 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id i21sm2448918pfi.94.2017.02.14.09.32.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 09:32:37 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Tue, 14 Feb 2017 09:32:41 -0800 To: IPv6 Ops WG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [v6ops] Vetting draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 17:32:41 -0000 A few months ago, several authors submitted draft-ali-ipv6rtr-reqs. We = are considering bringing it into v6ops, as it is primarily operational. = To do so, we need support from the working group. Is this a draft folks would like to discuss in Chicago?= From nobody Wed Feb 15 12:28: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 BA1F0129B57 for ; Wed, 15 Feb 2017 12:28:55 -0800 (PST) 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 YnDqjj5XBqMb for ; Wed, 15 Feb 2017 12:28:54 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1A5129B52 for ; Wed, 15 Feb 2017 12:28:54 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id 189so33895663pfu.3 for ; Wed, 15 Feb 2017 12:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gvwmqt2Qx92O+aZxZdYjknno1oKToxZdlyijwyH8QgQ=; b=nTj/BJyHUXqbVhtJwQLzMhALV0Zth5zohTxFFf/rbDFhQ6Yqya/qKGd2boKi4cO7d3 XzRenVN5fj+HhyClSUYHJrJJi5Uv54lKPqkVmAZn/MQx/3QjfTEYeHRiaH4ScFJiPDH8 Ql2REzGima9qObcfWt6n282P1MRZW6mB/Ppp3Bspe8hNJP5UknPWbjqnwp0CYTLtMcQc gYbIrKq7k9pJj+MEL7o0IqPo27w8x0/px44lbzffIiCcQcjHwstwFZ38C4nYDljFolkJ cfVCieeJwkYq4kPtUL8MgrgYVGqYX/W8ekWFmOf2A+WF4b3LHhSF1BPzA+vkFuUwDvmK LLSQ== 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=gvwmqt2Qx92O+aZxZdYjknno1oKToxZdlyijwyH8QgQ=; b=X3f7DD8okIkeDlvcALwC0BFD+HF+WCcqAu608Mm5LBkG1rG9F944EFvdt6k982C9fr syaTxwyYM+skvxWwmMMVeFPmsjsbDuCl6qKF/8r3LnFf8k830WK0u73wJ8EuS9iMEGVj OX5KvcupoONiuVarcgReIS7EXtC+ogt6tydvbswoSXoylObCyk0wpW4e5TOu9y3n6CsO eaInwXnemCPuQpqJOzkFnKTvgFFbH0ZnMJO2agPUXTZnQLnNBja3eEb4027YXdsaYYlP OfrcLp+vmHTbmGosgim6VYu37dBdOfqOGtkI0+yRiDPNyw9qOpZyVY3NXbrExYZ6JuNL Xmkg== X-Gm-Message-State: AMke39nC8UMWGeDqjRtZpWqTMKDXHB7xk10soOcOqYBw8IcwLlokxCdFgtPsM62M6gtq1A+h X-Received: by 10.98.214.73 with SMTP id r70mr39374975pfg.89.1487190533915; Wed, 15 Feb 2017 12:28:53 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id b67sm9107225pfj.81.2017.02.15.12.28.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 12:28:53 -0800 (PST) From: james woodyatt Message-Id: <047986F3-FB58-40F6-950B-5DECA9A10261@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ECF22E97-4674-4766-817E-6BAC6DBDDCCF" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Feb 2017 12:28:52 -0800 In-Reply-To: To: Fred Baker References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Vetting draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:28:55 -0000 --Apple-Mail=_ECF22E97-4674-4766-817E-6BAC6DBDDCCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 14, 2017, at 09:32, Fred Baker wrote: >=20 > A few months ago, several authors submitted draft-ali-ipv6rtr-reqs. We = are considering bringing it into v6ops, as it is primarily operational. = To do so, we need support from the working group. I recently had cause to give this draft a cursory review, because I was = searching for any IETF discussion relevant to a question about how IPv6 = nodes must operate when they have interfaces where they must function as = both a host and a router. I was rather surprised not to see any = discussion in this draft about the question of whether an IPv6 router = necessarily implements any dynamic routing protocol. The only mentions of dynamic routing protocols I can find are as = follows: - In Section 2.1, Robustness Principle: which recommends that software = shouldn=E2=80=99t fail in way that causes adjacent routers to fail or = generate traffic engineering problems. - In Section 2.4, Routers: an overview of the functional requirements of = a router are listed in a table, with no mention of a dynamic routing = protocol function. On the other hand, Figure 2 contains a diagram with = boxes labeled =E2=80=9CIS-IS=E2=80=9D, =E2=80=9CBGP=E2=80=9D, =E2=80=9COSP= F=E2=80=9D and =E2=80=9COther=E2=80=9D with arrows pointing to labels = reading =E2=80=9CAdjacent Routers=E2=80=9D and =E2=80=9CPeers.=E2=80=9D When I noticed this, my first thought was =E2=80=9Cthis needs a lot of = work.=E2=80=9D And I haven=E2=80=99t really given it much thought since. = Shouldn=E2=80=99t there be a lot more here about dynamic routing = protocols? Shouldn=E2=80=99t there, at least, be something about whether = implementing one or more dynamic routing protocols is even required? Also, I note that the draft contains a normative citation to RFC 2119, = but a) it doesn=E2=80=99t include the boilerplate from RFC 2119, and b) = it=E2=80=99s classified as Information, where RFC 2119 language is = usually not used unless there is an explicit notification that IETF is = providing guidance to other standards bodies, which is also not present = here. The draft uses RFC 2119 requirements keywords very sparsely and = inconsistently. So, it=E2=80=99s hard to know what the purpose of this = document is intended to serve. Shorter james: maybe this draft needs another revision before a call for = adoption. --james woodyatt > --Apple-Mail=_ECF22E97-4674-4766-817E-6BAC6DBDDCCF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 14, 2017, at 09:32, Fred Baker <fredbaker.ietf@gmail.com> wrote:

A = few months ago, several authors submitted draft-ali-ipv6rtr-reqs. We are = considering bringing it into v6ops, as it is primarily operational. To = do so, we need support from the working = group.

I recently had cause to = give this draft a cursory review, because I was searching for any IETF = discussion relevant to a question about how IPv6 nodes must operate when = they have interfaces where they must function as both a host and a = router. I was rather surprised not to see any discussion in this draft = about the question of whether an IPv6 router necessarily implements any = dynamic routing protocol.

The only = mentions of dynamic routing protocols I can find are as = follows:

- In Section 2.1, = Robustness Principle: which recommends that software shouldn=E2=80=99t = fail in way that causes adjacent routers to fail or generate traffic = engineering problems.

- In Section = 2.4, Routers: an overview of the functional requirements of a router are = listed in a table, with no mention of a dynamic routing protocol = function. On the other hand, Figure 2 contains a diagram with boxes = labeled =E2=80=9CIS-IS=E2=80=9D, =E2=80=9CBGP=E2=80=9D, =E2=80=9COSPF=E2=80= =9D and =E2=80=9COther=E2=80=9D with arrows pointing to labels reading = =E2=80=9CAdjacent Routers=E2=80=9D and =E2=80=9CPeers.=E2=80=9D
=
When I noticed this, my first thought was = =E2=80=9Cthis needs a lot of work.=E2=80=9D And I haven=E2=80=99t really = given it much thought since. Shouldn=E2=80=99t there be a lot more here = about dynamic routing protocols? Shouldn=E2=80=99t there, at least, be = something about whether implementing one or more dynamic routing = protocols is even required?

Also, I = note that the draft contains a normative citation to RFC 2119, but a) it = doesn=E2=80=99t include the boilerplate from RFC 2119, and b) it=E2=80=99s= classified as Information, where RFC 2119 language is usually not used = unless there is an explicit notification that IETF is providing guidance = to other standards bodies, which is also not present here. The draft = uses RFC 2119 requirements keywords very sparsely and inconsistently. = So, it=E2=80=99s hard to know what the purpose of this document is = intended to serve.

Shorter james: = maybe this draft needs another revision before a call for = adoption.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_ECF22E97-4674-4766-817E-6BAC6DBDDCCF-- From nobody Wed Feb 15 12:57: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 5FA901297CE for ; Wed, 15 Feb 2017 12:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76QL3GwCRqRo for ; Wed, 15 Feb 2017 12:57:29 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 1EBB9129717 for ; Wed, 15 Feb 2017 12:57:29 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id o64so8510437pfb.1 for ; Wed, 15 Feb 2017 12:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vyD0GhSVfTGpgIUYD4V1VkCk5oMAF7bBfksYxSmfL9I=; b=GYElLXj56UV3juZnb9rNANaxLQfn2gy5S8IKhEn27l/wdO30AF3BVUSMBRIU6Cm+Fk X7umRmQ1HDmGtN67mxRkM8rezmbMun/yFeGtRpLZ5uGgcqJfccE1oBMFRKzK6VYyfciK kfaIgayQQN5UnM/fgTFq+Iq/lgIOW76xd0btn57aGCQRnOA6ASHk2WloYC2fkDEhozC/ zm0TnIu2RjbFLr9KlGR8GC5ZmQqraDHq334CgXxxPWvYBqG+oWdciKCGPygN45yEo3T+ nLOgxPwLx0FyuzZoE38iDqratcrUz5wv6t/xUg+uPZh5vMYcS2jDesP5RFiemPnNTnrX WSAA== 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=vyD0GhSVfTGpgIUYD4V1VkCk5oMAF7bBfksYxSmfL9I=; b=hADdo9vYle/JJ8rMiRLREhaJ0Rg/3M6Rqx/55L2Dak7Nvapufvx5h4IbSayVmMY/RD AqrO6mByjQr8GCztuEBEs4c9nkRskM4H0EX+l5ORccVxXQclc1BMTXCaFA9moMkAXKJx NhDv8TyAj96eqRjCp6KfIuG240i57ufByAQIPlZSCS4eAbAP54ESClYEtJqmrX3QfN5c YvAv/d8x5T+REVSIWberDesDiAikpeVMy1tR0MTyGYHuy1iImjF55TYBKZPYfrt33Idy I8GZSQcXvsdxU6bH14P3pZbNGNlp27fxI1lF682Ve/uPoMu8CgcCgoL01d8SpxXYPvnd 4DVQ== X-Gm-Message-State: AMke39l4OmYdiGaFQxc51dtNeRYQgkU4DMfs9j1dutvDNGayVASrT8Rc0jTmTOx7II2y/A== X-Received: by 10.84.216.15 with SMTP id m15mr2476491pli.22.1487192248619; Wed, 15 Feb 2017 12:57:28 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id b67sm9158275pfj.81.2017.02.15.12.57.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 12:57:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <047986F3-FB58-40F6-950B-5DECA9A10261@google.com> Date: Wed, 15 Feb 2017 12:57:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <52D27923-6F1E-4817-A245-9C0548047083@gmail.com> References: <047986F3-FB58-40F6-950B-5DECA9A10261@google.com> To: james woodyatt X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Vetting draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:57:30 -0000 Maybe I should clarify. We are not, at this point, calling for adoption, = but wondering whether folks want to discuss it at the coming IETF = meeting. And for the record, there is another revision in the works, = intended to be posted for this meeting. You'll note that I am listed as an author (although "contributor" might = be more appropriate). =46rom that perspective, I would agree that some = comment on dynamic routing is appropriate. The obvious next question is = "which protocols" and "what should be said". I suspect that this leads = to the weeds somewhere. Do we want to say that every router in the world = SHOULD support BGP4+, IS-IS with both IPv4 and IPv6 support, OSPFv2, = OSPFv3, RPL, and Babel, for example? Some subset of those, and if so, = which subset and why? With BGP, there are a number of optional or = updating RFCs; do we want to list the ones we think are important? In = general, a product today SHOULD support both IPv4 and IPv6, but is that = true tomorrow? At what point would a recommendation of that sort expire? Thinking out loud, several of the authors are from a well known data = center service, so the initial thinking obviously targets data centers. = If we were to put something in, it's probably about BGP4+, IS-IS, and = OSPFv3. I could imagine discussing how one configures a contention-free = switching fabric (often called a "Clos" network). That said, I could = imagine service providers having their own set of requirements, = residential networks having their own set of requirements, and IoT = networks having their own requirement. Thread, for example, only = discusses RPL, and Homenet only discusses Babel or static routing. > On Feb 15, 2017, at 12:28 PM, james woodyatt wrote: >=20 > On Feb 14, 2017, at 09:32, Fred Baker = wrote: >>=20 >> A few months ago, several authors submitted draft-ali-ipv6rtr-reqs. = We are considering bringing it into v6ops, as it is primarily = operational. To do so, we need support from the working group. >=20 > I recently had cause to give this draft a cursory review, because I = was searching for any IETF discussion relevant to a question about how = IPv6 nodes must operate when they have interfaces where they must = function as both a host and a router. I was rather surprised not to see = any discussion in this draft about the question of whether an IPv6 = router necessarily implements any dynamic routing protocol. >=20 > The only mentions of dynamic routing protocols I can find are as = follows: >=20 > - In Section 2.1, Robustness Principle: which recommends that software = shouldn=E2=80=99t fail in way that causes adjacent routers to fail or = generate traffic engineering problems. >=20 > - In Section 2.4, Routers: an overview of the functional requirements = of a router are listed in a table, with no mention of a dynamic routing = protocol function. On the other hand, Figure 2 contains a diagram with = boxes labeled =E2=80=9CIS-IS=E2=80=9D, =E2=80=9CBGP=E2=80=9D, =E2=80=9COSP= F=E2=80=9D and =E2=80=9COther=E2=80=9D with arrows pointing to labels = reading =E2=80=9CAdjacent Routers=E2=80=9D and =E2=80=9CPeers.=E2=80=9D >=20 > When I noticed this, my first thought was =E2=80=9Cthis needs a lot of = work.=E2=80=9D And I haven=E2=80=99t really given it much thought since. = Shouldn=E2=80=99t there be a lot more here about dynamic routing = protocols? Shouldn=E2=80=99t there, at least, be something about whether = implementing one or more dynamic routing protocols is even required? >=20 > Also, I note that the draft contains a normative citation to RFC 2119, = but a) it doesn=E2=80=99t include the boilerplate from RFC 2119, and b) = it=E2=80=99s classified as Information, where RFC 2119 language is = usually not used unless there is an explicit notification that IETF is = providing guidance to other standards bodies, which is also not present = here. The draft uses RFC 2119 requirements keywords very sparsely and = inconsistently. So, it=E2=80=99s hard to know what the purpose of this = document is intended to serve. >=20 > Shorter james: maybe this draft needs another revision before a call = for adoption. >=20 >=20 > --james woodyatt >=20 >=20 >=20 From nobody Thu Feb 16 13:08: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 960CF129699 for ; Thu, 16 Feb 2017 13:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY7JiiLluS2C for ; Thu, 16 Feb 2017 13:08:38 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0115.outbound.protection.outlook.com [104.47.42.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED92B12943B for ; Thu, 16 Feb 2017 13:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pFheBDRPTwpmUpAZhPU8X6+98P0GMuZIwQXtX9lR/YA=; b=LduyfG7uHqW5JGzjy+Ktk4+qAhLpRSV8HGXhg66JVjo3tY2vCdigiDJTmXOotJsfh0txd25nfdu1Kmyoeajq+nJ403ElEYbXlNCp3aKg+gBhGtUAAgciX4TimebFPNq6jxBzvXQcGsg7VPPKf1BKC8HxNRQjMycbEJUKc7zOqM4= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2050.namprd05.prod.outlook.com (10.164.23.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 16 Feb 2017 21:08:35 +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.0919.013; Thu, 16 Feb 2017 21:08:35 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: Comments on draft-ali-ipv6rtr-reqs Thread-Index: AdKIk++8VFKArdEGSIW959JavwCXbw== Date: Thu, 16 Feb 2017 21:08:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 02c26c2f-d03e-4596-878c-08d456aff88f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BLUPR0501MB2050; x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2050; 7:C32r/zGT1G5NudmZ/vzH5rE8VDGAQdPFm4wPP36QG9EhaNaYlhmSopRY1zmL3yov9BRPbYj0X8iH8ESTZZOyLEhR/OUtQioaTNTqVsy4Sn+qRudBlF0Dx9sauR/gq2ZZA4ctueoXFGQPw68r4f2lp7WSnm8gEuMwsnaieJby5PQJ9qtRMMSLbsmzWMPN/B+sMyyou45OBD/7MlCmajq4LylFD6R+h58bEpC9GVJy3SoxgIGBbWu/mdAt2lj1t9qNsARUfiMfMK8MutUQ6Vo2E1h2vIpGrU5zr/JbqZMxFGTioU556JYTj+4E7dRwzlzHDKKF8nMk4aZgBTgN8UYyrA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:BLUPR0501MB2050; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2050; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(189002)(199003)(54094003)(2906002)(6506006)(2900100001)(7696004)(25786008)(9686003)(6436002)(74316002)(66066001)(230783001)(99286003)(55016002)(3846002)(6116002)(3660700001)(5660300001)(389900003)(102836003)(122556002)(77096006)(86362001)(68736007)(3280700002)(50986999)(54356999)(450100001)(105586002)(38730400002)(110136004)(106356001)(33656002)(8936002)(7736002)(81156014)(97736004)(92566002)(101416001)(53936002)(8676002)(305945005)(81166006)(6916009)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2050; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 21:08:35.4097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2050 Archived-At: Subject: [v6ops] Comments on draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:08:39 -0000 Folks, The following are a few comments on draft-ali-ipv6rtr-reqs 1) Should Section 3.4 reference RFC 6192? 2) Also in Section 3.4, should we say that the router, unless explicitly co= nfigured to do so, MUST not accept IPv6 fragments addressed to itself. 3) In Section 4.1, should SNMP be included in the list? Or can we see the d= ay when SNMP will become obsolete? 4) In Section 5.2, you say that link-local addressing should be configurabl= e. Do you mean that the user should be able to specify the link-local addre= ss? Or do you mean that the user should be able to suppress link-local addr= essing? I think the former, but you should be specific. =20 5) In Section 5.3, you mention Jumbo Frames in the section header, but not = in the text. Maybe we should remove Jumbo Frames from the section altogethe= r 6) You might want to add this text (from RFC 2460-bis) to Section 5.6 While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process 7) The addition above has implications for Jumbo Frames. (By default, Jumbo= 's will be dropped.) I wonder if we should mention this. Ron \ hatless From nobody Thu Feb 16 13:18: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 31D7C1296B1 for ; Thu, 16 Feb 2017 13:18:26 -0800 (PST) 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 Fi88rwFw79Xi for ; Thu, 16 Feb 2017 13:18:25 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752DA129470 for ; Thu, 16 Feb 2017 13:18:25 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1GLHven018960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 13:17:58 -0800 (PST) To: Ron Bonica , IPv6 Ops WG References: From: Joe Touch Message-ID: Date: Thu, 16 Feb 2017 13:17:56 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:18:26 -0000 On 2/16/2017 1:08 PM, Ron Bonica wrote: > Folks, > > The following are a few comments on draft-ali-ipv6rtr-reqs > ... > > 2) Also in Section 3.4, should we say that the router, unless explicitly configured to do so, MUST not accept IPv6 fragments addressed to itself. This doc ought to start with "all routers MUST follow host requirements [RFC1122][RCFC2460] when sourcing or sinking IP datagrams". Which would then require that a router MUST accept IPv6 fragments as a consequence of the IPv6 link MTU (1280B) being smaller than the EMTU_R (1500B). FWIW, I wish the rest of this doc took its lead from RFC1812 and addressed those functional issues first. As it stands, it doesn't even cite 1812. Joe From nobody Thu Feb 16 13:52: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 DA67C1296CB for ; Thu, 16 Feb 2017 13:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LoJI1F5cZrh for ; Thu, 16 Feb 2017 13:52:44 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D181296A4 for ; Thu, 16 Feb 2017 13:52:43 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id 19so2451091pfo.3 for ; Thu, 16 Feb 2017 13:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v424LRjbFUylpSQuMFde6DmXvYcxywotYt3cj2jqg8Q=; b=ioZwPoCAu4mOYg4InUqtFRwSiUzXijNyMOuorXxKS/4oSqYTNG2/B2SSTEtc5c8LiA PhzLKxX7KwhgcuueKMqzGL9Pqz37PDE2WCPHEepL46zG9TMhnXDgI5kCZTA+/+setr9R iIbQgB27pwwck9MRDE4N12H2mr69votug2Kzz+06CLBsYmi3I++jaEPpgz4DMIuShHh3 sBtQnizyVUb7A6Gy9rJEs/xlhTWjTPOMgomhmfLC44AMp9CXlLD3k7WPErSSoUpH2Qeo O99nJTJCcfAVVoOxmnnWL+8Jtzu2mxPCCG6N1rw9jNgT+85fhid9JVvs7PZNRIhecgCo qApg== 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=v424LRjbFUylpSQuMFde6DmXvYcxywotYt3cj2jqg8Q=; b=reHtDBDt/AsDHiyzjtoR8v6owKI/qglHCMcYw7UdVJtE04z5fSUtBsbvOd25pmZ4lP qP0tQIqXSZxeQWveeAf/MtPQu4LvLY7DtAJY3Fyqm8O+uHUdy2qv6BsBy1yUSq3l+kBm c5S2vJnjNy9TZM2xR9jZTCZbg/OPe1tfzG3naUFdGQa7qeKJfTjpN5d835OfbzLdfk4j yRU/BIm9o0FhxW6gmvJIstCDp5wTL0E3WhEzxvVi+7ph9z7rlJ800aGyM1qFqnCyXt1f wjYZlulpeQPmQYzHOa+DTcshft2+usgud4/fBuK1rin8cjbsLfNb2WBPFNvMumxJaesN +U+w== X-Gm-Message-State: AMke39lu+gZOvNtDupLyVbtcI6l8cF74Zm2bqxNS2ApnVVbXaU23k5EQAxufBQxK5OiZaw== X-Received: by 10.99.98.132 with SMTP id w126mr5578913pgb.59.1487281963413; Thu, 16 Feb 2017 13:52:43 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id b21sm15344127pfl.87.2017.02.16.13.52.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 13:52:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Thu, 16 Feb 2017 13:52:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E0A55D1-E8A0-4A17-ACC4-197EE4264402@gmail.com> References: To: Joe Touch X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:52:45 -0000 > On Feb 16, 2017, at 1:17 PM, Joe Touch wrote: >=20 > As it stands, it doesn't even cite 1812. "Requirements for IP Version 4 Routers". Why should it? I could see the document observing that IPv4 had such a document, but = frankly it was "accumulated wisdom from past deployments" rather than = "specifications for future deployments", kind of like the way RFCs = 1122/1123 set out to clean up a lot of little messes around RFC 791 and = friends. Something that was true of 1716/1812 was a sea change in the = deployment of CIDR, and the implications of it, which 1812 tried to = document. I'm not sure I see that happening here.= From nobody Thu Feb 16 13:57: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 9B40E1295DA for ; Thu, 16 Feb 2017 13:57:45 -0800 (PST) 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 mEUad7kp6a9Z for ; Thu, 16 Feb 2017 13:57:44 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28B8129560 for ; Thu, 16 Feb 2017 13:57:44 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1GLvECp026309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 13:57:14 -0800 (PST) To: Fred Baker References: <5E0A55D1-E8A0-4A17-ACC4-197EE4264402@gmail.com> From: Joe Touch Message-ID: Date: Thu, 16 Feb 2017 13:57:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <5E0A55D1-E8A0-4A17-ACC4-197EE4264402@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:57:45 -0000 HI, Fred, On 2/16/2017 1:52 PM, Fred Baker wrote: > >> On Feb 16, 2017, at 1:17 PM, Joe Touch wrote: >> >> As it stands, it doesn't even cite 1812. > "Requirements for IP Version 4 Routers". Why should it? Because, AFAICT, there's a lot of experience there that applies to IPv6. > I could see the document observing that IPv4 had such a document, but frankly it was "accumulated wisdom from past deployments" rather than "specifications for future deployments", kind of like the way RFCs 1122/1123 set out to clean up a lot of little messes around RFC 791 and friends. Yes, but lots of RFC2460 didn't address issues from RFC1122. AFAICT, IPv6 hosts still need to follow RFC1122 translated it through IPv6 glasses. > Something that was true of 1716/1812 was a sea change in the deployment of CIDR, and the implications of it, which 1812 tried to document. I'm not sure I see that happening here. Agreed, but I was hoping that this doc would serve the same purpose for IPv6 routers that 1812 served for IPv4. A good start would be to explain how IPv6 router requirements differ from IPv4. Joe From nobody Thu Feb 16 14:15: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 0F874129565 for ; Thu, 16 Feb 2017 14:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 PyuhKdDgwBba for ; Thu, 16 Feb 2017 14:15:25 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id BB02A124281 for ; Thu, 16 Feb 2017 14:15:25 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 16 Feb 2017 22:15:25 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B179AD788D; Thu, 16 Feb 2017 14:15:24 -0800 (PST) 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=uj4Hw9qOSuj2mp0BjiptiGdWMWw=; b= SwBnp8+nDFhzRws6vkn93h+f3P4VbhRDbevEl7ZGtKYblNJSjiHe8/yTVFtJJGA1 FR7LHWgefZJpFwVkUl5YfCON8aqBxTYml3UixRjL3FYoB4ojo0pYg13axHGfOC7N 4zCjBUYDE/NVyoVQjBfTxIk5rOAbOMPdj3eSMeRrDf0= 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=fgsZTIPzvzCJfnABw0NRzVF u89dEMA/+xn5ZG8Pmv3vBSHHLDr+trXwCIdnlgyOMk68CRrUR49QCGL7xXW/Bak+ OVW7pU8KOQcrudpJu3HGCpp9FSevc+0jzTWq4ihMq7w9xvbe3Zhe17h5k9eLuoJQ ibbqsH2aTh4AFo3DbtLY= 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 86187D788B; Thu, 16 Feb 2017 14:15:24 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 976548BE15AF; Thu, 16 Feb 2017 23:15:38 +0100 (CET) From: otroan@employees.org Message-Id: <7094C97B-C2F3-4FBB-B4E5-113A181A508E@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_53710DC3-A391-40F1-81D8-9967B84A7260"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 16 Feb 2017 23:15:37 +0100 In-Reply-To: To: Joe Touch References: <5E0A55D1-E8A0-4A17-ACC4-197EE4264402@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:15:27 -0000 --Apple-Mail=_53710DC3-A391-40F1-81D8-9967B84A7260 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> I could see the document observing that IPv4 had such a document, but = frankly it was "accumulated wisdom from past deployments" rather than = "specifications for future deployments", kind of like the way RFCs = 1122/1123 set out to clean up a lot of little messes around RFC 791 and = friends. > Yes, but lots of RFC2460 didn't address issues from RFC1122. AFAICT, > IPv6 hosts still need to follow RFC1122 translated it through IPv6 = glasses. I would imagine following that as a general advice would leave most = people trying to understand IPv6, very very confused... >> Something that was true of 1716/1812 was a sea change in the = deployment of CIDR, and the implications of it, which 1812 tried to = document. I'm not sure I see that happening here. > Agreed, but I was hoping that this doc would serve the same purpose = for > IPv6 routers that 1812 served for IPv4. A good start would be to = explain > how IPv6 router requirements differ from IPv4. Best regards, Ole --Apple-Mail=_53710DC3-A391-40F1-81D8-9967B84A7260 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 iQIcBAEBCgAGBQJYpiSKAAoJEL7aWKiYQt92cTkP/REftLu0R59SRsdVtrOusQj8 lv86NwtASto6LF1LiVLPvaMvoO6LL/v339p2WFq2QUG1FCJ+xWUeKzC+RUO4QWl5 4/Kq7p1fFAtuefigqXrxI69F72DZlrf7ZTLubwSCfwBhb1YMcGQDh6uwg6qK617/ QZhN+Fgn1g0zsX2sYu1k9X4G1vL3Gevp3k/r+1p/v9ESU1QrPsON2dYylm0wHIrX na5eILoxIm681DV0mjUtuBhL39+W6ST4qrpHtgnnz/iguuhLg+WJkF2anDXlku+r h5shuARqMIBbD8x385Od4x/E0LL9b2/aFfnrGuLwsZJNDS/qYjwZ4iBZTGatNF7b 7MLdkKZ8FYiHrM+iqFVqtUq8L/v/JXSmTQEFGrqmWfW7u3wpMySi89XS4D2oa1q/ WDN09LWZUyoiOTe0aosfYVvxg+daePTgrGo2E4R6Jp8qkBEWXqmehXm0ea3rVLGI bGm9kBf5h26w4YKLS5DrfTGZolJEBdn2R4Ks+yKTpt8bfKnGvJClkVvnVRbQ468c chH15GHZM4M8QyC1bKHtgQIQtzBqCCGZ024uAyQpIgu8KD1wUUvUZjzjliWNN+ag VVPhRm/w2hzGIsb/joB+eraIYGqfnd8DNhqQcv5bj9VQYnH2dpRvX4o7JZ2avAqs 0mzaOjFW59QmFg74qxyn =Z8n+ -----END PGP SIGNATURE----- --Apple-Mail=_53710DC3-A391-40F1-81D8-9967B84A7260-- From nobody Thu Feb 16 14:26:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D0C124281 for ; Thu, 16 Feb 2017 14:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[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, T_FREEMAIL_DOC_PDF=0.01, T_HK_SPAMMY_FILENAME=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 WzykVsMmZltF for ; Thu, 16 Feb 2017 14:26:22 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773F5129420 for ; Thu, 16 Feb 2017 14:26:22 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id e4so8415604pfg.1 for ; Thu, 16 Feb 2017 14:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=4JHoBF7oq6tnHaLzu0LKq/+b+JmXxvH4sVjc4eWPhP8=; b=vO1zQuZwuq6qZYjxACjQyeGiL2phxu+WqJI/ahEPSyjlYL3sHjx7fB/AN6bp6ZuC8T gwxPH8WO5o3KQ6RCBYp+wZyMmo9jH7IVn/zEjryz1g5LsLo8z8kK1R2CqxdaSZ0F5i8N dUBZZZPvrn5sp8v2E48pc7WnlR4FSv0dk6BfrghLIh2Wo5sCln+5YrsuE/3mczbnh+qF 8r5yHHfbS81aGO2sADPWjam08cHaJr2v88WGHI6le7epK7ubVVgFALkJD+HKD89vXw/K 6p8DBNaRlFHPGQ79xUgZjp2ACt64oqnsf44YY2jDQ/UFhMNCY44CMN80TU+JlW/npRE/ GOhQ== 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:date:to; bh=4JHoBF7oq6tnHaLzu0LKq/+b+JmXxvH4sVjc4eWPhP8=; b=J7JlxMYb+RbiukoIi8rcAOWk/NltOdC2Lz5ZJVN32AJw6D8mcVSt8tyQInHNj9tOqP HY7ykrqBNUjhgnOV0rL2xf5lh8IsQHZJA3m9sDqF37VV/S8n87pn7St4BsP3DJmXgPmY fmcVJX4mefAsCZtA5QYclxm6LQ3zGE//jCvVWLZrGR/VJcfcaMEifj5d6eKMctTI1XTF HJupTe/LZp1GnitMUWZbTaook/q5xXp28+rVzB+mRClJSThYLBnKB+y34QMXjlitoENk KRvh0Y9bhaOGUUXWu6zxMVs8LRYIlo0o3gIqlXbwwyoKUoAyXxHK71mrpfcbTWIzGlk3 bBaQ== X-Gm-Message-State: AMke39lC1muKLWEkGKlGyCWIW3Qa5L3fjy5O0hTsR570vlaTG/76C8TfUcge7burY9TyHQ== X-Received: by 10.99.64.69 with SMTP id n66mr5853249pga.1.1487283981727; Thu, 16 Feb 2017 14:26:21 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id f191sm15532712pgc.12.2017.02.16.14.26.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 14:26:20 -0800 (PST) From: Fred Baker Content-Type: multipart/mixed; boundary="Apple-Mail=_0A19FD05-2255-424C-8A8A-5A2D7B615C0A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Thu, 16 Feb 2017 14:26:18 -0800 To: IPv6 Ops WG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [v6ops] Looking for comments in a charter update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:26:24 -0000 --Apple-Mail=_0A19FD05-2255-424C-8A8A-5A2D7B615C0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The chairs and ADs have been discussing a possible charter update. We're = interested in your comments - yea, nay, other topics, and all that. See = attached. In short, we have watched the discussions relevant to v6ops change over = time. At one point, the predecessor working group was developing overlay = and transition technologies, and v6ops was chartered in part to say that = *that* discussion was pretty much done as IPv6 moved into native = deployment. There were (and are) still interactions with the IPv4 = network, but the focus has moved. We are now seeing real IPv6-only deployments and progress toward more: https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/ = https://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-ser= vice-is-coming-soon-get-your-apps-ready/ = http://www.internetsociety.org/deploy360/resources/case-study-facebook-mov= ing-to-an-ipv6-only-internal-network/ = https://engineering.linkedin.com/blog/2016/11/ipv6-inside-linkedin-part-ii= i--the-elephant-in-the-room = https://blog.apnic.net/2017/01/31/chinas-first-ipv6-backbone-network-conne= ct-1200-campuses/ On my phone, I observe that I am IPv6-only (and have a DNS server with a = ULA address). Google reports that the vast majority of accesses it = receives from Verizon use IPv6. Several measurement sources indicate = that they see over 5% of traffic in 33 countries using IPv6, and greater = than 20% in six countries. Belgium... = https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe,us= ,gr,de,ch,lu,ec,gb,ee,pt,ca,pe,in,jp,fr,no,br,my,fi,tt,cz,nl,ie,au,ro,nz,h= u,zw,si,gt,sa,vn,ax = https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe,us= ,gr,de,ch,lu In addition to "what if we turn IPv4 off", we are starting to see = creative thinking about opportunities that arise when we do. For = example, what if we run a prefix to a host (RFC 7934), and use addresses = to identify containers or processes? Tom Herbert presented to us on a = different data center model in draft-herbert-nvo3-ila. So we want to explicitly add and invite a topic: what issues and = opportunities do we encounter as we turn down IPv4? What are, if you = will, the carrots and the sticks? One thought that I have as I click "send" has to do with markets. When = IPv6 was designed, we mostly thought about service providers and what = belonged in someone's favorite computer. We now also think about content = providers, data center operation, residential, enterprise, and IoT = markets - which overlap but have differing requirements. It might be of = value to not tiptoe around that. Is this, or something else, important = to bring into a revised charter? --Apple-Mail=_0A19FD05-2255-424C-8A8A-5A2D7B615C0A Content-Disposition: inline; filename="Microsoft Word - IPv6 Operations (v6ops) -.docx.pdf" Content-Type: application/pdf; x-unix-mode=0600; name="Microsoft Word - IPv6 Operations (v6ops) -.docx.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHlXVnTJMV1fa9fUQak6UF8PbUvGoyBAWRjWTbmc/AAelAM ImTHjDCLw3/f52bmPTdr6eqs7mZaEYaI+aqrsrIy73ruze2H/Iv8h7wcjmWTl82x7MZxyNu+y/tu PNZ1/uOf86/yv+bPXvxU5i9/yovj2IxFOXZrV9lPL/OmaI7F0Fd5VdbHvm4r1N0dx7aTWtsjfqPG 76KPVkV/xCebpjniLZbJpl8ta/cfvrq8wld/kAd90xRFkbv/+asZj1XR5n01HMeyGrKXr/OPH/PW Fwt/Hl/nzx4f0dL88bv86/zwd09RXZUf3nqaP7iLt/XinfDkV/5Gdvi1PnmiF98cePVUr1hK339X n7Dm3zzN/LdYljW+98BSR33vWWiIVsjChXuQHfRBGQpWdaPv6qNWb3RP8z/mj5/nnz6CLyYOa5zJ FvKw5IfxaJMzJcShB9N28EZ69fhfb7ydohxFuaOdkKFeiUuWLXk+jMr0bygq7/12xtnnA7lvpZT9 ZOFRawqSmVMA7CW2RAVAZYMPfLXZgV8c+Ii39NOo5A5CU43DsW5hRXYp9HOqB/vTkXSd9qhVGrLQ gpisx6uZo/LlVOiLcSjqEcamqMu6r9pWzJjcqqp8U3dqMWvNMOwjg/K7qt+/hnlXNLvrjt3Y1zua ffj7y1X+moaOx64od+o8pYMCRGMeqXW2JjBJrnfZn2wiLyIVddXCd1c9PDnEox5gYuF6CzjeuhLv mOB9lzZ++eFUQVX3C4Ax9lWS9zUphcdao1WaX7q8zSKkrSCXPrXV9xFSALS27Ws40NR2wi8lyqiD PcaJHfZihhghoZdzogQ2HJp+TO/hfThRluhlW/bp7QQnjLoLZEao0KtLMi8Ok5KqFDdlRQOTUoyw iKnCdidWtPCmJTxMajPBCSIAo/LzD9LJfEt7WfbFsYb1mbUfoQGMd5U/vtwKXQ6/feebp/A9l0Lk KxR1aBBezRq9HWRRxudoNIpU/uHZU9gPRGKDcYa+taNztYcG5ULkFpm7EF/p51jPAtmOCt358vBB p6/pt7IDK4h7colqZi6uvpz4dVkeu66dkz9NZI5P3n0b8d+bF5m6bo9NVc9tZqKkfwh+XNrmiyPW uoEwdjvlfJFMsMBDZepdtfIUxd+oCFLGKYtnsgF/zJaB/E3AJZBcOdQCivpjVQ15NZbHoq8lEXQV tryYGwoti+E4IL2UhC0fGJbT5isTLG/ztrJDH5EbA7nAW2TZQFa9p+8hf7TGjjX8OnPVAq/nGS/B +uHeZmxYViUUq0RsGCiTr+S8snnOS+1avmLX2DN2NjJ53kCr4SWBlAZWb81n1ICoGvS4yg5azenM G19hJTWvLKZ/oiykkdb2sBE3ieCVIcYau9pkUiWRWS2R8B7xPU8eDyoj56SvkHXbKR3nbUlQZpW0 FlJPydmxXmqEcTzy2urIWVwrMBSMGMNnQPWRVUQuBu6vpTfT8Vqsa973XszGeugRg3ULNqb53gY9 feNOLJjNDom0seySrCbJT+6pPERQKcArQKV5BpNvsZ6OZniIZC2w/1equ0s5oPLzwpKjQEAqQPxO XNUlyMyPeATpiOxvopJjMOU4jH0eaH21HVaCrKQzqakk9nPlEclihlIf0VOpMQz6nR0G/ZYpIb0A L7TMtg4HwSBTyLvl64tAmC+xYXybHe0+vEb1r4DdDfzsiBxhsipdM3xxTTtraHo9pLcTIfFHpLxy iWL0QEtPLzuoQJm08H19hHrWVHAFm+6Pp2thRY9BSySXMfKHYcTy2I9x3lPqTBh1nI11bhFdBjvP DjsiB3scimJYU/2cECzzw45GvI4kppRTnZUfdMWqu/7BCoayeiNeOEdPmGVFLNA9qB1mG3hB5mpj tGJWyKLaqo6PaPv1Jao0u0S3svgQRW7a6zibtsARlNxZbdmh4xdtiFW7xMLsiraXrePbzul5IKyv sxD7zWY85y0tzBvKBzRNn0UejpSjBdYmsY2kpb6+HNTCk0RFjIGSd4VBIdDV9RErDRI74KJCxvzr GlFiWVbXRolbmrg9VKZ4p4cmpsEdMooiwAtyvAangmNTHvA1FuJrZCbL8JHnUwTYyUqtl5LEeocP lLu8FRkMBWIqSzmjKn6dr7EZO3zofvN82kyWvQwIVk3eJbJn3YXexIlQdnv4kLLLSwyiNUPXmOhe 5kQ2gos0H9IhVGyaBB+yTpxfON2g+tWKp2vWHN001yCza9KCnqX5uRiJt82xrUsM6XWpzQQGolWm SqraGeBdINaPw/ybSCFDXDOJhiXdkR82FJIm40VIgVNnhw/4GtV3MVHhkzCLxDJWwXlkB7YMvVlz BLvk5YKgaKyQra7bXaz41GYvkQ7sR/eZ8oXejxyrkcy7upNg1lLyNuFf1dRIjmJAcI+80auvdFF7 SEYTCwRhyA7LzrPCpcCQQJQzBVREWBICXk26/fIBNT32g7iEHaqqvvK0yi5pGkiAWHeXp1ROsEIl 3DtBUdeNw05KZjbhcsN/pCGfZjgiDklLkNOiUECUtBEMUYSxTPUYJVFRapeXgOLiLiOp1TVVg0Bw T6epOcpbmhYzn0iehG6zNElEHaJMsAKWmQiZDxWolXyN1Dc6Uoe1bXMLkJkXYcvsddb4nC3ZodY3 5ExVNZDCDmZ/D2eWlFEyUNNpryigWkQll5XoA9KJNAn8WpvPyxzZClFZkdbMT3E6Lz8xEQDv/vlM X183HW5khMJCjupLvMHqFpSImz6XYlSTqqgzQLZq2+kq02yTDIM0aaaJ3fsdacFBPN5hHpRqcppM Kh8kF7mHeF4CopWh1F3gaD9uKDFrpS1GOD9PmAQ4jf69cTitmL+qjoOk3VIGGBfj4OSncujBxDTi p0PPNuCj3pa8ek4ktDTDWli/4DmeXYPsc8PPHCdeUW12gO2kmrKZLwJGD0UARK5C9lHLFIqwFfym yjybpaShn+ETNovZBuHPhbZiVRUSbUVd1EjqwnNMxS3MFMnOzIl6lqwgN/R2NUZ1iwrhsLY5aZxN mUPftlCR4HCiGfpEGksGnpkp4iJQsDQ4BMpn7NR2cvuWqLWsjmOdOK2DMktqkHIT3bwGd5ku6ehl xAXqF0uBnDuId6vVTljhhOm2FfBvMvnSk0Y31I8SaeGywjTH9HZuz5il9NIoqzKd9O53WPGE0aAa ufD0Tt+FOcG7txhLK7quSTJd5717AGSZzUA3d0/bRT2iRq+7cEnOBbtFTVdPtpkq0kJzqUh0vkSV FhgSfjCG0G9Y/2wM5x/vYhYqWIMCODtP5+ldJW8oj3VfpEneP+msDyB259KU/J9Thn6tskLr/JxX aib0LT6gRaFPYQZ1/o7KqAnFg1bHWiim+nKQwEgf3LDODqcxG6xepigT8VWJRFuPpb5tIHsSnCdx SR72cOJyPU9YeoCGey9s2kEaxcjDsZK6ZdPMpAJfpydkRD99QBayPjaNn1IusGwRmiXh/h14UGH8 q2mH5pdkAvvKlAnJYcygKV5Qs1Pck9v6UHKT9pQfUQoTzGqFiwfkjorGehpkJ1duiEXbvjxicaYu X0ucol6CummR+Q2BVdvJRBisCZu1eXsthrKEnFidJOr1dj67z0SH0kS9U5bzRviATVKxLz5QclgP H2o9Nl+DYsoVUtoHVkObw/rEdKRK0Q15UkK3uwrzAHfxhM3nVDzqmD36ANQPOMicD60mO076z4xn tBzQk9gYQ7Xlx8wGKztI6lXT8OFdRt7qAlO/ZLW+Evu8N0uHOrME6DVJDQXZLfbEaMfqfCsR//xz CtQJo83kjUIdY+2CfZQT+nKKkGqVvuOhDtAyxSId6kTSRqiTJew5cZLqRn+72p5SQaizQXadl5fp diDsKslDw7QOde5hYyS0LHrYmNCzpKjNwNS2FfeWn0JhlsAqUEEhsVRiKIjBCEVZE8qdvsyyiqj3 oLEbWmxDY3uoya6fkZObZKEC7Uyr12SSk0ZJWLaRtDc+BUeyasxRKlWqoa63SmepkWywVLDRcDBt bcXYPnvrHcjVG0dgXJXfTlq9DcDobclFZYth4ffV088fkZWqRqxkFcZJ9JQdbgHjZGahF2b74hkY lypEN1TmcsS2VnUH07iDIatIM7hWJTNnBCyVijiLj/5forjlrF2IS9oGN5ixVwwtmXYeH12D4s5N az49gbVGwNUWErd74fpbbada0mqU8fbzrQTa/P1t0SZjEPqiLhq6tcVb1BiYNbEWlyHEpeQJRPRb K52BiFV7rEZM+21P02oKEW8geWicTqhP1RCZntyXWIy+0c7pzFvwdBvmiWfIbR4hOQE+BWxgyyQW TseqNvsYDCYrEpZePKliydJUUlWICYex2WTplFQ3YCkapyw10dueFIMBY4wP9ftYSuIqZlZ4oGw4 hS2iiWOrkC8d8S2d9ZJXyTRo62PlElhe/c7HMem8um07W6xc6Mir8+1MVD8mZxlF8IKs5no7hmRU R1pXz/6IycRoO7Z7jEPvq7cpwfSNdjSDdZ5i9+EsdlDD3A3snxAM6/l2grMkOxmhamgAvrkmIbbU qFTrV2MxpOy+etqdzWxf8o57sXSkrQ/bAlJYojFglWpyO0F1KgSpzrzwqczBTZcKtZhuUWCWTy1b bpTI4nEvFDE1d1hv2pZYcV5gAezKjDwFLXkZ1puSejQwNBEreS1KOF8LRN8dS14eAy6VINWtyE5y tROvQKGg1WnJhCfwrZcmEq5oM2S1a8XFTNu8kUq4j8UssSVQ0WO7yVlDEwfKnr0FubsDeWEQsSXm otV/e+TFZKmuwoqpGXk3GgrbaHNObNyW1lGxIVMYNKCY4ZKqnzPzD390hax3zvzLyn1vwc573TvJ egdZL9pxR0NX4QEJTnO6c0nxVSt2L15gI7u6t4246Sv5dFs/jGnzRYfNyUqIUTUgwXF3R4w5yzJ9 9bwjPmC/gjTjN9M3cX2X7hEm2bW2wWqcdqOdU1gIKZ7PsPo4zMRJwA9RHEKBpwpY6oAGStHzah42 JCPMiK3kGfxWUszDanDMj4d8bNQuJqiIgtjA6EupxnEZay6YFTFwczGpWyQ/DLCNgVnnbSOYpT0m bmO32FGdb8Miq3kAsoKJBBKR4Sdn2EV1o3vIJsXb6gU2aYUsy5Zhta4rs7YOaylkfB8V3oEtsiyh Am/2sYW0pnApOeJ5q0HC2WfKsakK34/JsJrAyw6WaN1I4JELcYVrdL2t6S6qIyInHAByHGR7ySsN 94aSbad9Q4K8GWG3cbpJSvx0mpXLJ6qNVJ2Bq51sCJevsRSZbHxfmEgWhkkDBoPO/csfNHVfqXCR p1Fkp21S6zbZSCvbPgckwReZedumfNlhCkw5jnkC7f2cjHTkl9BMSaOkbKupAoLJXFi5sCohC4d5 ela8TaFYcCjwM1FraRlsgyUKRDDPkTWlGJz6an7OVngJ09fj5NbMurMVMGJrVmRtJeUNnWYFfFo3 yIQ0gWFJTpM2MFITVY9IO4N5TtFO1vg7GnPewuaHoSbeYpW2Xns+Us92WNlgEzI7dYaMXpbmGgYw 8Q6MqWscW4DNGvcxZtkNZQtJJywL5EyZ90LF4bRKfsNXHS0T3UGpkxYnsjM7LQ72/yklplnxSQuL YwrJbdDOy4/X5mgHEeK6DbfDtddS5g5yVGLX86qRk8MCfZIU/DkXs1J7KEAqUTyViSZsZVNTI/Ri C6B5zebgKWpxzWpL+XAmh9FGRHDwqZQ+KYeRW06UQ2zSDkr3JPSlgqgdpW0i5YlpQtezg0YCcR6L 72lFJp1UZrsVuGArx0nzqG5+2N7jfg8sz1BRBWRIF/iTbNhvDmrkNtx5aSrwSXywjlEsEw9OmDs5 UP1C4Vvta6LwKezCGqUC461JSm7garA9b+cOdUUwOEdrotypnb4heMFBK5iDguPAsCQosdvXnLai +NdYYlfbmQmsKwRyr3e0E5kJKhYlkmoYjdohAHlzIUhdHDucU8l+rKmWjp9xXjibTzumBoKmnF0N O4rcYc0x8tUj9sdl185rUHp4dUORVz1vKiz9rNP0fKKmPuGnroGET9qIhx6Xr5G3Zj+Z49Jv2COW Xrgo3qCMhDAgCsr40ZQNG9hUm8XxRjVlkFNbCgTrgVFJmmIjUCQDPTZ1hT1TLWK+UfMaa9si8y3N ZvDGc+UTAy9dtGKAjKS3LdVpi9hCFhL/cAdvIInGrkduTGl+XoVhZZWKpLhtO0xx5Vwjdpp9ZZRI erIiEuZT4ysqD3hBqW7aIeVTyebwUhafN3yxc1KLUldYvDno6oHtQdOPKCu8IGlIiOfoWuisEpnP SD/QOLXPN7SiOJMHO9bioLBmT68XJzZo3irKgnBjLVNC9pXT0ZT3lWqaiSELQ9MC8UjZxff/VfOX fIsR6Yzi0cbJlNi94haOt77yKJAKafFmwFHTu0h/hlIhp0bXs6DUvymlvtCLz5UJpN00XMn0tO+1 BNzJcMWiRrvaTutiGBaHZWEandLjvKdIBx4J7YyCjk0MW+F48m5ojG9r7VzkWT6nQMoAV6qmo9m3 WhpVY9xkj5rfJT6oixaHRmK2gMpAkucirFNJXlWSYETWHPdnuziSf3Ubf4NjqbHV/QCknWx70wX+ hj6ibrGveYN5T+ntBJwwd24Ti5Q/apOJAQgVLjTFmEwaqa8Fo3a1qdLq+THhGNPp02IJ+ns7kYgj dEhChawQFj6zbyuOkMDKlrPY+DcxQvB70dQDJWAU/iL4TQ9/r3RdgFg4w6+CCdxDMfoXRd5LcQiD +SSZlqCrNpxAe0pGEGbyQxzgXBNGu8cXz/AqWJA1XhGaLJqunY0bBZe4dnYdi1g+SgnAThoBVAYI j9Ys2159upFlQ6zX1Djl7DL5YFpNu0iiWtRAzSHRyALeodRQk1iRDF07JuwlUMB+k4O+IoSz0+Ag HVYV2Lo8ZaTm3xWwsX+MhNmtKFNtoziwjBjjV1oySOZLKmPxfJKAIyl2QUWyw4swhYuNSN2DNBXy 3NBxuePUepkoEOichCZMw5YmRkkllj5YA6b/SSurwJLJy7SOVhVkM4pLWBG/r7zTd/Q3mTB9EA1E ssTEpKTy4obws8Ki6kYS1HtYYSbaLLPd674MOkw9N8qTdCTmIhKKKlLyMWalbvBiyUDeMU2Lcf2b CpsUuwi873AKzYop0UQ0F3JY12lG2RulhXkTyhBpCapcvixzkZ+JkNsmShtGJKZxdHCOfMXJvi4C rygloWpDpmpfaUjpKHzRSJG0qNZBM0rqTDTMmVwjM8Q3mAu7F8Q3P6SJrzaAU0DIOjzZodDxJoAR 5c1x2dUmNyoMp7cymh6YkWZbSXozjbwVcSEQC128sGerLjm1ZziLpR0qjF/vkTNyURm1OhM5+FWV Ihp/ShG5SlCqZVlEP8Cw1xy3Jr5ZNlZZP+Cxog+Uer4WWpFFURzhlX7eJJltjo1IKuNu6O+DKaxx YFDZJO5DyyZTDEky9pgIO2W8ha+bM7KQjnk5fu1hMolyRwh3Zchb1g3mrWK/jHRq3SX5oDzFuW9N m7jD62PAqAQBqkK8YfZYpZnGhzpgh+ZRP7SeiHv+/ezA9xeF6Sn4hPqiH9d6Q9Eo0KcV6MwfU8LY DK1n2QgKHIVZy5pQLqoxzaZ2BKq4w8BSNfuWOVckHOoegVId5GAN5ixcv5KVHWR3lkQgjPcvRZ6f b+tLL3aGQPeYgiXnCTQjjovfRbBPQs/MdFFjKHRKBeoJfQVFjLSkxGsSRF9WzlA3SOSlZrIS6oLJ J+pLlcZfwM903bEGIE1CPjbyaYo3mREp3jkKAkGh1J6d1LNVeLcJ6gZ4zm4AqqtD35L0jBwyxlAW lONksE1rNlZHR7HPxSoXr+PQNJ/MhSl8fko89wo/ik8F5EWaa7Vam8k8Nqi8h8qWOIusGepxH+1P a5J20BzHwwPVmZEueacVUXmNmfRXC/tJ0isV9aNa21LBtQR9FfkqDtfnqp5TfMg3a82Ah6mqcUOl rzGpte0xWqOqkaT2pCZJx+6ya7BrvtukM8soGZVoSuYF11Ag0ORNTu5RcIY9zWrZLikl98Buk8cW OFMmlmJjGqzUIg1INqWSUi2u5Q4Sg1OsscC9y2XLNyHPeYG5C8IucX4mjoFBJJDcTgzvafD5Hzr1 Q0F3vMz8Da4JqxEfNDiTQDuxJYv3XBSG083RyEZWLZ7Sl+zZ4yNWpueP3+UgtNI3FuYQyVOVVPDN vgc3Z3OWDXUs3jLTqvWYy6Bu6cadS62jT6HV4h0iNn5Tvf9kXNRmJu4axJyMwezHOiXADjYhgX6e 5sYipGD32VlSSInHJ2qs/YMoqOMraqhIHrNyJ3EKkxGLUbKlhGiTXswhFAdtItAUJ7BSrWUMPa8c U64Af+oRG1IHdpy3llCOT5ICFu9dldjkj1KHXodPLPTnrcCzSKGwimk6hZghkikUJ7pRbmxlNUPz qDiadAnpr8wFNd4oYU47NtTScCZto6MRBErbjOKGUKxFlNJ3Y5vX0yZvT9U0ppIZKhLUvwecQeAi B5UNdXNTXd4aTTUVXgAVmkMaAIqXfo+giE8oeNRPtnbP9OIbamrZgUQ4im0X9S3+VVLqX3IDBw+E vD97SEIpp5ROfGlRIrw7cTDn39Z6tWRkS0ObtMSLk7Y0P7Ax4FWqHt9QL6qhPg6N4ItkvbgL4pQZ lBVmh6Q3c6epX0qHcs9srd45bf0jj61iQcF8iAZ9ncHQEpHgTNzDZmVoS6q4QI9vNSM0mP0KS5lw BHqSv41muDGyXSBL85FmCx9oz2yKCkNiZYVahGkqJom8+YGWk8xfQChCJ/2QfjhVp2N/nyWCD5+8 YqNUTkySMAB0j3QTlkJjj2PArcD/tYBpCn/XbcXK5i7qa77OMd8Dkl3k3/rDtV58CWps7vn25Yt8 vuUniF72mH9aFDl27aoqbNHQw9BhIok7BryqEWJX2EvwdY4tHGBUEFe9yr90I2n2ZoFGbFSEzmd8 +3WOA5iiep69+Kn0scZm05FYbQvMH8URtH3VHUfZVfO13sp56xW2LcGGxdgEtMd+gtIzNBdH3OO8 +7jQoqpX+V+wQejXjppXU7HEt0DDVpQeWwUcAaUq+Xf665UQQp7JUD9aWfbYkDeUxK/oPTQuE5KX 7n+hBJZ9jVhZkmNpnpu1IaRY3HuFe3jcYP8clmsHbFNeY6RP7pStbMId7qAMMhUjzkOV+n0pkAyk K9sKzYvuYf05bmnljh9NjxetCeCQu/PSzVEsMLToqO/ugR/Yn7UYRNK0HNaw4bwcDCr32EZdKtcb 1gKpyheylkpVvBf6o5W7HsqMFpRBKOqaoNR66bhd5f97Rh1iRmIfYmgCzq14DR6Fy1e47MA9zJqR J/iBIjidDme+VfqrBz3dA8x9zl9l/lL2Xq6wyxJfrzEhwlUrFy/zCoKO33hBLgup0P106liHtzP/ C9XKC6KnKCUvuMvQCr4uDXTVyoUQQCRKFLfALuiYToWIRFji7vjLpsJCN2ESdgipsN7N5x9x8reU CX8eX+fIp9TMp3wWEP73PwYg9/pPP//853D9rcZ0cO/mkVc/jcn7OKtbpMZ/PPjPtY83/uOH3GKl 9SohWT02BU6vErjoM23y93/9OfRCsck34qK8z/pz6PV3fwpl/udVuNCXBBmd6fKI9QqyRWF6+852 ecRaGmx7uKNKdPkj7dWP/xk6ob3STr2HvvDcgDVatzBpfUzrDdlpQr7wDPta7HSJSc/sylqNwaGq QJTVtkTInpkjNoxTgidUea6RMGzY99J4mFDlf0NENMbHzrIVBLTsjoNQj5uv5bByBWyO28XaF+ow hDhUcAFWCIk2JMUl4vkOTkVqajHFCmtg4kLYfbzB5jWuUAkDGKGIVb8nmT9/Tke+Dz1I172Bwuc8 eshwkAcM1H704LGHvC0VAY3gMvMVnUE8cJb1CChWwtPB7+G0lUYM+OwW6kJyDDupik8C6foRDkvu 8c3qOIhuTu752taRA8i2ctzEWQqqw3HEQ0cFEICHbeb7rT/Fypc99mkTQuBf+ekKVyPEwX66d/HT G3sHH2SV4NJPx/BBfXIMH/ReBALkvAXgiOgO9kMR+BjDB+xE3bdABjF8gHS7zamJTXCjAJxDVYpq wh1UZb5b78XwQe8ZCsAdVJ5FN0ILYvgAMOZaGsMHnDIg/cEHZ9gEdSl8UCrshQ/CTXHucP6ED965 z/w/4EMN8TP4gGFREMFjBufc/SVy6wIfBEx49FHLAJOgErlQ+IDLGD7gp9fH8Hb4hWo9fMjkYwE+ sBWED9JeBx/kYg4fHIw6BR9gZbFBsyY+1zx4DB9ghLCc4hx8iEK6Nf+DqfABPoSPr9nhMG870f80 WKbn4cNGlVMHBF/6B/Wl3//4eulMDRCctMQX2pFJHKeWOIMPDZYYciJKeaklxtuwSC6OYz3nDXEI upx/E/fG8C0Tjyd3oJAavSmVcStEbywzrye2wKDXZhi5xwJnIQYTfUFj41+M3eR4QTQ7xG6uJGO3 8AvGFyO1y9itg8dBmt3RQS0f70XGl/fU1GbYeOk4ikfTOznqOY5iaCPj28EjDLKhfmR8OwR2Ayat WfAmdwAtsIM426B3IuvLUpH15T01thlr1zs52xCZX7Y1Mr/skZpf9DFQh+aXd/aaX4kdnHFsnNDx More5IkzrQiWI/ML/ASKugfYZV2jtxYSOY3eWsnXi/mVi2B+5TIyv/LTmV9920dvUm2I3uRjwfyy FTS/0kBnfuVibn63ojc4NWzBfqfoTT9+w+gtvcr7RG/p7UuO3tKrvHH0ph++3ntq9LZV49R5HlKj tx1VpkZvO6qMo7eTThyYZjUYcHqr2VdJqmznUL39kK0CfDgVO3EJ00IaN6Uil8qF63ZeDdBx6cXX gYeEUxjYqAUp47RDB+xQyfIebCvC0VqiLu+3JcTCVrOVC7j1TSk1ry325ldHpHE8VQ44yw7xlHPZ 0nH5mfmfzmcjABRKeIc+oGFaWJ5G707iKTlCUF2nwzESyoAkes/1392LXLrQxN2jA+8xTayScF7v oC7ZsEUMN+/BzY9IgsADxC5dJrZGHh2FgufUJpgvjT26loo9ut4z/x0q1xuoKrQgcuhsaeTQ2R91 6EYHdehGrb0OXeMpcEvjqUwuI4fuAyKJp7AHUxRPYUgmOPTGybx3+kA8E4eeeTwAh+7dLT1v5NC9 R0aqtdG3nXuXaoNDR0oBkMHHXNoKOnRpoKtWLtShyxYTSh7HbEjE4E5RKUtoHCRiHLF1FpI3X8Ur 5V1CFnIooVBsBeyXcAHiUOc9Vi6UiMa8SRclL7CC+xE06V0t4c88rfsJUrhNfkACsMsP/hppq1av v32aIWhDYhR3YGQtrknrkI5ohaEgsWXzk1SkZ0nbwjfAb7JQVzsaoId0FNnDEx21+YDidR7Qixp/ 6lwOg2Fn3HTL89yZdSZqOLsQdXCbay2iCwiA9iX44QmrZoOIs8MC9zX3yjlmoDvyKq21N6I9sgxn af/kiFFm0B7p5dJJEyQOY8j4t3ya4V9hDR6ANfi3iTjjRiOTu+oHS1/+tMaZ6N42Z4CqMSG2J2tC VyessYXhMtl0vuPT+fYu9JwqQElKb2+FhMi6WuxnjWfKN08xIUe0w46EPt+nG2qHYMq+xA5vM/UQ VV/p01RRgJTfVdkSCZvI1vvY+sBJ3eJJI+9gVufbmGiAEjK7BYbvCbZ0g7H4wAkmpttCPFGOhiNR PG/JbjP3mH6iOy6dIMxUTEEYMDbQ5vjk3bcn04d/ENMV4Uz71ci0QcwQ7wv54pqlmn4Hp1dlOuyx 4bcAuzAT8XylW5PO0+ZQ5M77vPgSPbwugzTJvYldcAigxOoWxe1lB1y6O/vmqhLg7l736beopv3z KDAkjgF/jA4xEYcBo3ALUC5k4lqc1j3WLocfMnFRIZ1HEd36RedRYHKkwHJNxoWfkn+ToRKhhkfv biqFPXVzKfxPxCHRaEiM3nGGHnoq2ChC77wXoXe9Z2MfcgdNMPSOupB2kYkTEXqX0bjBjywpygfB 8U2MmqCuMFVD7sj6eosgeCeC77wXwXe9Z6MfckdqB6gM0yTYhgi/s60Rftceoa4wHqK9NoDKO3vx u0iyS5eVLZbIx9cRgnfPHDwvceiqYHifiMMvYniwdJTAUuZdeOZjJgZ++UER3MFyP0nLuauQl3PX EY53v72KOvGpag/ZpW5F8u6bITfH1hDKu5Y6LO+uIjBvY0ekuxyJ6MA8dv0bIWtXYHlRumrAsBLI +fEjoMDVWF5Q1rdP83UsvwY67N42XFJUPmvyFlz6vQ2Lf/F/pMhg6gplbmRzdHJlYW0KZW5kb2Jq CjUgMCBvYmoKOTE5NgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBS IC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDYxMiA3OTJd Cj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUNCAxMSAwIFIKL1RUMyAxMCAwIFIgL1RUMiA5 IDAgUiA+PiA+PgplbmRvYmoKMTIgMCBvYmoKPDwgL0xlbmd0aCAxMyAwIFIgL04gMyAvQWx0ZXJu YXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofP vTe90BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFR REXl3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgB wOFmZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky /wTK9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wH Zb1USZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKm EdeYaeXoyGb68bNT+WIxK5TDTeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+ U/09yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6S xOIMJwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33 EP/jwDlpzcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4 SQfIbz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+E bMECEpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQ BE6CNnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQ kkD50CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4FZwH F8Db4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx 5AMGh6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZg j2BbsJexA9hh7DscDsfAGeIccH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/ HH8e348fxr8nkAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMU SYYkF1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5 QHlDpVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8 uAJRwUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnS uLRNtDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5 z+PP2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57P nV80/+T8h+qwuol6uPpq9cPqPeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57Ve MJWZ7sxUZiWzizmhra7tpy3RPqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+ UZ+tn6S/R79bf8rA0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmS SY3JTVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxT LessH1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm +zEHPYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4 HHKRLmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FX r7eS92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkS BXUEw8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jS yEeLjRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4z XJaz7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSX hLKE0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/D NKMwQ7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ +341ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+ YGiz7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal +3fgdgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqB Go+a5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujx kc9HhUelx8KPddU71Nc3qDeUNsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmK farpJ/2f9rbQWopaodbc1om2pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37y QsaF8YuJF4c6V3Q+urTk0p2usK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/s fmnpte9tvelws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4 /Wj9Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5 jN16sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4re q74/9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMTMg MCBvYmoKMjYxMgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCAxMiAwIFIgXQplbmRvYmoKMyAw IG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gL0NvdW50IDEgL0tp ZHMgWyAyIDAgUiBdID4+CmVuZG9iagoxNCAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMg MyAwIFIgPj4KZW5kb2JqCjEwIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlw ZSAvQmFzZUZvbnQgL1lQTVVSWCtUaW1lc05ld1JvbWFuUFMtQm9sZE1UCi9Gb250RGVzY3JpcHRv ciAxNSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RD aGFyCjExNiAvV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMzMzIDAKMCAwIDAgMCAwIDAgMCAwIDcyMiAwIDYxMSAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgNTAwIDAgMCA1NTYgNDQ0 IDAgMCAwIDAgMCAwIDI3OCA4MzMgMCA1MDAgMCAwIDQ0NCAwIDMzMyBdID4+CmVuZG9iagoxNSAw IG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9ZUE1VUlgrVGltZXNOZXdS b21hblBTLUJvbGRNVCAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNTU4IC0zMDcgMjAwMCAxMDI2XSAv SXRhbGljQW5nbGUgMCAvQXNjZW50IDg5MSAvRGVzY2VudCAtMjE2IC9DYXBIZWlnaHQKNjYyIC9T dGVtViAxNTkgL0xlYWRpbmcgNDIgL1hIZWlnaHQgNDU3IC9TdGVtSCA0MyAvQXZnV2lkdGggNDI3 IC9NYXhXaWR0aAoyMDAwIC9Gb250RmlsZTIgMTYgMCBSID4+CmVuZG9iagoxNiAwIG9iago8PCAv TGVuZ3RoIDE3IDAgUiAvTGVuZ3RoMSAxNDA2NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAG9e3t8VNW1/977nHm/TiaZzOQ1ZzJnZhJmMiRMEpKQkJw8CcRAQNQEiSQ8Im/CQypoTdBq NT7gVusDbcW3V3svkxnEICqpen20WrDeVqteoJVatSLcFumtQub33WdSX7/7+f1+n/vH70zWWvux 9muttdd+nJMtm65YQaxkmAhEXbauf5Boj38Y5IVlW7f4tCjJuo8QY2hg8PJ16Xj+S4Tobrh87baB dFzpIyQzsHJF//J0nJwDnb4SCek4rQANrFy35cp03H8BaMXaDcsm85UWxPPX9V852T55H3Hf+v51 K9L808dBywY3bN4yGf8BaN3gphWT/LQb7Tem876BKcI28hdSR3YSPWFEIqXkYoyknb1EdIjzfB3b ue/nBxuXOOo+N+YYtcIPflDZxgMvGq5MfnnT+VskYqwEr0nj5xkoZyicaCWXSOTLm744JmkpPOOr xza60DcmWpNWe4zTRKY7NiZaksU+2dEoiU4yDGDEAdwAWAIQNEyJKjoTV5arYyCb0mR9mqxOk4Xl 6rNgn0PKU+OiM+n2xDhv0myNDXNqNPF4RmJRudpoEjMwXM6XQS5M00QXryUj0clrySCz0qnJltZ0 qaZ0cv0k84xyuTEANh9ABQwC9gJOA/TofQYpBewCpACiFuN8Q4CdgD2A4wA970LCWO5ozBMl5Eja 2CUiI1QKEEifyKUb17BDNEIqRjIPcL9oIKJoTpC18gFUIiRbW3lPhWRkqkYTxVNiWkYiNz/2nCiw e0gRkcFJE9l5Wg5JNDVNBqZXpwPJcDR2rNEsEnIKwEQiUlKcLpUsnho7fQhxKkwQB6U8VTiXlLLQ mnA+6ciMqY2S8HfSBWAkLoyScQAjG4TPyRCAgX1vIjqNNyTsTZrtMQn8p4gPMAwQyB5gqsVVhDj/ qWRmNq/+TwlHhlbuWKKsIh1ISp5YV2OW8D7685rwa6IQWfgDqBf0FdAC0JeFV2HkvJ8PJx1SbBjt PQT2h4RtZAqyHxG2kxjo48I1JE9j+13Cnm7nd4nicKzRLDwmXK2xbBY2kgqwrhXWJGKy76DwMHqq Cp8mTRbev08Tkiv2nPCxsIZkgesEuNyy4zlhPSkF8JGMJU222K5GqzCGYY5BLDL6SMn9GlaFXydQ Edr7Z2GYZCPvsLCDuECfEK5NuOTxg8LftPbO8lrQ3oOwGE6SNntsvNEkPIjcuPAXSPwvWmtnkqHq GGkMCbeQMgCDUD9A6AOEJOEzhD6Dmj6Daj6Daj5DLz6D0RLhJHJOgqdUOEoGhffILsD9CIsYwLYE JMhVty0RKI4dEL4vXA1JSAchO4rUa5ImO+/Z1QlnpsZ2NZ/gDc8Jb5N5AAZhvcNn5IaDwm3aUHYl PXm8wL8nTFaI7qq0LlDTdq6D54Rh4VpNEjs0CcSfR5QSh3CdVjiVtGbEhqD9hYhuAN4JOAI4BRDB thBjWEiWAOC8ha6k3RFzHBQWaYVnJ+zl8nNCO4berkmrPeHya32eNRkQHYk8b+x5zBUHicKjxUS7 qE+UyvMPCh2wn3nC3MRyGX2fn0C9XCZzk9UzYmUHhbmaLOYmZCWdnMjM0QJtCVParpqT5gzekxaN MZIw2rX8yOSUFMLJLHdMbpSEGdpoy4GJUAX1VUE1VZgn5ZoyYknJCetfLsS0EcVIH0J7AHGACB3H wB6DjmPkuJbiEKZjuNNJCiBAt9PJaQDcrDCNNAB2Ag4BjgN0WmofQgzpZWihD3gXgKHGUsQlYBXQ BxgG7AGMA04DDOSwEEU7UXCXAQ8D4oBjABG6KkE/SpDnFHzkPBYVmQyxe9QZdIgM0SE2JAyJQ7oh aSjDqFYGS2Lqao6mclQMVNVnGjQNm4Qyk2rqMgmSyWdiY6nxhGFGOYjq1M8of7fzk84vOgVn1S79 LgM73GilGeQY4BRAIIephJiEmKT+UDhcf6z+VL1wuPNY56lO4fDRY0dPHRUOR49FT0UFtTNvRqxq Cd1Ah+hOKsq0lDbQeVRcImwQhoSdgigLpUIDbEHsswxahi1CmUW1dFkEyeKzsF2WPZa4ZdxyxKKL 68f1R/TH9af1ui59n35QP6zfpd+j18uGUkODQdWLpxub2XsQ6h7gOICRYeBdWkgCpmQc+IgW56lQ B/CgFleBu7SQAlzGQwAFdb0LvmHgXQBMPi2uAJfxOECBd/8deAaBdwEY+52a7y8LqAEmBXwBRgL0 dIAeCRwPsHhgPMDGG2ewd8C/BzgO4L18ByV5SAEu4yGAgt6+rfG9DT4+8YeBd2mhPcDfTetD2qCW qwJ3aSEFuIyH2NsJpcrR6Gb3osYlwPcDjgEEUgrcANigxWRgyu4FVtnuZFEJFny2OxGCjwTxp4k3 TfI1kszJjS1pdLDdqHI3qtyNKnlMBjTwWGqc3ZNo4bz3JGamyYzyY41VWEV5V+4hewGMzAO+XwuV AjdoIZ4DV/VVPI7QcS1nEHiPFuLleC1YB4D/UVZgu/G7BykOth2p21ULI9nZ2Do5M4zOMfZMYpVT HmP7EsUSSDJNEpw0ZjIBsrfRzzT8rxq+X8N3aPgSDTtUi2L7u2L7N8X2mGJrNLM5JIBCpzX8sYZX q/aA7aOA7eWA7aGA7cGA7SD9gPjBVKjm+m1/9Nv+w2972m97wm+73W9b7LfN99su8POqiomP2FgB x/QyDeerbp/tnM/2e5/tlz7bqz7bAz5bj882wwd2+hdSAcb7NHyXhiufrrDJFbaCCtszDJ6JXppw ENNBxuilxCaYE+F6eUwwaYQVJjqDkEB+orMRJC/RuQAkN9G5CSQz0Xm73GhiDjqKzYrM7HTUyKk1 Ed6BbEuaGBPhyxDTJcI18hidSIQVkC8TAwUgXyQGvCBnEwMVIJ9z8iz9KxlgqIb+Z2Lgp6iefkKK ebX0TyTEngQdS3Q2gPvpdOt0H6mnQSQnsDvkbD9LhNE5+ngiXAzyWCIcAHk0TR5KhGXEHkgMTAX5 aWLgdpCfJAZOgOxOFK/lzd1DirV67iYhjW5OdOYhe2Oik1c0mOgsBdmQ6KwEWZOofwNkVaL+BC96 OR2lsGw6QMJaT/sTA2FkL5kcSC8p1rIXk0qt5lmJTi6SNl5Jo422Tg6khTbzPR9toqNaLWoiXAa2 +kQ4BDIzLbm6xEAEsepEMURNqxLFP4Xkpk82MIXr51kaQDd4RUoi/CSY5MTAFBBvYqAVJI+XRJ8z J1t1knqtUxmJMOeSEmGf/Dy1kAGty2YSorv3y+dR75f1Y/TihPyFOmakCflvxSD75U87l8p/7hzD jlf+BDP5yf3yMbAerUdQtcjvh0/I7w345V+EwaHmya+Fp8ovhrbJY8UH5WSnVx5Fx+IDS+W9A1oN /xpCsYT8ePEYoyi9Z+AC+e5wRL4rBCXtl38E5h/yNlDR9eFt8rWhHfIVMMQtnTfJm8MF8mDxZfLq Yt6QW14VXiCvxEAuR5kVA5fL/eHb5b5KrceXhd+QL+TBhNwxoI1odr2W0T6wQG5DD5DRwDPQg1rY ZQxFp1Ye5DLCTqU5+YZ8UdWzDKswHQZsUqcanjNcY1hqWGhownpTZAgaCg1eQ5bRaZSMdqPVaDYa jXqjaGRGYiQsayx1XI3wI1uWXju56XEIoATHEGCJcQwETBg1Mhy04plCB+u4sCleFekYM6QWxKsj HXFj16Xdo5Te1kM74uPLSMdSX/zshcoYNc9fFNcpTTTu7CAdC5s8YI6zG8coWdg9RlO8xPV5cWdz 9wFCacn1t+Zx2nb9rT09JHtrg6fBWZ9R09by36A+LbGvpbUl8vXj+TqIkCdSEL+z48Lu+BMFPfEY D6QKejriUy70Le4+wNay1a0tB9gaTnq6D9CVbG3rAp5OV7b0gK1WYyP1bA3YSCcnYGOLST1nQ/ri b7DRUSS3jNYDcaZ5dJQzYdLM05gWaXXR5m8yCTfTZo2pWbhZY/ppusEw+oEGVU5Ql24tCWsNhnVr NTYPZxsNhdDcAFBP92gsBIbRUEzLnv91dnE6+1/S2f/Cs8co/Tq/Uss/AB/OOQ7ApRWD51si/P8c WdH0P2iQJmduXd/dukJp7VNaVwD64jdvXemJDy/1+UbXb+UZvrgQ6lu6bCWn/SviW5UVLfH1Sotv dKZW7jvZ3Tx7ptIySrpbF3aPdqsrWhIz1ZmtSn9LT3LujuqN32rrpq/aqt7x37S1g1dWzduaq5X7 TlsbefZc3tZG3tZG3tZcda7WVseCJtrR1T1qJE09zdA5p0lmMWO29OUV9jRlS4P12tSpLfRck/eM SOjjxBLpiVuVprgNwGdVtDHayLMwpXmWHcmOySzPNbWFec/QxyezJCRnKE1ki6d1VQv+NuPZsuUK PNDJ5s1pxfA8nh5p1fLBsAUhYDzgRJgDEr7O30J4HZNPJJLmJZsjzd2jnZ2tnlUtedjEJ/m+O9Kz mUQi4NTaImgTo9Y2+tnaRt+izy7/TecfOz/vFMa1Hf4R7O6Pazv8cezujwCOY4fvFcbrj9QfrxfG O490Hgfv0SNHjx8VxqNHosejQtVkD3hTPRRd/fp3RWTzFTw5QrXRauNGDClbIpshAuBJMSCGjC0A LiWex4O8aATVaZmR9CiQkg5oJTdvQYQX0FK1JF6Gl7qCV8+z/7dnMhUuWHcbkXUXaJAv3IHbC5L6 PeAE4KOJOalzujVEmVidOi5kwl0H0jB5AxckP8BG7yNyJzlEeskvsW9spVNJN256PCQHjr2GdEB8 bqKjZlz9KKSDdOEqYg75I7WRvWQa+YS2kR3Y28wj92FfOBeH9EbyT2QPnZX6mOwgb9FV5EmUfpyq uG66gLanjpH5pCv1NNogpJbcRXZTOxarC6iZKqmjqGEz+SF5hvyWpMgicrduD2rpIgvI+tTTZDF5 ky6il6byyWyynlxD7iYPkOfICXojHRd1qT5SSZaSTdRAM2mxcG3qcVKte8f0VOql1BHcZq4H7zPk UxYR21KfEZV8JNLUSmzyM0k5fuvJg2Q/eZ96aKXQTOzYfi6GLK4me4Vi9LGd3ISxPUOvonsFe+ph jKaKLCNDMKkr6Tgr1L2jO53aTpwYXwV6OkIeJj8nL5I/o7Y2ulBYN9GQwj0A1tMIaUVLPyA3kH+F 5F7A7yXqoIV0Nmr+OT1Kfy+sFz5EzY+Rk+Qs+S9aTFfRa1gDu1YXO78j9RQJYYQq6phNLiFryc9o iKr0UpS9j32PXYOj8n7hfbFYPJWqTr2I6xscycm15AmM61fkLfI29NVGO+lv2TVCUndD6ir0t5Ss xCh+QB4hB8jnVEdN1EqzqI+W0yqM7Co6Tn/PCpjCuoWlwl7dLaltqVtJIWyll6xAydXkOnI9eZoc Jn8gfyYnaS5KlqJkA+2it+KI/BI7LFwiLBbuFFXxTvFJ8QXxnC5D98LEmxPHIXVeTxnpxK+XDJDt kPUYfi+Sd6lA86gXNc2kc1DTEjpAr6a76I/pQ/RRup++Qo/Qj+kp+nfmYbewO9hB9m/sMDsiFAhh oUW4X3hdLBTfFb809J8vmDg0cSplSUVS5aldqftS76VOalrIJ0HSQJphXWvIMEa/i/yY/AQy30fe IL+B3R3TfifIaejgS6qHNeWgR36q0CJagtFdQrvp9+gIvZ0+TF+mv6cn6DlGmJX58Quz6WwOW8yu ZZ+yc4JZUIRG4UrhLuHXwhfiNl0Mvyd1T+lO608YgsbXz917/ugEmVg1cefEvalK2KIelpeJOVdB mmBzc6Dl5WQjfpvIVvI9yGg7JH4fLGcvSZCD5FXyOmR/mLyHNwDHyAnt9zE0cYacJxOUQZ86asQv 3fcyaKYZ1tJHV0C36d9V9Fp6E70bv3vpT+kDkO+b9Nf0LXqMfkA/x5gIi7JGNgsj6mKXsl78lrBl bAe7me3D71fst+w99gf2hSAJGYIsFAmtwuXCjcKIEBf2Cf8u/EYMiY1iu7hGfEV8EyNv183WLdEt 092se0D3kO4F3S90J3Qp/e36B/Vj+o8MZsN0Qxe2pTcZ/tlw0PC+IWUsgj11ovdTJv0UJ7fTS8VS toum2BjG/TzbIvyS3UGf/AYH0Y2gB8txmB4TnmM/uXoXLoF/xq4lRGzRuGbCi71OniWv694SXbqP yCssl3wGf3iH0M+ex1HbQ6cLteL14uvwOtvQz4fYMWZge8HxZ2hjCbmI5pC/iBeTU5D/Yd0IZNrG jtIn2cs4OveSd8jD7CDBoZ6soFXo3XLyFPmC/BM9IPjoftjdEDlCPiXHv+6vWHq+iTXoPWyrfgY0 dIDOT73CpqT+jFn/e3o9eU/4ArZ/MZ1LS8mj5ANo/Te0gsrihJhH3oTn85J7YbV/IknMwV+IAcyg z8kBoYIsEo/DXkvPvzbRotsiXEfPskao06157nncG8MH3w1fxf2onezFXIcX0Wb0n8kb1I/15C39 u2Q32UmeEVwkKDzChllKeFX0kR/hSvACtPp9+Kd8vKt6nKwjqyBdX+rDiYdRw2pSTarpUrqItCCn nXhT69DzR+GL1NTi1D26Hl2E/IpeQF3kELyXB1K8U2eaOAnOfZiH75F2ejNJTiwn41hXPDRIY7Cm k7qtul26J3T7dM/r3tBPI1di1t4LLf6BnMGq4aPLIItPyN9g602YPSWYP43oRTvWsLWsR3iONNNc MggfWAy/3QQZLIImN6OWa8ktmE+PYA35FTlNJbqYPE/ewcxxY54vQ/tG1NNBLoLWN5NH4R2vo0mk LMcrhTDm2RfUTqvZFrTH/eyd8LPj6NP75EN4jpTWrxJaS1ugvWXkb3wuo4XppAvnAZLaT2qwUrYI r5M/4mJNIk3wLw+jXB9sw45XFTW6DygjJRNzU9VslfAczcZqaIdVLcTKPpNuRC8cGMd54qLzSOXE LNT2JHxZl+4RrL4RrAwu5hIv0V2Efr+LlexXZFOqm+42YAaoTRctVBvqZ9bVzqiprqqsKI9NKyud Gi2JhKcUF4WCAcVf6JO9Bfl5uTked7YrK9OZITnsNqvFbDIa9Dq8NaKkpFVp6/PFQ31xMaS0t0d5 XOlHQv83EvriPiS1fZsn7uPl+pH1LU4VnAPf4VTTnOpXnFTy1ZG6aImvVfHF32hRfGN00fxuhG9t UXp88ZNauFML79LCNoQLC1HA1+pZ2eKL0z5fa7xt68qR1r6WaAkdtZibleYV5mgJGTVbELQgFHcr g6PUXU+1AHO3zhhlxGjDEOO5SktrPEdBUVQjBFv7l8e75ne3tuQVFvZES+K0eZmyNE74JjqisZBm rZm4vjlu0JrxrYpjNORm32jJ+MgtYxJZ2hexLleW9y/ujgv9qKM1nhFBuy1x9/YTnq+jqBzb9R9+ MzdPGMH22MeZR0Z+6Ivvmd/9jbJ5hbyGnh7UgbIs2NY30oamb4GmOvgRL86u7+mO0+vRJI4cQW1U 6fGlz0PBvtW+uElpUlaOrO6DanJH4mTBtsJEbq56IHWc5Lb6RhZ2K4Xxhjylp78lfzSLjCzYlsxR fTnfzomWjEoZacGO2h2TAavtm4EVEHo6Twtp7DzUseAryVLeR2V2XIVFLfOhJ90KxlTN0YpqMrKs GgrA00NRKr4cGlkVNzX3jUgzeDqGSOO6oKT4Rj4nsADl5KffTumfTNEHpc8Jz+R28pWpxWn/P8Lx SCQeDnMTMTRDp+hjvRavjJZsHWP3K4OSDwTHSdIF2fb3zCiF+AsLuYJvHlPJUkTiw/O703EfWZqH i8BSHLtYH88Z/0eO6yKeM/yPnK+K9ymw5H38poW44sbQV38OKTuzdeWMOM3+P2SvSOd3XKh0zF/U 7Wsd6Zu02o6F34ql87lAITfkTYbimc3dQh5DGg+xPEHLhVEuXvQVCyLd1rgYxJ9eM+rlYwYjrFJL ob62uNTXnsY95sLCyTnzfys0ljrNS2nk62KTw4jPiEx2NN3teO234t/qnnVE6FgIl8M6Fi4aGTF/ K68NzmxkpE3xtY30jfSPpYaXKj5JGTmA/UzRyGAr3FBao2OpZ27Oi7fd0oOhrKQzYLeMNI0q9Mb5 oyq98cJF3QdwK+a7cWF3glHW3NfUw+XFmhd2T/ZXEya3SQiXEH0NzWdQJnuC7NW9QvLED8hUkZDF 4ma8Hr0VrxFqSET/BLkAaXMQ7wBfCOx42Q5M8BWKHusl2sPqlE7Rkv+fEW/6u4+ABDT3P3h0Whk9 XvV98zHiKxBCzFqSBdg6mTmdTCdbaT2ThFvEnbrLdP9hWGWcY8o3/QhnzXzsPPJRnYC6mvYx+qLe MCYY1UyiE18UiNkgvkhJjlGve5EJz9JGYsIG4WLiiUhn687XzZXO1HWeryMNCEvngKaVFWYUZgSB aL5IzvmE8XOqjnyJTzTGIXiyN/Unek54gViwH4odIDl4X5jjzKzQzyYG62ynxSHMNpUcclFXjued w54Iau/tPMOrP9lwcloZjdAYlke94g9VVkzP/EaYXtza398KaGnrX8qp8IIWRfD8Ji2htXUpbx9n dN1GnNnzSIRa1MW5wyZzhcKRxFGEo8szV3ouD+6eMlasuzxjFSJ3Zdyd/XCmfpnd4Csgfr/RV2D3 K/lTHXbmr8zLI0ZnNN9RIBewgnpjmYF2Gajh+yUzn0r3fiOk01vXKTV3qxIJSSEW6iRZUlZZlpA1 /Wxv58e9eftDnWVZVIud7IEcpZMNdScjkWllHRduG73M2LxNnaNEpFxnZkYm0xcXTSkKFwn6r2NM n+1yuzyuHJeoDwQjUihIwxwpuUBFmfkcRZAWCbr8QRKR6nCdwq80wvzZsYP00l4eLa8sj02vml6Z UREKKUplYcyd7XRl2ZlBrwgZWdnu7PJY1fQMqShUFMqL1jY4TNnNNVG25K93PHVw8Y8Ojcy8bpGU mVf+WPeVCxoH2oNBn2uVcPXKiqJg0/yJscM7//MnS3KtYurLowtDZsem3dif6e7bXiJjFuE+QnwU +ijBm61Og2gylwh+yxyLTq/TmyEsISSGzCFLyDpPaDPPswyYt5pvMNu3T9k19SnxKfPL4svmD8UP zWd1Z81mu68gy68U+Apcfn9ofknJGCtWVxcVhBw4js23Wn9pKjDiMt4wn7Ff6gsMXl9BwK8YDYYQ s86z4YI4dChIg7nxqXQqoTaHXbYze32BA3ckjNR7vQU50SxXSXGAFdNiq80WyLIX1PCEICkOBpjL GJ36LLaOhdgmGjAzIqQBOpROSnVn6jKcNaV1J7UI1SaLdLJXgknUYer0nuWm8aH0ocYUodLJT4n0 ee93KLcF2osjKc2AjqZXlWcoXEfQSnZ5uasQiqv6puZ4blFIYeVFizbNsypK5j+vKXJDWedro7WB XLuFK068cop987q6B8WJ829NH153/pKfXzXRz9UVdNn9noG06iauuukHeQ6Mf3Hqr8JR4UXcOtWx OapLL0k1ok+qial1LRU3V95uuLdSqOcv/vs7KvfX0GsMj0Z/Vvd09OXoO4VvR9+p/DBqqjS0GuZk znHPrux2Dxh/TO6tfASXCvuN1nK8Iam/R9wdvW+aSOq76pdl99Vvct/p2ksfmXGIHq83G7O76rfU Cu1G5nK6WC1v5SV3zalaGis3Ym8cKSmOlAQjJVPqyp8sP1guiOUzyzvLv19+a/n95f9S/lz5r8r/ o/xkuWWwnJbXZhkLjSuMVxhFZqw1XmDcbrzJeL/xUeOrxt8ZTRZjnnHQKGQ5jYLHFpIjqHHKQGlt O4vdRXpLS5lHnRKpcHhkzxLPBs/9nr2eQx7DMc+nnnMeweNR7VKFh8kGZnGUyCWlJQ0lYknLlGZH UA6y4CeElJoaTEOmQybRB8KISTIx0xg9qEpq/XA9U+v76ln943B5/N5VLe4qbkjl0bwIqZKqWFVM pyrBig260zpWplN1Xbo+najLmVl9kWeMTrte848bI50nN57ZGPl5r9S78Uxv76Y6mNfZE72wQWdN pLR3I+a8dIYb4PkzJ6STGe6a3o2bnBxl1NRQWF6N9JpRqrPX1ZHeCN00qufL5z6rp8DDSG/PtDI4 oFj1jHzFLAmiI1gQKgxaQjUhuzfDS6w+k5f6lRlClZdI+TYvNfuBqsVaL9GubTVvw71LZAceumlj LwHQjRGyEWnBST8erOQ+x2/Qu7L44WcydXp5DF7HpVl5rMqt58lFGfo0V3mMzX7yxq7VY7TSrRY3 hnPzQ7NrGy7a9Pr66+91281Ztlx8ObSmpWuReVttUWFONDZy16p5a5687bLVVVMKnB6XHCme1npB eft1bRubwndN/FgtlIKeOc0dP6Y1s+ZPr5qqYJnAZwWpE2IrfJMXL/W2q8rdtsdtB2xPZ4tOZ5WR eCUvc8tRk9HzoOz9N8VhgAEYxuhn++iD+KpkjF76tDHyA6vVaMEL0yVqjntbYSjLgKrwdaeEF31h 4pE8zBOmXOn2WE6DA5+1sDilNLcUSYmOSk6StTMrOFWzrPaKrtIjpWywdE8pK5VDNKRKPMPFi0q0 TFKlLumIJEo5U6t3TC49MIxeOJlNkPVZmAFiJ3v5St1w8gzWGBjE5yfP0c97I4Jdgjuqo72asov9 YVtmIKgEmd4Z4usN09uD/sxQEQnbgIIZhUW0yBEp4irmK0k4gmUEy1vpoG0wc9A/GI6XjpfqB+1D zq3uIWVwylXRG9wj0bttd2XfW/Jo9pMlz5TYhx03ZTACS+jl71EOkFKMNKewQRuxx6dRfLnXwGvv wQKVAbvIdrt0ldwIivjSrxlHRkUR7KYyU7MdGE96kRJ+rTdGqyeumLWhLbly4cqnVjavrDVZy5p+ OGdN0BMsrYi6i7vn6i748vV1WYU+sbDzjovr91z73F2ntlc00tw12QX54fM33JYl3/fA6BOhzJG0 FQi98H4u4qOVarfe2ZHVm7Uha6VrhWdbliFofgy3UK9lvMneFN6xveP6q/BfNvOQi/rVTFfFxcKA sMH/PWHIf51wg/0T20cuU9iYyqZGkynCzcBnFIy9Ol82oW3ZY7R4X14o06DDW/ik1WLK5tq1QLvZ ao6/InsVQXw/VzYWTQSTFnsFp6ono5Lklvob/Ev8p/yi3zfFQWXcpsS4dSTBr1GvM01DZRWa1Vhh TkckKuUUVt+WNhaIOoKdygm+KEUi3FgikfS2C9sv7kB6T1DptY2ahWDqFwQ97hw30+c7ZS/Jzcr2 Um9Gnpe6XUBpuwhHdmBnwZW8kRZqqpmensVcgU5MbkMFX6b4tHcJvedTpkWt/XVLq/0XjG07subi 80/c9uZnStClVBTW0s+fWXth8yXZ9+7Ys+PQJ9T18YMPXCk7y3vuVSAKvCdnAcxRiYyr+c7hDHdD nxPvtqlDh826JOskrFZ6S0DW86nppwEZ8v1sn2INyBICaraCknqdmaSlFrZaVFRhgewSMyo5SUYr KjTqUzSqKpnuiriF7rRQYpEszHKV7NzjjDuFUmeDc6dz3HncqXPyctMqKjjdH51akTF3HLvlSKR3 49lezEP+1GEHwGcidmMRPu+wvkdg57DywsrJxbyokianNk8Y6r1ZU5tgsFuXVYmBAPO7lwmvLq0S g/xcgq/U9VfANtvYXFWexajTKatmb5XRkYlPytvkTCiuTU+nV+UE5Kwx9vY+fzQg48uJt9Usf2NA rlP8joCcqShqEfUH5KIx9s7TilpLqwJyLcJqWGkKyG2KYvBHpxcaqOitiw2I3gGzGd88t+nraouL sjLN7SqMrB0jVS/y+itI+572ePt4u9judufaHQ7ZwRzh3Bx1ZmWOGolW3J9zKOdwjqDm7MxhOR8X +sNTo8iKalnRQ9HD+OAvujPKoh8TR5WM5S/c1Mhrzi3wV/Q1Hm9kexrjjeONQinQkUahMWdW+xi7 MFk4Fx4vMvcMlrSItt3m3g4irpukvXVzW1e0fIg0iJw/XPCd8H8nM5xubQnkSuB/eAQJK+GkKwyU TssrsNh0+rJQfmiabqqX6g0FllwvtdpK9TEvzbN60+aOXTXfWGvLHJm9cJvqlH1Gk8/oLdLJpsIi 4is0GiiUUYeXl5qzDPS1H29nemvAWmFV239r0c3TzTPONc2zjLfrqtk8/TzrF/jqAw5y46a0i2yH SWUXaIJOSq4G/Vjqv5JZ1jR1WhqsOK4n/0EzbOl0UC3dYUnHQbW4NFkOlMdHLTj2fvXA6XKf60r7 WA1rq/A3LBOzVm/gTpmn1bP0mQETGWnfMeDXOq+bu2h7YdftXf2bo0X1EwU1ec6sSEGkO5rhbpzI L4o6skrzigtLK5Hnrc3JKKoXHrtqYfPCixd19dx058SOtRXGQEBXlNdPf/T9lsKGhgnzitwgnwXK tAX0R0NqwCV3TJiXNegDAb0vey2TVlcYg/DZc1InhKcxL2ykkC5UPa/k0iIrdV5itIdslBjcIYPJ aClQRW5bfO0V1RC2dyIVcxUkYe3VyKw0adBIsmZmBU9VA8WRinHliMKIoip9Cg9ij3a/whSHU3Yy p3rEQjWHgXo1iqo53Q+Xa8nxo47hfUWV1Ru5xUpnIPbe9CoN2+XPWVhp50lup1ii63DmxfarhWJ7 woKy1+dl+qxMF86B+lBefm5+Tr6gd9icRRhlgZdmm5xe4jEUFNEMq72IegW7l2aa3V6Sr3MXaRpO H/xw9IOlYsWeVkxr8Bp0trTNqhvUD1mHpMGcYf1O605pOOdV9rJsHjJgTXcMeXYahm3Djp0eI+0l vRt7KJx6LBtbNRwO/Qze3O3Xa5s37ZCIYyL37HRi+6/Xrdj+9lsnPj5cPtttt7RPjXqLbFmhYK7w 4jUfjbxyw4O0+MXXaGRW5we/WNM7a06Of+YSWvjEUIGLe7YOXEeshwan0CLVbAlZaixZViktUH+A C/RPyTy5IgLBck8LOpyQK7VogTed7JA0qhZlZVdIEXqnZVeEWXJsGRWOAmzDpsgFkleaoqeubLeb +LGH0xYI98tygbZAKAF5Cl8gChRzzKF66xocan5Vg+NynQDnN0XvLTA7eon5GboEb+yXPL3LcMRw 3CBg2/eMaiFTHG7ZzdxhxZ+2Jk6SZRUVGs3zaVTNcmZXjPvpoJ8Sv4S3mO+G517E71QmVwgsEGfO 9OLceEJbJrgtRCL4ixi0zRp3ULjBmFxNtG8iJqdsegOdXln52upOb56wrPDDPXZMWFde672lsbq5 cWrlXIPZVpA7xeWjBmtp9YRhZsRoDpUJj/37Py1pbWie0yLqs/0N/Ve8XV0j5eUImIo125muKzs/ VxeEjkKpv7I7xfN4+3O3at9p2WllGrJYSc4Y3a/mUDErS3Bdx6jeZ+HfZQuWTaYVdgsTxqhdLdBZ 9ltz86iIfxTQyTqmC2dmu7ZlZWWq1qyGTEhMleD1SzPHM49kCpk5uVw6/DoIjr0Td07aEVrCGfps 50lEScP5E738Dkrbq9Rhq4I1NX1kdqVPyvwMwY8QocoMBbKoomNHjzpCUuMM7/z9PVdlmLdfM9ok np94Ytn5Q/NLC5Zljy+b6b+T/l3peWkbPwtoT6oQ78r/u8eGRAFvkIrwHy0t+KeldnyXwb+fuAhv oLg1OwH80YOH9HR1XrSgO7Jw1boVm+eu+N6CDev613ddGG3asHZ550LyvwAvRufwCmVuZHN0cmVh bQplbmRvYmoKMTcgMCBvYmoKMTAxMzQKZW5kb2JqCjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9T dWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1ZDR1FXSStUaW1lc05ld1JvbWFuUFNNVCAvRm9u dERlc2NyaXB0b3IKMTggMCBSIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFy IDMyIC9MYXN0Q2hhciAxMTcgL1dpZHRocyBbIDI1MAowIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAw IDI1MCAwIDAgMCAwIDUwMCA1MDAgMCAwIDAgMCAwIDAgMCAyNzggMCAwIDAgMCAwCjAgNzIyIDAg MCA3MjIgMCA1NTYgMCAwIDAgMCAwIDAgMCA3MjIgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAKNDQ0IDAgMCAwIDQ0NCAzMzMgMCAwIDI3OCAwIDAgMjc4IDc3OCA1MDAgNTAwIDUw MCAwIDMzMyAwIDI3OCA1MDAgXSA+PgplbmRvYmoKMTggMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNj cmlwdG9yIC9Gb250TmFtZSAvVkNHUVdJK1RpbWVzTmV3Um9tYW5QU01UIC9GbGFncyAzMiAvRm9u dEJCb3gKWy01NjggLTMwNyAyMDAwIDEwMDZdIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgODkxIC9E ZXNjZW50IC0yMTYgL0NhcEhlaWdodAo2NjIgL1N0ZW1WIDk0IC9MZWFkaW5nIDQyIC9YSGVpZ2h0 IDQ0NyAvU3RlbUggMzYgL0F2Z1dpZHRoIDQwMSAvTWF4V2lkdGggMjAwMAovRm9udEZpbGUyIDE5 IDAgUiA+PgplbmRvYmoKMTkgMCBvYmoKPDwgL0xlbmd0aCAyMCAwIFIgL0xlbmd0aDEgMjA2ODgg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBpbwJeJvFtTc+M6/29dUuWbb0arMty/sa OyJ+HdvZnGBD4sROMXY2EtY4GwWaEFOWEAONSylLaUm6BCjQG8VJwIG2GG5KS9uU9EK5wC2QtmkL FLcpTWkpsfX9ZqQEuPc+///zPZ/kmTmzb+ecOefMyFs3b1tHLGSESERdc/WqYSI+oTEEx9Zcu1XJ xeV9hOjfuGx4/dW5uH87IdqD66+6/rJcPHw7IdUvbFi3am0uTs4ibNyAhFyc1iOMb7h663W5eKga 4dBVG9fk88PLEK+9etV1+f7JrxFXrll19bpc+Z7vICwf3rhlaz7eg3DZ8OZ1+fK0jxB7Zy7vUz4F 7CcfkDT5BtETRmRSRZZj5L/V/IloEef5WrbntHvLykF7+u+GgEFU/tbvip7nwL/rr7v9463Td8rE YEPUKMrzDNTTR2Y6yQqZfLz1X2/LIoVnnP/4j5Jl0vuHpLJwa5tHOkWGpHfJXun35G04DZGRIgNq hRsGnIXTZiel3xzq7KxVJxCmKkU4XpqsPcozxgsKa38g/YY9QUpIGAlvj3uDIuet8blz80DjrBxw qKyi9u02k/QW+Qsck96S3ialuVqHSitrT7dZkUClG4mdUhIm+6Q3SQaOEVV641C8uHbvs9LPkf9T 6UWyVlR7cdzqqEWDP5aeIk4Slp6UjuRzjhyyOWpJ2xbpLqzJJPwTcCfhTsNpyEbpEbITbg/cATgN scMPw1XBdfMU6XHpcYxzP+rb4VfBbYTbA6fBEj6G9Cu5Lz0qXUGiqHundA/xILxD+ooIv4OwAPFv IT2E8JuI83BvPv4gQp7/tXz6A4h7Eb8/H96H9CDi9yLOw6/m49dK20S9rflwn7RlPBSW20LIV+Cq 4SRA9wC6B0t3D2IEPpVulq4SIziIsBYtXp0LsWs7xiMxsUc7DvkCtfuwpDuw9DuwcjuwcjuIBmW2 nyuzPVemQtqOMttRZjvKbMeqVEtb0N8WbBiBL8MpcBLWfQvWnadn4E/CnYCTyC3wx+D28Zj0eaxj EqPaLV0xXhoGsq0/1KzWtj4jXYalVqXLDgWKavd8EjOaOCJedshoy4d2XnadKLvukNHCU9cdKijK hSh1ZZtNWkO+AMeIG34crh6uA04jrRmPV4Wfli4kVxuIagvvZDulnZqdWk11B3U+K9WSHlBgmDil CpJGgWR4ME2bhozDxhGjJBsVY7VRNfYYtRulndIeSQpLVVKr1C0NStqJ7OS4vqUOgTpf11I3Zt5n zpgnzSfM2oxuUndCd1J3WqdVdNU6VdejG9IN60Z0Y7p9OuOYbkzPhszD5hGzJJsVc7VZNfeYtWE9 3dd2q7Qa0yTwZbhhuDE4DdZ4EOmKdCncIHZjEMt2KdIJfIKYDHcC8EmEWsTsKGdHOTtS7Ui1I5XA 5zk9cENww3A8V3c+51wdXv40z4ErQa4NLdkIQzs2pAOCW4SYFTErYlaUOsHOYoQyfAWuB04SaScB AWvgn8urzucPIdQRnn8ajol6PE+Fk9hZdVXJZJJmknRfko4lqZpubatVo/CcTudgbDAxWDq4X7Mx tjGxsXTjfk13rDvRXdq9X9Maa020lrbu11TFqhJVpVX7NeFYOBEuDe/X7Fl8YPGzi19arBlcvHHx zsVSE7bu0HiqulaE0QQPj4wHCmqb7G2z2QFMZxD+Xri34SQShl8F1wq3EU7DDsAPs+8h9XtI/R7p hhuE06LG91DfDp/n8zyevhdOK6C3AbHP5OMwZE+Mt9R1ty0Cyx2E2wsnoe0nUP8JUToHHRDpGfgn RXo3fF5+Hxwf5RPn60hgcCv5OOCH4VrhBuGG4bTkJWkFDocVvGX4YbhhuANwGmklviukFex7+D7B npDKVWuNJ0y8Xhw3TodBbpOZBThgpY8K/37h7xZ+q/Djqm2R9cNF1h8ust62yFoCgJWSNlS4R/gR 1dxmPdxm7W6zJtusaM1HIsTKPMLXcZ/+SfgXCr9cdUesH0Wsf4tY/xqxfiNi3RSxXhDh9QpBu1bm Fr6Z+/Re4S8SfrFqDltfCFtXhK1NYWublT5EMQYyV/gh4Qe5Tz84bO+wE+Mz9APSgfboeDoZnmBE BDQ7nm4LT9CZ8fR8BNPj6YcQ/Gs8/ZXw9+lHVBxp9MPx+Klwm4eeoQs1OOLo3/LhX+lC8jjipxGu R/gwSdMEwu+Mp2/i5b+N+l9D/FskauD1vkl6RP29dKFI/0a+3tfHy1ej1wfHy69Hr18j5ZSXvm+8 /BRSvzJevhvB3ePlVyHYM57gA7xiPF0WbnPQ9STOeNk1JMH4SBbne1yAlq9CfH6ucud4Oa/VwTuY oO3jsRoEJXyU36cx0iO6C4/HxCSLSEwMrpDExKCDJCFCG7WLwVtJVISG8dhNaEV3OHEq/I/0M3zi 5O/UPv5Q+Hffx/yWI/pbunD88fAvj/LlGg+/VD5BE0+GfxF7Jvyj+ARdPh6eLJ8wIOPZ8glGj4QP YpEzKMvok+ED5evD34uJ3P0x5GKr96Yrwg/GVoYfSCA+Hr6p/Pt8GORqzHg5svvL54QXpx8Pz0tM UGSraXSmmsItsc3hZiTPmqALDz0erolP8KFUo43HnwyXocfimBhKb9PTrIHo6Ta1XL9Vv1q/XH+R fra+Tl+hV/RF+kK92+A0yAabwWIwGQwGnUFjYAZicE9kT6opLq65dUJq04FtU6IRsAzWSEGAQppj 1MBAOxmX1MW6ls6lGWcX6Vo2N9OU6prQZy/OzEp1ZQw9n+s7SOmX+hHLsNsnKFnWN0GzPOnWYMbZ 3neUUFp1611BHm6/9a7+ftqVmVxDulYrmQ+XYh6mi1ZmtLG5fuK9ttXf6pzjaJ7X8b94QyJxqCP1 ycf/CQjIX5S5t2tpX+axov5MLQeyRf1dmflLlUv6jrJNbGNnx1E2zIP+vqP0Brap82KeTm/o6D9f jETZMIqRNA94sUMkyouRKD0kii0WrQFNo50dB6PweKHn6UJeCOjzvCi0XhQCjm/ibfXwAMVYiMRF W3EW4sWAD7nG7J9uzEKoXTRmtxDRWCEvdDCRQH/l8Pr7DjYlUOBgoklkP/5JdkxkH6X9hBc4ShK0 X/RDRT+5JkpzZYAF+TLMgDKfWcb/18i6uf8XLdBDq369dk3nuljnUKxzHdxQ5o5rN/gzI6sV5eDa X/MMJSMVD61es4GHq9Zlfh1b15FZG+tQDq4S9f5b9hqevSrWcZCs6VzWd3CNuq5jfJW6qjO2qqP/ 0MM727s+09fu83217/xf+trJG2vnfT0s6v23vrp49sO8ry7eVxfv62H1YdFX18VzaVdP30EDmdvf jg3k4SFmNoEehoKR/rleeXiOII7ZEf+Nwac1BMeWOdWfscTmZqxwnG4q2iraeBaok2fZkGzPZ/lv nB0JPk0fzWfJSHbE5pIU8Xde3nH+b8uWLVu527YtBX/rNp4JAEQbWdqVmXfRyr5MOpPuzKhDHf2U 79q2/Ke9T5WfTb+UZhvTO9N70nvTB9Labdv6kex8NvpSlA1GN0Z3RvdE90YPRHU845K+J9X03uhf otI2YBPdik8n7wpdI8Qfj27dhsFs2ULQyRa4XHepban2vrYoWQNpl0IyryAuuBhcHdxSOC35d/gv w/0O7m9wGnIz/K/AfRvuEE+RKqSKTv/lHbzHfrR4lPil2kPVDbWzJhCuuiwXLl2ZCzsvzIXptlo/ 8sdb60xtdgjelDwN/6dwb8C9B/cvOK1UK9WKxjFm/unfQrakKFaLILKVe1tSW2kKAOXLvXVLKoUC PI4ExLC2YnkRz38I3bKNYCmwIQhQSKRv4dXQB+rmPzwDrFj7JbjFJAxXCO0qSEj2N3Cn4N6ZWZQ9 q72SxGauyJ6UXCj8vbwjJEHuJXtJnJymNeR5MglO/jBEnR5yD5lPXiIHiI1cT3+G1YxBwngU/CIM vj+P+KiWPEBeJ5eQzeT35CS05i7yFnWinU4yDK2xOfsu/C5ye/YoSplIO/k38jS9ii6FXaGdLGDl WIkE2ZOdJD5Smj2efQ2xb5Df03j2IFkA6A/EAel8J/ky1OgryE+z3EoSJ6vJI3Q7fRey1RC5Q1Ov Gc1eSWaTI+RXtAvQEnK99jXjEUgHXybfpj46mX07+0fyQ5yl69DSF8ntGPE4mWSVUrt2H1FIMbmA XEhWIfcL5HXqojWSmi3Jzs0+gNRHyAcsxV6Q9BhHiiwkg+Qu8k2sxqvkFEQBM22g36CP4/tL+mft axhbF9lGbiAjGPnDqPsEOUpraA3zQT5kmGGS9CJvD9mP/g+RE7SL9tNJ+py0X1s905p1Zz3ZP2az pIz0YYR7yXPo4wytRhn0IEWlrZqQZqu2dvomzHAt+To5QX6JcbyFdf87+Sctw/c37Ea2M7si+2j2 9xiLAbLDLHIRWUk2kmvJ58m3sKvPk2Pkr/RjZkTJlzQ/0t6gPZ29G2tbTOZi7N0ovRRt34FdGicT +L6KWTqoglnMohfSi+l6uofeSyfo6/R1pmMRHJXvSRnpZ9KvNY1abbYFLXm5Jg8sWUE2YAduxGrf jfk+Sn5EXqQeWkwrMKNXUf9DNpt14Ptt9hJ7S7pV2qM5q71t5uTMn2Y+zo7C9tQBvOvDaj6GVfgL 9WIMSXoF3UJ/h5GPscOSTZKlmNQgtUnLpH7pduke6SfSLzSbNY9r3tAu1K7SPq5fNXPNzC+zXdlb sBYUuloImFRO6kkT8OcyYNOVGN8wvpvJdnITGSVfAr7cTfZB3p0gz5IXya/Im+R97AChEYz5cvR+ NbDuVvolfB+gT9Dn6I/oi/Q39EP+ZVF8S1kja2XtbB5bz27F9x52gr3K3pEKpTXQv0fwfQimoNfB pTWarLYW3wXaO7SP6H6mL9Uv0K82/Pzs1HTZdP/0WzNkpmDmczP3zjw388fs8uz1GH+CVJBKjHQX RvkAcHA/vo8BE58kL5Cfk/8UY/2AMqoFxvtpDNhQjl1rpfMhaiykS+hF+Pbiu4KuxHcVXU034LuT jtAv0pvpLfQu+lXxvR9z20+/S5/E9yn6NL6/om/TP9D36AcMSMwkYHOClbAq1oyZtrP5rJtdjO96 thHfYbaZXYsdeoQdYkfZq5JLSoDbrpI2SQ9I/yY9L70ifaRhmnJNlSatWa5Zr7lZ85Lml5rXNB9r w9pO7QbtQ9rndUFdva5Xd4Xuft0B3Tu6s3qdvgfi6nb9K/qsIQGO9WPM+wj29JNPle4lukXr1lzH 3gZd+KVh7S7aixXTsWXSVdKXpP/QXkZPSwp9g45Kl0tXZr8tzWP/lDbS5exZGpXC2haYcu4kWfo4 +w07w/6o8dBl7F1aqvkyfYptlNoZbAzgqS9rPJqbte/AGvCfpIXtoJPsR7Bc3Zz9AWnRPkTf1j7E fkkUzUnmIm+Dqnex+1DpF+xydgfp09RrPyaXY92/q70O6z2H3U7LpFc0D5HfSzH2N2hX94JrHKeL NHF2KWumj4PjTtMQmaKbyDD9KlHpM/RNOgGZ+FHpEbqYWbBbGWalTTC2HJci9BXJRPr5GGkx89Ae dpr1St/XnZAaoPacIP9BbqASrQbunPvMkGtAAfewEvC0TnCTl2ktrL73gd+fmfk+59ja17R3AM++ KZWTi0k1GWA/Iy2gjd/j20dug43uaeDg7aSa3U+2Z0foWvD9JeCfjEBvI1XUDG7pw9h24rzwsih4 4SC6/if4/0/B9bvon8nnqQLKmiSlGp5zp6YTnGkI/PcOfNeSAcS+Tu7WHdG+TLqpjxCNMvMQsPzX 5FKcOb9D/wWwUH8ZnO2bmnKMWgFn3oQaX59ZQFR8byM/o4zswJjngM57NAvAee/NXoEZXo4zajHO xBfJ5dn7SDv27uLszdk7yGD2m9lLoOEuzT4K/nttdpw0kl3afrZcm9LUg8e+SI/hPPovegf49gLy BvhRgvrJe/j+G8Y/R/sMGdX8J3hna/bO7K9gZS2F5fUB8JlF4F5Xkz9j3RZIk6Ru5kJ2MDtPGsYJ 9Ta5KPtINkxNZEP2KnDe75P9ei14zwgJafcDd+/QXMaqMd4k8dIqpF6i3UuIOrd3mdo654L07Jbm WU2NDfV1tTXVVZUV5amyZGlJcSIei0aUcKioMFgQ8Pu8bpfTIdttVovZZDTodVqNBFW6vDM2b0jJ FA9lNMWxBQsqeDy2CgmrPpUwlFGQNO+zZTIKr7cKWZ8pqaLkZf+tpJorqZ4vSWUlTdIV5UpnTMkc 74gpE3TlRX2A7+qI9SuZKQEvEfCYgK2AIxFUUDr9GzqUDB1SOjPzrt0w2jnUUVFOD5pN7bH2daaK cnLQZAZoBpTxxYYPUt8cKgDm62w5yIjBiilmCmIdnZlADFXRjJToXLU203NRX2dHMBLpryjP0PY1 sdUZwqXmlChC2kU3GV17Ri+6US7PYDbkDuVg+eTonRMyWT2UsqyNrV11SV9GWoU2OjOOFPrtyPhu OOX/JIrGIZ/v+nRuUBqFhKjwwqOju5TMvov6PlU3GOEt9PejjQxLzBsanYeO78Q+dXH1LcNu7e/L 0FvRITSMhJhTbnY59ScxdIWSMcbmxjaMXjGEjSkYzZCLr4+MFxSoR7MnSUGnMrqsLxbJtAZj/as6 Cg+6yejF1x8KqErgszkV5QdlR25ZD9rsecBi/TSwDkueyxOQKM6hrovPryvlY4wthNKQUdYoGElf DHOaxb11s8jomllYfnz6KWpl1mI/Ls8Y24dG5Raky5gizWgTckwZ/TvB/sem3v9syqp8ii4h/53w TI4l5xEtg0Muj3SZVCpTVsYRRN+OHcUY54h4Q0X5tRMsExuWFQTQHkkP1nZVf0sVFj8S4dt7x4RK ViOSGbmoLxdXyOrgOFGroGWxIZ4zeS7H08tzRs7lnK8+FAMeH8YZTognYyg+/2eXva7ODS0Z6v3/ yF6Xy+9aGuuCDqZ0jg7lcbZr2WdiuXy+oFg35OUhmquIBc9oEhldYmEMqHcxlDkk4E+bmBfrvHxo AUgNY8y42vukIEMDHGJBSTQF/L1k5bn2eKTPwtvSJHQC/9dO6A1AYJFClXkZeWhBzu83RSJ58vr/ qzSRPc1rieCTavk5Z1pS+Vnl5piZ/Zn4Z4ZnGZW6loE7sa5lK0dHTZ/Jmwe+Nzo6L6bMGx0aXTWR HVkdU+TY6FGpT+obHe4Ex8pt/0T26TuCmXl39mMqG2gLkJyRuQdj9PaLDqr09qUr+47C+KXcvqxv nFHWPjS3n68Xa1/Wlx+vWHmMmO8EtlzXTAu5iYw9RpbBVQK+RkPIabhy1kwy2h8TGS6m2UIi2h9n fy/dRRbCLUbZbuSn4S7QNRMHylvgOjUk+xHyrEh3I86bhogKH/mQcp9EqODONpcikoXHYFznH1TJ f7Qo/dmP/jPR3NWuEWmmz6TDwvDf4v971JJPtkJ35B+78GXIBk7iIm7EPHBe6EX8MxvfHeSH1Ep3 QpY8IP1N84T2Ft03DQ+ZvmQ+YU3ZAvKNzlrXBvcvPH/wOfxrUIPRQkhlhfxqCPrCkoOMPsN+iDnp 2bPjRKuZYD88LBGTngNHKAkYdNpnkY91oElipFfSS4k/JX+Ynk5fKJ9JL5lOk1bA8ll4NdURR8SR gEcLNeSsIk2eVbXkY0h3k1jXZTOL2HZo2S7SosbudTziYLdZdjuY6X6jg9wP/RHrZXzUFu3RUd2I e9mlvJOBqel0WkYPU61TNZCn6AD1FJcUswaZNHl0OuZx+0KMbb9v3djXae2HX3jowkjBoh0zGxOL L/syHX2FNtLsNWUd78/c+6NXD4w+8jWMoRJjWC7G0KzGk5oywwKthM4dGIQLYqLRhAHkLu8k3Yin 7zv/cxB0wNXg9XmdHpnoGxobnQ31JZWs8v51e74+89I/vrB3SSTQtV27tqzrsrtnPv+rmZ/O0GsS nX+iV/7oV5nRh/kIrpl5nN5PfoLdW6qW9LN+3zGvZPQNBU4EJCMleo3GbnCSJ52qxaxpsXvCnhGP 5JmgZbBj2wftzB7wfx2DwsoPLJkemMLCnHI2U4fT11xTjcXZ5MKQMKLiWFSvi0WLG+ob62q9Hrfu mvWbjHq9OeF017R0Nc5dv2fm8fLonh6X1eg2ttTVzNsyuP4gp4fTQAqddgOw6z7VrfqH/Pv8J/0a 4lf97FqIh8zW5oJG1wY82AdJTRKwAXAMlf+Ja/7LIXW1Af5AxaWAHeoy1RoNFibBePEPFF+oOm02 u+poqLbvtI/Z99k19oDvaRanp4BTfFKp9BJ56hTf8XRr2sGn1kz+PnWW/j2VEvu/acCVqHO4vV6f J9IwhzU4MFc+2dN0UcSVvmSGDc3ymvSJgsRczY+/+fGuzbNCLJFgRTU3sF/fU6aEwnyO5Zjj45hj iG5Qv6j3m5t9/sIL6v0qvAD37CGvN6lP6xfqv6vXqcrnNCsNn/Ot9F9p2OrY6vy6+Ru2BxxPmJ+w vah90fcT/+u+1/0nlY80H/k8HlqkCWiDnoA34Cvy640+s99cVB+YH9jt26Po/QHGfAUBS0BnlQJM q4OY6XHrXRrrBIZhNKpuS+uIkRonpDrVImsL9gTo3sCBAAs8LdVh4e46RJklNEHvUq1E99tu16Br o2unS+OaoHrVpWJSBURRlRFFGlL2KUwJPEM/AnVbqaq6B6Fe7mR72LMwGLzN/sIMLBB+Gqo4zS/5 klPpqQvlgU0fDiw5MzAlA6fSU9MDm9Kt05sO6jh7fmqPkT5rfMnIyMCm/tQpjmxiZ5zNzUzOFTm8 I3BXAPn9tvQuWbvjmO0Y0HHT5gFQLIxsJEWlSAMhDfXYKp0+1phDSiioTB+pbWxskh4fPHsSYofy 0DVr9xYnAi89uP/N6kUPfzSHrr5qxbwCqp35OEHn0vu/e9PD2zYdfeGVsfXrv3Vk5vQsuaYCfCmT PUXHpAy4qw/njRTg1ztF1vWNY4F9AaZTid6iOs121SOpxvoxzz4P83yfJqC3/Qc4jqDvM2LWgsXQ gRQVBJMjHtenYBqpbGurhCuvapvLQykjogCnXSKhsnIuP1dwymkzsBbijpL5DzK+hKqThkMsVEQK Q4WkKExDhcz9Q+m3xAenhzNJv1V9BlYYkuyGQm8RCQ/DvsAoNdiZgVS1OpurBo6fOF5Vxddenpr6 8/u0KveRd+w6dkyGq6kOqkGDzW63yqaQMdwT0XnsLrnAURAMFvqLdBFcco8nGnhwqLqvXoSpShGO J3PJSnEuuSCUS/aJ5HGPCNT7ZFe91W5G4832RfZ58sJQd6TfvkLudfeFrrCvlzeErpVHNLtso/Zd 8i7n7tDt4QftD8oPOB4MHbUflX9QcDT0M/tP5Z8U/TT0X/bX5D/Z35HfCX1k/6f8UdFHoXKjvSvI wiHKF4kUhUKFRpspaPQW+oJeA9MHDR6HO+i5LmSXFTlUWBh1yG7HsINyFc02wV5UHSzkZiwULtpP oPbzhZugR1SLQbZLHq/XYDAaCnFxqxrtqMP221THBKs+1B2ioQn2vmpTVFuP7bRNsj2iXDkq8CFQ ANbqL5CnZM5hcf7IYEZgTml5Or3LVpnS7pCP7RqwVfpTu4DrKT+Rp6g8+T/9XfKOY2l9Gn+cGgbO 2ZtTdPNAP43odR63YGONTY1NtI7meJpg32YmfXf6b5dEZ6+e6e0N1M2hb8boa80DS6ffvai59Jo/ vE9feLW7JFylTyTs/uqvaC75+P7bL9ImEprKSPkgtbL4NB61Mc6TtdfDmu0lESqp/eagueg2+avy r2TttfK17l3y/a4HPC8GXyx6RTb4HU53UUjSe+iugttDrNSgCwdJJKoPB62RmC8SCJfabFYWKMVD AENhuttJiVN2Ks5qp+rUOieybz1ptbJe58IY0Eud09qgxqgSo8OxfbGTMSkW8elcLtbrs+BAgM+L +nA8WWSZ9epEoq6AJ+oeiq5aI44BrBQEC+GDMW1OfZga2LxEbMUUNmLK0dzMj4P269XCgpDdIyfc xSF74XJa4IFX5Agvp0FXYDm/KeBLftNN4FtY8k11DXW10P35kRGLNUQUDc5wvS5S4q2rJQ6Z4BSJ 1S2PewtLltSxUlguL3juiedmtv3XzuXv0NqZX5xeuSXRFNkiXbVTKU+Mzvzw5Znf//CV1YV0HuyG AdpRxE+WCMREfn9QQcsOllZN0JDalFjbaNQYTZkq6f7U06kXUq9LL6fe1bxr+ljzsck4rB3W7dTv NIxoR3R79HsMBr3JWAaeaLFM0GLVagjqi8JBXySqizDGU5LaoM4WDnojsVA4WByJpcpLTQaLRssY jWFdfbjTKSalcikrnWAvq4kSSEpen6EkVfoESVKSrE6qyeGkJjmm0+HZUbeePqunek4qlcQmtsgm dsMmtsgWDRWJLSoSiUVii4oeqvwfW3QGO5SGqLZp+pQ4teU/D4BOwLIgEOKcyB8V2Ax56n0iT58L cZxvgjy3KUUddbWNTXWOWCWLxRxuH4Srujqc7uc3K7ddLp5Pv/2P3m5rIkFLOjv+YTUp5dU1009X Lyv2W01hYIT0V2usoHPdFVo2/aeujTMN3YsSM8vXRwJOfyJRo9wgXZWDZ14d7C/FfmV/n31P+xj2 q4Q+p3aNOqlzD6VM7W7Yw6iziNESVuGa5brOdT/OzSzTu6JRpxwOmiLRSDgYjMAAGjRGYu5wsCAS czodlLGoM+p2OqPRCfot1V7yBDUZjZQFCwxOo8Q4o7I4lzocilwtq7Ik44HAYYeD9QI4c5iTBgcE IckPJTkhySCkJFX4U6iTSZZ0uXkTnkikOkonozQqNicq85pRKICqidNQNFC66lvnaAiH+BJsxZI8 DaVSA4D/wAV2Ll2BrU1N7cpxMwJJq1nc9OtlMCsysBnXkKVGZ8CZpK2k2dlNFjkHyUrnRnKF8wbn gzBzP0OPOH9G/0Wdf4FpDPvYT7CTm6DjHiUs++ihkLOV8bPGa20Ff3jnSV8zVQubOTieD4Ii9mSg mRr8HHxNtTubnV4nZAoPXKDZhbRxczOaOZEL/nnE3cxUCIScqvE5d92HeD8ZgDn3HGV7uPTrccQo x6ZP4VIxVIdYkA5LFxQmeqroa9Wg9vjZLwaLu6tnSqtWxL2zL5hdNFu7+Kxesu0IlyUS9crmj3dr Os7+4FxMOtBZ7jKCty7MTuFd4wFYVC+QFubPeKVV5VvQqnJu5wnqKxMGs5n1JgQ5JYgFbwZPq2an k/XWeXkRxN86zJkggDOqh29knShb16wXob6ikuOBYkSVyjoS0iTLq+stqhGNWtSiIu47kGWZyL6i hnghi0Wz00/9ItUvSvjlREifLteQKog3x4ABoEu+dserpkGYza+kjtMqRHhSanLyzVTqmPzK8Zrq VCqobjQXjtYx59JG6lTCzSOtjxqfNEnOlHMH2VF3G7nDfEeDrsjpbZFbR1o1xsLF2sW6TqUzurhF bd1dZDDZ9AqJLqRdpoXmhQ1dTe0tCy9YYV5vvtV4i+kWs32Z92YvC7cOtrIhQx2pT1cmK+qfoUEo 4pbs5JPGZkupuRnTmlQLWhpkS4+FqfCGLJIigmstGkvaz1EmaW7u9g/6N/qlKv9OP/PfGJYpn3F1 Wk0zTHu4YqSCVTRg3SakeapDY66crKAVQwlSZ7VY6uux8GexA7reumf4eymS4D3amkkinBhJjCU0 auJ0go0kaELmhRLPsHYozB5IUuFm6GTr1VCwqrlGr9qaFVy1jOglWU9P62kPuGr7nPZrchrNps2b U0umzkylwPr4WZaeTgmJAuT34QBI8cz0qQF5alPr1GYI3SlHMy+TSlXl5OpxyQLq6p/K8VHoeDjz 5jfMLoxpXU2zGmcxnRGPjpguElWiTNdgblaIo8hVSJwue9haSKOx2drmQjLLUK/Qhnqzs1AupLYo vBZdupBTEQYCKoKHv1RZWdlNN91EN+PuZBNkdzLQ3jfe6gRlQyYmm0HZh2swU2DkyXFZBE/ampsU zJ0TtYUHJ1WzudmvQKGCK+TYXmBuNmErm+BMpSaEJoRGhMbzVMwxj39Awv0JXV5rbYJSILQF0LHP fV6T5WcDZEEvTmzITB6eXuJAHS5J1dWy+XfFGy8Y/EIo+bP3VyxtTRSzquJEVWbvDRfOLnSafHbZ 4kkPX1bTQu8r7+5YPmvxLVc7Al+8or2m47rl8d2XRaPlLZW19RXLx5LhualbZ168ebZbb03Purfj K3QgHSgfal6AKxdGFmdPSUuhbbhJkbQjT/mlBq/bQyx20DLBGYogf4Z6qqGbKbgJgrVJhgeUPuxy oxTHbQfn/jAKBRMOPdHLUIZ4Nq/NgSO8HIww2VdFDQA/fYrzDk2N2Qy1H5QKam6dEvQ8MDAwBTpO vZmarDo+CVUghz1qkWcE97IZIvEhqFAIxSByPRp4J2qcI7aMl2wZPYxBQ0DifXqN/m7NtzTjGol3 pcfUOHsqtlp1vW53OIR5chCztcPnEoOu1+blSTZbOAREFeNITQoISgvGOnBsYCBVK8aKkYK9BNWA c9A/EBgiQ+5XJW1AKQTKFDZ7cUSE+ahM7YvqDeF260Ajjx4qLa0XyUvLKuuDuoCxz3WpdxAa+ecK 9FQy6vSwMGg9C3W72Z26XZZR+daib7PH/Udcr7DX7W/IZ9jfJJdzSD9kGMbsdhuf0//Eflpv0FC9 9RYmGZ+GcV8HzF3UaJzH5hu7w8vYMuNq3Mbudu0OPOD6jvE7pgnDEWPG9GP2R3bScsbkNpzQw05z Qs828ZCv3RgWLQNtdofGTaq9Hj4DF86yQc9Oz17P2x6NxxN8WUOxgyfG3c0I3hl38eA1dYGzma/x JUHKcUD/c4O3NNhs99KN3p3ePV7Je8btHjHQasOYgVUb9hjeNkiyQTVgJoaM4SSeGj5m82jIbo5X eKnrrLZxTUYiNtmm2KTTNmrjIzFiLW3tofaunFQAdrRkehM0mYFNEA/kKfAcrvJPbeYoldrsgKYJ ut/oAd2DVXGtBwxJGJfIrFlcYmvvO6wjkHU29QtGxUlXcIejRI/ezLFmi1rRbIUzoPfx0maOZgh0 PAjmYsFcXj5mysVMuTyjiKk2Y7MHMkBAcTRb4YQsf+7c512m+vv7XTqc7hAdfTowAtZQ7+SmrkQE hzw3M7xB167dtfLWirDnp/fv/9Nfn/zaC9O76KNaObCmcenNbPbPt25dc517928off1PVP+zx1r6 4rPUmyDDd8M6dIP2TpJihjx1JypUfkpXqPyErhBnfBBSrE1HDbYkNfAznzqx1u+peKMO0nfylLwo rXsa2r0R2r3JEE+EYLG1J+0TNDju1HG9fmpSnmw9DuuDoN4Uzt9J+Zj8Av9Coccs84R8FJY1XgfX xEG1KKmLoyVDkgpCpDpOgZRxQhbDeE01C2oU6RjWG0/xLJutojxHnLwbHPbo/vjxnF01qM65Q3nA 80Cx1CF1WBYEbpVutWi/pqFVFTsj/GcLew17jQ/JDzkyFUZZBz41WDaYYoUG2+GQ4e4oPRzST0gG NRwL7Q09CyOHI57w0VQPDuLqsqTToYNSIwPBJ+jFh/bg8J1gH47TstQElVVraZI67Q75brudxjmy HhoaqhdhS0subG3NhfEaEarewkj9mI1yFB+0DdsmbSdsOlug/GlJJ+nz5ix+eqZw4gJ1xTmbRvCH gVObhW6STk9vhmELpyy4lDhNnYkSt7c44SlOeEsLSYk7XkiFYMlPwk0DBA5vaT8lR0I/d8Qa6mBY bayr5SY8fghxuTKKU8hT56EPFybmLJ1+M1k6NzA+3ndk0+V9LfUhX92icLi4Ui18X1o8/fBItDwe L+1YzVYuSO/+4baOilmhhsjVLlfN+lfnLuBnTBqeHlZqM4myvHR5lMRBXkUctZxWgXPWiJ+jZcTP 0TLi8kvGieyfD3PBEsDJw7wkgFeFagHgF0/y0kYr5KYzohSA34pSAE6KUgBePcJL+ZUJbpDqjmyM 7IxIkehG0MUQzPKCAjglP8W70UV1LmDRqziHjg/Ib+aOIC5a8g04Lh97IZWSU9wQeA6NVavi5LgY ET5v53BXF56scKCtLQeogaYmXa+qw8OjfTrGOyVEgSXCxaf3oVrI6xuN8ZhVILyVceS3CkLgMzst pDkAH2JCul6e8hQnBr8/Hstj/3EMLnc2YexvHm89nhO4+DAh9AbG4nQoPhwfi++Ln45rlXhPnKnc i3P0rK2tF+GsllxYUZ0LYwkRqpWBgnp/MuRaFLUmQ85FsUhJoE0JRTosAYtrDFNpJiRq0bucpjFY epslNDne3sAD1d7aIF1psVgD1rhfTTVj4JBEG1vqx/y0x0+H/MP+MZjiT/u1/vHY+LeFlYqzX2A5 8BxhDr3BxjE1+bzBPKchQckeoJuBxp8yZrqEFAUtG+bX80b0kgRNls2eXVaWnn1joKZtpr29MmjU hwoKS23Urf0Sz0iXlc2eiUwry5sL4/GCdC9d9dVyJWCPDwNDLgDW2oG1HvrlHOc8SnzYMoGzbouO 6vO8UsMRluosFvgQ8j8Q2AjgvcM8CUAOLQG8KtQjAG8d4XUs2h+Amxrg9HjA+lvV7HKrRqA5ZC89 38xU7XlWCgTEPh/j3BSM9Jw8VOISmOd2cyxyoRp+XZnnojn+iaGBi6LDHCIB4Kq5jg8qh0gWi8/7 KURCr8ChHO48Neab9J32ST6OKa3z6nmotjTPrqe+cevaxh4fVX09viHfsG/Mtw8F9ZZkSL8oSpMh XUnMXWJtc4XcHRiSXmciNG5Fl6IZHqoFDbPrxyy0x0KHLMOWMcs+y2mL1jLu/RQq4LAWLO6Tzcd1 kOBlYu8/u9/izgTb/YVA/fyZ1tbKAlvYX1AK86j2Sx+3LZ9VJPZWUh+cXyDHhrlly4H72Grouyuk l/Onoq8fxx3r7Rfnoc8hWJKjd3F1bslYL4D3xPbxFNXOGUZ1SpRK1TTNO1cKQK4UT1EjvNS8tvlt olybQJQ2gShti2FYYb2Lz9UD8KFgXgByDQD4lxrgGLTYxJtZnBLVU6J6Cj/6gu7NkahJ5pwR8VdU M+d1TYW8YcTfU8O8dhMT+Yy30eQQbThEGw6u6OTaUKp5GcSfz7WhlPE2EH9DNfM2FNEG4meBo2hH 8QaqajsXcKaqzF/Wq/IyVb20u3dj785eqXe5bn6NP1FuhqKu1UMWa52Ccb/1TQjNx+XpSf7hwr34 AKv/J5hHdRQAvnO9IAUJgnPe8wKEmkbzaN2s1+qX9S7X+2vmOwTGOxQNpwUlJaSFlEhLNbWJWJuI tS3GPN4TXFRR+rBO/xQ8VgCcNAB8IHKbmvqwB38W9AIgR0EA/ilyFy/u78sTDmRMDJH7MkYuHKiV iDkfb22F2X0KFJWx4jHGs2Re9h3SCVcFV51950iBP+D3+2flPv1BtbBef6L/L15pBKd0/xA0hpSV jvVTxaAkQ/4JdvZwtCkZqgGgmqOLk6H5i6KOZMg3IdkOx1LJEMwC1sOxtmRoHgB1Tqy3ZEnbslBv hyHZtERtTpYaiD4xf/kKvjGJcovJrNdptPr582qq/T5Tv89XIDvikWqFDisZheFlVoNqb0pWpuKz qpvocFOmiTXxNO+SFW3xxYvDS3qWsJElY0sYWSIvYUtA10+6vfVLhvr6J9jKQ5GHd/on6NpbU6kL z3BDgTDdyWcATJ/KBekLO9d1/AFEzj/w8bcEa8XvSWFew+KeuynlmCKEG3c0brFbE7HiuCUC1d8e tSW4eMO1fZjFKXR82Oy4gIMrCIgzXl/O5zq2D0p23gh7zmaOqzu97xM+cj4Zms8nqZ8+Tepoz1pn xYa65ds967/UtXBTxGs1NV4wk3bNjvhMmmDJ8oYrFzPmaZk3U7O42ayNlHc3NiytCNR0zcxurS0Q J0+JnbpT7P219uKytYPXdXX1tmyfuXa54g3H4z455uiho8OVasMCc2qm69JKJMbjjouRVqMWlTfN eFY2BuPx4Oxeeul95ZH8KYXXFdI/wMnq2HlO1iA4WbWFs4Ma4dsMdi8uM95TK3larCieNAiWZBD8 wCD4gcEb51TvFYZxr4XTufccewKQM+0B+LNazOndS4pE5SLRUJFooijp500kbbxykhMP7w7AaSGP AcgxOQD/Uk28lSQpZHFg7W9VY41q5OOttfKLRBkuCpfgOXF7vFZfUM4EL6mqgnrx/vvymyluRWo+ x0mEDpBnJZx/gHMcE96n9Q710iovZw98aXS9NQIWA6jJtW+PG4ToZRCcwiC4hsEL5qfr9Yokr4Gz CK+3oZ4UiZJFIqFIZBaJifLCAuBdAPjgKV4lmWyoz7MLMdI8zEcKRgEW+eZxPhtx8kJsa2lQyxoM DZz+qxt6GoYahhvGGrQVGqoKeASxTIMu03CigWUa6FDDSMNkg1Rk8CZD9gkJ7xGiyWQovihqSIZs i2JFyVAMDEKtjNWUlLVVh2o68IPH2jqxovFYzG63mXzeuH7MQDMGaocyvtfwEn71N8F+oAaTdUXx snCyJznEb1pGkmPJTFIiSRn2e36OG0HwyaF6kDoetwgqh4oNVRxEzk9vcdPICbq5OX+Mn9NS/AFJ p0kEJF8hxdMBbcE5MgYV43JrYBNM8BAHOSVzMv4MAYO2IeFBQQGVnqdqkcTTShJ1tOubd3ddpXht 5pq5M7Ndap1J07bk89eabZwQ3fNq7OGCwhwdTj3ftTy9feb6FeEAxL+SYns3/fyOTV+cKRrwFoHS 5q+ly/YvKODSIAPTPiUdBZ3ZSRGz5GWGQoiBHMMt4koJ4i5OUYvMjeSWAhhEzgj054Dq4okaUUzj gx1dTkDE4yejwN+8ivGJocvI83m5Al45yHGqQOMWGOe24IoEEhyOffhoHHIABzWakMWSM1iJo4hL jDiLRCfcQtXpHPHQR7xPevFjBeOxoteNOucfTXSBsdO7wnMrvdO42/56UB9Waxs0wlC1N0xf8LxY wNQwXWg4NxonuptUU05zazdQUUNPcL9HM6QZ1oxpMhqd5n3+NKFVtey1MMt5Gw23F3OrC35CVoqf kPVctPKgJbTwYFizEO8Pf8At5PzfN/D/l4FTEL8X+z4pwA+oNPgfCLXvyu8GPxXF6dCfnxAMx420 yJmwFbNEYbEpoSt22N0KKaIFCvUaAfn1gFxWWaFBCZ7H7FNIQAsPJHf+qgWgsBAD14B1sAWpjm1s m+4G0w22G5zXebf5txUaBvrx7APmYtVYKDuag3CwiJ0+aBYWX5htaE5t1sWiJfx9UqOPa85uGG/E wyVGTtx45bUv7XzphvU7fr604cq5e7+46sbL50sHHtp14AtnR/bf8b0bP/p8W+tD238y89a+fz9z 5xCUjuxHM4ukp4FrJaSZRfO4lpwt7mFqTWWcuZrAm+D7XQH8i4SkS/BglyKuYSDe/EuIklxeE3wX wBnVyhFVkUpTTo1NV8DNOHisoZohflQmbI39On2J4MJEcGFCgZ3gsJDcILuB4YojWbBX2HQmYc6R jyF2/BNd5CipzZ49whGx1sRx0s9Bk2l2C0Yn8NYleKQLY+FnAEQ0fpIEhbCmoFSpzlZCaMCGwZj5 aPgAOH20yjnOyOUB9AjmeSJvioVIEFRvNM3mZtVmeaH8OXm3Q3NbOZ1d3jq7q/xz5Vc4rijfYrje cX35LYb9+ncNHxmt1bP76vrrr6rXqLNplUEqTTpdEKsCt0VdEK5KYqQk0l0SIh3MmSqVNJVyI+Uj Ybj4spkDflttTdg0ZmJDphHTAZNk+pPC8FxpvRpUlJ7IcISNRHBhLkcykcnIiYg2MtTyPEyU/B4Z t8mCK27mN/6YEddq8ewlzxElm8zlHyHfKFUNeqshUV9sKa5ONOhrFVplhVdnbMQvr8yVChF2Q47A XNzh75HwCqO/X0rUec6Zb/iFQwluEfilApd3vJCEOLvkvFGbY5j80UD+SR2jBcXz93SPXrLp9uHH FjWW1vqau2aUQFOJyyPHQv4ErTfarl66ds5Fl6h91VVxqXnzq9evuuqWV6Ye3OmxV8y8e2ldCJfX XnPNWml1f7XftnPmsY2xlr4LLzv6H5su9Du5pmUFQj8FXC6lR/KYXFomMFkX9jlKhAhR4g/TvML1 af0ENvLcRTKAnNwA4M+qgyNyWKhPYSFoIBXSMKeHMJUlvzfwDJDbT4qB3rbuko0lO0ukklK93wKT WutxrodMQQvhp+1nZAdu3+FCwycojVcfaK4YdTcadxqZEQ34dRipQGeH0DMc6JsTm64XwHtCVeCA sFCGw2XJ/DEPrIUhFMr18eMD50963EhCyLbXslq7ylT7FzV6tYwOltEwx0Uh1d8WKylR2opDJR3E ZC5zuBWZavz8UV2zbKGWfgk3HJDbB3UU5iVdZRi//COOeDgcVuiIMqYwosiQ4yeVE4pWGUo+fP7+ LieJbz6FOzFxbz61eWoACMkprJmcQ0tIIptxCoO9efgRnLML8nvoT05dfmd1HregfC/ecn3Tgvp4 bIXH6amodlnnzplJzYsGTFo8YgiXmKhHOvCLX7SXlzR2upOXzixcXIIjNu4VUu+afRcU8mMW+OLO /pWlNc+RIJ3O40uiSHWC5RUJq7XZIkRMi8dFtS4BugQSuLgix3EAwBnB/gCcxtNDIIvLbCi3e90a bqgmMMC1Hp/G47OpY/n9fxP8DJfGn1YvAz4hIXqF7/kUHITOLPRFHMw5IMC1aDfnY8NmarYHqedy N13opqI7tZDq0Lc5SLWC/WmFuKgVGKTFALmADMsNRipwB8C/hHbpchUVfoI7KXHr1Dp9YmBgUoYh ciAnJvKHiCn8hwQrBtBmaR6kg4y1Fj3geCDwrOdZ70TgnYB+bxHdXUC7Ld3WQcug9e9+yFoef4lf 8nr8gQKJcs8d3EclTzVfHIxWqsbbG52lgQ/a+xIue/6C57rr3MGfE/MEfV8tV4B4lVVFmSJWhOfF Go027u5x0RE8dnbJroxr0nXCddKlcw0VPr77HPMD7+PfAfEYk786I63Tp/izJxmPoeVTFKhH4JwQ fvl9DOdqm7nk56jz4PmMVzym4TcixcXcUo2LVLwuW/Tqq3WlkTmOkthIR2Vf2ZebtlT4kprnZl6e N/1v/XOSpavX1A2uYRsi3ssXFK/jWMUgvU3jV9AJVp3HKm+J0JIMeSOeWSnN2zzyvEQJ5W0ip1SX ODoLxCFb4BT2FTzwyKEbgNxpC+CMMDY74+cOV5s/oTMrNr+uqNyGi0fITke4imMwkao3U8dxEoDg YB7A40fO0Y/nLCG4zfg0D1qhz12QSQYT/smS34bLCLSaa9JMDRx9qIkLhHm7n1IAFsqlRZ5TYOKs qcBpMBQrAvMUnTh6lWKM9gOBewBytmUOCNxzOkuK87gnLBvwuE1DGDZwzcIPMCChUFfAS0E2QbWB lnBVRSkZKhkuyZRo6s1N4RZlQXiBoi0wuLr52RrpDiVKYoYS2qYPGToUc6LIMEE7VZeJJBKBgJiP zWQ2mc0R2B3Wqzb80Af/7mSY7qUvUQ3lukjCGSiAhtrjGnOxEXj4ByMc6ZQ82gHpip+HHsJfXZ+z NkATgSIC7OO6CH9qx79CbTxvVYQcKQcL7Y5Ce0EhkR1BuQgvCbhFgT+zw0sBjoi5C3qfNtZwDg9x nuobInnsxOla0iCtsUe84RLbzJ8rrt3euWRTeWHTAtrW35q6uqt5pXTP9K/2zi90xDY9PzK3/84R +kBbbZAmph8c6WlczPQXNrEETLe4U+efbAS/fPzfPn4kSrhDsUAHcRMPKcILjxL8LrAGv5FeQBbi 94zd+J3+Rfil5lL8vnwFfqHJP3jaCMc/OhyKZHn7/ItWLEwtu/zqdVsuXPf5izdeveqanqVL8F8E /w8XKvrKCmVuZHN0cmVhbQplbmRvYmoKMjAgMCBvYmoKMTQ3OTUKZW5kb2JqCjkgMCBvYmoKPDwg L1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVVRKTlVQK0FyaWFsTVQg L0ZvbnREZXNjcmlwdG9yCjIxIDAgUiAvVG9Vbmljb2RlIDIyIDAgUiAvRmlyc3RDaGFyIDMzIC9M YXN0Q2hhciA4NSAvV2lkdGhzIFsgNjExIDU1NiA1NTYKMjc4IDU1NiAyMjIgNTU2IDU1NiA1NTYg NTU2IDU1NiA1MDAgODMzIDU1NiAyNzggMjc4IDI3OCA2NjcgNTAwIDU1NiAyMjIgNTAwCjU1NiAz MzMgNzIyIDI3OCA1MDAgNTU2IDMzMyA1MDAgNTg0IDI3OCA2NjcgNzc4IDk0NCA3NzggMzMzIDMz MyA1MDAgMjc4IDU1Ngo2NjcgNTU2IDU1NiA2NjcgNzIyIDcyMiA3MjIgNzIyIDcyMiAyNzggNjEx IDY2NyBdID4+CmVuZG9iagoyMiAwIG9iago8PCAvTGVuZ3RoIDIzIDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAFdk8tu2zAQRff6Ci7TRWBapO0YEAQECQJ4kbao2w/QgzIE1JIg ywv/fc8dpynQxV0cDYeeQ5qrl8PrYegXt/o+j80xLa7rh3ZOl/E6N8nV6dQP2Tp3bd8sH2TfmnM1 ZSuaj7fLks6HoRtdUWTOrX7Qclnmm3t4bsc6fdG3b3Ob5n44uYdfL0f7crxO0+90TsPifFaWrk0d 271X09fqnNzKWh8PLfV+uT3S9W/Fz9uUHBPRsb6P1IxtukxVk+ZqOKWs8L4s3t7KLA3tf6W4v3fU 3cfSfF0WivebWGZFnoPE++2TMIAE3AgjSLzPvXADEqo74RYkYCPcgQTshE8gAXPhHiTgWliBBLQx apB4v7MfakAC7rW4BZMtboUdSKiqNyCvsNVWiJzifVRvQE7BVzsH5BR6bTFywQSDIXLhLmi9yPFd i4N6kVNAHU5ATgElGJBTQB1OQE7h6HQ4ATmFIW0r5IIJ8utUEVRYLMGAq8LiWoirQlUYcVXAJMRV wVcHG3FVQN1CxFVBX1NFXBWqhrhGE+SmqCKnoGCIXDRBRKgip3jP8YLIKewso4hcvBvpNCI20RQY BmR8hcVCrsLCGNLfML4CyoglFlBjsL0FXxnxt7VQ1ZVtUFBALoUH8PefrregN/v5xprrPPO87GHb y9OL6of0+fancdIGlj/8eAs7CmVuZHN0cmVhbQplbmRvYmoKMjMgMCBvYmoKNTEzCmVuZG9iagoy MSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9VVEpOVVArQXJpYWxN VCAvRmxhZ3MgNCAvRm9udEJCb3ggWy02NjUgLTMyNSAyMDAwIDEwMzldCi9JdGFsaWNBbmdsZSAw IC9Bc2NlbnQgOTA1IC9EZXNjZW50IC0yMTIgL0NhcEhlaWdodCA3MjggL1N0ZW1WIDAgL0xlYWRp bmcKMzMgL1hIZWlnaHQgNTMwIC9BdmdXaWR0aCA0NDEgL01heFdpZHRoIDIwMDAgL0ZvbnRGaWxl MiAyNCAwIFIgPj4KZW5kb2JqCjI0IDAgb2JqCjw8IC9MZW5ndGggMjUgMCBSIC9MZW5ndGgxIDQ5 NTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBdVgJWFPH9p+Ze5NYF0wISdwAQyBB cU0MQQUsLmiV1V2KCyqibCoIRcEFWRXUihW1VZRFRRRxiVYiVkWf+lCKS9WKWutrtS5VW/v6ag13 eGcSav3/v+8l39y5c+fcs83vLMmSpJRo1A6tQhxCcxKiFiHbhwyAaXVM/NJ59jXnjpDUaX501Fz7 GrXA7D0fHtjXeBDM7vMTlqS1rafC/G38wjlt+8QM68SEqLQ2/ugerHsmRiVE2+nlPmz9v/fDKmC/ z6KFyUvs9GFhME9clBTdxg+DvM6j7HvvXTHce5NjyBc1IAkiSIr6I/aMfUSwZvfiK40PIyUrZ3b2 /b1d93a2rbIfdL3ZTWPYTeXbGiFGitqFw/KDd+/CexJ/GoJGSNHbmrfLpOjdju19uHiL4REZjBCp Qhls8AdQEqyr4D4AZgvb45PRAxi+MCbD6AYjGJ7Xiia3CqLJqFh0Ec2DUQL3ZfwPqFI8GCXAugJo TsO8HdZzYK8E7kthjgSaAZJ1qCvwGQsjl0coDOZAGOPgHTnMw2Hk4YsoH/byYc4SV6E89gzGSDaD fjmwNwzo3WGdBffdgL8Y5s4w1GAbbrO2IxIjdh5qZETOSIs08NwD9UJ9UE/kitxQX3jeG3mhAcgd qVA3pEedkA5OYCDqhwzgfzViHDwRD2fTGXVFLkgBZ8KhQcgBfN0DtUcd4MRkqDtyRF2QElDqhORt DlYArQlNRYtQDipCO9B+dBb9hgfhcLwZ78WXSHviRxaSXPIFaSa/EoGTc2O4JK6K+zcv5n34At7C /yRSioJEi0SHRNdFj8RI3FH8oXiu+FPxWfEDiU4SLEmRbJAclzS3aw8SCQOKCL6gnQQMlqllHnDB oHpLT+5My4ciZEU9+TPMNxk0nMwS3QDNEdYS2SCTt8kglsBXIcX4weavgyPqMpfq/DRe2IuG1+E3 2OFls2C9Om1t8clT1JX2/H885BokG6TTwtegVCkVUiJkYi8vNz/dssy6iOAmGo6/xw/raovXRly3 Cs0v6WsKGMYoCb3gh/DHwYPIQ6Y2qmUGmVqhlhFMF+MNVXgDXfwCF1WyuZImAn0V/Q5noUbwOTIY DQonsUTn7W063hg2RT/Ym2tsXFygDe4a9TFQBuATJJYksHwhN6oVAaQXPnHsGJNpgUse8IAdxsPS 2NgIT1HrT2Qw+AOeKrAB432f0qldRT+/dYK9B+Baq+gMk6rWyMRiiRGEGojVHHBj4pZ/9V/Cp/tn uB4c3TATaH0hXiRA6wIWKdRaE1B6exsHaTVuNl0NeiVoDW4WS3hJi4moPMo/f1W5LX31dlwrf3Pt xn/G7K0vi3Sprg7wnXNmxflH8+I2bV8rb7rzrHpqVV1FftRAZsHk1se8EmR4gW0mpdKgtwuQmN7d /iWLCZMo4Yo0btrJZtfNcStrypYbgpwcOySfyI1dUOhkVj87mNYQN2/u6k/pk1tnW3FWl215h1Zn lDqVkLTlc1ZnZ/c8djHmyNyZ2/u5nFp/hv7+GJwBUYJ4qcgCHulkw5kRG2QGhUbGyTApFrLJjk0X LpipEc/czR1vGbublhKebBbi4M3g1p94BejuDDGHsAQQo3Fj3vD2NugdmWs0bkgmNcFKiZ3+tk3M WY926fNR3OSASbNJQF2MWfjkavZD+uOONU+q7wum0PUhSRVl6cuq+AkOsQOCB/i/vDdnFv3j+toX K/A4nIH3na2sb7k/vWraiZKtNTXMglqQnstr7ZEiBxxwMGoBC9y0xsaWvYAJ0ipANE0DKyUQ6UgD qNBwak6u5rQ6sYQjhmtk6v39wheld/Cv2wLdehhElreBuI6OJBG4uPaTdQXAuxj89BQ4yOz2Arr1 7DTsZ+JANFitt8NDq4FA1Zv8CUAF7ouJtvJy8ryYnA1TVp0tpJuwX6bP2HGBq0voXZwwQzsiYsjE zYW0WmSZVhs9Y49BV7cq5vCsgdx4mXJe8EcLe1l3STr6xAWOXzoQ0DKv9SdRKiDbGSxWiXmNmzsI cXQ36HmVBGS5iYnCyZEhhzfX+9Fzj17Q21/U4BH193CfoacN9Zv2/RCZ8Di3/F+EDHxlPYsTrz/C kw5/f7nvrqIy+mrjSfp0bR34swR8FQGWdmZymJ0qyANwoASs9FDr26IATltdgv/cH7Fi2pLkkGUb G3PoYTx44+6Bo4K3xIdU0ysii8I5aDZtOr+X0n1R+mrvgaOe7nn8R28IJ4zKwJtPQAZkC3ueYLlC rSjj3VtKOK+Wm1y2yFJNhx2gnaqBuhKoc4D6g/epK7n7LY/IISGMUQ6pFqBxwCgBPFQLHvKAhdFD 9n98pFRJ+hFwEsuMTo48uMkk44JIwgZ6dde3dKf5KA67uxPjIm2NevbxhTn1n6h98jDZuOIXfzLs ABa+T0quxTO+vYWTzTEnPhuwaFVweHZo/s7z9M2qKBOWMekV4Dm3v6wCuyAHauBaUU/e1tcLYpFF 2EMi3gaSo0IwUJ+GVzKBmmNWGWSn6xnq4Pl24OL6l7UGzJhg2faLHLFcbKEiizWTX/k2kF9lXQVn NQfsvS/6BlDdHTKIFKn1PDspGzRMUmTQQy4ngAw0B+dj78s4cL+ZHj/dRC2Vl7Dz7bu4+9KnG7+m t0kDTsA76unuew/ormOXcMRX9A/aBNWt+1HcYRN9ZEcFL4BWnaAy2lHhAmgjarUMEMKylg0QpFdR cHzRtJf0nzQfp9eVTA8amE3XiCwOjtHHE05SQTjA4cKVkVkKSDYElYKlgHzg6Gbn2RZRADi5hutH gKXGxt6WFdWlZO35K8sabgR7Tgpq/Xf9pMQpfdXjHuLSnOKQLeV0gMgSemnp9lvOHu4hKVB0BmYX +nSQCCmcwbR09Pxcdj6RkLGeAzoGsGzrQgABdsXddVqtcRDLW0oAiS2SFE4qJa+y6QN5zF0b+WWn mZeWL6yaEBY5lMaHL4hZ8fqz8j9zRZbO1fsOlQ72wXemrlqWa91xkf62Dd+WJq6bMjx55KgYjSrK y1QevfDs3AVXMh0K1md+HGowxHkOPZaa0pS85CnoBLrwFvCBvcpDfYOaKafO/FraXdSpuvrtb0DT Fbq/VJufkBob5EqVtwkmR5jkkMkwS2IYl9D0iw/cu/m0x6pn10M1Pfo+PkcTT9LLOonKif5TZGkZ tmXzc3fuO6Eb/fm3AjN3EEA0vbBn9GhrOTuLsa1P+B68P3RHJqh3YjDa5hJoJuBrhIbAVvb8wWng I6VC4aRUabScWOIAKGApB4g437m1sTV1o5PHGOOaY7BhVP7Kpc6HuiReXZNfFSb9QOVW10M1+/zC SH3CgvllWuesSYH7c0IyQ5wcOnVz92if2Ndv2uIuiwvGfRg1tl/aL9YcPx9837OH1DO4/5hZH4f6 fcK0zAUtWWxIWW6CCm6QwaEBEKVQFXUcnBloYi/RuO9ec9Lh2TWLP6SvT9XFkUGTNqYe2J2SegCi 8PcNoRsakukremsHLj49qaDx8tULrHMIa33CvQAfQE2E/AougOhxZKh4BwrGn/M97PzqYDP9I+np mup7rjVdV0bkV1Vkx67HOaovm7Azbn8Ak8ya0u5x8edu3KpfzfQOBM4PQG9WPZDayLwL7rXzBiOg Pr5TnPOJPr/yZkrsN1mzivsfFXoeSEndXZmeVppbUmgt34m5teEBxAGSiOOVhrMXmq+cB+7jwCsu oLeirTLYNLdHv5NEbSu9WG2rz2JuhqXPy9qn9BV2uncTO+CWJ+2P5MwpFJpJeEefyWsy9uHJqnIz dsUc7og96Xf0T2nPGst8vDl3xPw9LIagHyarIIZULGI1RoMR+k1wEXgIAKJQsNbhyM6d8m5ZqUGR 3X3040c2NXGfFy6OGxQ4xXFH+8BZswtbIFMTNJyGc89AZxfWPahYibGBSAe6s6LGWBoNMlsXoZW/ 5555NR30I5Ysz+/igFMP3f0l8dq6umV7ou/u+urZtj3LMyqrl6VVTu0W7qGfG2E6VIB972/FuHDr qpbYN01p+7ne186cvnLuwjmwIw9aa1aBnOzZF+RBsEO6tvV3YoUsz7ziTOrBceaUuLB1voCZ10XT K7YLM0lpXvqE9cuFk8yGfHAI7L3XecBZ5pvNZv55U5NVwWutzSAJqLg3QGWrdXDW0JJqsATocNVT GotPf0dLV0J41uFDNFWYS1yXUdb1ZgFvk423rTpkmduqA+gt1oLfNDa9Fcz3kA/gYlfedgrvm1Gq 3xObusV1RUNJ1VFNpP+iz8xT5wZlDuG1m0Nmzp5qqTku6MiO+JlDNlcIW8iRtLSwzzcKd9r88xjk KNvkMP9A3NtY24XklaXcn1UaJm1v7h03Jnkvr91SM2pRsH65kExyExMCiq4IrJsYCdjUAZ9OLIvJ be0gamsO3z/WkRVr/nEXK9OfFzygL2qP5OUeOZqTd4TIsW59Kn0oND5fjV1wpyuXr1z7x+UG5vs8 uoBXA19H1p/LoWW1eQI6MgII0upk3HuYyasYUjQ//2psyoP0iA39ZHtS0/bvXZJ8mC4QnVobHl7Y urWcWguChghWrqLx/OWblxtuM6TngJgLIAFKO2uJ/0Y59A+ynDL/BcM+nuE/fPjQGU4uvLZ08Zgh e3Wjh81KEr6Bd4dBvB+Gd22Vpq33hV9U/QDakCltYHuXUxj2VayY2pLusCOd16RnpBk9Nl3YFhrg 03vjhOWnImSHOiYvyIhVKvt3zz69ZfKCC8ub7mC/HnFJ0SP9NF089B9lhoxe6unqNSY9psv4yPEm TQ9neXt3Q0BGZMTOKQdAH/fW16S3aBuLWg8Vc5DWyIJXZrL1+rbunEi7BfnOju+TnX302DG5l6dL 6U6pf3QZmVOIJfF0XaGwKbgPS4woC2z7Hvpt6APaMpkOuEGsqmyGerN7bljGzRnlodIO5g6yxPDw 9UPN281jEkKNyaRIOLpu4OjwCRvyyWAID+AHTLknwI/9JmurblDW8EEa/9WPHq5dvH6upYm8VsiO WTgxleTb3xFD5/AlvONof8dWCeUqWznkdBweR09a9g3jDftqdxr9jtdQ88l9vW4Djy9+lDWQRGHr 5UYyz9pMMo61NDENOoMGvwI3KZw0xgY4Dm+TiYUpp8OdcTbd9rC8X48+Hkdv04244H7zEPqUeGL6 5+gBww1W2lH4Go+dRqcDHzXktJfAByyS65S2fAbV82+boPME3690GtrHd4xKphV1oAn1973cXL1+ MNP4APcBGZMH0Zh9Uk/37nGdnXlPYVtKZkYqibNeqhk+bQL8IYDBXvbHAKQA9jtm0sSxIZPCvAKS FkTFB0/8LxdQl2IKZW5kc3RyZWFtCmVuZG9iagoyNSAwIG9iagozOTY3CmVuZG9iagoyNiAwIG9i agooTWljcm9zb2Z0IFdvcmQgLSBJUHY2IE9wZXJhdGlvbnMgXCh2Nm9wc1wpIC0uZG9jeCkKZW5k b2JqCjI3IDAgb2JqCihNYWMgT1MgWCAxMC4xMi4zIFF1YXJ0eiBQREZDb250ZXh0KQplbmRvYmoK MjggMCBvYmoKKFdvcmQpCmVuZG9iagoyOSAwIG9iagooRDoyMDE3MDIxNjIyMTY1M1owMCcwMCcp CmVuZG9iagozMCAwIG9iagooKQplbmRvYmoKMzEgMCBvYmoKWyBdCmVuZG9iagoxIDAgb2JqCjw8 IC9UaXRsZSAyNiAwIFIgL1Byb2R1Y2VyIDI3IDAgUiAvQ3JlYXRvciAyOCAwIFIgL0NyZWF0aW9u RGF0ZSAyOSAwIFIgL01vZERhdGUKMjkgMCBSIC9LZXl3b3JkcyAzMCAwIFIgL0FBUEw6S2V5d29y ZHMgMzEgMCBSID4+CmVuZG9iagp4cmVmCjAgMzIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDQ0 NDUwIDAwMDAwIG4gCjAwMDAwMDkzMTIgMDAwMDAgbiAKMDAwMDAxMjMwOSAwMDAwMCBuIAowMDAw MDAwMDIyIDAwMDAwIG4gCjAwMDAwMDkyOTIgMDAwMDAgbiAKMDAwMDAwOTQxNiAwMDAwMCBuIAow MDAwMDEyMjczIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAzODkyMCAwMDAwMCBu IAowMDAwMDEyNDQyIDAwMDAwIG4gCjAwMDAwMjMzNDQgMDAwMDAgbiAKMDAwMDAwOTUzNyAwMDAw MCBuIAowMDAwMDEyMjUyIDAwMDAwIG4gCjAwMDAwMTIzOTIgMDAwMDAgbiAKMDAwMDAxMjgyMSAw MDAwMCBuIAowMDAwMDEzMDk3IDAwMDAwIG4gCjAwMDAwMjMzMjIgMDAwMDAgbiAKMDAwMDAyMzc0 MiAwMDAwMCBuIAowMDAwMDI0MDEyIDAwMDAwIG4gCjAwMDAwMzg4OTggMDAwMDAgbiAKMDAwMDAz OTg5OSAwMDAwMCBuIAowMDAwMDM5MjkwIDAwMDAwIG4gCjAwMDAwMzk4NzkgMDAwMDAgbiAKMDAw MDA0MDE0NyAwMDAwMCBuIAowMDAwMDQ0MjA0IDAwMDAwIG4gCjAwMDAwNDQyMjUgMDAwMDAgbiAK MDAwMDA0NDI5MyAwMDAwMCBuIAowMDAwMDQ0MzQ2IDAwMDAwIG4gCjAwMDAwNDQzNjkgMDAwMDAg biAKMDAwMDA0NDQxMSAwMDAwMCBuIAowMDAwMDQ0NDMwIDAwMDAwIG4gCnRyYWlsZXIKPDwgL1Np emUgMzIgL1Jvb3QgMTQgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw1N2QwNzFmZDQ1OWYwMzM3MWY0 N2IxMTY4OTQwZjhiMz4KPDU3ZDA3MWZkNDU5ZjAzMzcxZjQ3YjExNjg5NDBmOGIzPiBdID4+CnN0 YXJ0eHJlZgo0NDU5NAolJUVPRgo= --Apple-Mail=_0A19FD05-2255-424C-8A8A-5A2D7B615C0A-- From nobody Thu Feb 16 14:35: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 548FE129556 for ; Thu, 16 Feb 2017 14:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toR5Y2gyLqDr for ; Thu, 16 Feb 2017 14:35:03 -0800 (PST) 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 9F3D21296DD for ; Thu, 16 Feb 2017 14:34:54 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id y6so5980918pgy.0 for ; Thu, 16 Feb 2017 14:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=yp+6zq8yO/bFONqGRE0RQj5j3BYWPZv9X1vWVXkcKng=; b=khLS1njI8fskbjOVFlAzX78kBnvbfFUFMnPCwXKaBDP8XXtnyWykbR/JEkp63faBud liucUg8wEpKnQHWS813+B/EozvA18+iUCx+fol3Vv7ZYunKWinlzvzWEcsJ6NL8P+vdi 2jqMJYSRS8AvvgNm1IUI2At3KkMwYn1HtMAuTsizZyzj2UdhZNCamPOwLB9DRwnaMrHT fhqmm1Vq8mBcUsiCuEf3buwURxMLkyErSzhspyQC7i0AsMZlXE7Jwm68juzCg4irIJkF K33C/testvdPbZI2FXqtfcjmFk+12sPurP1bQux99AxSjzt9u9GUYo+eN8sF6efLnqrX 5VUg== 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=yp+6zq8yO/bFONqGRE0RQj5j3BYWPZv9X1vWVXkcKng=; b=kE+Ro39Ig6yP2DsP6H1xgVyjPBQD/GPmwfgUVXmYsiObjuKK+fCag5TMdQ7CSm++gD jURuMP10XxO+cctQZqUiyERZsuXqfJjkoumG4U22EqFFW3TrA9aAuOp1WTnOLFEXLBi4 PUvp8li3TsRMOQAef6SUM4Zze7BmPj6lVVfiFTtj9Eunmw7XUkkcOxiQ7VkkBPzPbFLI SV3UG335XLNzPjmUT4deaymsmZdCbTw4DT4Qwj479PnnCjGfjP39UBQk65UWGxcVQWXM mRBB+iC9W48EK6Is0YfncKlHCOB43ocHdEgiGxKkMEGuoODPlTm80xXdjaXfZlyjExJM 4Dzw== X-Gm-Message-State: AMke39mKRgPfmNduAzOwik0IrsPVJs6MuKP2CC1p6BPQkQFRhy7JBgQRB309jwqfkEhbFQ== X-Received: by 10.84.131.130 with SMTP id d2mr6491825pld.41.1487284493989; Thu, 16 Feb 2017 14:34:53 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id x2sm15411351pfa.71.2017.02.16.14.34.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 14:34:53 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <59E0A9AC-9B23-4186-B8E1-5BA497E5F468@gmail.com> Date: Thu, 16 Feb 2017 14:34:51 -0800 To: IPv6 Ops WG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:35:04 -0000 With a draft cut-off date of 13 March (four weeks hence), this is the = state of play in v6ops: WG: Unupdated WG Document 2016-11-13 draft-ietf-v6ops-design-choices 2016-08-17 draft-ietf-v6ops-dhcpv6-slaac-problem 2016-08-17 draft-ietf-v6ops-ula-usage-considerations Individual Submission: Unupdated=20 2017-01-28 draft-xli-v6ops-cernet-deployment 2016-10-29 draft-ali-ipv6rtr-reqs 2016-09-20 draft-ybai-v6ops-ipv6-for-openstack 2016-09-08 draft-anderson-v6ops-v4v6-xlat-prefix 2016-08-18 draft-templin-v6ops-pdhost We expect to have a charter discussion, and are currently investigating = interest in a discussion of an updated version of = draft-ali-ipv6rtr-reqs. Other discussions are obviously welcome. For = them, we need new or updated drafts, and we will ask about working group = interest.= From nobody Thu Feb 16 14: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 25EDB1296FA for ; Thu, 16 Feb 2017 14:36:45 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 QVdU0rarWlj0 for ; Thu, 16 Feb 2017 14:36:44 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9E2129556 for ; Thu, 16 Feb 2017 14:36:44 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1GMaEKb001664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 14:36:14 -0800 (PST) To: otroan@employees.org References: <5E0A55D1-E8A0-4A17-ACC4-197EE4264402@gmail.com> <7094C97B-C2F3-4FBB-B4E5-113A181A508E@employees.org> From: Joe Touch Message-ID: Date: Thu, 16 Feb 2017 14:36:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7094C97B-C2F3-4FBB-B4E5-113A181A508E@employees.org> Content-Type: multipart/alternative; boundary="------------B1228513F6DCB7CD18B2FF63" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:36:45 -0000 This is a multi-part message in MIME format. --------------B1228513F6DCB7CD18B2FF63 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 2/16/2017 2:15 PM, otroan@employees.org wrote: >> Yes, but lots of RFC2460 didn't address issues from RFC1122. AFAICT, >> IPv6 hosts still need to follow RFC1122 translated it through IPv6 glasses. > I would imagine following that as a general advice would leave most people trying to understand IPv6, very very confused... Which is why it would be very useful to have both this doc and an updated RFC1122, but neither one should begin in a vacuum as if these precursors at IPv4 aren't relevant. Joe --------------B1228513F6DCB7CD18B2FF63 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



On 2/16/2017 2:15 PM, otroan@employees.org wrote:
Yes, but lots of RFC2460 didn't address issues from RFC1122. AFAICT,
IPv6 hosts still need to follow RFC1122 translated it through IPv6 glasses.

I would imagine following that as a general advice would leave most people trying to understand IPv6, very very confused...
Which is why it would be very useful to have both this doc and an updated RFC1122, but neither one should begin in a vacuum as if these precursors at IPv4 aren't relevant.

Joe
--------------B1228513F6DCB7CD18B2FF63-- From nobody Fri Feb 17 01:03: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 86BF512947B for ; Fri, 17 Feb 2017 01:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 yAbyJ7u787or for ; Fri, 17 Feb 2017 01:03:05 -0800 (PST) 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 6DF67129568 for ; Fri, 17 Feb 2017 01:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487322181; x=1487926981; 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=IhwizbnE49XlC9VzRuK3Cj0nt PD5zbVy4OWZEPfKYu4=; b=b4mujPIx1PrTaXQXNlnE9//15iokS5fEd7FiBcnuH hoRw8AgCxcFj4XYWjE5f4z/HFO2X6OZIpF+cWRudUnceBCLFA3oVefzj3EXgw/BT oddXTxkgaWYyWcBm5J+kyAMz97WE/DQM/Z/T+sPbAn9lQpBPdhnlpvKGxt3O3Hq5 ek= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=a7x5QDeMcz9GfpfmQmSgEXlj72dhYQ8eam1mC3efSUJX9eGGhdVOweAziOR2 PPT5mfqaX1KVa/9vuuV7O72nuOtMJp0PyotHi7YmzzM/2bl5xVYDsADH8 IQcuil2arwawoFE3kmBOO02+/AnP5rT0L93fgLgdOml4j1xveK4w4k=; X-MDAV-Processed: mail.consulintel.es, Fri, 17 Feb 2017 10:03:01 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 17 Feb 2017 10:02:58 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005369159.msg for ; Fri, 17 Feb 2017 10:02:57 +0100 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:170217:md50005369159::3iAYE2EfYbXZGJt/:00000A3B X-Return-Path: prvs=1221b41efe=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Fri, 17 Feb 2017 10:02:55 +0100 From: JORDI PALET MARTINEZ To: , IPv6 Ops WG Message-ID: <7E4C8EA4-D170-4579-9132-B172F54A9C61@consulintel.es> Thread-Topic: [v6ops] Looking for comments in a charter update References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Looking for comments in a charter update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 09:03:07 -0000 Hi Fred, One of the main issues is the lack of support from the IETF specs of mechan= isms such as 464XLAT and MAP, so operators and end users can go to the mark= et and buy a router with not only supports DS-Lite but also those =E2=80=9C= IPv6-only in the WAN=E2=80=9D protocols. Can we somehow include this in the chapter? The ideal way will to update RF= C6204 as already discussed in the list, or work in a new document to descri= be that situation. I=E2=80=99m happy to volunteer for that, as already indicated several times= . Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: Fecha: jueves, 16 de febrero de 2017, 23:26 Para: IPv6 Ops WG Asunto: [v6ops] Looking for comments in a charter update The chairs and ADs have been discussing a possible charter update. We'r= e interested in your comments - yea, nay, other topics, and all that. See a= ttached. =20 In short, we have watched the discussions relevant to v6ops change over= time. At one point, the predecessor working group was developing overlay a= nd transition technologies, and v6ops was chartered in part to say that *th= at* discussion was pretty much done as IPv6 moved into native deployment. T= here were (and are) still interactions with the IPv4 network, but the focus= has moved. =20 We are now seeing real IPv6-only deployments and progress toward more: https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/ https://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-= service-is-coming-soon-get-your-apps-ready/ http://www.internetsociety.org/deploy360/resources/case-study-facebook-= moving-to-an-ipv6-only-internal-network/ https://engineering.linkedin.com/blog/2016/11/ipv6-inside-linkedin-part= -iii--the-elephant-in-the-room https://blog.apnic.net/2017/01/31/chinas-first-ipv6-backbone-network-co= nnect-1200-campuses/ =20 On my phone, I observe that I am IPv6-only (and have a DNS server with = a ULA address). Google reports that the vast majority of accesses it receiv= es from Verizon use IPv6. Several measurement sources indicate that they se= e over 5% of traffic in 33 countries using IPv6, and greater than 20% in si= x countries. Belgium... =20 https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe= ,us,gr,de,ch,lu,ec,gb,ee,pt,ca,pe,in,jp,fr,no,br,my,fi,tt,cz,nl,ie,au,ro,nz= ,hu,zw,si,gt,sa,vn,ax https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe= ,us,gr,de,ch,lu =20 In addition to "what if we turn IPv4 off", we are starting to see creat= ive thinking about opportunities that arise when we do. For example, what i= f we run a prefix to a host (RFC 7934), and use addresses to identify conta= iners or processes? Tom Herbert presented to us on a different data center = model in draft-herbert-nvo3-ila. =20 So we want to explicitly add and invite a topic: what issues and opport= unities do we encounter as we turn down IPv4? What are, if you will, the ca= rrots and the sticks? =20 One thought that I have as I click "send" has to do with markets. When = IPv6 was designed, we mostly thought about service providers and what belon= ged in someone's favorite computer. We now also think about content provide= rs, data center operation, residential, enterprise, and IoT markets - which= overlap but have differing requirements. It might be of value to not tipto= e around that. Is this, or something else, important to bring into a revise= d charter? _______________________________________________ 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 Feb 17 03: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 442551294F7 for ; Fri, 17 Feb 2017 03:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS2fjliQOR9L for ; Fri, 17 Feb 2017 03:09:55 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8F9129410 for ; Fri, 17 Feb 2017 03:09:55 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id y6so11391087pgy.0 for ; Fri, 17 Feb 2017 03:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BBUAgjaTgEpsIBwB2BJrOsyNZNRovZx3WzFs16s6mBM=; b=R0A+YC6RA76u9WOVV/beVnno2fieH5n8ZddhMYzsrAN/KFW4DQlUuwbtou2mMU7PzX I+3FlTQU/bk296rCOsOWtu1ZN/ZOkTDg1JFU/n1jpn6KF2L4YFWQ/oGFy+aZGydkX5ez H+kONx13AKOK6KOqOMvYYyb4VSbdjvdIAp88fVes2ke78iBzMyE+hMMEBrSKIgpvsBSU wLutrcpPCZjWb0b7gCkylLBUx3R1mW9U1YSP5XOQUh6h5h8hHuSgMqd1PK5QTuNx5WZ2 uwFGtxE75YWfaVdTrLKd7QKjdTV9e5bY1663pTJvDsNJc4ZEvgs39gsCULp1jpjLDIHv SR5w== 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=BBUAgjaTgEpsIBwB2BJrOsyNZNRovZx3WzFs16s6mBM=; b=sWYUbuMKnwuFOJNamv0pKphhCOwWz6uPh3YJHeybYy9ofme5BiexW33ssL184EJhhl bKM4U3kKRryTWdtd/sP77tjItUkGmpEMzS05Np+j9hh0q4U22lbXwO1HY0ONPOE0KmkS XQK/NkBIbMepga8MYTBBAgjySuBfQiG2lzKs3BRanEh/VjXswwTMjFsX9zRaSmneHiKm BNXHtZp7p74DAaK2oW8LeT5RaD3QDQ7p6xC40EZMv7F25p3JSjtH3jyxIbxOXOavj9aa ADeYpiSW64fLpX6Sc1rwD1hHZs3x9mbuZNs6wh3TLrno1ENA7LgY87QZGmKcWAHayxz+ L7VQ== X-Gm-Message-State: AMke39kyBlm5HyEsOJfUL7/qOJ/Ramm3zgDjvClHctURPK6TQ8UweLSI0o3nmMQMcZfb6g== X-Received: by 10.98.14.217 with SMTP id 86mr8773322pfo.79.1487329794630; Fri, 17 Feb 2017 03:09:54 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id c2sm18988354pfl.61.2017.02.17.03.09.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 03:09:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <7E4C8EA4-D170-4579-9132-B172F54A9C61@consulintel.es> Date: Fri, 17 Feb 2017 03:09:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E4C8EA4-D170-4579-9132-B172F54A9C61@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Looking for comments in a charter update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 11:09:57 -0000 I'd be happy to entertain a draft proposing what you have in mind. I = just said that in private mail. I no longer work for a major routing = vendor, but I can tell you that the obvious ones do have translation = products, and are working with their customers on IPv6-only operation. = They understand "IPv6-only" to mean "no IPv4", not "translation", = though. Their customers are drumming that into their heads. > On Feb 17, 2017, at 1:02 AM, JORDI PALET MARTINEZ = wrote: >=20 > Hi Fred, >=20 > One of the main issues is the lack of support from the IETF specs of = mechanisms such as 464XLAT and MAP, so operators and end users can go to = the market and buy a router with not only supports DS-Lite but also = those =E2=80=9CIPv6-only in the WAN=E2=80=9D protocols. >=20 > Can we somehow include this in the chapter? The ideal way will to = update RFC6204 as already discussed in the list, or work in a new = document to describe that situation. >=20 > I=E2=80=99m happy to volunteer for that, as already indicated several = times. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Fred Baker = > Responder a: > Fecha: jueves, 16 de febrero de 2017, 23:26 > Para: IPv6 Ops WG > Asunto: [v6ops] Looking for comments in a charter update >=20 > The chairs and ADs have been discussing a possible charter update. = We're interested in your comments - yea, nay, other topics, and all = that. See attached. >=20 > In short, we have watched the discussions relevant to v6ops change = over time. At one point, the predecessor working group was developing = overlay and transition technologies, and v6ops was chartered in part to = say that *that* discussion was pretty much done as IPv6 moved into = native deployment. There were (and are) still interactions with the IPv4 = network, but the focus has moved. >=20 > We are now seeing real IPv6-only deployments and progress toward = more: > https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/ > = https://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-ser= vice-is-coming-soon-get-your-apps-ready/ > = http://www.internetsociety.org/deploy360/resources/case-study-facebook-mov= ing-to-an-ipv6-only-internal-network/ > = https://engineering.linkedin.com/blog/2016/11/ipv6-inside-linkedin-part-ii= i--the-elephant-in-the-room > = https://blog.apnic.net/2017/01/31/chinas-first-ipv6-backbone-network-conne= ct-1200-campuses/ >=20 > On my phone, I observe that I am IPv6-only (and have a DNS server = with a ULA address). Google reports that the vast majority of accesses = it receives from Verizon use IPv6. Several measurement sources indicate = that they see over 5% of traffic in 33 countries using IPv6, and greater = than 20% in six countries. Belgium... >=20 > = https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe,us= ,gr,de,ch,lu,ec,gb,ee,pt,ca,pe,in,jp,fr,no,br,my,fi,tt,cz,nl,ie,au,ro,nz,h= u,zw,si,gt,sa,vn,ax > = https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe,us= ,gr,de,ch,lu >=20 > In addition to "what if we turn IPv4 off", we are starting to see = creative thinking about opportunities that arise when we do. For = example, what if we run a prefix to a host (RFC 7934), and use addresses = to identify containers or processes? Tom Herbert presented to us on a = different data center model in draft-herbert-nvo3-ila. >=20 > So we want to explicitly add and invite a topic: what issues and = opportunities do we encounter as we turn down IPv4? What are, if you = will, the carrots and the sticks? >=20 > One thought that I have as I click "send" has to do with markets. = When IPv6 was designed, we mostly thought about service providers and = what belonged in someone's favorite computer. We now also think about = content providers, data center operation, residential, enterprise, and = IoT markets - which overlap but have differing requirements. It might be = of value to not tiptoe around that. Is this, or something else, = important to bring into a revised charter? > _______________________________________________ > 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 From nobody Sat Feb 18 08:21:56 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 88A5B1294D7 for ; Sat, 18 Feb 2017 08:21:54 -0800 (PST) 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 B3tCtT-85oHC for ; Sat, 18 Feb 2017 08:21:53 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD82712940C for ; Sat, 18 Feb 2017 08:21:52 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id r141so27658125wmg.1 for ; Sat, 18 Feb 2017 08:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=XOCyOMC82PFxlqarfhAWHKh9SnUuzFn+aBGxp/10QTc=; b=o1i0lNaz085t8CEvezZLXL92KnA22eTQpCq3wiHl20cbWkMeDGNx4tlfZdu+mJHJDX mAV9e8VbEzR6jOmC+U7jZmJyte2yF49J6RKgYf4rrQuvuLFi3oa66wAuXUgY//VKm3Ze rWv5ZMLDcrjssAvATMHhBQf7PGOqJ43i11Pvj44nILtgE0Gjeq6TWK8iFoEWZUYAYUIi LNlrj5A7lLvWZMvInLIQffgbyzjCTU6qModW7U3zGrSeAfvVwSQTCCm1McLqbRQZSagV YW7WXuwK37GbP2Y9jF3CJhON7ZCUzulpx4Dxn518gAwuPIqT/7Lz8oRXml516+klwZX7 q/gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=XOCyOMC82PFxlqarfhAWHKh9SnUuzFn+aBGxp/10QTc=; b=dT3r23r+fKRWFEUrfJYkq/JCsO0/9iGzG+HzO9KcXw9ZFtIUe2uoVf5on9mJColo+O 0Fo+Vvb0kiwed/dRIVnflKEdguge9ckFar4POg1+B1OTuVA7cQ++7cHaKapHNgUvRT8P B3rdu/9VMINIYs5oVO3HY0gsB/onwfZBDu9Vxv0ceLV+bWWv9J9leTUZ0IL7mB1GvDf2 uoPrfVlSEWkWEx/XXW7UaD94JtgYN4g4kjuse11SR7ODPjPjD1I7+LNvWLys7Bb/vZyN lAcalvpKc4k1Ww8LznKf9F+hyCmzNeFThC3pRDUr8fi+4R5/vwDsbaxa/sMlAKzUlIMF sunw== X-Gm-Message-State: AMke39lXY2DcBbyqxbMrcrdDp/Apqo7M0Nz7KUBVcsJWxQz2rUoAnOimaXaJ+3+uFsSUyQ== X-Received: by 10.28.174.14 with SMTP id x14mr9603409wme.75.1487434911221; Sat, 18 Feb 2017 08:21:51 -0800 (PST) Received: from Russ ([89.27.137.162]) by smtp.gmail.com with ESMTPSA id y126sm6153147wmg.19.2017.02.18.08.21.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Feb 2017 08:21:50 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: Date: Sat, 18 Feb 2017 11:21:49 -0500 Message-ID: <005101d28a03$1b8c4c00$52a4e400$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKKAuz73KLM9Yv2TUyglYVbPtkk8g== Content-Language: en-us Archived-At: Subject: [v6ops] Posted a new version of draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 16:21:54 -0000 Y'all -- Posted a new version of draft-ali-ipv6rtr-reqs. Data tracker page is here -- https://datatracker.ietf.org/doc/draft-ali-ipv6rtr-reqs/ We'd like to present this at the Chicago meeting, and potentially call to pull this into a wg item there. I have a list of outstanding comments and questions; I'll email these to the list in a bit, along with some thoughts on them. :-) Russ From nobody Sat Feb 18 08:26:25 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 365AD12946F for ; Sat, 18 Feb 2017 08:26:24 -0800 (PST) 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 aBeDV0FspYnX for ; Sat, 18 Feb 2017 08:26:22 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 88BBB12954B for ; Sat, 18 Feb 2017 08:26:21 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id r18so7375796wmd.3 for ; Sat, 18 Feb 2017 08:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=BOXZv7jKVG4jrFcKVlqxrezr3BPA9RxEQh9ZOMcEQLc=; b=Noi8J0Z4ZsQhlBPjOeazxUYWYxVWfh7xt3YzOl774J3uRw3TDmzEI1iEuizoCx4gtK PwBpnB87hsVeWxi27BbffYiK3dTkivL6cwoLqXR1OA7rhBQc8fLKhFXq6ubAZF2dVSm6 ina5hKQs6ybeg3+5ep2qR1aoK02jSMBSi1S6/GD73dL0s0cY9H20D0XrMHNl47d5kxDR Xe4RQziW0C22KkmY1tFjMvOKci4SGKSrjy1KuXVQlw/cgLctNNssU70LTgpdZOvKs1xi 37Ii7UVFTItmeeRrAaYVyN6drvzdi2IXRUM6lnrf/0Crs6Z4AL1pY0+Hmod00UZjY224 U/FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=BOXZv7jKVG4jrFcKVlqxrezr3BPA9RxEQh9ZOMcEQLc=; b=ZS1pUg+5YBmqB3buBQsyZ04OBt49RMp6p9cFXy/tndwE5LQLRt3usYMN7yZvQe+lqC xt6F+iYjCcBeloCLbrl9xkSrvBVgOhd8bnOaQeP9rfemEYKeVRvalEvnc2eELh1QnUMR Op6eGpELKIXgYjgqtUTNyarcFEvpA7xUcpZaQ+r3ke0jwYYobUT0Jm5WkxdaLkD/nqHW KwKqAREd1S46igmhvwfnfTttFkuqc3D0FhcUxHLTL1uUBapGTPlKGZN6grsqlqRdaXsX 1vjKSRPpbBvrxsDFjsZW4QY38ablLfHqhyd8coSaVUREHYAo0r7cF5P6KedM1ew9IhtR YQew== X-Gm-Message-State: AMke39nUaR2VcDiImaM0fcb0798XjVis96KRMvImZQ/bbLZ7xGf1fSW4xzd20dimoj2U8w== X-Received: by 10.28.18.134 with SMTP id 128mr5306379wms.53.1487435179889; Sat, 18 Feb 2017 08:26:19 -0800 (PST) Received: from Russ ([89.27.137.162]) by smtp.gmail.com with ESMTPSA id c9sm6191791wmf.18.2017.02.18.08.26.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Feb 2017 08:26:19 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: Date: Sat, 18 Feb 2017 11:26:17 -0500 Message-ID: <005201d28a03$bba8c2e0$32fa48a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKKA7SsWymceVWYRN2BXFPPlc/Lwg== Content-Language: en-us Archived-At: Subject: [v6ops] Outstanding edits for draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 16:26:24 -0000 Y'all -- These are the outstanding comments and areas where work is needed for draft-ali-ipv6rtr-reqs. :-) Russ == There has been some discussion around changing the name of the draft. It would be good to discuss this to see if there is something better here. == There are still some sections that either need to be filled in or deleted. If anyone has opinions on which to do, it would be good to hear them. == The bullet "The desired optimization" isn't clear to me. Do you mean efficiency? Something else? It's hard to describe, because "it depends." It can mean "higher utilization along all links, so we don't need to deploy more bandwidth." It can also mean "lower ovoerall jitter, to better support application x." Or, perhaps, "improving utilization while also decreasing jitter for application x." The problem with describing this particular third of the triangle is the goal can vary depending on what you consider "optimal use of resources" -- which is actually as it should be, because every network is supporting a different application mix in support of different business requirements. "Efficiency" has the same problem -- "efficiency of what?" The efficiency of supporting a particular application, efficiency in terms of making the most use of available bandwidth, efficiency in terms of... == "Network devices should place a priority on supporting machine readable APIs." Do you mean device maufacturers should focus on writing code to do that, or do you mean the devices should prioritize API config bits somehow? I think you mean "Router manufacturers should focus on developing machine-readable APIs." But I'm not sure I agree, since to prioritize something means to implicitly deprioritize something else (if everything's a priority, nothing is), and I don't want to encourage vendors to prioritize APIs over CLI. Just about everyone else wants implementations to focus on APIs rather than CLIs, I think -- at least most of the folks I've talked to. We should discuss this some, and see what the list says, as well. I have changed the text a bit here, however, to make the concept "more clear." == The bullet "Configuring an prefix length longer than a /64.should require additional configuration steps." Hmm. I'm not sure about this one. More discussion required. I'm ambivalent about this; I'll leave this for discussion amongst the contributors to decide. == 5.6 I wish you luck! I actually don't know what to put here; is there a specific set that should be supported? Is it "fair" to ask for hardware support for specific extension headers? == 3.1 citations needed for SNMP and MIB definitions. I couldn't figure out "one" citation, and I didn't want to list them all. :-) I suppose we could just list the one for IPv6 (?). Thoughts? == This section should make reference to ANIMA and SUPA WG efforts, even if just for awareness. Maybe HNCP (Homenet), too. All of those efforts could make a difference in this area. I'm not certain ANIMA, SUPA, and HNCP fit into this section. From nobody Sat Feb 18 13:24: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 0AEF9129570 for ; Sat, 18 Feb 2017 13:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56fi18gVyqS5 for ; Sat, 18 Feb 2017 13:24:41 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A008F1295FD for ; Sat, 18 Feb 2017 13:19:25 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id o64so6735853pfb.1 for ; Sat, 18 Feb 2017 13:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aiVmkO3VWuJTD60VY22xpkysptWbwbOZPjc/B2UD5o8=; b=Nz2u/oGc158OldPyEB5QGGpK9fXEmb+UdSBw8zm4j7HHSTX5g1yfGGOaK1LQtLLUIS xw5KCJKfn5dffIXasYtxNptuskgyv4fQr2OdA0AEg8idFKZOogqBL3Sgze9WKnJQzIeB 5/NCv+rCVy8W6xhId9j8g38tH3GWoeY5Is+2oIMAU54ifs7K7OPWOWBHaV54rnZ1ce7Q LkcXI7cEqPHzNDSg0oAT3v1TLikfWW2QR64I0fBZBHQh+P8D0zCsRvw6iQ/oO9TKLHpe F5GovSJSGQ2hR6CpR46nGVQ45l+is79B+lyNlqhwKtnEq5LYYt4FczRqZ88ooojKhJcZ 4hSw== 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=aiVmkO3VWuJTD60VY22xpkysptWbwbOZPjc/B2UD5o8=; b=hnxUcIv2/B8/kWzJD/tM5QvpCya/vpIx2gpU0tuP2oJGlGL2hKeRdfblyey12Yl8sB kNkCvigwVch6/PhQrfucCyEWSOGsGAcaJrMghR1MudiUYKvu+RJFMRzbFEvN0Qe5nUEd zAjevb0OaPllgqDs4Y1zCvEfsE4MhAgPEJa6hDjTFimc5w8VzvSdW/hbCkCbhQCMuxUB zvZ1Hu94JoAHhkmJcFkJ9qlr1DyeZO68tPIY/p/X0ne2QhTNjukf4ADtXJ5H9ApC4986 lO4iFsYN/JnJx8Eqvdx4nOpFWSzepbvt5TpTfd/efnGsashbA+FOyJN1VSu/aAalcxht 2QOg== X-Gm-Message-State: AMke39mM3zO/KLw2CJEp6CKrvJ1j8frpMLgV56BRduj5lhcK+GA91WDJ6JRrZbWI2W62pQ== X-Received: by 10.99.95.216 with SMTP id t207mr18347171pgb.0.1487452765219; Sat, 18 Feb 2017 13:19:25 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id i21sm26750232pfi.94.2017.02.18.13.19.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Feb 2017 13:19:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <005201d28a03$bba8c2e0$32fa48a0$@gmail.com> Date: Sat, 18 Feb 2017 13:19:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2DA40C6A-845E-4B95-99D5-6144F3B7EB0D@gmail.com> References: <005201d28a03$bba8c2e0$32fa48a0$@gmail.com> To: Russ White <7riw77@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Outstanding edits for draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 21:24:42 -0000 On Feb 18, 2017, at 8:26 AM, Russ White <7riw77@gmail.com> wrote: > I don't want to encourage vendors to prioritize > APIs over CLI. >=20 > Just about everyone else wants implementations to focus on APIs rather = than > CLIs, I think -- at least most of the folks I've talked to. All hats off. Personally, I think CLI is to be deprioritized. SNMPv1 was pretty much = handed to the IETF, and the IETF developed it, including writing a lot = of MIBs. The operators essentially came back and wanted something they = could read - ASCII. The outcome of that discussion was NetConf. Then = they wanted a list of improvements, and the outcome was/is being YANG. I = know some vendors that want CLI, and perhaps even a standardized CLI = variant. The one thing that the operators have not really asked for, at = least in my hearing, is CLI. At least part of that is Cisco's fault; CLI on one OS is not necessarily = portable to another even within Cisco's product line, and the companies = that use the acronym to mean a "Cisco-like Interface" aren't = interoperable either. If there is one thing that I have heard from the = operators, it's that they want something that is interoperable across = the machines they use, which means multi-vendor interoperability. YANG = gives them that in the sense that there is a described outcome, and the = vendors supply whatever it takes to implement that outcome on their = equipment. In your list, I didn't see James' comment from the other day, regarding = discussion of routing. I'd suggest you add it to the list. You might = also be interested in my reply - I asked a number of open-ended = questions. They come down to - first, for what market, and making what = assumptions? Second (from a different email), should there be a list of = target markets (and, reading my email again, let's add mobile wireless) = with differing requirements? I also didn't see a reference to Joe's comment regarding RFC 1812. If = you like, Joe and I can put our heads together on that one - I have some = history in it. What he asked for, and what I think might be a reasonable = first step, is some description of the use cases the document targets. I = *think* there might be real value in a description somewhere of the = Internet in 2017, which is quite a bit different than what it was before = 1996. From nobody Sat Feb 18 18:11: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 83863129420 for ; Sat, 18 Feb 2017 18:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1lXgRdhX_4T for ; Sat, 18 Feb 2017 18:11:33 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D571293EE for ; Sat, 18 Feb 2017 18:11:33 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id c193so2281741pfb.3 for ; Sat, 18 Feb 2017 18:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vDgG2teC8Td3dMP6dUwNNgE68dBxqheZy6pu0n7Z9iE=; b=l74fCSXI10eGT99s5teLYfNx0KQhBTozS6yN7EwFeOTLIaKchAVFI0D0aD8ZCjtIZO Z73kmFz4LKzfdZMiAGja3ZIFl4TmRighythynQ3W012EWJZt4JGCXpaA/nBljNQ461RP NUrC/2LOGGM2rKrzW9kBOugdj/OoQZjMSTcsLC0PVeq7IlgGIlV89LYFug48ZwDoMqkP rtT61ZU4tvaUbF6bT2OvEA1Pmk5ZOxAafiPaiKzgE4v0FwCAyTAILVgNBpFjZTLB/VZV J9+hIiWx7m9aSZ33BvAUUY7MWoWW+s+2pi3mRl66zD3Q7FN1NQ2JAp0S9nAvz34KHFT0 T87A== 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=vDgG2teC8Td3dMP6dUwNNgE68dBxqheZy6pu0n7Z9iE=; b=TZR7P0I7wyhCOvWBEjINAnkABqmDqg9VQE0JXztkhH3Zpg5bjNlwTA5gEYFzfSsfSe c95bGT2KuqvVcAh/L3Uhi06gLnPRSWAzHvhn6XnXH5eV0sJIgMdOB6H9wCy5GCKKZxrK CRLtFonmjBUFUqkG3gQP10GJo0gVWUaAFSjhXn1zjyGZZ53kdPTNt7qR2tRFj3lC4l6S rO5WuBovGBATHj9vgh/kwiEUGGLCGgZU5aJGpStV6z3+9epR8dj8DpAJvsLhlxTIFEdJ 7cANcUxjaJTwv4XQaZlEC0kbC597vCWhFszBGY2C4V4WfO98+ov8H+r+/GCfunVaKPjr +QWQ== X-Gm-Message-State: AMke39lGmb26jMgmr2euJZ4lVKP6XU6Ae+GEtJY/hg1MGyi8UAnzWJ7Nioy/ayePko3now== X-Received: by 10.84.241.10 with SMTP id a10mr21944945pll.47.1487470292791; Sat, 18 Feb 2017 18:11:32 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id 129sm27260203pgj.59.2017.02.18.18.11.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Feb 2017 18:11:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <2DA40C6A-845E-4B95-99D5-6144F3B7EB0D@gmail.com> Date: Sat, 18 Feb 2017 18:11:30 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <005201d28a03$bba8c2e0$32fa48a0$@gmail.com> <2DA40C6A-845E-4B95-99D5-6144F3B7EB0D@gmail.com> To: Russ White <7riw77@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Outstanding edits for draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 02:11:35 -0000 On Feb 18, 2017, at 1:19 PM, Fred Baker wrote: > In your list, I didn't see I also didn't see Lee's response... From nobody Sat Feb 18 19:07:05 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 58850128BA2 for ; Sat, 18 Feb 2017 19:07:04 -0800 (PST) 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, 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 8I1RdGazwWUQ for ; Sat, 18 Feb 2017 19:07:03 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CCC126B6D for ; Sat, 18 Feb 2017 19:07:03 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id v77so8711367wmv.0 for ; Sat, 18 Feb 2017 19:07:02 -0800 (PST) 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=0+dsLeu0eC3XYmGFhmzrs2u5L4CrMs3pcpRJ78P/klc=; b=oXYUji3JazSGWqmdnW/P9EO289Ey9QxXcLby466BVyUaHCG0BfAAjkoPOxu+kuLeMS ZvBGpInzNi6fXYxpe27Ivx/3udFn8CuOvCp7xqLKQNSvVwvIyDRAlO9FtYVKgVtawIqq gwywbXNVoKxh+ovwaDtwyLZcT2A8MVQzhQw3tkC0nWibG45ldwFZqTRao12Xlp6+L7U4 G+5qniCWrA4OlJ3gQ5Sb3kKrPVfA0fqSzJv5D4+yOb3sWxEYPTZ/U+EcvWd0m/sL2tsB K8VQZXSDFXGYqIcNyBo/AmUZcWNsYC5mmOuLytjGXeqVYX3/cibp589I3AINhe9bcQ/m T2hw== 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=0+dsLeu0eC3XYmGFhmzrs2u5L4CrMs3pcpRJ78P/klc=; b=FUPyFmKyWVFVjeRQJ1RWed/mWY80m1YULR5NlOyExsqegdJ2enrsajtCG47efhRT5q iquNDl4RoUcR4VkdDuDnr9OB13F/PYLYUJuov50Fo3cgh1sScf8A90MFDR4nuHya/Z2s 7d/R1T77o+Dn1qs0DZJsS6nQhMfswMWjKCl0+YlwoTO7VIJSPat/1Yf+x/3C3hc3I/pf WYjwTLAGrW/7b8MAAkj7PJWb/MHMzd4O8H/gztSFhSI9iDc94gbkbxcIRufh36YQ9Ho0 Jg0JYtygVWvp/Ul0gQ189vi3i02IwIhBQsamCFWKPEhVMEozlzANiCfUsL+GB4bZQhny QkPg== X-Gm-Message-State: AMke39nG9Qe8wxH2fxv5Ed2cmhfIP9u2NYpI+oNKbmrTUqj7df4x3uRreL8AT1gqlE3b5Q== X-Received: by 10.28.51.205 with SMTP id z196mr11262923wmz.22.1487473621422; Sat, 18 Feb 2017 19:07:01 -0800 (PST) Received: from Russ ([89.27.137.162]) by smtp.gmail.com with ESMTPSA id v128sm7833732wmv.2.2017.02.18.19.07.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Feb 2017 19:07:01 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Fred Baker'" References: <005201d28a03$bba8c2e0$32fa48a0$@gmail.com> <2DA40C6A-845E-4B95-99D5-6144F3B7EB0D@gmail.com> In-Reply-To: <2DA40C6A-845E-4B95-99D5-6144F3B7EB0D@gmail.com> Date: Sat, 18 Feb 2017 22:06:58 -0500 Message-ID: <000a01d28a5d$3c6c5550$b544fff0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLjvkRZywduHSMEjXK3/ZOSgbWw+AJljh84nzoPuSA= Content-Language: en-us Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Outstanding edits for draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 03:07:04 -0000 > In your list, I didn't see James' comment from the other day, regarding > discussion of routing. I'd suggest you add it to the list. You might also be > interested in my reply - I asked a number of open-ended questions. They > come down to - first, for what market, and making what assumptions? > Second (from a different email), should there be a list of target markets (and, > reading my email again, let's add mobile wireless) with differing > requirements? I saw that exchange -- I don't know that I want to say "should implement routing protocol x and y" -- because I don't know that we'd agree until we said, "BGP, OSPF, IS-IS, BABEL, LISP, etc., etc..." And then someone would say "sure, but what specific elements of each protocol need to be implemented," in order to "narrow the list," and then... I can see where this is going before I turn down that particular rabbit trail, I think. :-) Because, as you said, everyone has different requirements here. > I also didn't see a reference to Joe's comment regarding RFC 1812. If you like, > Joe and I can put our heads together on that one - I have some history in it. Sure -- I didn't really understand the question... I don't know how I'd write a "state of the Internet in 2017," other than something like -- - very dense interconnectivity - largely deploying dual stack - might be seeing a shift in architecture away from "real" transit in many ways, and a focus on the "edges" - definitely confused about SDNs and things in that neighborhood (largely a definitional problem) Maybe a few other things -- but I wouldn't mind having some ideas in this space, if folks think it's useful. On Lee's comments -- I addressed most of them in the rev (or at least I hope I did). The ones I put on the list are the remainder. I might have missed another round of comments, though... I wasn't trying to make a list of issues, which is what I probably need to do now, so I can keep track of folks' comments. :-) Russ From nobody Tue Feb 21 01:11: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 AC69A129529 for ; Tue, 21 Feb 2017 01:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 31BYLHpXYRVj for ; Tue, 21 Feb 2017 01:11:53 -0800 (PST) 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 429FA12940B for ; Tue, 21 Feb 2017 01:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487668310; x=1488273110; 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=/Gdf5f6dkfHhP6/d07mb/X81L 3hAKOC90gdLNS2LedY=; b=K1gmGshpCkPdgBEWgDD6/kf2AeR1UZuLrxBQ9zasR 9fGaszDul6ptIZvYLecYxp/PZq11OE7LAjrbmJJggHLHcEYHm7+bxYa6UgE4FBMg oojo5kz/XY95KC+2SauejiiMbUArovyf+NjC4Rak+OYM2x1RsbgOnHiz8h/srvJp YY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=G3C868fQVf1OAnVi0W8mAO4Y7jR9ag+m43/WYVZf+YK6FNvrTb6MOdNItU+W tWz1XVqwFF+TpmS1wI+fGrPUlclGgXszHZ98Fd9YKs8rWlm90rHIHNAvh QExW3yOm/q27UKARBqppJIRlARYs/wbLD3TK7IDpO/QxdB+nzk0CcM=; X-MDAV-Processed: mail.consulintel.es, Tue, 21 Feb 2017 10:11:49 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 21 Feb 2017 10:11:46 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005371079.msg for ; Tue, 21 Feb 2017 10:11:45 +0100 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:170221:md50005371079::1Evr57HzYmolawtW:00002m6o X-Return-Path: prvs=1225bef9b4=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 21 Feb 2017 10:11:40 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> In-Reply-To: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 09:11:56 -0000 Hi, I=E2=80=99ve submitted a -bis draft for updating RFC7084 (Basic Requirement= s for IPv6 Customer Edge Routers). The basic idea behind this update is to consider that the ISPs have not mor= e IPv4 addressed so they will need to make sure that CEs are capable of run= ning on IPv6-only links, but including some support for IPv4 transition, so= the customer LANs can still use IPv4 for older devices or apps, until they= become updated. The approach of the RFC7084 was to rely either in 6rd (which requires dual = stack on the WAN link), or DS-Lite (which required dual stack by means of C= GN with private IPv4 addressed for the WAN). My view, considering the time frame when this document may be accepted by t= he WG and then the time that vendors can take to implement new firmware ver= sions or new products (almost one year from now), is that more and more ISP= s will have troubles to use 6rd (which by the way is not being used too muc= h), or will prefer other solutions than CGN. So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as SHOULD= . In my version: 1) Considering that there=E2=80=99re no more IPv4 addresses and according t= o my experience with service providers, they will prefer to avoid dual stac= k in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to be change= d to MAY. 2) At the same time, I=E2=80=99ve included lw4o6, also with MAY. The ration= ale for this: Many service providers try to avoid the CGN, and lw4o6 is a w= ay to do so, without increasing the cost of the CE. Basically, a CE that su= pports a regular IPv4 NAT+DS-Lite, is already capable of supporting lw4o6. = The cost in terms of CE flash memory for DS-Lite is about 1Kb. The open sou= rce package available for DS-Lite that I=E2=80=99ve been digging-in takes 6= Kb, but already includes also support for both MAP versions. 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those protocols are= the 3 alternatives that a service provider has to deploy IPv6-only WAN, bu= t at the same time provide dual-stack in the LANs, with practically the sam= e functionalities or even more, that what CGN requires. At the service prov= ider network, it requires, instead of CGN, a stateful NAT64 (which cellular= providers are already using) or a Border Relay (for MAP). Basically, a CE = needs only 3Kbytes of code in the flash to support CLAT (the CE part of 464= XLAT). The support for MAP (both versions and also lw6o4), requires about 6= Kb. 4) Include support for 6in4 as SHOULD. The rational for this: According to = my experience, sometimes, business customers (specially SMEs) are in the sa= me access network as residential ones, but they are provisioned manually an= d often require dual-stack with public IPv4 addresses, because they have to= publish external services such as VPNs, or others that may not yet rely in= an IPv6-only network. I=E2=80=99ve seen cases of service providers with 10= .000 customers and 250 of those =E2=80=9CSMEs=E2=80=9D, and all them are pr= ovisioned manually because don=E2=80=99t make sense to find an automatic co= nfiguration. So, I think we must keep this support, with typically is alrea= dy available in any dual-stack router today. In fact, if the router support= s 6to4 or 6rd, the 6in4 support is already there. In terms of flash utiliza= tion, 6in4 requires 1Kb, 6rd 2Kb and 6to4 1Kb. Note than I=E2=80=99ve been looking for the =E2=80=9Ccost=E2=80=9D of the f= lash memory into open source available as GPLv2, which also means that the = impact for any vendor in =E2=80=9Cupdating=E2=80=9D available firmware of a= ctual CEs is minimal, if any, and is more an =E2=80=9Cintegration=E2=80=9D = cost, probably a very few hours+testing. In fact, there are a few vendors t= hat have it already (unfortunately very few) and I heard about some that of= fered it to =E2=80=9Cspecial big customers=E2=80=9D, but not offered to the= =E2=80=9Cgeneral market=E2=80=9D. I=E2=80=99ve been evaluating myself, with trial customer deployments, using= open-source such as OpenWRT/LEDE, the cost/functionally of those transitio= n mechanisms and they just work. Typical CE today have a minimum of 8MB (ma= rket moving quickly to 16 or 32 MB) flash memory and 32MB (market moving qu= ickly to 64GB and much more) RAM, and they hold perfectly all those feature= s without any issue and without needed to take out other code. So, the questions for the WG: Do you agree with my changes 1, 2, 3 and 4 above? Now a more complex question. Do you think it will be acceptable for 3 and m= ay be 4 above, to be a MUST instead of just SHOULD? I think vendors need a very strong signal here, otherwise, many of them (an= d this is happening), are reading actual 7084 and only reacting to implemen= t those transition technologies with specific firmware versions for =E2=80= =9Cvery big=E2=80=9D customers which will buy several hundred thousand unit= s in one shot. But many small and medium service providers, buy only a few = units every week when they connect new customers. This was discussed alread= y in this list a couple of months ago. https://www.ietf.org/mail-archive/web/v6ops/current/msg25152.html Please, note that that this document version doesn=E2=80=99t include yet th= e details of the requirements for each transition mechanism. I=E2=80=99m wo= rking on those already, but will be nice to have some inputs from the WG, r= egarding my questions above. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: lunes, 20 de febrero de 2017, 23:37 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt =20 A new version of I-D, draft-palet-v6ops-rfc7084-bis-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-rfc7084-bis Revision: 00 Title: Basic Requirements for IPv6 Customer Edge Routers Document date: 2017-02-20 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= rfc7084-bis-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7= 084-bis/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-b= is-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 Tue Feb 21 01:32: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 868C112989C for ; Tue, 21 Feb 2017 01:32:24 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, 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 ejUS4cANYcMA for ; Tue, 21 Feb 2017 01:32:23 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0271912959A for ; Tue, 21 Feb 2017 01:32:22 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cg6nz-0005cy-Mi; Tue, 21 Feb 2017 10:32:21 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::12e]) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cg6nz-0000oD-Jg; Tue, 21 Feb 2017 10:32:19 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Nathalie Trenaman In-Reply-To: <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> Date: Tue, 21 Feb 2017 10:32:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------ X-RIPE-Spam-Report: Spam Total Points: -6.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4336] 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a2f53b910b2b20bec5d8c8d656a64556e Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 09:32:24 -0000 Hi Jordi, >=20 >=20 > So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as = SHOULD. While I agree with most things listed below, and I also agree with your = points changing 6rd to =E2=80=9CMAY=E2=80=9D, I don=E2=80=99t agree on = changing DS-LITE to =E2=80=9CMAY=E2=80=9D. I would leave it with = =E2=80=9CSHOULD=E2=80=9D.=20 Some really large residential deployments chose for DS-LITE a while ago, = (before MAP was standardised) and won=E2=80=99t change their plans soon. = They already purchased the CGNAT equipment, etc. Their IPv6 deployment = takes years=E2=80=A6.(from what I hear in all the IPv6 courses) So, DS-LITE is a =E2=80=9CSHOULD=E2=80=9D, not (yet) a =E2=80=9CMAY=E2=80=9D= but also not a =E2=80=9CMUST=E2=80=9D Just my 2 cents.=20 Nathalie >=20 > In my version: >=20 > 1) Considering that there=E2=80=99re no more IPv4 addresses and = according to my experience with service providers, they will prefer to = avoid dual stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE = need to be changed to MAY. >=20 > 2) At the same time, I=E2=80=99ve included lw4o6, also with MAY. The = rationale for this: Many service providers try to avoid the CGN, and = lw4o6 is a way to do so, without increasing the cost of the CE. = Basically, a CE that supports a regular IPv4 NAT+DS-Lite, is already = capable of supporting lw4o6. The cost in terms of CE flash memory for = DS-Lite is about 1Kb. The open source package available for DS-Lite that = I=E2=80=99ve been digging-in takes 6Kb, but already includes also = support for both MAP versions. >=20 > 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those = protocols are the 3 alternatives that a service provider has to deploy = IPv6-only WAN, but at the same time provide dual-stack in the LANs, with = practically the same functionalities or even more, that what CGN = requires. At the service provider network, it requires, instead of CGN, = a stateful NAT64 (which cellular providers are already using) or a = Border Relay (for MAP). Basically, a CE needs only 3Kbytes of code in = the flash to support CLAT (the CE part of 464XLAT). The support for MAP = (both versions and also lw6o4), requires about 6Kb. >=20 > 4) Include support for 6in4 as SHOULD. The rational for this: = According to my experience, sometimes, business customers (specially = SMEs) are in the same access network as residential ones, but they are = provisioned manually and often require dual-stack with public IPv4 = addresses, because they have to publish external services such as VPNs, = or others that may not yet rely in an IPv6-only network. I=E2=80=99ve = seen cases of service providers with 10.000 customers and 250 of those = =E2=80=9CSMEs=E2=80=9D, and all them are provisioned manually because = don=E2=80=99t make sense to find an automatic configuration. So, I think = we must keep this support, with typically is already available in any = dual-stack router today. In fact, if the router supports 6to4 or 6rd, = the 6in4 support is already there. In terms of flash utilization, 6in4 = requires 1Kb, 6rd 2Kb and 6to4 1Kb. >=20 > Note than I=E2=80=99ve been looking for the =E2=80=9Ccost=E2=80=9D of = the flash memory into open source available as GPLv2, which also means = that the impact for any vendor in =E2=80=9Cupdating=E2=80=9D available = firmware of actual CEs is minimal, if any, and is more an = =E2=80=9Cintegration=E2=80=9D cost, probably a very few hours+testing. = In fact, there are a few vendors that have it already (unfortunately = very few) and I heard about some that offered it to =E2=80=9Cspecial big = customers=E2=80=9D, but not offered to the =E2=80=9Cgeneral market=E2=80=9D= . >=20 > I=E2=80=99ve been evaluating myself, with trial customer deployments, = using open-source such as OpenWRT/LEDE, the cost/functionally of those = transition mechanisms and they just work. Typical CE today have a = minimum of 8MB (market moving quickly to 16 or 32 MB) flash memory and = 32MB (market moving quickly to 64GB and much more) RAM, and they hold = perfectly all those features without any issue and without needed to = take out other code. >=20 > So, the questions for the WG: >=20 > Do you agree with my changes 1, 2, 3 and 4 above? >=20 > Now a more complex question. Do you think it will be acceptable for 3 = and may be 4 above, to be a MUST instead of just SHOULD? >=20 > I think vendors need a very strong signal here, otherwise, many of = them (and this is happening), are reading actual 7084 and only reacting = to implement those transition technologies with specific firmware = versions for =E2=80=9Cvery big=E2=80=9D customers which will buy several = hundred thousand units in one shot. But many small and medium service = providers, buy only a few units every week when they connect new = customers. This was discussed already in this list a couple of months = ago. >=20 > https://www.ietf.org/mail-archive/web/v6ops/current/msg25152.html >=20 > Please, note that that this document version doesn=E2=80=99t include = yet the details of the requirements for each transition mechanism. I=E2=80= =99m working on those already, but will be nice to have some inputs from = the WG, regarding my questions above. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: > Responder a: > Fecha: lunes, 20 de febrero de 2017, 23:37 > Para: Jordi Palet , Jordi Palet Martinez = > Asunto: New Version Notification for = draft-palet-v6ops-rfc7084-bis-00.txt >=20 >=20 > A new version of I-D, draft-palet-v6ops-rfc7084-bis-00.txt > has been successfully submitted by Jordi Palet Martinez and posted = to the > IETF repository. >=20 > Name: draft-palet-v6ops-rfc7084-bis > Revision: 00 > Title: Basic Requirements for IPv6 Customer Edge = Routers > Document date: 2017-02-20 > Group: Individual Submission > Pages: 22 > URL: = https://www.ietf.org/internet-drafts/draft-palet-v6ops-rfc7084-bis-00.txt > Status: = https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis/ > Htmlized: = https://tools.ietf.org/html/draft-palet-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 = 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 >=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 > The IETF Secretariat >=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 = 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 Feb 21 01: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 6AF5F129529 for ; Tue, 21 Feb 2017 01:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XYafE1c2GVhS for ; Tue, 21 Feb 2017 01:40:15 -0800 (PST) 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 B6249128B37 for ; Tue, 21 Feb 2017 01:40:14 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id l19so61400414ywc.2 for ; Tue, 21 Feb 2017 01:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3BQJ3wa7p12RHqUjTLU5ZjAJGZzpSHTb2Le+T++toMs=; b=mki3jH/3UzWSWzzetvZl7VObMTnmlcSk90BLpOzvHC1g9XGE2fzicS+KWNlvq9ROwd hmQ82HwcqemzRrk5lPXl96BmdFxzV+iwKP+LIqzXJonPWVQrb7ON26dXYteqKMGDG0Ec 2/a8kquoujdadD+RPq9pUkph2jkL8mDJgwNbEHVelX2Laa06keMmeAFVoeMQHJS+ibXS bwCUWr0iwGr1Ur43N5ebdN6O1ZrsKKhKxhejmNR2gSrMz79vp+3XbYIxuoy1Y2h61vZp qRgeHj2uNqUI2wTBn5SPakH+gjn/H3R4KNdYApRJ0/U3bFm1CJoS3KdCjXfawfkzFrcy 36Pg== 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=3BQJ3wa7p12RHqUjTLU5ZjAJGZzpSHTb2Le+T++toMs=; b=ee2TNvRm85U74+a4+rXSrVUEltxTxt0Dp/Ndn6q0tQf4KUki8ZKtV/pLKgtNrb1XWu f9XdkqycyurHWh0vqLk25cLcDFkmBBrdWUuQLqckjKtNNstC3fFacsVvHg0GSGH63xvk QEL+10Sri5HLihsYFCtLv5j66olgONhExMUenmm356/6Enivb0J9F00mN2mPWsfI/mlX utD1SjciNyDC46MDMwzv/EmcXaSovN5HVxV4OYw/I/uOtaJ4A3YAxqEkUM+QhFBf7CCH XJByivq32f11Yo/yicpZB/GAR7BYNfJ8CfWTcvAnwZHgYisvfaPgvTVUWyoeVye1QZuz WaNw== X-Gm-Message-State: AMke39l9+QvxEEx0Sej9kw3QxH9iqEPnMTyQNYt0m2bvTNeKLSK8Ae+TD084YdghNFW4yX8ZcMzLxz9evDAoibvO X-Received: by 10.129.129.3 with SMTP id r3mr19560107ywf.0.1487670013322; Tue, 21 Feb 2017 01:40:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Tue, 21 Feb 2017 01:39:52 -0800 (PST) In-Reply-To: References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> From: Erik Kline Date: Tue, 21 Feb 2017 18:39:52 +0900 Message-ID: To: Nathalie Trenaman Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07dd3ebc1b860549072ab1" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 09:40:17 -0000 --94eb2c07dd3ebc1b860549072ab1 Content-Type: multipart/alternative; boundary=94eb2c07dd3eb04d000549072a7d --94eb2c07dd3eb04d000549072a7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And AT&T has a very large 6rd deployment, so I wouldn't be surprised to see push back from them on downgrading 6rd to MAY (though perhaps they don't much care, idk). It's hard to see how this discussion won't just degrade into "my deployment technology should be SHOULD or even MUST, everyone else can be MAY". On 21 February 2017 at 18:32, Nathalie Trenaman wrote: > Hi Jordi, > > > > > > > > > So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as > SHOULD. > > While I agree with most things listed below, and I also agree with your > points changing 6rd to =E2=80=9CMAY=E2=80=9D, I don=E2=80=99t agree on ch= anging DS-LITE to =E2=80=9CMAY=E2=80=9D. I > would leave it with =E2=80=9CSHOULD=E2=80=9D. > Some really large residential deployments chose for DS-LITE a while ago, > (before MAP was standardised) and won=E2=80=99t change their plans soon. = They > already purchased the CGNAT equipment, etc. Their IPv6 deployment takes > years=E2=80=A6.(from what I hear in all the IPv6 courses) > So, DS-LITE is a =E2=80=9CSHOULD=E2=80=9D, not (yet) a =E2=80=9CMAY=E2=80= =9D but also not a =E2=80=9CMUST=E2=80=9D > > Just my 2 cents. > > Nathalie > > > > > > In my version: > > > > 1) Considering that there=E2=80=99re no more IPv4 addresses and accordi= ng to my > experience with service providers, they will prefer to avoid dual stack i= n > the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to be changed t= o > MAY. > > > > 2) At the same time, I=E2=80=99ve included lw4o6, also with MAY. The ra= tionale > for this: Many service providers try to avoid the CGN, and lw4o6 is a way > to do so, without increasing the cost of the CE. Basically, a CE that > supports a regular IPv4 NAT+DS-Lite, is already capable of supporting > lw4o6. The cost in terms of CE flash memory for DS-Lite is about 1Kb. The > open source package available for DS-Lite that I=E2=80=99ve been digging-= in takes > 6Kb, but already includes also support for both MAP versions. > > > > 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those protocols > are the 3 alternatives that a service provider has to deploy IPv6-only WA= N, > but at the same time provide dual-stack in the LANs, with practically the > same functionalities or even more, that what CGN requires. At the service > provider network, it requires, instead of CGN, a stateful NAT64 (which > cellular providers are already using) or a Border Relay (for MAP). > Basically, a CE needs only 3Kbytes of code in the flash to support CLAT > (the CE part of 464XLAT). The support for MAP (both versions and also > lw6o4), requires about 6Kb. > > > > 4) Include support for 6in4 as SHOULD. The rational for this: According > to my experience, sometimes, business customers (specially SMEs) are in t= he > same access network as residential ones, but they are provisioned manuall= y > and often require dual-stack with public IPv4 addresses, because they hav= e > to publish external services such as VPNs, or others that may not yet rel= y > in an IPv6-only network. I=E2=80=99ve seen cases of service providers wit= h 10.000 > customers and 250 of those =E2=80=9CSMEs=E2=80=9D, and all them are provi= sioned manually > because don=E2=80=99t make sense to find an automatic configuration. So, = I think we > must keep this support, with typically is already available in any > dual-stack router today. In fact, if the router supports 6to4 or 6rd, the > 6in4 support is already there. In terms of flash utilization, 6in4 requir= es > 1Kb, 6rd 2Kb and 6to4 1Kb. > > > > Note than I=E2=80=99ve been looking for the =E2=80=9Ccost=E2=80=9D of t= he flash memory into open > source available as GPLv2, which also means that the impact for any vendo= r > in =E2=80=9Cupdating=E2=80=9D available firmware of actual CEs is minimal= , if any, and is > more an =E2=80=9Cintegration=E2=80=9D cost, probably a very few hours+tes= ting. In fact, > there are a few vendors that have it already (unfortunately very few) and= I > heard about some that offered it to =E2=80=9Cspecial big customers=E2=80= =9D, but not > offered to the =E2=80=9Cgeneral market=E2=80=9D. > > > > I=E2=80=99ve been evaluating myself, with trial customer deployments, u= sing > open-source such as OpenWRT/LEDE, the cost/functionally of those transiti= on > mechanisms and they just work. Typical CE today have a minimum of 8MB > (market moving quickly to 16 or 32 MB) flash memory and 32MB (market movi= ng > quickly to 64GB and much more) RAM, and they hold perfectly all those > features without any issue and without needed to take out other code. > > > > So, the questions for the WG: > > > > Do you agree with my changes 1, 2, 3 and 4 above? > > > > Now a more complex question. Do you think it will be acceptable for 3 > and may be 4 above, to be a MUST instead of just SHOULD? > > > > I think vendors need a very strong signal here, otherwise, many of them > (and this is happening), are reading actual 7084 and only reacting to > implement those transition technologies with specific firmware versions f= or > =E2=80=9Cvery big=E2=80=9D customers which will buy several hundred thous= and units in one > shot. But many small and medium service providers, buy only a few units > every week when they connect new customers. This was discussed already in > this list a couple of months ago. > > > > https://www.ietf.org/mail-archive/web/v6ops/current/msg25152.html > > > > Please, note that that this document version doesn=E2=80=99t include ye= t the > details of the requirements for each transition mechanism. I=E2=80=99m wo= rking on > those already, but will be nice to have some inputs from the WG, regardin= g > my questions above. > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: > > Responder a: > > Fecha: lunes, 20 de febrero de 2017, 23:37 > > Para: Jordi Palet , Jordi Palet Martinez < > jordi.palet@consulintel.es> > > Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis- > 00.txt > > > > > > A new version of I-D, draft-palet-v6ops-rfc7084-bis-00.txt > > has been successfully submitted by Jordi Palet Martinez and posted t= o > the > > IETF repository. > > > > Name: draft-palet-v6ops-rfc7084-bis > > Revision: 00 > > Title: Basic Requirements for IPv6 Customer Edge Routers > > Document date: 2017-02-20 > > Group: Individual Submission > > Pages: 22 > > URL: https://www.ietf.org/internet- > drafts/draft-palet-v6ops-rfc7084-bis-00.txt > > Status: https://datatracker.ietf.org/ > doc/draft-palet-v6ops-rfc7084-bis/ > > Htmlized: https://tools.ietf.org/html/ > draft-palet-v6ops-rfc7084-bis-00 > > > > > > Abstract: > > This document specifies requirements for an IPv6 Customer Edge (C= E) > > router. Specifically, the current version of this document focus= es > > on the basic provisioning of an IPv6 CE router and the provisioni= ng > > 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 wi= th > > 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 time 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 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 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c07dd3eb04d000549072a7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And AT&T has a very large 6rd deployment, so I wouldn&= #39;t be surprised to see push back from them on downgrading 6rd to MAY (th= ough perhaps they don't much care, idk).

It's ha= rd to see how this discussion won't just degrade into "my deployme= nt technology should be SHOULD or even MUST, everyone else can be MAY"= .

On 2= 1 February 2017 at 18:32, Nathalie Trenaman <nathalie@ripe.net> wrote:
Hi Jordi,

<snip>

>
>
> So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as S= HOULD.

While I agree with most things listed below, and I also agree with y= our points changing 6rd to =E2=80=9CMAY=E2=80=9D, I don=E2=80=99t agree on = changing DS-LITE to =E2=80=9CMAY=E2=80=9D. I would leave it with =E2=80=9CS= HOULD=E2=80=9D.
Some really large residential deployments chose for DS-LITE a while ago, (b= efore MAP was standardised) and won=E2=80=99t change their plans soon. They= already purchased the CGNAT equipment, etc. Their IPv6 deployment takes ye= ars=E2=80=A6.(from what I hear in all the IPv6 courses)
So, DS-LITE is a =E2=80=9CSHOULD=E2=80=9D, not (yet) a =E2=80=9CMAY=E2=80= =9D but also not a =E2=80=9CMUST=E2=80=9D

Just my 2 cents.

Nathalie


>
> In my version:
>
> 1) Considering that there=E2=80=99re no more IPv4 addresses and accord= ing to my experience with service providers, they will prefer to avoid dual= stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to be c= hanged to MAY.
>
> 2) At the same time, I=E2=80=99ve included lw4o6, also with MAY. The r= ationale for this: Many service providers try to avoid the CGN, and lw4o6 i= s a way to do so, without increasing the cost of the CE. Basically, a CE th= at supports a regular IPv4 NAT+DS-Lite, is already capable of supporting lw= 4o6. The cost in terms of CE flash memory for DS-Lite is about 1Kb. The ope= n source package available for DS-Lite that I=E2=80=99ve been digging-in ta= kes 6Kb, but already includes also support for both MAP versions.
>
> 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those protocol= s are the 3 alternatives that a service provider has to deploy IPv6-only WA= N, but at the same time provide dual-stack in the LANs, with practically th= e same functionalities or even more, that what CGN requires. At the service= provider network, it requires, instead of CGN, a stateful NAT64 (which cel= lular providers are already using) or a Border Relay (for MAP). Basically, = a CE needs only 3Kbytes of code in the flash to support CLAT (the CE part o= f 464XLAT). The support for MAP (both versions and also lw6o4), requires ab= out 6Kb.
>
> 4) Include support for 6in4 as SHOULD. The rational for this: Accordin= g to my experience, sometimes, business customers (specially SMEs) are in t= he same access network as residential ones, but they are provisioned manual= ly and often require dual-stack with public IPv4 addresses, because they ha= ve to publish external services such as VPNs, or others that may not yet re= ly in an IPv6-only network. I=E2=80=99ve seen cases of service providers wi= th 10.000 customers and 250 of those =E2=80=9CSMEs=E2=80=9D, and all them a= re provisioned manually because don=E2=80=99t make sense to find an automat= ic configuration. So, I think we must keep this support, with typically is = already available in any dual-stack router today. In fact, if the router su= pports 6to4 or 6rd, the 6in4 support is already there. In terms of flash ut= ilization, 6in4 requires 1Kb, 6rd 2Kb and 6to4 1Kb.
>
> Note than I=E2=80=99ve been looking for the =E2=80=9Ccost=E2=80=9D of = the flash memory into open source available as GPLv2, which also means that= the impact for any vendor in =E2=80=9Cupdating=E2=80=9D available firmware= of actual CEs is minimal, if any, and is more an =E2=80=9Cintegration=E2= =80=9D cost, probably a very few hours+testing. In fact, there are a few ve= ndors that have it already (unfortunately very few) and I heard about some = that offered it to =E2=80=9Cspecial big customers=E2=80=9D, but not offered= to the =E2=80=9Cgeneral market=E2=80=9D.
>
> I=E2=80=99ve been evaluating myself, with trial customer deployments, = using open-source such as OpenWRT/LEDE, the cost/functionally of those tran= sition mechanisms and they just work. Typical CE today have a minimum of 8M= B (market moving quickly to 16 or 32 MB) flash memory and 32MB (market movi= ng quickly to 64GB and much more) RAM, and they hold perfectly all those fe= atures without any issue and without needed to take out other code.
>
> So, the questions for the WG:
>
> Do you agree with my changes 1, 2, 3 and 4 above?
>
> Now a more complex question. Do you think it will be acceptable for 3 = and may be 4 above, to be a MUST instead of just SHOULD?
>
> I think vendors need a very strong signal here, otherwise, many of the= m (and this is happening), are reading actual 7084 and only reacting to imp= lement those transition technologies with specific firmware versions for = =E2=80=9Cvery big=E2=80=9D customers which will buy several hundred thousan= d units in one shot. But many small and medium service providers, buy only = a few units every week when they connect new customers. This was discussed = already in this list a couple of months ago.
>
> https://www.ietf.org/mail-archive/web/v6ops/current/msg25152.html
>
> Please, note that that this document version doesn=E2=80=99t include y= et the details of the requirements for each transition mechanism. I=E2=80= =99m working on those already, but will be nice to have some inputs from th= e WG, regarding my questions above.
>
> Regards,
> Jordi
>
>
> -----Mensaje original-----
> De: <internet-drafts@ie= tf.org>
> Responder a: <internet-= drafts@ietf.org>
> Fecha: lunes, 20 de febrero de 2017, 23:37
> Para: Jordi Palet <jo= rdi.palet@consulintel.es>, Jordi Palet Martinez <jordi.palet@consulintel.es>
> Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt
>
>
>=C2=A0 =C2=A0 A new version of I-D, draft-palet-v6ops-rfc7084-bis-= 00.txt
>=C2=A0 =C2=A0 has been successfully submitted by Jordi Palet Martinez a= nd posted to the
>=C2=A0 =C2=A0 IETF repository.
>
>=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dra= ft-palet-v6ops-rfc7084-bis
>=C2=A0 =C2=A0 Revision:=C2=A0 00
>=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bas= ic Requirements for IPv6 Customer Edge Routers
>=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A02017-02-20
>=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ind= ividual Submission
>=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022<= br> >=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-dra= fts/draft-palet-v6ops-rfc7084-bis-00.txt
>=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-palet-v6o= ps-rfc7084-bis/
>=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bi= s-00
>
>
>=C2=A0 =C2=A0 Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This document specifies requirements for an = IPv6 Customer Edge (CE)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0router.=C2=A0 Specifically, the current vers= ion of this document focuses
>=C2=A0 =C2=A0 =C2=A0 =C2=A0on the basic provisioning of an IPv6 CE rout= er and the provisioning
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of IPv6 hosts attached to it.=C2=A0 The docu= ment also covers several
>=C2=A0 =C2=A0 =C2=A0 =C2=A0transition technologies, as required in a wo= rld where IPv4 addresses
>=C2=A0 =C2=A0 =C2=A0 =C2=A0are no longer available, so hosts in the cus= tomer LANs with IPv4-only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0or IPv6-only applications or devices, requir= ing to communicate with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4-only services at the Internet, are able= to do so.=C2=A0 The document
>=C2=A0 =C2=A0 =C2=A0 =C2=A0obsoletes RFC 7084.
>
>
>
>
>=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the= time of submission
>=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ie= tf.org.
>
>=C2=A0 =C2=A0 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 privileged o= r confidential. The information is intended to be for the use of the indivi= dual(s) named above. If you are not the intended recipient be aware that an= y disclosure, copying, distribution or use of the contents of this informat= ion, including attached files, is prohibited.
>
>
>
> _______________________________________________
> 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

--94eb2c07dd3eb04d000549072a7d-- --94eb2c07dd3ebc1b860549072ab1 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg6qJQ686TdliE1RfCkVThOkBAacwqpXri d0NqlkAAbpIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjIx MDk0MDE0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAC0iqvzhVtJ7gUeicSH8zccKdPAGJKwjiPcLHA85SlGmRKIJmOqX phP1SLbHGEseTsiDejZT9DZ0X5PxRl2Iw5xWFcwtQxzaAv7fDGj9UcxSOFoy+T+sGegDrmmDoc2a gVIEgAtx5mbFXhKMXuNyrVJS2g0fY8j1tLZDEfROgIgiVTe+Bo/f3NCSVlys936+QU2mk74WU58+ OTS/R3aumd6523fAqwb3NEU4h4PBW0c8p2NpWQE5YURlCsVmciKyBlC0qrQ/tXgNFOqv6TjuW5nr AhaWCnC5uWVXuewFm+7bw0f8FpqFY6TJkSo2qHv5RdA93EyltAc3lU5hXwAmEXA= --94eb2c07dd3ebc1b860549072ab1-- From nobody Tue Feb 21 02:01: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 9648712940B for ; Tue, 21 Feb 2017 02:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 93v0oo1hB7Mi for ; Tue, 21 Feb 2017 02:01:35 -0800 (PST) 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 70367127058 for ; Tue, 21 Feb 2017 02:01:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487671291; x=1488276091; 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=Qp8F9Fk3dgvWc05CmFc0SLdWV u2QKORPc3MSvbyOCZ4=; b=WIvDwouUBhaz5FcUSImpHP/nWA1//ljG69nAy59od SAq9j2RXHMCgxPJfhS54HgUJnNUuuJ70kW3qjhX4YkmHAe5mzg4VQi9kXk/eI5ui 2+MfIFI2KJ60nTn5HxLtwyufKJ25Xx8Q6Jgre6wr7cXZ3V0CtAn8oji9ZlJM/yJ5 Qg= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=RXQZbk+H9tdVRW0NEHJEMhGmhq/eSTS9AZLAPN4G9v9cMwa8l3Mqir6ZjDLG Q3fYpKphz9AfURdL+m33yrVY1vA3AtPf0mQ8xPcC1vfXCy9fxAhsLOhhr YbB5G2oc/KieQFgTuSLjUw2I2K50g3CDZv97zUu+XAuWG6exA1LW98=; X-MDAV-Processed: mail.consulintel.es, Tue, 21 Feb 2017 11:01:31 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 21 Feb 2017 11:01:30 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005371096.msg for ; Tue, 21 Feb 2017 11:01:29 +0100 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:170221:md50005371096::XslwP5AIJhbdv3vB:00007u+4 X-Return-Path: prvs=1225bef9b4=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 21 Feb 2017 11:01:26 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 10:01:37 -0000 Responding to Nathalie and Erik,=20 First thanks to both for the quick response! I think it will be ok to keep SHOULD for both 6RD and DS-LITE, in fact ther= e is no impact, if we include the other protocols, in terms of =E2=80=9Chow= much=E2=80=9D memory they take from the flash. However, those big deployments that you both mention, are =E2=80=9Calready= =E2=80=9D done, so their actual vendors will, for sure, make sure to keep t= hose customers, so it means they will keep 6RD/DS-Lite even if it is a MAY = and competitors will also include support if they want to become providers = for CEs to those service providers, right? The main issue here is to support new =E2=80=9CIPv6-only=E2=80=9D in the WA= N, but dual-stack in the LANs, deployments. Anyway, as said, I=E2=80=99m happy to turn again to SHOULD both of those, a= s there is no impact. Let=E2=80=99s see if other folks can tell us what the= y think! What do you think about moving the 464XLAT, MAP, to MUST ? Regards, Jordi =20 -----Mensaje original----- De: Erik Kline Responder a: Fecha: martes, 21 de febrero de 2017, 10:39 Para: Nathalie Trenaman CC: Jordi Palet Martinez , "v6ops@ietf.org" Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7= 084-bis-00.txt And AT&T has a very large 6rd deployment, so I wouldn't be surprised to= see push back from them on downgrading 6rd to MAY (though perhaps they don= 't much care, idk). It's hard to see how this discussion won't just degrade into "my deploy= ment technology should be SHOULD or even MUST, everyone else can be MAY". =20 =20 On 21 February 2017 at 18:32, Nathalie Trenaman wro= te: =20 Hi Jordi, =20 =20 > > > So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as = SHOULD. =20 While I agree with most things listed below, and I also agree with your= points changing 6rd to =E2=80=9CMAY=E2=80=9D, I don=E2=80=99t agree on cha= nging DS-LITE to =E2=80=9CMAY=E2=80=9D. I would leave it with =E2=80=9CSHOU= LD=E2=80=9D. Some really large residential deployments chose for DS-LITE a while ago= , (before MAP was standardised) and won=E2=80=99t change their plans soon. = They already purchased the CGNAT equipment, etc. Their IPv6 deployment take= s years=E2=80=A6.(from what I hear in all the IPv6 courses) So, DS-LITE is a =E2=80=9CSHOULD=E2=80=9D, not (yet) a =E2=80=9CMAY=E2= =80=9D but also not a =E2=80=9CMUST=E2=80=9D =20 Just my 2 cents. =20 Nathalie =20 =20 > > In my version: > > 1) Considering that there=E2=80=99re no more IPv4 addresses and accor= ding to my experience with service providers, they will prefer to avoid dua= l stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to be = changed to MAY. > > 2) At the same time, I=E2=80=99ve included lw4o6, also with MAY. The = rationale for this: Many service providers try to avoid the CGN, and lw4o6 = is a way to do so, without increasing the cost of the CE. Basically, a CE t= hat supports a regular IPv4 NAT+DS-Lite, is already capable of supporting l= w4o6. The cost in terms of CE flash memory for DS-Lite is about 1Kb. The op= en source package available for DS-Lite that I=E2=80=99ve been digging-in t= akes 6Kb, but already includes also support for both MAP versions. > > 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those protoco= ls are the 3 alternatives that a service provider has to deploy IPv6-only W= AN, but at the same time provide dual-stack in the LANs, with practically t= he same functionalities or even more, that what CGN requires. At the servic= e provider network, it requires, instead of CGN, a stateful NAT64 (which ce= llular providers are already using) or a Border Relay (for MAP). Basically,= a CE needs only 3Kbytes of code in the flash to support CLAT (the CE part = of 464XLAT). The support for MAP (both versions and also lw6o4), requires a= bout 6Kb. > > 4) Include support for 6in4 as SHOULD. The rational for this: Accordi= ng to my experience, sometimes, business customers (specially SMEs) are in = the same access network as residential ones, but they are provisioned manua= lly and often require dual-stack with public IPv4 addresses, because they h= ave to publish external services such as VPNs, or others that may not yet r= ely in an IPv6-only network. I=E2=80=99ve seen cases of service providers w= ith 10.000 customers and 250 of those =E2=80=9CSMEs=E2=80=9D, and all them = are provisioned manually because don=E2=80=99t make sense to find an automa= tic configuration. So, I think we must keep this support, with typically is= already available in any dual-stack router today. In fact, if the router s= upports 6to4 or 6rd, the 6in4 support is already there. In terms of flash u= tilization, 6in4 requires 1Kb, 6rd 2Kb and 6to4 1Kb. > > Note than I=E2=80=99ve been looking for the =E2=80=9Ccost=E2=80=9D of= the flash memory into open source available as GPLv2, which also means tha= t the impact for any vendor in =E2=80=9Cupdating=E2=80=9D available firmwar= e of actual CEs is minimal, if any, and is more an =E2=80=9Cintegration=E2= =80=9D cost, probably a very few hours+testing. In fact, there are a few ve= ndors that have it already (unfortunately very few) and I heard about some = that offered it to =E2=80=9Cspecial big customers=E2=80=9D, but not offered= to the =E2=80=9Cgeneral market=E2=80=9D. > > I=E2=80=99ve been evaluating myself, with trial customer deployments,= using open-source such as OpenWRT/LEDE, the cost/functionally of those tra= nsition mechanisms and they just work. Typical CE today have a minimum of 8= MB (market moving quickly to 16 or 32 MB) flash memory and 32MB (market mov= ing quickly to 64GB and much more) RAM, and they hold perfectly all those f= eatures without any issue and without needed to take out other code. > > So, the questions for the WG: > > Do you agree with my changes 1, 2, 3 and 4 above? > > Now a more complex question. Do you think it will be acceptable for 3= and may be 4 above, to be a MUST instead of just SHOULD? > > I think vendors need a very strong signal here, otherwise, many of th= em (and this is happening), are reading actual 7084 and only reacting to im= plement those transition technologies with specific firmware versions for = =E2=80=9Cvery big=E2=80=9D customers which will buy several hundred thousan= d units in one shot. But many small and medium service providers, buy only = a few units every week when they connect new customers. This was discussed = already in this list a couple of months ago. > > https://www.ietf.org/mail-archive/web/v6ops/current/msg25152.html > > Please, note that that this document version doesn=E2=80=99t include = yet the details of the requirements for each transition mechanism. I=E2=80= =99m working on those already, but will be nice to have some inputs from th= e WG, regarding my questions above. > > Regards, > Jordi > > > -----Mensaje original----- > De: > Responder a: > Fecha: lunes, 20 de febrero de 2017, 23:37 > Para: Jordi Palet , Jordi Palet Martinez = > Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis-00= .txt > > > A new version of I-D, draft-palet-v6ops-rfc7084-bis-00.txt > has been successfully submitted by Jordi Palet Martinez and posted= to the > IETF repository. > > Name: draft-palet-v6ops-rfc7084-bis > Revision: 00 > Title: Basic Requirements for IPv6 Customer Edge Route= rs > Document date: 2017-02-20 > Group: Individual Submission > Pages: 22 > URL: https://www.ietf.org/internet-drafts/draft-palet-v= 6ops-rfc7084-bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-palet-v6ops= -rfc7084-bis/ > Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-rfc7= 084-bis-00 > > > Abstract: > This document specifies requirements for an IPv6 Customer Edge = (CE) > router. Specifically, the current version of this document foc= uses > on the basic provisioning of an IPv6 CE router and the provisio= ning > of IPv6 hosts attached to it. The document also covers several > transition technologies, as required in a world where IPv4 addr= esses > are no longer available, so hosts in the customer LANs with IPv= 4-only > or IPv6-only applications or devices, requiring to communicate = with > IPv4-only services at the Internet, are able to do so. The doc= ument > obsoletes RFC 7084. > > > > > 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.or= g . > > 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 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. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 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 Feb 21 02:13: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 1A2831298AA for ; Tue, 21 Feb 2017 02:13:21 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, 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 hnpYE4SbNyZp for ; Tue, 21 Feb 2017 02:13:19 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 9499912940B for ; Tue, 21 Feb 2017 02:13:19 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cg7Rd-00059x-1I; Tue, 21 Feb 2017 11:13:18 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::12e]) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cg7Rc-0006G4-TU; Tue, 21 Feb 2017 11:13:16 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Nathalie Trenaman In-Reply-To: <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> Date: Tue, 21 Feb 2017 11:13:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a35f5f5604f62735b6422d3f83436f702 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 10:13:21 -0000 Hi Jordi, > On 21 Feb 2017, at 11:01, JORDI PALET MARTINEZ = wrote: >=20 > Responding to Nathalie and Erik,=20 >=20 > First thanks to both for the quick response! >=20 > I think it will be ok to keep SHOULD for both 6RD and DS-LITE, in fact = there is no impact, if we include the other protocols, in terms of = =E2=80=9Chow much=E2=80=9D memory they take from the flash. Ok. >=20 > What do you think about moving the 464XLAT, MAP, to MUST ? Agreed.=20 Nathalie >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: Erik Kline > Responder a: > Fecha: martes, 21 de febrero de 2017, 10:39 > Para: Nathalie Trenaman > CC: Jordi Palet Martinez , = "v6ops@ietf.org" > Asunto: Re: [v6ops] FW: New Version Notification for = draft-palet-v6ops-rfc7084-bis-00.txt >=20 > And AT&T has a very large 6rd deployment, so I wouldn't be = surprised to see push back from them on downgrading 6rd to MAY (though = perhaps they don't much care, idk). > It's hard to see how this discussion won't just degrade into "my = deployment technology should be SHOULD or even MUST, everyone else can = be MAY". >=20 >=20 > On 21 February 2017 at 18:32, Nathalie Trenaman = wrote: >=20 > Hi Jordi, >=20 > >=20 >>=20 >>=20 >> So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as = SHOULD. >=20 > While I agree with most things listed below, and I also agree with = your points changing 6rd to =E2=80=9CMAY=E2=80=9D, I don=E2=80=99t agree = on changing DS-LITE to =E2=80=9CMAY=E2=80=9D. I would leave it with = =E2=80=9CSHOULD=E2=80=9D. > Some really large residential deployments chose for DS-LITE a while = ago, (before MAP was standardised) and won=E2=80=99t change their plans = soon. They already purchased the CGNAT equipment, etc. Their IPv6 = deployment takes years=E2=80=A6.(from what I hear in all the IPv6 = courses) > So, DS-LITE is a =E2=80=9CSHOULD=E2=80=9D, not (yet) a =E2=80=9CMAY=E2= =80=9D but also not a =E2=80=9CMUST=E2=80=9D >=20 > Just my 2 cents. >=20 > Nathalie >=20 >=20 >>=20 >> In my version: >>=20 >> 1) Considering that there=E2=80=99re no more IPv4 addresses and = according to my experience with service providers, they will prefer to = avoid dual stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE = need to be changed to MAY. >>=20 >> 2) At the same time, I=E2=80=99ve included lw4o6, also with MAY. The = rationale for this: Many service providers try to avoid the CGN, and = lw4o6 is a way to do so, without increasing the cost of the CE. = Basically, a CE that supports a regular IPv4 NAT+DS-Lite, is already = capable of supporting lw4o6. The cost in terms of CE flash memory for = DS-Lite is about 1Kb. The open source package available for DS-Lite that = I=E2=80=99ve been digging-in takes 6Kb, but already includes also = support for both MAP versions. >>=20 >> 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those = protocols are the 3 alternatives that a service provider has to deploy = IPv6-only WAN, but at the same time provide dual-stack in the LANs, with = practically the same functionalities or even more, that what CGN = requires. At the service provider network, it requires, instead of CGN, = a stateful NAT64 (which cellular providers are already using) or a = Border Relay (for MAP). Basically, a CE needs only 3Kbytes of code in = the flash to support CLAT (the CE part of 464XLAT). The support for MAP = (both versions and also lw6o4), requires about 6Kb. >>=20 >> 4) Include support for 6in4 as SHOULD. The rational for this: = According to my experience, sometimes, business customers (specially = SMEs) are in the same access network as residential ones, but they are = provisioned manually and often require dual-stack with public IPv4 = addresses, because they have to publish external services such as VPNs, = or others that may not yet rely in an IPv6-only network. I=E2=80=99ve = seen cases of service providers with 10.000 customers and 250 of those = =E2=80=9CSMEs=E2=80=9D, and all them are provisioned manually because = don=E2=80=99t make sense to find an automatic configuration. So, I think = we must keep this support, with typically is already available in any = dual-stack router today. In fact, if the router supports 6to4 or 6rd, = the 6in4 support is already there. In terms of flash utilization, 6in4 = requires 1Kb, 6rd 2Kb and 6to4 1Kb. >>=20 >> Note than I=E2=80=99ve been looking for the =E2=80=9Ccost=E2=80=9D of = the flash memory into open source available as GPLv2, which also means = that the impact for any vendor in =E2=80=9Cupdating=E2=80=9D available = firmware of actual CEs is minimal, if any, and is more an = =E2=80=9Cintegration=E2=80=9D cost, probably a very few hours+testing. = In fact, there are a few vendors that have it already (unfortunately = very few) and I heard about some that offered it to =E2=80=9Cspecial big = customers=E2=80=9D, but not offered to the =E2=80=9Cgeneral market=E2=80=9D= . >>=20 >> I=E2=80=99ve been evaluating myself, with trial customer deployments, = using open-source such as OpenWRT/LEDE, the cost/functionally of those = transition mechanisms and they just work. Typical CE today have a = minimum of 8MB (market moving quickly to 16 or 32 MB) flash memory and = 32MB (market moving quickly to 64GB and much more) RAM, and they hold = perfectly all those features without any issue and without needed to = take out other code. >>=20 >> So, the questions for the WG: >>=20 >> Do you agree with my changes 1, 2, 3 and 4 above? >>=20 >> Now a more complex question. Do you think it will be acceptable for 3 = and may be 4 above, to be a MUST instead of just SHOULD? >>=20 >> I think vendors need a very strong signal here, otherwise, many of = them (and this is happening), are reading actual 7084 and only reacting = to implement those transition technologies with specific firmware = versions for =E2=80=9Cvery big=E2=80=9D customers which will buy several = hundred thousand units in one shot. But many small and medium service = providers, buy only a few units every week when they connect new = customers. This was discussed already in this list a couple of months = ago. >>=20 >> https://www.ietf.org/mail-archive/web/v6ops/current/msg25152.html >>=20 >> Please, note that that this document version doesn=E2=80=99t include = yet the details of the requirements for each transition mechanism. I=E2=80= =99m working on those already, but will be nice to have some inputs from = the WG, regarding my questions above. >>=20 >> Regards, >> Jordi >>=20 >>=20 >> -----Mensaje original----- >> De: >> Responder a: >> Fecha: lunes, 20 de febrero de 2017, 23:37 >> Para: Jordi Palet , Jordi Palet Martinez = >> Asunto: New Version Notification for = draft-palet-v6ops-rfc7084-bis-00.txt >>=20 >>=20 >> A new version of I-D, draft-palet-v6ops-rfc7084-bis-00.txt >> has been successfully submitted by Jordi Palet Martinez and posted = to the >> IETF repository. >>=20 >> Name: draft-palet-v6ops-rfc7084-bis >> Revision: 00 >> Title: Basic Requirements for IPv6 Customer Edge = Routers >> Document date: 2017-02-20 >> Group: Individual Submission >> Pages: 22 >> URL: = https://www.ietf.org/internet-drafts/draft-palet-v6ops-rfc7084-bis-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis/ >> Htmlized: = https://tools.ietf.org/html/draft-palet-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 = 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 >>=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 >> The IETF Secretariat >>=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 = 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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=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 = 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 Feb 21 03: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 41DEA12963F for ; Tue, 21 Feb 2017 03:47:05 -0800 (PST) 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 d2dSS7wip7wC for ; Tue, 21 Feb 2017 03:47:03 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691AE12965B for ; Tue, 21 Feb 2017 03:47:03 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3F6C2A2; Tue, 21 Feb 2017 12:47:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1487677621; bh=Rck1PPejusuHHXp+NL7IKnmrEhzYa5zBYlEinVuoqNs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=w35EKR9UUx8VqEApxfrGenE9/I2mIOAHywYclV3N+k/E3SDfYlitWaHknPPDkzs/B pcvfA+nZBlE0G++TQzvMcy0weI7Pdan6IaOql64hhfXQmC30w71bXEV/qP9oXz/4ty EiBk54uEBDKWmjET0TzApv6kh7Q3UAnSQ8Aey9/k= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 27EE488; Tue, 21 Feb 2017 12:47:01 +0100 (CET) Date: Tue, 21 Feb 2017 12:47:01 +0100 (CET) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ In-Reply-To: <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> Message-ID: References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@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; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 11:47:05 -0000 Hi, One thing that happened to me as of late has made me consider what the CE should do in this situation. I think most of the text in the current document agrees with what would like to happen, but there might be opportunity for one of two new requirements. My current situation is that I have a statically configured 6in4 tunnel to my CE, because my ISP doesn't support native IPv6. My ISP started sending me RAs with no prefix in them, M=1, and responds to requests for IA_NA and IA_PD with "NoPrefixAvail". My UBNT ER5 overwrites the static ::/0 route I have over the 6in4 tunnel and points default to the ISP router (breaking my connectivity). In the routing table, it says "proto RA" for that route. Changing distance on my static route doesn't help. I ended up having to firewall ICMP6 from my ISP towards the ER5 so it wouldn't even see the RAs, and I will continue doing this until my ISP deployment is done. Now I have a working soltion again. My Omnia Turris (running OpenWrt variant) in the same environment (but without 6in4 tunnel), seems to consider these RAs and the lack of prefix/address as a reason to just ignore them. It doesnt install a default route (so I don't have a ::/0 route on it at all on it). Do we want some text in the document on what to do with RAs of different types? What about if it gets an native RA when it has 6RD configured and working? Which should be preferred? If it now has multiple prefixes, should it announce all of them? Just one? The current document just touches on what the device should announce and configure onto its LAN interfaces when certain things happen, it doesn't touch on how different situations should influence what routes to configure in itself, what things to prefer etc? Should we have source routing requirements, as discussed in homenet? My situation wouldn't have been a problem if I had installed a source/address based ::/0 route towards my 6in4 tunnel that would have taken precedence over the non-SADR route learnt from the RA? I know we don't want to make this document hugely more complicated, but where do we draw the line? Do we want to support transition from for instance 6RD to native in a not-too-disruptive-consumer-experience way? From nobody Tue Feb 21 03:59:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768181298C5 for ; Tue, 21 Feb 2017 03:59:04 -0800 (PST) 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 Lyd9phPWl_Sv for ; Tue, 21 Feb 2017 03:59:02 -0800 (PST) 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 1F79312963F for ; Tue, 21 Feb 2017 03:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12096; q=dns/txt; s=iport; t=1487678342; x=1488887942; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GSAfzv16USilmY18XWP2J5Iblkp/wrxTtmuYPTP/AwQ=; b=V6x6SCnhE4PciNHIvjbibEEJzgrN5P0UDatB97oqeCdttu3rFMcBaUcH InJ6Qec97JN8CqaumYq5ebumR/ykGdK9ItwHxBVzNuzq+vxNsHO+lX6f/ ghA02Yu7hjPVDUNy8j9Kzwa3tIvWC5lWjnASp+Qsw5lzJB9RlNjFYelEs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAQBwKqxY/5BdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygpYYEJB4NUigiRdx+VNIINHw2FdgIagkg/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHABAQEDAQEBIRE6AgcHBwQCAQgRAwECAwImAgICJQsUAQgIAgQBEhuJSwgOr?= =?us-ascii?q?gWCJotWAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhUGCBQiCYoQ3AQEbgwYugjE?= =?us-ascii?q?Fj0mMPwGGc4spCoFxU4RIiXiINIpvAR84gQBTFRgmEQGEboFIdQGIYYEhgQ0BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.35,189,1484006400"; d="scan'208";a="209266294" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 11:59:01 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1LBx0tB020507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Feb 2017 11:59:01 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 05:59:00 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 05:58:59 -0600 From: "Rajiv Asati (rajiva)" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSjDnj5HCQYpyIc0CpuL/9rvGtAA== Date: Tue, 21 Feb 2017 11:58:59 +0000 Message-ID: References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> In-Reply-To: <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.233.65] Content-Type: text/plain; charset="utf-8" Content-ID: <94BC17E257A5A745844F4987C0074D5E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 11:59:04 -0000 PiAgICBEbyB5b3UgYWdyZWUgd2l0aCBteSBjaGFuZ2VzIDEsIDIsIDMgYW5kIDQgYWJvdmU/DQog IA0KWWVzDQoNCj4gICAgTm93IGEgbW9yZSBjb21wbGV4IHF1ZXN0aW9uLiBEbyB5b3UgdGhpbmsg aXQgd2lsbCBiZSBhY2NlcHRhYmxlIGZvciAzIGFuZCBtYXkgYmUgNCBhYm92ZSwgdG8gYmUgYSBN VVNUIGluc3RlYWQgb2YganVzdCBTSE9VTEQ/DQogIA0KWWVzLiANCg0KDQotLSANCkNoZWVycywN ClJhaml2ICANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIDx2Nm9w cy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSk9SREkgUEFMRVQgTUFSVElORVogPGpv cmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0KUmVwbHktVG86ICJqb3JkaS5wYWxldEBjb25zdWxp bnRlbC5lcyIgPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0KRGF0ZTogVHVlc2RheSwgRmVi cnVhcnkgMjEsIDIwMTcgYXQgNDoxMSBBTQ0KVG86ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGll dGYub3JnPg0KU3ViamVjdDogW3Y2b3BzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv cglkcmFmdC1wYWxldC12Nm9wcy1yZmM3MDg0LWJpcy0wMC50eHQNCg0KICAgIEhpLA0KICAgIA0K ICAgIEnigJl2ZSBzdWJtaXR0ZWQgYSAtYmlzIGRyYWZ0IGZvciB1cGRhdGluZyBSRkM3MDg0IChC YXNpYyBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3VzdG9tZXIgRWRnZSBSb3V0ZXJzKS4NCiAgICAN CiAgICBUaGUgYmFzaWMgaWRlYSBiZWhpbmQgdGhpcyB1cGRhdGUgaXMgdG8gY29uc2lkZXIgdGhh dCB0aGUgSVNQcyBoYXZlIG5vdCBtb3JlIElQdjQgYWRkcmVzc2VkIHNvIHRoZXkgd2lsbCBuZWVk IHRvIG1ha2Ugc3VyZSB0aGF0IENFcyBhcmUgY2FwYWJsZSBvZiBydW5uaW5nIG9uIElQdjYtb25s eSBsaW5rcywgYnV0IGluY2x1ZGluZyBzb21lIHN1cHBvcnQgZm9yIElQdjQgdHJhbnNpdGlvbiwg c28gdGhlIGN1c3RvbWVyIExBTnMgY2FuIHN0aWxsIHVzZSBJUHY0IGZvciBvbGRlciBkZXZpY2Vz IG9yIGFwcHMsIHVudGlsIHRoZXkgYmVjb21lIHVwZGF0ZWQuDQogICAgDQogICAgVGhlIGFwcHJv YWNoIG9mIHRoZSBSRkM3MDg0IHdhcyB0byByZWx5IGVpdGhlciBpbiA2cmQgKHdoaWNoIHJlcXVp cmVzIGR1YWwgc3RhY2sgb24gdGhlIFdBTiBsaW5rKSwgb3IgRFMtTGl0ZSAod2hpY2ggcmVxdWly ZWQgZHVhbCBzdGFjayBieSBtZWFucyBvZiBDR04gd2l0aCBwcml2YXRlIElQdjQgYWRkcmVzc2Vk IGZvciB0aGUgV0FOKS4NCiAgICANCiAgICBNeSB2aWV3LCBjb25zaWRlcmluZyB0aGUgdGltZSBm cmFtZSB3aGVuIHRoaXMgZG9jdW1lbnQgbWF5IGJlIGFjY2VwdGVkIGJ5IHRoZSBXRyBhbmQgdGhl biB0aGUgdGltZSB0aGF0IHZlbmRvcnMgY2FuIHRha2UgdG8gaW1wbGVtZW50IG5ldyBmaXJtd2Fy ZSB2ZXJzaW9ucyBvciBuZXcgcHJvZHVjdHMgKGFsbW9zdCBvbmUgeWVhciBmcm9tIG5vdyksIGlz IHRoYXQgbW9yZSBhbmQgbW9yZSBJU1BzIHdpbGwgaGF2ZSB0cm91YmxlcyB0byB1c2UgNnJkICh3 aGljaCBieSB0aGUgd2F5IGlzIG5vdCBiZWluZyB1c2VkIHRvbyBtdWNoKSwgb3Igd2lsbCBwcmVm ZXIgb3RoZXIgc29sdXRpb25zIHRoYW4gQ0dOLg0KICAgIA0KICAgIFNvLCBqdXN0IHRvIHN1bW1h cml6ZSwgaW4gUkZDNzA4NCwgNnJkIGFuZCBEUy1MSVRFIGFyZSBjb25zaWRlcmVkIGFzIFNIT1VM RC4NCiAgICANCiAgICBJbiBteSB2ZXJzaW9uOg0KICAgIA0KICAgIDEpIENvbnNpZGVyaW5nIHRo YXQgdGhlcmXigJlyZSBubyBtb3JlIElQdjQgYWRkcmVzc2VzIGFuZCBhY2NvcmRpbmcgdG8gbXkg ZXhwZXJpZW5jZSB3aXRoIHNlcnZpY2UgcHJvdmlkZXJzLCB0aGV5IHdpbGwgcHJlZmVyIHRvIGF2 b2lkIGR1YWwgc3RhY2sgaW4gdGhlIFdBTiBBU0FQLCBhbmQgYXZvaWQgQ0dOLCBJIHRoaW5rIDZy ZCBhbmQgRFMtTElURSBuZWVkIHRvIGJlIGNoYW5nZWQgdG8gTUFZLg0KICAgIA0KICAgIDIpIEF0 IHRoZSBzYW1lIHRpbWUsIEnigJl2ZSBpbmNsdWRlZCBsdzRvNiwgYWxzbyB3aXRoIE1BWS4gVGhl IHJhdGlvbmFsZSBmb3IgdGhpczogTWFueSBzZXJ2aWNlIHByb3ZpZGVycyB0cnkgdG8gYXZvaWQg dGhlIENHTiwgYW5kIGx3NG82IGlzIGEgd2F5IHRvIGRvIHNvLCB3aXRob3V0IGluY3JlYXNpbmcg dGhlIGNvc3Qgb2YgdGhlIENFLiBCYXNpY2FsbHksIGEgQ0UgdGhhdCBzdXBwb3J0cyBhIHJlZ3Vs YXIgSVB2NCBOQVQrRFMtTGl0ZSwgaXMgYWxyZWFkeSBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgbHc0 bzYuIFRoZSBjb3N0IGluIHRlcm1zIG9mIENFIGZsYXNoIG1lbW9yeSBmb3IgRFMtTGl0ZSBpcyBh Ym91dCAxS2IuIFRoZSBvcGVuIHNvdXJjZSBwYWNrYWdlIGF2YWlsYWJsZSBmb3IgRFMtTGl0ZSB0 aGF0IEnigJl2ZSBiZWVuIGRpZ2dpbmctaW4gdGFrZXMgNktiLCBidXQgYWxyZWFkeSBpbmNsdWRl cyBhbHNvIHN1cHBvcnQgZm9yIGJvdGggTUFQIHZlcnNpb25zLg0KICAgIA0KICAgIDMpIEluY2x1 ZGUgc3VwcG9ydCBmb3IgNDY0WExBVCwgTUFQLUUsIE1BUC1UIGFzIFNIT1VMRC4gVGhvc2UgcHJv dG9jb2xzIGFyZSB0aGUgMyBhbHRlcm5hdGl2ZXMgdGhhdCBhIHNlcnZpY2UgcHJvdmlkZXIgaGFz IHRvIGRlcGxveSBJUHY2LW9ubHkgV0FOLCBidXQgYXQgdGhlIHNhbWUgdGltZSBwcm92aWRlIGR1 YWwtc3RhY2sgaW4gdGhlIExBTnMsIHdpdGggcHJhY3RpY2FsbHkgdGhlIHNhbWUgZnVuY3Rpb25h bGl0aWVzIG9yIGV2ZW4gbW9yZSwgdGhhdCB3aGF0IENHTiByZXF1aXJlcy4gQXQgdGhlIHNlcnZp Y2UgcHJvdmlkZXIgbmV0d29yaywgaXQgcmVxdWlyZXMsIGluc3RlYWQgb2YgQ0dOLCBhIHN0YXRl ZnVsIE5BVDY0ICh3aGljaCBjZWxsdWxhciBwcm92aWRlcnMgYXJlIGFscmVhZHkgdXNpbmcpIG9y IGEgQm9yZGVyIFJlbGF5IChmb3IgTUFQKS4gQmFzaWNhbGx5LCBhIENFIG5lZWRzIG9ubHkgM0ti eXRlcyBvZiBjb2RlIGluIHRoZSBmbGFzaCB0byBzdXBwb3J0IENMQVQgKHRoZSBDRSBwYXJ0IG9m IDQ2NFhMQVQpLiBUaGUgc3VwcG9ydCBmb3IgTUFQIChib3RoIHZlcnNpb25zIGFuZCBhbHNvIGx3 Nm80KSwgcmVxdWlyZXMgYWJvdXQgNktiLg0KICAgIA0KICAgIDQpIEluY2x1ZGUgc3VwcG9ydCBm b3IgNmluNCBhcyBTSE9VTEQuIFRoZSByYXRpb25hbCBmb3IgdGhpczogQWNjb3JkaW5nIHRvIG15 IGV4cGVyaWVuY2UsIHNvbWV0aW1lcywgYnVzaW5lc3MgY3VzdG9tZXJzIChzcGVjaWFsbHkgU01F cykgYXJlIGluIHRoZSBzYW1lIGFjY2VzcyBuZXR3b3JrIGFzIHJlc2lkZW50aWFsIG9uZXMsIGJ1 dCB0aGV5IGFyZSBwcm92aXNpb25lZCBtYW51YWxseSBhbmQgb2Z0ZW4gcmVxdWlyZSBkdWFsLXN0 YWNrIHdpdGggcHVibGljIElQdjQgYWRkcmVzc2VzLCBiZWNhdXNlIHRoZXkgaGF2ZSB0byBwdWJs aXNoIGV4dGVybmFsIHNlcnZpY2VzIHN1Y2ggYXMgVlBOcywgb3Igb3RoZXJzIHRoYXQgbWF5IG5v dCB5ZXQgcmVseSBpbiBhbiBJUHY2LW9ubHkgbmV0d29yay4gSeKAmXZlIHNlZW4gY2FzZXMgb2Yg c2VydmljZSBwcm92aWRlcnMgd2l0aCAxMC4wMDAgY3VzdG9tZXJzIGFuZCAyNTAgb2YgdGhvc2Ug 4oCcU01Fc+KAnSwgYW5kIGFsbCB0aGVtIGFyZSBwcm92aXNpb25lZCBtYW51YWxseSBiZWNhdXNl IGRvbuKAmXQgbWFrZSBzZW5zZSB0byBmaW5kIGFuIGF1dG9tYXRpYyBjb25maWd1cmF0aW9uLiBT bywgSSB0aGluayB3ZSBtdXN0IGtlZXAgdGhpcyBzdXBwb3J0LCB3aXRoIHR5cGljYWxseSBpcyBh bHJlYWR5IGF2YWlsYWJsZSBpbiBhbnkgZHVhbC1zdGFjayByb3V0ZXIgdG9kYXkuIEluIGZhY3Qs IGlmIHRoZSByb3V0ZXIgc3VwcG9ydHMgNnRvNCBvciA2cmQsIHRoZSA2aW40IHN1cHBvcnQgaXMg YWxyZWFkeSB0aGVyZS4gSW4gdGVybXMgb2YgZmxhc2ggdXRpbGl6YXRpb24sIDZpbjQgcmVxdWly ZXMgMUtiLCA2cmQgMktiIGFuZCA2dG80IDFLYi4NCiAgICANCiAgICBOb3RlIHRoYW4gSeKAmXZl IGJlZW4gbG9va2luZyBmb3IgdGhlIOKAnGNvc3TigJ0gb2YgdGhlIGZsYXNoIG1lbW9yeSBpbnRv IG9wZW4gc291cmNlIGF2YWlsYWJsZSBhcyBHUEx2Miwgd2hpY2ggYWxzbyBtZWFucyB0aGF0IHRo ZSBpbXBhY3QgZm9yIGFueSB2ZW5kb3IgaW4g4oCcdXBkYXRpbmfigJ0gYXZhaWxhYmxlIGZpcm13 YXJlIG9mIGFjdHVhbCBDRXMgaXMgbWluaW1hbCwgaWYgYW55LCBhbmQgaXMgbW9yZSBhbiDigJxp bnRlZ3JhdGlvbuKAnSBjb3N0LCBwcm9iYWJseSBhIHZlcnkgZmV3IGhvdXJzK3Rlc3RpbmcuIElu IGZhY3QsIHRoZXJlIGFyZSBhIGZldyB2ZW5kb3JzIHRoYXQgaGF2ZSBpdCBhbHJlYWR5ICh1bmZv cnR1bmF0ZWx5IHZlcnkgZmV3KSBhbmQgSSBoZWFyZCBhYm91dCBzb21lIHRoYXQgb2ZmZXJlZCBp dCB0byDigJxzcGVjaWFsIGJpZyBjdXN0b21lcnPigJ0sIGJ1dCBub3Qgb2ZmZXJlZCB0byB0aGUg 4oCcZ2VuZXJhbCBtYXJrZXTigJ0uDQogICAgDQogICAgSeKAmXZlIGJlZW4gZXZhbHVhdGluZyBt eXNlbGYsIHdpdGggdHJpYWwgY3VzdG9tZXIgZGVwbG95bWVudHMsIHVzaW5nIG9wZW4tc291cmNl IHN1Y2ggYXMgT3BlbldSVC9MRURFLCB0aGUgY29zdC9mdW5jdGlvbmFsbHkgb2YgdGhvc2UgdHJh bnNpdGlvbiBtZWNoYW5pc21zIGFuZCB0aGV5IGp1c3Qgd29yay4gVHlwaWNhbCBDRSB0b2RheSBo YXZlIGEgbWluaW11bSBvZiA4TUIgKG1hcmtldCBtb3ZpbmcgcXVpY2tseSB0byAxNiBvciAzMiBN QikgZmxhc2ggbWVtb3J5IGFuZCAzMk1CIChtYXJrZXQgbW92aW5nIHF1aWNrbHkgdG8gNjRHQiBh bmQgbXVjaCBtb3JlKSBSQU0sIGFuZCB0aGV5IGhvbGQgcGVyZmVjdGx5IGFsbCB0aG9zZSBmZWF0 dXJlcyB3aXRob3V0IGFueSBpc3N1ZSBhbmQgd2l0aG91dCBuZWVkZWQgdG8gdGFrZSBvdXQgb3Ro ZXIgY29kZS4NCiAgICANCiAgICBTbywgdGhlIHF1ZXN0aW9ucyBmb3IgdGhlIFdHOg0KICAgIA0K ICAgIERvIHlvdSBhZ3JlZSB3aXRoIG15IGNoYW5nZXMgMSwgMiwgMyBhbmQgNCBhYm92ZT8NCiAg ICANCiAgICBOb3cgYSBtb3JlIGNvbXBsZXggcXVlc3Rpb24uIERvIHlvdSB0aGluayBpdCB3aWxs IGJlIGFjY2VwdGFibGUgZm9yIDMgYW5kIG1heSBiZSA0IGFib3ZlLCB0byBiZSBhIE1VU1QgaW5z dGVhZCBvZiBqdXN0IFNIT1VMRD8NCiAgICANCiAgICBJIHRoaW5rIHZlbmRvcnMgbmVlZCBhIHZl cnkgc3Ryb25nIHNpZ25hbCBoZXJlLCBvdGhlcndpc2UsIG1hbnkgb2YgdGhlbSAoYW5kIHRoaXMg aXMgaGFwcGVuaW5nKSwgYXJlIHJlYWRpbmcgYWN0dWFsIDcwODQgYW5kIG9ubHkgcmVhY3Rpbmcg dG8gaW1wbGVtZW50IHRob3NlIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIHdpdGggc3BlY2lmaWMg ZmlybXdhcmUgdmVyc2lvbnMgZm9yIOKAnHZlcnkgYmln4oCdIGN1c3RvbWVycyB3aGljaCB3aWxs IGJ1eSBzZXZlcmFsIGh1bmRyZWQgdGhvdXNhbmQgdW5pdHMgaW4gb25lIHNob3QuIEJ1dCBtYW55 IHNtYWxsIGFuZCBtZWRpdW0gc2VydmljZSBwcm92aWRlcnMsIGJ1eSBvbmx5IGEgZmV3IHVuaXRz IGV2ZXJ5IHdlZWsgd2hlbiB0aGV5IGNvbm5lY3QgbmV3IGN1c3RvbWVycy4gVGhpcyB3YXMgZGlz Y3Vzc2VkIGFscmVhZHkgaW4gdGhpcyBsaXN0IGEgY291cGxlIG9mIG1vbnRocyBhZ28uDQogICAg DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50 L21zZzI1MTUyLmh0bWwNCiAgICANCiAgICBQbGVhc2UsIG5vdGUgdGhhdCB0aGF0IHRoaXMgZG9j dW1lbnQgdmVyc2lvbiBkb2VzbuKAmXQgaW5jbHVkZSB5ZXQgdGhlIGRldGFpbHMgb2YgdGhlIHJl cXVpcmVtZW50cyBmb3IgZWFjaCB0cmFuc2l0aW9uIG1lY2hhbmlzbS4gSeKAmW0gd29ya2luZyBv biB0aG9zZSBhbHJlYWR5LCBidXQgd2lsbCBiZSBuaWNlIHRvIGhhdmUgc29tZSBpbnB1dHMgZnJv bSB0aGUgV0csIHJlZ2FyZGluZyBteSBxdWVzdGlvbnMgYWJvdmUuDQogICAgDQogICAgUmVnYXJk cywNCiAgICBKb3JkaQ0KICAgICANCiAgICANCiAgICAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0t LQ0KICAgIERlOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KICAgIFJlc3BvbmRlciBhOiA8 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KICAgIEZlY2hhOiBsdW5lcywgMjAgZGUgZmVicmVy byBkZSAyMDE3LCAyMzozNw0KICAgIFBhcmE6IEpvcmRpIFBhbGV0IDxqb3JkaS5wYWxldEBjb25z dWxpbnRlbC5lcz4sIEpvcmRpIFBhbGV0IE1hcnRpbmV6IDxqb3JkaS5wYWxldEBjb25zdWxpbnRl bC5lcz4NCiAgICBBc3VudG86IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGFs ZXQtdjZvcHMtcmZjNzA4NC1iaXMtMDAudHh0DQogICAgDQogICAgICAgIA0KICAgICAgICBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcGFsZXQtdjZvcHMtcmZjNzA4NC1iaXMtMDAudHh0DQog ICAgICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9yZGkgUGFsZXQgTWFy dGluZXogYW5kIHBvc3RlZCB0byB0aGUNCiAgICAgICAgSUVURiByZXBvc2l0b3J5Lg0KICAgICAg ICANCiAgICAgICAgTmFtZToJCWRyYWZ0LXBhbGV0LXY2b3BzLXJmYzcwODQtYmlzDQogICAgICAg IFJldmlzaW9uOgkwMA0KICAgICAgICBUaXRsZToJCUJhc2ljIFJlcXVpcmVtZW50cyBmb3IgSVB2 NiBDdXN0b21lciBFZGdlIFJvdXRlcnMNCiAgICAgICAgRG9jdW1lbnQgZGF0ZToJMjAxNy0wMi0y MA0KICAgICAgICBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgICAgICBQYWdlczoJ CTIyDQogICAgICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtcGFsZXQtdjZvcHMtcmZjNzA4NC1iaXMtMDAudHh0DQogICAgICAgIFN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYWxl dC12Nm9wcy1yZmM3MDg0LWJpcy8NCiAgICAgICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYWxldC12Nm9wcy1yZmM3MDg0LWJpcy0wMA0KICAgICAg ICANCiAgICAgICAgDQogICAgICAgIEFic3RyYWN0Og0KICAgICAgICAgICBUaGlzIGRvY3VtZW50 IHNwZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIGFuIElQdjYgQ3VzdG9tZXIgRWRnZSAoQ0UpDQog ICAgICAgICAgIHJvdXRlci4gIFNwZWNpZmljYWxseSwgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0 aGlzIGRvY3VtZW50IGZvY3VzZXMNCiAgICAgICAgICAgb24gdGhlIGJhc2ljIHByb3Zpc2lvbmlu ZyBvZiBhbiBJUHY2IENFIHJvdXRlciBhbmQgdGhlIHByb3Zpc2lvbmluZw0KICAgICAgICAgICBv ZiBJUHY2IGhvc3RzIGF0dGFjaGVkIHRvIGl0LiAgVGhlIGRvY3VtZW50IGFsc28gY292ZXJzIHNl dmVyYWwNCiAgICAgICAgICAgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMsIGFzIHJlcXVpcmVkIGlu IGEgd29ybGQgd2hlcmUgSVB2NCBhZGRyZXNzZXMNCiAgICAgICAgICAgYXJlIG5vIGxvbmdlciBh dmFpbGFibGUsIHNvIGhvc3RzIGluIHRoZSBjdXN0b21lciBMQU5zIHdpdGggSVB2NC1vbmx5DQog ICAgICAgICAgIG9yIElQdjYtb25seSBhcHBsaWNhdGlvbnMgb3IgZGV2aWNlcywgcmVxdWlyaW5n IHRvIGNvbW11bmljYXRlIHdpdGgNCiAgICAgICAgICAgSVB2NC1vbmx5IHNlcnZpY2VzIGF0IHRo ZSBJbnRlcm5ldCwgYXJlIGFibGUgdG8gZG8gc28uICBUaGUgZG9jdW1lbnQNCiAgICAgICAgICAg b2Jzb2xldGVzIFJGQyA3MDg0Lg0KICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N CiAgICAgICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICAgICAgDQogICAgICAgIFRoZSBJRVRGIFNlY3JldGFy aWF0DQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQogICAgDQogICAg KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KICAgIElQdjQg aXMgb3Zlcg0KICAgIEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KICAgIGh0 dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMNCiAgICBUaGUgSVB2NiBDb21wYW55DQogICAgDQogICAg VGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJl IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQg dG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xv c3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhp cyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0K ICAgIA0KICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZvcHNAaWV0Zi5vcmcN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgDQoN Cg== From nobody Tue Feb 21 04:08: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 741C51298D0 for ; Tue, 21 Feb 2017 04:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, 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 JOEsBIZ1QyOw for ; Tue, 21 Feb 2017 04:08:03 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFAA12963F for ; Tue, 21 Feb 2017 04:08:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1LC7xkk025580 for ; Tue, 21 Feb 2017 13:07:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A70D220689B for ; Tue, 21 Feb 2017 13:07:59 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 93AF12067B2 for ; Tue, 21 Feb 2017 13:07:59 +0100 (CET) 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 v1LC7xCM003412 for ; Tue, 21 Feb 2017 13:07:59 +0100 To: v6ops@ietf.org References: <005101d28a03$1b8c4c00$52a4e400$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 21 Feb 2017 13:07:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <005101d28a03$1b8c4c00$52a4e400$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Posted a new version of draft-ali-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 12:08:04 -0000 Hi, Perhaps it makes sense to mention IPv6 routers that implement "Requesting Router" functionality of DHCPv6 Prefix Delegation RFC3633, as well as "Mobile Router" NEMO extension RFC3963 of protocol Mobile IPv6 RFC6275. Alex Le 18/02/2017 à 17:21, Russ White a écrit : > Y'all -- > > Posted a new version of draft-ali-ipv6rtr-reqs. Data tracker page is here -- > > https://datatracker.ietf.org/doc/draft-ali-ipv6rtr-reqs/ > > We'd like to present this at the Chicago meeting, and potentially call to > pull this into a wg item there. I have a list of outstanding comments and > questions; I'll email these to the list in a bit, along with some thoughts > on them. > > :-) > > Russ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Feb 21 04: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 8A37C1299B3 for ; Tue, 21 Feb 2017 04:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTk6JVrQ3Jg1 for ; Tue, 21 Feb 2017 04:55:48 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 92D0F129456 for ; Tue, 21 Feb 2017 04:55:46 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cg9yr-0000D8C; Tue, 21 Feb 2017 13:55:45 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> In-reply-to: Your message of "Tue, 21 Feb 2017 12:47:01 +0100 (CET) ." Date: Tue, 21 Feb 2017 13:55:44 +0100 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 12:55:49 -0000 In your letter dated Tue, 21 Feb 2017 12:47:01 +0100 (CET) you wrote: >My ISP started sending me RAs with no prefix in them, M=1, and responds to >requests for IA_NA and IA_PD with "NoPrefixAvail". > >My UBNT ER5 overwrites the static ::/0 route I have over the 6in4 tunnel >and points default to the ISP router (breaking my connectivity). In the >routing table, it says "proto RA" for that route. Changing distance on my >static route doesn't help. I ended up having to firewall ICMP6 from my ISP >towards the ER5 so it wouldn't even see the RAs, and I will continue doing >this until my ISP deployment is done. Now I have a working soltion again. > >My Omnia Turris (running OpenWrt variant) in the same environment (but >without 6in4 tunnel), seems to consider these RAs and the lack of >prefix/address as a reason to just ignore them. It doesnt install a >default route (so I don't have a ::/0 route on it at all on it). I guess this is something that could be fixed with source-dest routing. The 6in4 tunnel should be preferred for source addresses associated with the tunnel. The default route from the RA can be added but won't be used because of longest prefix matching on the source address. (Just not accepting a default route because there are no associated addresses may break other setups) From nobody Tue Feb 21 05:23: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 8F23B129BA5 for ; Tue, 21 Feb 2017 05:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 BwIaOo3hJewa for ; Tue, 21 Feb 2017 05:23:04 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0B41299C2 for ; Tue, 21 Feb 2017 05:23:04 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EF618A2; Tue, 21 Feb 2017 14:23:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1487683381; bh=2DJ+mbHZ66XBg+x0bkPRfNu/QjBJe61PCSdivfRVUO0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=1YVjapsZAG0Dm42q03ld0C2Rvs3afMU6WqC2Ri0mi3KUG2sNkIxX/8anPu4DmFEUo ealNP39240v/DNIFu4tMMIa0BoCJse2d4Finn4U1QBkacwN6oqjA3+PSc4s7Sjy9je JksnWWjbXQy+vLPq+HFHDIlvuqo+99aKsHdkK/AM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D7C5E88; Tue, 21 Feb 2017 14:23:01 +0100 (CET) Date: Tue, 21 Feb 2017 14:23:01 +0100 (CET) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ In-Reply-To: <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> Message-ID: References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@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; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 13:23:06 -0000 Hi, another potential mechanism to be included in 7084bis. https://tools.ietf.org/html/rfc8026 This should probably be supported by a 7084bis device. If there are mechanisms in 7084bis not in RFC8026, that should probably be added. Also, please do not downgrade MUST requirements in 7084 to anything less in 7084bis. That means an ISP supporting for instance DS.lite can have reasonable "trust" in that a 7084bis device will still support this. We don't want to drive ISPs to support all/most mechanisms just because the CEs don't support at least one mandatory one (and that this changed over time). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Feb 21 06:00: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 2B9C3129BC3 for ; Tue, 21 Feb 2017 06:00:32 -0800 (PST) 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, 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 HS00PbjTMjvY for ; Tue, 21 Feb 2017 06:00:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255DE129BB5 for ; Tue, 21 Feb 2017 06:00:29 -0800 (PST) Received: from [192.168.1.162] ([62.225.30.138]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LslCb-1cDxkn1k0v-012IWW; Tue, 21 Feb 2017 15:00:16 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ian Farrer In-Reply-To: <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> Date: Tue, 21 Feb 2017 15:00:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com> References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.3124) X-Provags-ID: V03:K0:UlEAgReI8M7vpDL/dY+lmQ4phfGOUHy9hGbgRpmg2hlzFm7cuH9 Besg8McokrW8uWR/r7tLV/HzDuMREPMQf9l22hLYnRXCjaDKK60ooPZlOJOROCj3kO1x5Kj nDsfPPIOwjUai4jSmW9FJ/10Da25Hfr7tPDRqTO2sztbys2smJNpaLCJR5c6Tf8g1CruNJT yd/xRfoFpcWzzWgwMjDxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Bvdt50OGylQ=:84FF29P2Br55HwU72i/Djv W1E/0tYNcEbPUzItTYI9f1fhQP5pKAiMFbDjNipFzP9RFIWL8y3+7zAYQlHr9nyUbidvNDc6V o7w70QaNQC9avU9dN9CtYefNP9/psPwdRqBv5Fvq4m3GYUIR0pMV1+teQ9sXPnAX1l2lywZQI IGGw3ZFJxgJ6A/63ga7U6I/HZ+ymwHhgP/AEq0gIOVswP3ipcs+PT8ug4wZ4uhmefKcJ4mqj9 5PWGOPys/Fr+GYW8BBXN2lEWx2tQr7WXxceOk7c5W8TDWt8ZXykboxpyqMjGwG2M+IWnDRbxI paeGLGj5AgJ86vAns9J1OLv2MIZnsIV5oQoy+SgZzrvvaWz/wVH8K1iEDFY4D21mmzMOmMwcG xe1L4suYqmQVqdWZ6EBr0+X/CIMse6i/ZfkO5SN8Gv7J0QtxgadD5ln5GBS5ZXnizcbLj03p5 ywBtUWEg3m81aPVzBPs90eP7S0SuTkeQiPWFqUux+w2xW0RecFXcp1rrN/6A2tEib9Gkzv+9b bxC9fEgAW+jB+uE097tbATI9tMAhD6tI+PPVL/uJzz/EdGbu4/DjCNkpiTXzmRc79ooo9Crt9 9TIhgoyCdD7D9/1iJ3+9nKgnKPHXW1+kax2sriIpBqr6M1QScJI9mrkHHjNh8Ws8DGy3YceuV wgTHWQxZZl+d4MT49ZqKz2nB4Vtcth1bgpv7EPtlyGbkdmJO+EC9eGLdDJAqWaD2ei5y2oveK cuexxhqccvVzm8al5JdWdy5RyXk0cYU8E4x1OEfypt4r/hzufwpJ5qAdNqI9m2Fww4t0gMYIX T27FwSz Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 14:00:32 -0000 Hi Jordi, >=20 > What do you think about moving the 464XLAT, MAP, to MUST ? [if - RFC7084 already has MUST requirements for 6RD and DSLite and as = they are already widely implemented would like them to stay as MUST. = However, I would prefer not to see any more mandatory transition = mechanisms added in this document. I think it=E2=80=99s more useful to construct the requirements for any = of the newer (post RFC7084) transition mechanisms, as =E2=80=98MAY = implement the mechanism - if implemented MUST support a, b, c'. When = specifying requirements for a CPE, I can just point to the particular = section relevant to the mechanism deployed in my network. Regards, Ian From nobody Tue Feb 21 11:20: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 31FE112943F for ; Tue, 21 Feb 2017 11:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 94OIqLsRhXT2 for ; Tue, 21 Feb 2017 11:20:23 -0800 (PST) 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 072E112711D for ; Tue, 21 Feb 2017 11:20:23 -0800 (PST) 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 v1LJJXTl016254; Tue, 21 Feb 2017 14:20:12 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 28rukx00r7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Feb 2017 14:20:12 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1LJKB0A029793; Tue, 21 Feb 2017 14:20:11 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1LJK8Hg029778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 14:20:08 -0500 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 21 Feb 2017 19:19:48 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.76]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 14:19:47 -0500 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSjErmrfnJlR21KESvvZHHQ3NOt6Fzvufg Date: Tue, 21 Feb 2017 19:19:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DAC7459@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com> In-Reply-To: <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.251.237] 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-02-21_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702210178 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 19:20:24 -0000 U29tZSBvZiBteSB0aG91Z2h0cyBvbiB0aGluZ3MgdGhhdCBoYXZlIGJlZW4gc2FpZCAuLi4NCg0K PiAuLi4gdmVuZG9ycyBuZWVkIGEgdmVyeSBzdHJvbmcgc2lnbmFsIGhlcmUsIG90aGVyd2lzZSwg bWFueSBvZiB0aGVtIChhbmQgdGhpcyBpcyBoYXBwZW5pbmcpLCBhcmUgcmVhZGluZyBhY3R1YWwg NzA4NCBhbmQgb25seSByZWFjdGluZyB0byBpbXBsZW1lbnQgdGhvc2UgdHJhbnNpdGlvbiB0ZWNo bm9sb2dpZXMgd2l0aCBzcGVjaWZpYyBmaXJtd2FyZSB2ZXJzaW9ucyBmb3Ig4oCcdmVyeSBiaWfi gJ0gY3VzdG9tZXJzIHdoaWNoIHdpbGwgYnV5IHNldmVyYWwgaHVuZHJlZCB0aG91c2FuZCB1bml0 cyBpbiBvbmUgc2hvdC4NCg0KSSdtIG5vdCBhd2FyZSBvZiBhbnkgdmVuZG9ycyAqd2hvIHNlbGwg dG8gSVNQcyogYW5kIHVzZSBSRkMgNzA4NCBhcyB0aGUgYmFzaXMgZm9yIHdoYXQgdGhleSBwdXQg aW4gdGhlaXIgZmlybXdhcmUuIE1vc3Qgc3VjaCB2ZW5kb3JzIHVzZSBCQkYgVFItMTI0IG9yIENh YmxlTGFicyBDRSBSb3V0ZXIgc3BlY3MuIEFzIGFuIGF1dGhvciBvZiBSRkMgNzA4NCwgSSByZWFs bHkgc2F3IHRoaXMgUkZDIGFzIHRhcmdldGluZyB0aGUgcmV0YWlsIHZlbmRvcnMuIFRoYXQgd2Fz IG15IHJlYXNvbiBmb3Igd29ya2luZyBvbiBpdC4gSWYgYWxsIEkgbmVlZGVkIHdhcyByZXF1aXJl bWVudHMgZm9yIHZlbmRvcnMgdG8gSVNQcywgQkJGIFRSLTEyNCB3b3VsZCBoYXZlIGJlZW4gc3Vm ZmljaWVudC4gDQpJIGRvIHN5bXBhdGhpemUgd2l0aCB0aGUgc21hbGwgSVNQcy4gSSBqdXN0IHdv bmRlciBpZiB0aGlzIGlzIHRoZSByaWdodCB3YXkgdG8gZG8gaXQuIEkgd29uZGVyIGlmIGEgY29t cGxldGVseSBuZXcgKG5vdCBtb2RpZmllZCBSRkMgNzA4NCkgZHJhZnQgd2hvc2UgaW50ZW50IGlz IGNsZWFybHkgc3RhdGVkIGFzIGJlaW5nIHRvIHNwZWNpZnkgYWRkaXRpb25hbCB0cmFuc2l0aW9u IGZ1bmN0aW9uYWxpdHkgbmVlZGVkIGJ5IG1hbnkgc21hbGwgSVNQcyBtaWdodCBiZSBhIGJldHRl ciBhcHByb2FjaC4gSXQgbWlnaHQgYmUgZ29vZCB0byBzdHJhdGVnaXplIG9uIHRoZSBiZXN0IHdh eSB0byBhY2hpZXZlIHRoaXMgZGVzaXJlZCBnb2FsLCByYXRoZXIgdGhhbiBmaXJzdCBkaXNjdXNz aW5nIHdoYXQgcmVxdWlyZW1lbnRzIGFyZSBNVVNUL1NIT1VMRC9NQVkuIEFuZCBhbHNvIGFncmVl IG9uIHRoaXMgYXMgdGhlIGdvYWwgb2YgYSBuZXcgZHJhZnQuDQpJdCBtYXkgYmUgbW9yZSBlZmZl Y3RpdmUgdG8gaGF2ZSBhIHNtYWxsIHRhcmdldGVkIGRyYWZ0IHRoYXQgc2F5cyAiZG8gbWFuZGF0 b3J5IGR1YWwgc3RhY2sgcGFydHMgb2YgUkZDIDcwODQ7IGFuZCBoZXJlIGlzIGFkZGl0aW9uYWwg dHJhbnNpdGlvbiB0ZWNobm9sb2d5IHRoYXQgbWFueSBzbWFsbCBJU1BzIG5lZWQgdG8gYmUgYWJs ZSB0byBnZXQgZnJvbSB0aGVpciB2ZW5kb3JzIi4gDQpXZSB3b3VsZCBuZWVkIGEgbnVtYmVyIG9m IHNtYWxsZXIgSVNQcyB0byBqb2luIGluIHN1cHBvcnQsIGlmIGl0J3MgdG8gYmUgc3VjY2Vzc2Z1 bC4gQW5kIHRoZSBzZXQgb2YgcmVxdWlyZW1lbnRzIGRlZmluaXRlbHkgbmVlZCB0byBiZSBsaW1p dGVkLg0KSWYgdGhhdCB3ZXJlIHRoZSBmb2N1cyBvZiB0aGUgZHJhZnQsIEkgd291bGRuJ3QgYm90 aGVyIGluY2x1ZGluZyA2cmQgYXQgYWxsLg0KDQo+IEFuZCBBVCZUIGhhcyBhIHZlcnkgbGFyZ2Ug NnJkIGRlcGxveW1lbnQsIHNvIEkgd291bGRuJ3QgYmUgc3VycHJpc2VkIHRvIHNlZSBwdXNoIGJh Y2sgZnJvbSB0aGVtIG9uIGRvd25ncmFkaW5nIDZyZCB0byBNQVkgKHRob3VnaCBwZXJoYXBzIHRo ZXkgZG9uJ3QgbXVjaCBjYXJlLCBpZGspLg0KDQpBdCB0aGlzIHBvaW50LCBmb3IgbWUsIGl0J3Mg YSAiZG9uJ3QgY2FyZSIuIFdoZW4gZGVwbG95bWVudCBmaXJzdCBzdGFydGVkLCB0aGVyZSB3YXMg YSBkaXN0aW5jdCBwZXJjZW50YWdlIG9mIEFUJlQgY3VzdG9tZXJzIHdobyBoYWQgbm8gKGFuZCBu byBvcHRpb24gZm9yKSBBVCZULXByb3ZpZGVkIENFIFJvdXRlciAoYmVjYXVzZSBvZiBhIGxlZ2Fj eSBicm9hZGJhbmQgYXJjaGl0ZWN0dXJlIGluIHRoZSBzb3V0aGVhc3QgVVMpLiBBcyBJIG1lbnRp b25lZCwgUkZDIDcwODQgd2FzIGFib3V0IHJldGFpbCBhbmQgbm90IElTUC1wcm9jdXJlZCBDRSBy b3V0ZXJzIC0tIHNvIGhhdmluZyA2cmQgaW4gcmV0YWlsIHJvdXRlcnMgcHJvdmlkZWQgdGhlc2Ug Y3VzdG9tZXJzIChpbmNsdWRpbmcgbWUpIGEgd2F5IHRvIGdldCA2cmQgdXAgYW5kIHJ1bm5pbmcg b24gQVQmVC4gT3ZlciB0aGUgcGFzdCAxLjUgeWVhcnMsIEFUJlQgaGFzIHB1dCBGVFRIIGluIHBs YWNlIGZvciBhbG1vc3QgYWxsIChvciBtYXliZSBieSBub3cgYWxsKSB0aG9zZSBjdXN0b21lcnMs IHdoaWNoIG1lYW5zIEFUJlQgQ0Ugcm91dGVycyBhcmUgYXZhaWxhYmxlIChhbmQgZm9yIEZUVEgs IHJlcXVpcmVkKS4gWW91IGNhbid0IGV2ZW4gZmluZCB0aGUgNnJkIGNvbmZpZ3VyYXRpb24gaW5m byBvbiB0aGUgQVQmVCB3ZWJzaXRlIGFueW1vcmUuIFtZb3UgY2FuIHN0aWxsIGZpbmQgdGhlIGlu Zm8gd2hlcmUgb3RoZXIgcGVvcGxlIGhhdmUgcG9zdGVkIGl0LiBKdXN0IG5vdCBmcm9tIEFUJlQu XSANCkkgZG8gaGF2ZSBteSBvd24gQ0Ugcm91dGVyIGJlaGluZCB0aGUgQVQmVCBDRSByb3V0ZXIu IFRoZSBBVCZUIENFIHJvdXRlciBwcm92aWRlcyBhIC82NCBmcm9tIHRoZSA2cmQgLzYwIHZpYSBJ QV9QRCB0byBteSByb3V0ZXIuIFNvIGl0IGxvb2tzIHRvIG15IHJvdXRlciBsaWtlIG5hdGl2ZSBJ UHY2Lg0KQVQmVCBjb25maWd1cmVkIGFuZCBlbmFibGVkIDZyZCwgTEFOLXNpZGUgU0xBQUMsIGFu ZCBMQU4tc2lkZSBESENQdjYgSUFfUEQgaW4gdGhlIEFUJlQgQ0UgUm91dGVyLCB3aXRob3V0IG15 IGRvaW5nIGFueXRoaW5nLg0KDQpCYXJiYXJhDQoNCg0K From nobody Tue Feb 21 12: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 027241293F9 for ; Tue, 21 Feb 2017 12:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2kHOO4JcMjxP for ; Tue, 21 Feb 2017 12:21:42 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F317129514 for ; Tue, 21 Feb 2017 12:21:42 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id 1so22214329pgi.1 for ; Tue, 21 Feb 2017 12:21:42 -0800 (PST) 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=7ong0CTSzyilSr6FAXbZHgmk2oXZ+1JNkXE5n9NWvSA=; b=qcGFEh3SDJC1wnUIH4oBrU3lobR7yhqhHHMa8v72lu+XeiejmTrOu9j76uAB2pkama uwjkvwaK5dXto6dACKpFpszbahycF33jRa6t5POxmsqNixLmxjc32pEx0p/hko8bqOur +ga9nVurjXVTE5LXToov0kuCtqbk3SmVuFS9yi946tz7oA0M9mSZMn9IXTKGx8GD0nDO CJIruJ1gFN1Z4xye4NltotCfPDW627323HoxH+lwg6iBv5zNftO9kHZuYrY6aQw7nXp4 nJk4toTwi/2MCKMWdKrZ2JxzjPz0zbmiCpAqIT5J1jBB0NrUbqlze6X4vcmn/c2ypSbx nCmg== 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=7ong0CTSzyilSr6FAXbZHgmk2oXZ+1JNkXE5n9NWvSA=; b=kNutFOnv5VSAFhX3uh62Hfyrm6Akyn4yl9/iX5eMDOWuxgG9Th2k7BQT/1QNcjeCqn rpEe70L+qLNuTzzqtS71hJ5YrDjATk5AJo8cojnB6UT4pzdjU+S64n0REqVFZWvgjQ1L 9jJOZ6QdGLHuN5a2Dzx90PQE0mlweJ9OVbv05b17CyCzGWilr588+HY1BfCne0+SJ16o p18aMXesN3NMHBQFhuk0XVLP6gHuk1w/mUYljfyK8FfnXb53ia3sqjGltaiGM6/VAzyT py4F+V4lfXel53SIY6DNdyhN+VJGxj998Q9qHpe+Pjutb8ciHqgTSnUWKKnYRQwHXeTD rKKQ== X-Gm-Message-State: AMke39mjN6U8RP1Bc1291Xw8hLBreFz2dNKdft0YDZvgJjwOLMsFGftTe4u2IgZ6/VN7oPsa X-Received: by 10.98.36.16 with SMTP id r16mr35346439pfj.56.1487708501985; Tue, 21 Feb 2017 12:21:41 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id c204sm42548672pfb.51.2017.02.21.12.21.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 12:21:41 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_08D44C34-1757-44ED-AECB-63DFF9D2FFC2" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 21 Feb 2017 12:21:39 -0800 References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> To: IPv6 Ops WG In-Reply-To: <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> Message-Id: <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 20:21:44 -0000 --Apple-Mail=_08D44C34-1757-44ED-AECB-63DFF9D2FFC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 21, 2017, at 01:11, JORDI PALET MARTINEZ = wrote: >=20 > I=E2=80=99ve submitted a -bis draft for updating RFC7084 (Basic = Requirements for IPv6 Customer Edge Routers). I strongly believe that any update to RFC 7084 that doesn=E2=80=99t = REQUIRE the LAN interfaces to provide HNCP services [RFC 7788] is an = incomplete update. --james woodyatt > --Apple-Mail=_08D44C34-1757-44ED-AECB-63DFF9D2FFC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 21, 2017, at 01:11, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

I=E2=80=99ve submitted a -bis draft for = updating RFC7084 (Basic Requirements for IPv6 Customer Edge Routers).

I strongly believe that any update to = RFC 7084 that doesn=E2=80=99t REQUIRE the LAN interfaces to provide HNCP = services [RFC 7788] is an incomplete update.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_08D44C34-1757-44ED-AECB-63DFF9D2FFC2-- From nobody Tue Feb 21 16:42: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 35D831294AD for ; Tue, 21 Feb 2017 16:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 IDLUIpgSR6ev for ; Tue, 21 Feb 2017 16:42:18 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3011294A9 for ; Tue, 21 Feb 2017 16:42:18 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v1M0ZPa6025623; Tue, 21 Feb 2017 19:42:16 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 28rwkk3c9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Feb 2017 19:42:16 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1M0gGv2027896; Tue, 21 Feb 2017 19:42:16 -0500 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 v1M0g9dL027819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 19:42:11 -0500 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 22 Feb 2017 00:41:51 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.76]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 19:41:51 -0500 From: "STARK, BARBARA H" To: james woodyatt , IPv6 Ops WG Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSjIAmzvhblLtaeUmv4ODS24LKk6F0LK1g Date: Wed, 22 Feb 2017 00:41:51 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> In-Reply-To: <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.251.237] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DAC7803GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-21_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-1612050000 definitions=main-1702220005 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 00:42:20 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DAC7803GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIEphbWVzLCBJIGRpc2FncmVlLg0KVGhlIGNoYXJ0ZXIgb2YgdjZvcHMgaXMgc3RpbGwg ZG9pbmcgdGhpbmdzIHRoYXQgaGVscCBnZXQgSVB2NiByb2xsZWQgb3V0LiBXaGljaCBpcyBleGFj dGx5IHdoYXQgdGhlc2UgSVNQcyBhcmUgYXNraW5nIGZvciBoZWxwIHdpdGguIFdoaWNoIGhhcyBu b3RoaW5nIHRvIGRvIHdpdGggbXVsdGktcm91dGVyIGhvbWUgbmV0d29yayB0b3BvbG9naWVzLg0K DQpJIGJlbGlldmUgYSB2ZXJ5IHRhcmdldGVkIGRvY3VtZW50IHRvIG1lZXQgdGhlIG5lZWRzIG9m IHRoZXNlIElTUHMgaXMgd2hhdCB3ZSBzaG91bGQgYmUgYWltaW5nIGZvci4NCkJhcmJhcmENCg0K RnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg amFtZXMgd29vZHlhdHQNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE3IDM6MjIgUE0N ClRvOiBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzcwODQtYmlz LTAwLnR4dA0KDQpPbiBGZWIgMjEsIDIwMTcsIGF0IDAxOjExLCBKT1JESSBQQUxFVCBNQVJUSU5F WiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM8bWFpbHRvOmpvcmRpLnBhbGV0QGNvbnN1bGlu dGVsLmVzPj4gd3JvdGU6DQoNCknigJl2ZSBzdWJtaXR0ZWQgYSAtYmlzIGRyYWZ0IGZvciB1cGRh dGluZyBSRkM3MDg0IChCYXNpYyBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3VzdG9tZXIgRWRnZSBS b3V0ZXJzKS4NCg0KSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgYW55IHVwZGF0ZSB0byBSRkMgNzA4 NCB0aGF0IGRvZXNu4oCZdCBSRVFVSVJFIHRoZSBMQU4gaW50ZXJmYWNlcyB0byBwcm92aWRlIEhO Q1Agc2VydmljZXMgW1JGQyA3Nzg4XSBpcyBhbiBpbmNvbXBsZXRlIHVwZGF0ZS4NCg0KLS1qYW1l cyB3b29keWF0dCA8amh3QGdvb2dsZS5jb208bWFpbHRvOmpod0Bnb29nbGUuY29tPj4NCg0KDQoN Cg== --_000_2D09D61DDFA73D4C884805CC7865E6114DAC7803GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Tb3JyeSwgSmFtZXMsIEkgZGlzYWdyZWUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgY2hh cnRlciBvZiB2Nm9wcyBpcyBzdGlsbCBkb2luZyB0aGluZ3MgdGhhdCBoZWxwIGdldCBJUHY2IHJv bGxlZCBvdXQuIFdoaWNoIGlzIGV4YWN0bHkgd2hhdCB0aGVzZSBJU1BzIGFyZSBhc2tpbmcgZm9y IGhlbHAgd2l0aC4gV2hpY2ggaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBtdWx0aS1yb3V0ZXINCiBo b21lIG5ldHdvcmsgdG9wb2xvZ2llcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBiZWxpZXZlIGEgdmVyeSB0 YXJnZXRlZCBkb2N1bWVudCB0byBtZWV0IHRoZSBuZWVkcyBvZiB0aGVzZSBJU1BzIGlzIHdoYXQg d2Ugc2hvdWxkIGJlIGFpbWluZyBmb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CYXJiYXJhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5qYW1lcyB3 b29keWF0dDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyMSwgMjAxNyAzOjIy IFBNPGJyPg0KPGI+VG86PC9iPiBJUHY2IE9wcyBXRyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtcGFsZXQtdjZvcHMtcmZjNzA4NC1iaXMtMDAudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDIxLCAyMDE3LCBhdCAwMToxMSwg Sk9SREkgUEFMRVQgTUFSVElORVogJmx0OzxhIGhyZWY9Im1haWx0bzpqb3JkaS5wYWxldEBjb25z dWxpbnRlbC5lcyI+am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZdmUgc3VibWl0 dGVkIGEgLWJpcyBkcmFmdCBmb3IgdXBkYXRpbmcgUkZDNzA4NCAoQmFzaWMgUmVxdWlyZW1lbnRz IGZvciBJUHY2IEN1c3RvbWVyIEVkZ2UgUm91dGVycykuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCBhbnkgdXBkYXRlIHRvIFJGQyA3MDg0IHRoYXQg ZG9lc27igJl0IFJFUVVJUkUgdGhlIExBTiBpbnRlcmZhY2VzIHRvIHByb3ZpZGUgSE5DUCBzZXJ2 aWNlcyBbUkZDIDc3ODhdIGlzIGFuIGluY29tcGxldGUgdXBkYXRlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1qYW1lcyB3b29keWF0dCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpod0Bnb29nbGUuY29tIj5qaHdAZ29vZ2xlLmNvbTwvYT4mZ3Q7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6114DAC7803GAALPA1MSGUSRBF_-- From nobody Tue Feb 21 17:09: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 50A6D1294C1 for ; Tue, 21 Feb 2017 17:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sodkuqx_9rm for ; Tue, 21 Feb 2017 17:09:26 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE18B1294BF for ; Tue, 21 Feb 2017 17:09:25 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id 1so25646295pgi.1 for ; Tue, 21 Feb 2017 17:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=uqCy7cGPrC/PKplztQLDsquseE3bvXn2Bs63hhHvrG0=; b=KS+EXGVXobs7mLqqvUvGnpbThSTyHixzp6ZJVNF2Tybp6CLFAEHc0/0L5cJtTmnyfn BZ0W+Jy/HX2zDlNSqNgKi71l7x/GnG77MN2dcQZasKZKiHE9GfPmDM84goflG3iBVY9E c0g6HNYdN9Vlvr+35m0EgbKEAnvznAHplvoY3lDl1hZgRYSeOywp5GkWCUa7H7wkpXv5 kAichCaoyXv8ULkiaJm7oU1uDy6PdXuM/Xz+v+USUi0PIPmJFSJOXA9DhSHcbadD8aaC AgCoCZlSprbNjkg7CbfyI9VL0zwoUILbwhfbmqC9VIKzCdgpJcwFy6UOXiPqXG6A5MWF RgXQ== 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=uqCy7cGPrC/PKplztQLDsquseE3bvXn2Bs63hhHvrG0=; b=eO7UQSOGbzXD08kAd2Xevx4UfU65HzFlrUwUuUQyTS/j86+qUD0loPhKVotXxgQMLn 7c5hDyqs1ommaoFb6gvDCPX7e3azy/unR8SulGwh5RaQ/3JdSF81aA+BZlIpxaPkA9Be Cq3+3X9fRlgguG53u3f2DikGkPLUi5JOLyc2Aq01WuXW98hXbbjA5uxGPw7sgpCmukuS 19Pm09UmVMbCoMtAj9L95z1el2Qnrk08BzFB4LnakE+rvmYKpKTdehlRL4c364gc5eW4 OEv1cRv84y5j1q0bZ4bNVcJirnEJH7gMDilBRzKe1tqUJpdhMQJ/efZihAEeFQ0GzIpm b3Aw== X-Gm-Message-State: AMke39mPIPksEG7eieD9sm7+GyEJZfL1XkLCcAIYVaqr61mo2Q1mBoVsTbhGieVB5Pj6rg== X-Received: by 10.99.119.142 with SMTP id s136mr4519551pgc.207.1487725765159; Tue, 21 Feb 2017 17:09:25 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id n189sm42980559pfn.108.2017.02.21.17.09.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 17:09:23 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 21 Feb 2017 17:09:23 -0800 References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> To: IPv6 Ops WG In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 01:09:27 -0000 This argument is essentially what I was referring to with respect to = draft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812 = didn't have to address. They include, at least, ISP, content network, = data center, enterprise, residential, IoT, and mobile wireless networks. = Those markets have differing non-exclusive sets of requirements. Let me throw a question to the working group. One way to approach this = is to try to push requirements for all of those markets into one = document, which is what I think James is trying to do. Another way is to = separate them, which is what I think Barbara is trying to do. I'm not = going to say that either is automatically right or automatically wrong, = but they are different, and I have visions of an argument that takes = forever, boils blood, and nobody wins, if we don't systematically = address it. I see two approaches that might be considered reasonable. One would be = to add a section about residential networks (which are definitively not = ISP networks, but use routers that might also be used as ISP = "customer-edge" routers) to the document, stating that it is = requirements for routers that might be used within a multi-router = residential network including the router connected to the ISP; the other = would be to invite a separate document that addresses residential = networks. If we take the latter approach, we might as well also invite separate = documents (or in the former approach, separate sections) describing = requirements for IPv6 routers in ISP, content network, data center, = enterprise, IoT, and mobile wireless networks. This might be one of = those, and draft-ali might be one of those. I suspect we will find that = a lot of the requirements are in fact common, and could be described in = a core document. But I don't know of any ISPs suggesting the use of = HNCP, residential networks discussing RPL, or yada yada yada. Opinions? On Feb 21, 2017, at 4:41 PM, STARK, BARBARA H wrote: >=20 > The charter of v6ops is still doing things that help get IPv6 rolled = out. Which is exactly what these ISPs are asking for help with. Which = has nothing to do with multi-router home network topologies. > =20 > I believe a very targeted document to meet the needs of these ISPs is = what we should be aiming for. > Barbara > =20 > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of james = woodyatt > Sent: Tuesday, February 21, 2017 3:22 PM > To: IPv6 Ops WG > Subject: Re: [v6ops] New Version Notification for = draft-palet-v6ops-rfc7084-bis-00.txt > =20 > On Feb 21, 2017, at 01:11, JORDI PALET MARTINEZ = wrote: > =20 >> I=E2=80=99ve submitted a -bis draft for updating RFC7084 (Basic = Requirements for IPv6 Customer Edge Routers). > =20 > I strongly believe that any update to RFC 7084 that doesn=E2=80=99t = REQUIRE the LAN interfaces to provide HNCP services [RFC 7788] is an = incomplete update. > =20 > --james woodyatt > =20 > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Feb 21 17:18: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 6B11C1294C8 for ; Tue, 21 Feb 2017 17:18:03 -0800 (PST) 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 trNAuOjEPRIF for ; Tue, 21 Feb 2017 17:18:02 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793751294BF for ; Tue, 21 Feb 2017 17:18:02 -0800 (PST) Received: from [128.9.184.189] ([128.9.184.189]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1M1HSQw024676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Feb 2017 17:17:29 -0800 (PST) To: Fred Baker , IPv6 Ops WG References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Joe Touch Message-ID: Date: Tue, 21 Feb 2017 17:17:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 01:18:03 -0000 On 2/21/2017 5:09 PM, Fred Baker wrote: > This argument is essentially what I was referring to with respect to draft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812 didn't have to address. They include, at least, ISP, content network, data center, enterprise, residential, IoT, and mobile wireless networks. Those markets have differing non-exclusive sets of requirements. Is there a way to focus on the core requirements that all routers need to support in this doc, assuming that there are lots of things a router in general MAY also do... And then leave it to other documents to focus on the additional requirements (or relaxations of SHOULDs) that apply to these environments? Joe From nobody Tue Feb 21 17:29: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 861F11294C9 for ; Tue, 21 Feb 2017 17:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 IxXFxiAYIrJk for ; Tue, 21 Feb 2017 17:29:06 -0800 (PST) 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 09D561294C1 for ; Tue, 21 Feb 2017 17:29:06 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id 1so25961341pgi.1 for ; Tue, 21 Feb 2017 17:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CNPztm7YLUkuXVu3zj1TF2TnttEDYYhJyNCqBeMU/Pk=; b=kiOO71EeTncqmYb38aETS6XjevWW2lGRjejI5tNpyi3lWaNg9K8G71eukH4wynp3DF H/n/pDI4uYctFD+ilIkYHYiO6bJE4GmfjEwvCgdPdimWU9iKTtKY/JWVWAUSqZoo08IL Tb2kMHRiRUn1TU9y9ixQAdSFIMfq/23z79J4I0RYdvhNNxXUeR4ST6jwCwRCbNpBxBtB 2aLHj0tgQKIGuBHGhN+9mEdC+hAOgk+tKgYt3v9isY6ImYJ7GLRA8VsxETnbCk3OouQM kBYY5CxmSYocykfM3A0/a9OiD9aZFzTXaDKtFmIXPHB55Plicza22CH5hScKuxoSVj4G K9jA== 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=CNPztm7YLUkuXVu3zj1TF2TnttEDYYhJyNCqBeMU/Pk=; b=aKHCQyamjTUfv0TEjDOTG/ysdIGfUQyY1meSTgN2Rpy6HyLnRq9xnfKCE22masH0Wx Tq+zUALRdrVJrzwrWGrnJbBtFMVEQirdKK7mtwwkzqW4o1ZeGKyNErn2MQTqpbWOgzS8 MfZ6EdGp01KRslYVsVpZH28RwRQbp4rMdGg5rK79vOb0fFUFet5y94jy3WkZY+wdGARX FhpWEww1+3HlSPAwbGDX3MW8yojkh7+vpYGbjVhDUbKqdXTDyP81AgN0ASgUINBPX8e6 l4DmeTb7oLm/+C6VWFoVmP56KZ62C9YmwDLs9dkBdo3366sU7sjXQdF81JxntIij9IYk Hl+w== X-Gm-Message-State: AMke39mrVVIOo+LvUTZmgRG21CDj4EQzZOWehgG1Hd/y+Q6M7SMFNF3Ta3O3iX/ASyLkUg== X-Received: by 10.84.238.1 with SMTP id u1mr44490135plk.174.1487726945621; Tue, 21 Feb 2017 17:29:05 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id o66sm43077009pfa.119.2017.02.21.17.29.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 17:29:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Tue, 21 Feb 2017 17:29:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Joe Touch X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 01:29:19 -0000 > On Feb 21, 2017, at 5:17 PM, Joe Touch wrote: >=20 >=20 >=20 > On 2/21/2017 5:09 PM, Fred Baker wrote: >> This argument is essentially what I was referring to with respect to = draft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812 = didn't have to address. They include, at least, ISP, content network, = data center, enterprise, residential, IoT, and mobile wireless networks. = Those markets have differing non-exclusive sets of requirements. > Is there a way to focus on the core requirements that all routers need > to support in this doc, assuming that there are lots of things a = router > in general MAY also do... >=20 > And then leave it to other documents to focus on the additional > requirements (or relaxations of SHOULDs) that apply to these = environments? There may be; it would be the "core document" I referred to. A document = that is accurately described as "7084-bis" would not be that document; = 7084 describes a router in a particular application, and probably a = particular price point, something called "customer-edge".= From nobody Tue Feb 21 23: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 77260129480 for ; Tue, 21 Feb 2017 23:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 P5G_dlZqbEBn for ; Tue, 21 Feb 2017 23:48:02 -0800 (PST) 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 0E4201293DB for ; Tue, 21 Feb 2017 23:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487749674; x=1488354474; 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=mIDB/H7jhLTkYK19wSBA7OnAt z7aHL+095WBK1/c6QU=; b=Km0gVYIeLB6rOhQR+9IDFP1qTS0hJbV6bbhAyGwME 8ygr+PctSFfOryTO7DQOTlAlLsmcqqK+YGKV5jXNB2RICn7uSQirzEd09JfbhJXP 5XAcRl9jdSKSX4j4bLIaev2Ojvdq/eCYOQTk/IdpafLUiEKgVdq/fJ/6LY23WrWi T0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=bwxd5dzmMdNCh0dObiJURA5vb1aOk87QXsyfQjfr5R08OstydZNkNB3FeYzT cyAjzuBzueBim54zC91sn66H4vgg1r81YNRT13DpWb/fDf7bXpaWIV45Z XXIHOjQ1PnsEriY/x17KGiqa5vmE0JUNPwF+PB93SonkXrK7ljcSbQ=; X-MDAV-Processed: mail.consulintel.es, Wed, 22 Feb 2017 08:47:54 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 22 Feb 2017 08:47:54 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005371659.msg for ; Wed, 22 Feb 2017 08:47:53 +0100 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:170222:md50005371659::vM2jRl1RX55cdLjK:0000Giev X-Return-Path: prvs=1226ba9495=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 22 Feb 2017 08:47:50 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <0C23A2E7-F41B-4226-A670-1DDDD86956DF@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7459@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DAC7459@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 07:48:04 -0000 Hi Barbara, I=E2=80=99m trying to understand what was the goal for the original documen= t. You mention =E2=80=9Cretail vendors=E2=80=9D. Not being a native English speaker I really feel that I=E2=80=99m in the li= mit to understand correctly what is a =E2=80=9Cretail=E2=80=9D vendor and w= hat are the other types, so to understand what makes them different in term= s of requirements. At this way I think we can take a better decision if we want a single docum= ent or separate ones. Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: martes, 21 de febrero de 2017, 20:19 Para: "jordi.palet@consulintel.es" CC: "v6ops@ietf.org" Asunto: RE: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-= bis-00.txt Some of my thoughts on things that have been said ... =20 > ... vendors need a very strong signal here, otherwise, many of them (= and this is happening), are reading actual 7084 and only reacting to implem= ent those transition technologies with specific firmware versions for =E2= =80=9Cvery big=E2=80=9D customers which will buy several hundred thousand u= nits in one shot. =20 I'm not aware of any vendors *who sell to ISPs* and use RFC 7084 as the= basis for what they put in their firmware. Most such vendors use BBF TR-12= 4 or CableLabs CE Router specs. As an author of RFC 7084, I really saw this= RFC as targeting the retail vendors. That was my reason for working on it.= If all I needed was requirements for vendors to ISPs, BBF TR-124 would hav= e been sufficient.=20 I do sympathize with the small ISPs. I just wonder if this is the right= way to do it. I wonder if a completely new (not modified RFC 7084) draft w= hose intent is clearly stated as being to specify additional transition fun= ctionality needed by many small ISPs might be a better approach. It might b= e good to strategize on the best way to achieve this desired goal, rather t= han first discussing what requirements are MUST/SHOULD/MAY. And also agree = on this as the goal of a new draft. It may be more effective to have a small targeted draft that says "do m= andatory dual stack parts of RFC 7084; and here is additional transition te= chnology that many small ISPs need to be able to get from their vendors".= =20 We would need a number of smaller ISPs to join in support, if it's to b= e successful. And the set of requirements definitely need to be limited. If that were the focus of the draft, I wouldn't bother including 6rd at= all. =20 > And AT&T has a very large 6rd deployment, so I wouldn't be surprised = to see push back from them on downgrading 6rd to MAY (though perhaps they d= on't much care, idk). =20 At this point, for me, it's a "don't care". When deployment first start= ed, there was a distinct percentage of AT&T customers who had no (and no op= tion for) AT&T-provided CE Router (because of a legacy broadband architectu= re in the southeast US). As I mentioned, RFC 7084 was about retail and not = ISP-procured CE routers -- so having 6rd in retail routers provided these c= ustomers (including me) a way to get 6rd up and running on AT&T. Over the p= ast 1.5 years, AT&T has put FTTH in place for almost all (or maybe by now a= ll) those customers, which means AT&T CE routers are available (and for FTT= H, required). You can't even find the 6rd configuration info on the AT&T we= bsite anymore. [You can still find the info where other people have posted = it. Just not from AT&T.]=20 I do have my own CE router behind the AT&T CE router. The AT&T CE route= r provides a /64 from the 6rd /60 via IA_PD to my router. So it looks to my= router like native IPv6. AT&T configured and enabled 6rd, LAN-side SLAAC, and LAN-side DHCPv6 IA= _PD in the AT&T CE Router, without my doing anything. =20 Barbara =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 Tue Feb 21 23:50: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 55F6112967C for ; Tue, 21 Feb 2017 23:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 lpox4Vl0lwYT for ; Tue, 21 Feb 2017 23:50:48 -0800 (PST) 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 7F248129457 for ; Tue, 21 Feb 2017 23:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487749846; x=1488354646; 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=T/E1H4DRWaNCCRunsvxY+I+QL XEPtfU9yYBjxltw9N8=; b=TVw19RVveudzT24YQYlKWtc8RLlMZLd/vuwsRxna7 9Rhlyot9VhFhJESlJuPGjOtwQuoUPlcrneQ5TcbECGwgRT86xIuVX/G6/TfLCApD W7olARAD4xtQVYww+eXLmWIOxlQ7SMoFSy57rfEK45Go4n5C+FkLuOVApEWNr/e+ Lg= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=oKUSnhUFsEfu2Ajm/+mNOk6V0ZEKEjGBUbNobBRGhGj3kOc/UI7HzydHX3PB HdcJFaSOmNlAsB+s1dj5/WuS50rPI4vkUdXGaOkGpCovFVb408/37CaTQ 8D2bvxzA4oy7sG6EjwNZG2Dvi8YvnG6bfez3wCWkfeRT2r/ABCkvqA=; X-MDAV-Processed: mail.consulintel.es, Wed, 22 Feb 2017 08:50:46 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 22 Feb 2017 08:50:44 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005371662.msg for ; Wed, 22 Feb 2017 08:50:43 +0100 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:170222:md50005371662::UCAoYdnvAIhAHx7a:00005esS X-Return-Path: prvs=1226ba9495=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 22 Feb 2017 08:50:39 +0100 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: <6D46AB66-8FC7-4D2F-8E15-B32BA4139655@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> In-Reply-To: <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 07:50:50 -0000 I tend to agree on that, but also agree that we need to decide if we really= need two or more documents or a single one. The main issue I see is that looking at open-source, HNCP requires 200Kbyte= s of code. It is probably still possible in most of the today routers, so s= hould not be a problem, but it is required in a router for a SME? Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de james woodyatt Responder a: Fecha: martes, 21 de febrero de 2017, 21:21 Para: IPv6 Ops WG Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-= bis-00.txt On Feb 21, 2017, at 01:11, JORDI PALET MARTINEZ wrote: =20 =20 I=E2=80=99ve submitted a -bis draft for updating RFC7084 (Basic Require= ments for IPv6 Customer Edge Routers). =20 =20 =20 =20 =20 =20 I strongly believe that any update to RFC 7084 that doesn=E2=80=99t REQ= UIRE the LAN interfaces to provide HNCP services [RFC 7788] is an incomplet= e update. =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 Wed Feb 22 00:18: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 DE9441294C0 for ; Wed, 22 Feb 2017 00:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=unavailable 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 uPjRnOWZQvrq for ; Wed, 22 Feb 2017 00:18:07 -0800 (PST) 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 8A4F5129541 for ; Wed, 22 Feb 2017 00:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487751020; x=1488355820; 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=QAdIHIYStoNuz/MossYPxnoSu VOKqn/9F6xAZMsRUfU=; b=niP19Zmg+uj5E8XvFWhIh/exh85HtH9kL92OkYVn/ UvomgAa6IuraFbls+ra9flMrwjIqSX+XCKFwg2GH8RNTuQCOYtRgZSYaiUhjk/80 5vURCAJSFHWTRXcC2cTvUjaSn63/k5ITq7VgB0+DJtBv10cfpZif9lDc95uTZZW/ vM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=eSCrlkB3O98dP2VFIVnY4tAfK95koCoF3Pp98y+elEamqlxb1ZJ92CqF/R+w qBbNixyHtM15erIOHPkd+VpRj62NWgukRfnFhpD/A+X7T8N6FRvTGs8t5 qbjRQp2+BJXpgNzLBejnuBR487NFne4+AVbKl+skwvrPx8Qjfv8+D4=; X-MDAV-Processed: mail.consulintel.es, Wed, 22 Feb 2017 09:10:19 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 22 Feb 2017 09:10:19 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005371673.msg for ; Wed, 22 Feb 2017 09:10:18 +0100 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:170222:md50005371673::v1rHzWvg0ZROrb8+:00002J6m X-Return-Path: prvs=1226ba9495=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 22 Feb 2017 09:10:18 +0100 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: Thread-Topic: [v6ops] Requirements for IPv6 routers in various locations References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:18:09 -0000 HI Fred, My initial view on this. I prefer in general a single document. I think 7084 is a good starting poin= t. I look into the reality of the market. Most of the CEs/CPEs that are being sold/installed are used in several scen= arios: 1) Pure residential 2) Residential with small home office 3) Residential/techie (with or w/o home office) that have exported services= (email server, web server, VPN server, etc.). 4) Small home office 5) SMEs with just use Internet for =E2=80=9Cbrowsing=E2=80=9D, emailing, et= c. 6) SMEs as in the previous case that also have exported services (email ser= ver, web server, VPN server, etc.). Those CPEs are in the range of 15USD to 150USD, but even much more expensiv= e (up to 500USD) if they have sophisticated WiFi support. This is very comm= on for gammers. Then we have other cases for big corporates. Those typically use more expen= sive equipment, WiFi with APs, etc. In this case, there is a =E2=80=9Csmart= =E2=80=9D and conscious decision, typically there are engineers that design= the network, or an external company, and decide what equipment they need a= nd what are the required features. I also believe that in many cases, the r= equired features may be the same as for 6 above. I believe the cases that you mention as content providers, data centers, et= c, etc., are probably closer to the big corporates model that I just mentio= n, and to be honest, I don=E2=80=99t know if we need to say what are the re= quirements, as I tend to believe that the market is doing it correctly. We = can just have a section in the document explaining this scenario, but not s= ure if we need a new/different document for this. What James indicated may be not required for 6, but is in the =E2=80=9Climi= t=E2=80=9D. So looking into this, I believe that it will be much better, easier and les= s confusing, to evolve 7084, and if required, include some text/section wit= h possible target scenarios and state there =E2=80=9Cthis may be not requir= ed in this scenario=E2=80=9D (just an example). I believe draft-ali-ipv6rtr has a different scope, but I will need to read = it again to make sure. 7084 seems to be the right place because it has alre= ady a good base of what we intend to do (in my opinion). Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: Fecha: mi=C3=A9rcoles, 22 de febrero de 2017, 2:09 Para: IPv6 Ops WG Asunto: [v6ops] Requirements for IPv6 routers in various locations This argument is essentially what I was referring to with respect to dr= aft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812 didn= 't have to address. They include, at least, ISP, content network, data cent= er, enterprise, residential, IoT, and mobile wireless networks. Those marke= ts have differing non-exclusive sets of requirements. =20 Let me throw a question to the working group. One way to approach this = is to try to push requirements for all of those markets into one document, = which is what I think James is trying to do. Another way is to separate the= m, which is what I think Barbara is trying to do. I'm not going to say that= either is automatically right or automatically wrong, but they are differe= nt, and I have visions of an argument that takes forever, boils blood, and = nobody wins, if we don't systematically address it. =20 I see two approaches that might be considered reasonable. One would be = to add a section about residential networks (which are definitively not ISP= networks, but use routers that might also be used as ISP "customer-edge" r= outers) to the document, stating that it is requirements for routers that m= ight be used within a multi-router residential network including the router= connected to the ISP; the other would be to invite a separate document tha= t addresses residential networks. =20 If we take the latter approach, we might as well also invite separate d= ocuments (or in the former approach, separate sections) describing requirem= ents for IPv6 routers in ISP, content network, data center, enterprise, IoT= , and mobile wireless networks. This might be one of those, and draft-ali m= ight be one of those. I suspect we will find that a lot of the requirements= are in fact common, and could be described in a core document. But I don't= know of any ISPs suggesting the use of HNCP, residential networks discussi= ng RPL, or yada yada yada. =20 Opinions? =20 On Feb 21, 2017, at 4:41 PM, STARK, BARBARA H wrote: >=20 > The charter of v6ops is still doing things that help get IPv6 rolled = out. Which is exactly what these ISPs are asking for help with. Which has n= othing to do with multi-router home network topologies. > =20 > I believe a very targeted document to meet the needs of these ISPs is= what we should be aiming for. > Barbara > =20 > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodya= tt > Sent: Tuesday, February 21, 2017 3:22 PM > To: IPv6 Ops WG > Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-r= fc7084-bis-00.txt > =20 > On Feb 21, 2017, at 01:11, JORDI PALET MARTINEZ wrote: > =20 >> I=E2=80=99ve submitted a -bis draft for updating RFC7084 (Basic Requ= irements for IPv6 Customer Edge Routers). > =20 > I strongly believe that any update to RFC 7084 that doesn=E2=80=99t R= EQUIRE the LAN interfaces to provide HNCP services [RFC 7788] is an incompl= ete update. > =20 > --james woodyatt > =20 > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Feb 22 00: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 E6C4D1294C0 for ; Wed, 22 Feb 2017 00:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 wErc9Li6NppP for ; Wed, 22 Feb 2017 00:18:37 -0800 (PST) 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 80F9D1295E9 for ; Wed, 22 Feb 2017 00:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487751513; x=1488356313; 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=E+koj6BiagekY96/rYJha4SJQ OnOUcF8GwaAWOTVpEc=; b=kLNBBeE0RCjKl+18MNfBcEAx14d4kwT39174K0BA5 EdUbyYCmuHGqOZVobibe1+4GSbj0ac+qhLX4F4+GQlxxNrF8n3tnRFHcjISdqkWj O3Rjoww7c4JTw0jxq2tizrJlXk5nZHgzQpKEST8wDwu76FNyMljKLisshoJ4rwJh 64= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dulzwj4HpASfDDpZQ3kTXVsKIr8t5Q6cxtNbgH7OqEBRrr/qtpdI0kmCyXP0 G52luYynbRBcGQw4zdnvnsLvEUPCVlil+Py3Ins3wxQttIPnXNcjRR+kq H7niDrIpkOBOYTEoA7hHZrF628RVvxcxowrLUKNSXRvdd+4yltes4o=; X-MDAV-Processed: mail.consulintel.es, Wed, 22 Feb 2017 09:18:33 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 22 Feb 2017 09:18:29 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005371678.msg for ; Wed, 22 Feb 2017 09:18:28 +0100 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:170222:md50005371678::WlN3uS3Ffk1bhsk6:00003RXE X-Return-Path: prvs=1226ba9495=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 22 Feb 2017 09:18:25 +0100 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: <65EF9449-6FCC-4666-983F-E33E9812C9F3@consulintel.es> Thread-Topic: [v6ops] Requirements for IPv6 routers in various locations References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:18:39 -0000 Can we define what is a customer edge? Is it different than what I=E2=80=99= ve mention in my previous email: 1) Pure residential 2) Residential with small home office 3) Residential/techie (with or w/o home office) that have exported services= (email server, web server, VPN server, etc.). 4) Small home office 5) SMEs with just use Internet for =E2=80=9Cbrowsing=E2=80=9D, emailing, et= c. 6) SMEs as in the previous case that also have exported services (email ser= ver, web server, VPN server, etc.). In my opinion is the router provided to residential customers, SMEs, etc., = by 95% of the access links in the world and even sold in markets so custome= r can buy a new one if broken or a better one with better WiFi support to r= eplace the one that the ISP deployed. Some ISPs just provide a =E2=80=9Cmodem=E2=80=9D or =E2=80=9Cbridge=E2=80= =9D and is the customer the one that need to buy it. Some ISPs make their own as OEM devices from vendors, or have such volume t= hat get their logo on it and even specific firmware versions. Smaller ISPs need to go to the local market to buy them because they need s= maller quantities and have no way to ask for =E2=80=9Cfeatures=E2=80=9D whi= ch they need. Same as when you buy it in the local store, you will find wha= t is generally available and can=E2=80=99t ask for a special software. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: Fecha: mi=C3=A9rcoles, 22 de febrero de 2017, 2:29 Para: Joe Touch CC: IPv6 Ops WG Asunto: Re: [v6ops] Requirements for IPv6 routers in various locations =20 > On Feb 21, 2017, at 5:17 PM, Joe Touch wrote: >=20 >=20 >=20 > On 2/21/2017 5:09 PM, Fred Baker wrote: >> This argument is essentially what I was referring to with respect to= draft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812 d= idn't have to address. They include, at least, ISP, content network, data c= enter, enterprise, residential, IoT, and mobile wireless networks. Those ma= rkets have differing non-exclusive sets of requirements. > Is there a way to focus on the core requirements that all routers nee= d > to support in this doc, assuming that there are lots of things a rout= er > in general MAY also do... >=20 > And then leave it to other documents to focus on the additional > requirements (or relaxations of SHOULDs) that apply to these environm= ents? =20 There may be; it would be the "core document" I referred to. A document= that is accurately described as "7084-bis" would not be that document; 708= 4 describes a router in a particular application, and probably a particular= price point, something called "customer-edge". _______________________________________________ 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 Feb 22 00:22: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 09BF9129480 for ; Wed, 22 Feb 2017 00:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhuA1_wPyx8R for ; Wed, 22 Feb 2017 00:22:39 -0800 (PST) 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 0A48C1293DF for ; Wed, 22 Feb 2017 00:22:39 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id b129so3822127pgc.2 for ; Wed, 22 Feb 2017 00:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mb2C2vh/2yYENPuXwW12JDL5VBUwWp6OMdc8dKmxBGU=; b=HTG5xMPCuARcZcXVfqjhrYlYI/0GBPokQYmJ3xSA5d2Vv2FI+927oCitDOlRzk7Agu sJEnfZZkIAyQ9Fx7cMa4/LWBbhIs1QsWuoFEMOBRqolX681BhJ6F+ANlscddlqcn6vgh 82UPtktGVKZ/aNzxOwDwDRjJfxR+Xd4A+dvhI4NHkWNML86EKERTtkA2n8hxkMytEfsG 5laA7KYq2zkIEs1FlBKj/sjBgUvSMjOU9Z39jmjPVZNcPu83Tl/LwyqZF/jnAl2zUpZa TKdNqRWKevbiM5vIITcGhSTxCtX36AAMZ8pAJ+dQJOKk4MBW2su4Ka4JqIkgmsxgoc27 NOcw== 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=Mb2C2vh/2yYENPuXwW12JDL5VBUwWp6OMdc8dKmxBGU=; b=i7R7BopR0XL25Rpe28+GNWHG2rOclzNAAcAdMVLA3xl0E2GRHRxdMCcZxy5lHkjRiO fspoo5RLvphnoFM7v0XnsrIZ+TIyyL/gSKlbDoQVVC8uBl0nHRwk7VvWatoy1L2ti38u N38V6e5RllZyBOtG0XvLyd1UaES0Z9LDTLTIVKlFpk0daZKbRJq4LO4c/hfjh9kjwRxf HZoqaqKQStAbo6i1GjmO6MM3WG/rQrUpgojZ0yjXH1Ku5Y59q5Fj+5Qo0FkxnnvYMdBs dapcadidHDV6wy4opBBHUxpxpOW5pNPzrivmm5x7TicsOXLiSvepAFcI6JTIBtxR94Bw /mXw== X-Gm-Message-State: AMke39nQX5aFZI6Wn5EAYOWG8aF48QFlQSgaw7w9f6JO6icKPKYZ/Hsog6FaIkUpsVc6iQ== X-Received: by 10.98.1.213 with SMTP id 204mr38304774pfb.61.1487751758669; Wed, 22 Feb 2017 00:22:38 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id o24sm1801947pfj.78.2017.02.22.00.22.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 00:22:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <0C23A2E7-F41B-4226-A670-1DDDD86956DF@consulintel.es> Date: Wed, 22 Feb 2017 00:22:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7459@GAALPA1MSGUSRBF.ITServices.sbc.com> <0C23A2E7-F41B-4226-A670-1DDDD86956DF@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:22:40 -0000 > On Feb 21, 2017, at 11:47 PM, JORDI PALET MARTINEZ = wrote: >=20 > Not being a native English speaker I really feel that I=E2=80=99m in = the limit to understand correctly what is a =E2=80=9Cretail=E2=80=9D = vendor and what are the other types, so to understand what makes them = different in terms of requirements. I think she is comparing equipment that is sold to an ISP and used in a = managed service (which would be specified by a Cable Labs or Broadband = Forum document) to equipment that is sold in a store, purchased by the = user, and installed by them. I don't know what you have in Spain, but we = have both types of service; the router in my home was purchased by me = and is not managed by my ISP, but AT&T (and other ISPs) have equipment = that they install as part of a service managed by the ISP.= From nobody Wed Feb 22 00:29: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 E35A0129480 for ; Wed, 22 Feb 2017 00:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2FcIxXsy6Q-v for ; Wed, 22 Feb 2017 00:29:18 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8BA1293DF for ; Wed, 22 Feb 2017 00:29:18 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=46590 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cgSIW-0002y7-Fh; Wed, 22 Feb 2017 09:29:16 +0100 Date: Wed, 22 Feb 2017 09:29:16 +0100 From: Tore Anderson To: JORDI PALET MARTINEZ Message-ID: <20170222092916.1f7ae76a@echo.ms.redpill-linpro.com> In-Reply-To: <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> 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: Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:29:20 -0000 Hi Jordi, * JORDI PALET MARTINEZ > So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as > SHOULD. >=20 > In my version: >=20 > 1) Considering that there=E2=80=99re no more IPv4 addresses and according= to > my experience with service providers, they will prefer to avoid dual > stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to > be changed to MAY. >=20 > 2) At the same time, I=E2=80=99ve included lw4o6, also with MAY. The > rationale for this: Many service providers try to avoid the CGN, and > lw4o6 is a way to do so, without increasing the cost of the CE. > Basically, a CE that supports a regular IPv4 NAT+DS-Lite, is already > capable of supporting lw4o6. The cost in terms of CE flash memory for > DS-Lite is about 1Kb. The open source package available for DS-Lite > that I=E2=80=99ve been digging-in takes 6Kb, but already includes also > support for both MAP versions. >=20 > 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those > protocols are the 3 alternatives that a service provider has to > deploy IPv6-only WAN, but at the same time provide dual-stack in the > LANs, with practically the same functionalities or even more, that > what CGN requires. At the service provider network, it requires, > instead of CGN, a stateful NAT64 (which cellular providers are > already using) or a Border Relay (for MAP). Basically, a CE needs > only 3Kbytes of code in the flash to support CLAT (the CE part of > 464XLAT). The support for MAP (both versions and also lw6o4), > requires about 6Kb. >=20 > 4) Include support for 6in4 as SHOULD. The rational for this: > According to my experience, sometimes, business customers (specially > SMEs) are in the same access network as residential ones, but they > are provisioned manually and often require dual-stack with public > IPv4 addresses, because they have to publish external services such > as VPNs, or others that may not yet rely in an IPv6-only network. > I=E2=80=99ve seen cases of service providers with 10.000 customers and 25= 0 of > those =E2=80=9CSMEs=E2=80=9D, and all them are provisioned manually becau= se don=E2=80=99t > make sense to find an automatic configuration. So, I think we must > keep this support, with typically is already available in any > dual-stack router today. In fact, if the router supports 6to4 or 6rd, > the 6in4 support is already there. In terms of flash utilization, > 6in4 requires 1Kb, 6rd 2Kb and 6to4 1Kb. >=20 > So, the questions for the WG: >=20 > Do you agree with my changes 1, 2, 3 and 4 above? I believe this document should not attempt to rank between IPv6 transition technologies. If you say that transition tech Foo is SHOULD while Bar is MAY you're suggesting that Foo is somehow better or more relevant than Bar. The actual ranking of such a list does however depend entirely on the deployment models of the ISPs operating in the market the device is being targeted at. There's no universal ranking here, no single technology that has =C2=ABwon=C2=BB yet. So if you really need to make this =C2=ABIPv6 CE router=C2=BB document almo= st as much about IPv4 as it is about IPv6 by listing all the available transition technologies, the they should all be MAY. Better yet, move them from the normative section into the appendix or a separate document analysing and comparing all the various transition technolgies. > Now a more complex question. Do you think it will be acceptable for 3 > and may be 4 above, to be a MUST instead of just SHOULD? Absolutely not. Tore From nobody Wed Feb 22 00:30: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 357D91294ED for ; Wed, 22 Feb 2017 00:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DtNxZB1kV8Na for ; Wed, 22 Feb 2017 00:30:09 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D36A129444 for ; Wed, 22 Feb 2017 00:30:09 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E676F615AF for ; Wed, 22 Feb 2017 09:30:05 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id B5AA2615D2; Wed, 22 Feb 2017 09:30:05 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id B227937BF1; Wed, 22 Feb 2017 09:30:05 +0100 (CET) Date: Wed, 22 Feb 2017 09:30:05 +0100 From: Gert Doering To: james woodyatt Message-ID: <20170222083005.GK2367@Space.Net> References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:30:11 -0000 Hi, On Tue, Feb 21, 2017 at 12:21:39PM -0800, james woodyatt wrote: > I strongly believe that any update to RFC 7084 that doesn???t REQUIRE the LAN interfaces to provide HNCP services [RFC 7788] is an incomplete update. Seconded. This is the way to go. 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 Feb 22 00:49: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 7416B129690 for ; Wed, 22 Feb 2017 00:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 6l9pRQMHR7zS for ; Wed, 22 Feb 2017 00:49:12 -0800 (PST) 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 DD2BF1294ED for ; Wed, 22 Feb 2017 00:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487753344; x=1488358144; 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=eN+H6fW5ohQ7f2ikQ7fi0dpU8 pCzH9bGlxaw783wTq4=; b=RtwcJAIbPxievt2no415Pk+V2wlHOn8JRSZTMjGB4 NHUSbmKpSBzIG9uccShT+MlrEIBTS41w2SvV0aRZwd7prnMnT1oCvkAGstCJQKu9 bJrwb5P7mKQWxXJE8a7Bs0NBZ/gX1ozqkbsDhUZBEJ/Qm+ClFS2chNcv61ja8Jga 6c= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=FoBL/6q8HbIU1NKgcuqQyHkNf2W1Qq/kqAJQuILuIWosWg0qj2nE7Ix/4VHS Hi90GxlUO6Wyy1o5mnpI5mJ3UU5AmccECFY2+bScpf7iTYlpugTrnjAVC TSTSqa7z8syggnmMz0Q9WQdR1+MeSZuF/lq51MLYhFGCcicX9RpVKQ=; X-MDAV-Processed: mail.consulintel.es, Wed, 22 Feb 2017 09:49:04 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 22 Feb 2017 09:49:04 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005371698.msg for ; Wed, 22 Feb 2017 09:49:03 +0100 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:170222:md50005371698::e8450GG08PsV3JHN:00008jtL X-Return-Path: prvs=1226ba9495=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 22 Feb 2017 09:49:01 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <81E963D6-95A1-4922-B292-3A6C4CD39D97@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7459@GAALPA1MSGUSRBF.ITServices.sbc.com> <0C23A2E7-F41B-4226-A670-1DDDD86956DF@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:49:13 -0000 I think vendors don=E2=80=99t see this as different equipment. I=E2=80=99m working in all the RIR regions, not just Spain, and most of my = customers are small and medium ISPs; some are big ones. All them follow the model I mention before. If they place big orders, they = speak directly to the CPE manufacturer, sometimes they agree on specific fi= rmware modifications. But in all the cases, end-users can buy their own CPE, replace the one prov= ided by the ISP, or setup the one from the ISP in =E2=80=9Cbridge=E2=80=9D = mode and use their own behind the ISP one. I don=E2=80=99t think vendors make a difference, in fact, all the routers t= hat up to now I=E2=80=99ve seen provided and managed by the ISPs, can be al= so acquired in retail stores, Internet, etc. (sometimes same product differ= ent label). In all my customers and all what I=E2=80=99ve seen up to now, even if this = CPE is managed, this management can be disable by the users, because they h= ave the legal right to do so (if we want to go to that point). They just ne= ed to use the same parameters/protocols as the original ISP supplied device= was having (or as said have it configured in bridge mode). So the point here is: I don=E2=80=99t think the vendors do different things= for the products that go directly to the ISP and the retail market. Someti= mes the difference is only that the products for the ISP have =E2=80=9Csome= extra=E2=80=9D functions or come pre-configured in some way, so I don=E2= =80=99t see we need to have different documents. Moreover, ISPs talking to vendors (usually big ISPs) will take 7084 (or a p= ossible successor), as a starting point (as they do today), and ask the man= ufacturer to add what they need (even if it is not =E2=80=9Cstandard=E2=80= =9D). Saludos, Jordi =20 -----Mensaje original----- De: Fred Baker Responder a: Fecha: mi=C3=A9rcoles, 22 de febrero de 2017, 9:22 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-= bis-00.txt =20 > On Feb 21, 2017, at 11:47 PM, JORDI PALET MARTINEZ wrote: >=20 > Not being a native English speaker I really feel that I=E2=80=99m in = the limit to understand correctly what is a =E2=80=9Cretail=E2=80=9D vendor= and what are the other types, so to understand what makes them different i= n terms of requirements. =20 I think she is comparing equipment that is sold to an ISP and used in a= managed service (which would be specified by a Cable Labs or Broadband For= um document) to equipment that is sold in a store, purchased by the user, a= nd installed by them. I don't know what you have in Spain, but we have both= types of service; the router in my home was purchased by me and is not man= aged by my ISP, but AT&T (and other ISPs) have equipment that they install = as part of a service managed by the ISP. =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 Feb 22 00:55: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 851591293DF for ; Wed, 22 Feb 2017 00:55:10 -0800 (PST) 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 header.b=QaG3RZ+c; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com header.b=glIo1jXx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdMQQU2_pDol for ; Wed, 22 Feb 2017 00:55:05 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A5F129692 for ; Wed, 22 Feb 2017 00:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1487753702; bh=Hn8/TRC6RhPj3dJl0/MXATc/Xy0cffChCcl0OxEXUJM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QaG3RZ+c7E22KzfChai4qCATwBN5TMSa1Pkqq/ZQl86N1EsJMDFa0ATqQjx5EPKzpXiWinfxwx9qlJ6z69dWATLiBJ5NNocKAjfqIbRuY1qD1t+rfzD7F5C3ADOg/wcSruxeR7zIM5D9Xqplqp/57HRoFgVdOLMHegvpBCUYcvU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hn8/TRC6RhPj3dJl0/MXATc/Xy0cffChCcl0OxEXUJM=; b=glIo1jXx/ogd0o/RJErV09Jmn3thxH9pTUxlzvmLwgwygEueKmPbw5IRe7A/hcfaF68fJfQAZfOXLzkLU8bePo2wQ+UdLbOVk+5ZFShaAM8bd/5j9hV0Ilm8RGVsAowvUrRT0tYL/TsABLOBceJj1r5j69fKtiu8VyKGhMtULe4= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0245.outbound.protection.outlook.com [213.199.154.245]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-88-_vxF_zRvMwWfXgg51TvtOw-1; Wed, 22 Feb 2017 08:54:56 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Wed, 22 Feb 2017 08:54:54 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e911:6bac:9832:3857]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e911:6bac:9832:3857%14]) with mapi id 15.01.0933.011; Wed, 22 Feb 2017 08:54:54 +0000 From: Tim Chown To: "jordi.palet@consulintel.es" Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt Thread-Index: AQHSjErmrfnJlR21KESvvZHHQ3NOt6FzvufggADocQCAAAm3AIAAB2GAgAABpQA= Date: Wed, 22 Feb 2017 08:54:54 +0000 Message-ID: <3F6FAA87-16F2-4E8D-82CC-1682FFF3EAEB@jisc.ac.uk> References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7459@GAALPA1MSGUSRBF.ITServices.sbc.com> <0C23A2E7-F41B-4226-A670-1DDDD86956DF@consulintel.es> <81E963D6-95A1-4922-B292-3A6C4CD39D97@consulintel.es> In-Reply-To: <81E963D6-95A1-4922-B292-3A6C4CD39D97@consulintel.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: b9e8e6fd-9675-4dbe-92b9-08d45b0078b8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1138; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:jaRoZ23EAAXenm4sp5t6dw7zHO8sUZf2Jyp+7BJUy34/Ro1lteQxMYVpST7KYRGN/DzDajrni9IsVEWNlsh/auhgp3FALB2+gpLlpGL0nNvKdKevBWuZYseFWYUxdWkDp58xxvpvEHePvwXUBLU0Jwinsu3/1if6fhpKMhJNfP7z5UB0wYVcvqp0i4g8XwVAjieQiBvyxgjZzUeh+g+ebHR26QJKEi1STgAaj+pzAMiaWjQp8WAf6ZpgZXdeuUN6jVfbVLAkZjU1ii0GymfvV/d/TJJ6Nm+Xevj7aDwIOZyZKocy2GCm4iSGNos7lKbVexZENf+wJOh/1rpFjcRT9A==; 20:g73XtnSgOdDi32pVYxR41sWQYUUqDAz0MjuOVXb7CmqmsW589eibkEpQhv2f1OY7+25xGuv99ybNRkdLOyngQeS7MASaTcjeIGvCvr36n1xWd92R0f2nBxhLyLHjl7vR/VIJeQyCUfOl5+xQ7Epx6Trz232i2d7gz/D3n6rDryQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(122424002)(377454003)(59124004)(68736007)(6246003)(966004)(38730400002)(230783001)(110136004)(53386004)(7110500001)(7736002)(2900100001)(189998001)(74482002)(106116001)(53546006)(106356001)(33656002)(93886004)(5250100002)(50986999)(105586002)(101416001)(2351001)(2501003)(305945005)(5890100001)(53936002)(76176999)(36756003)(50226002)(8936002)(81156014)(83716003)(5660300001)(99286003)(6306002)(2906002)(4326007)(6512007)(229853002)(6116002)(3846002)(102836003)(2420400007)(10710500007)(6506006)(6436002)(6486002)(42882006)(57306001)(2950100002)(6916009)(15650500001)(8676002)(97736004)(81166006)(82746002)(86362001)(3280700002)(3660700001)(92566002)(66066001)(5640700003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2017 08:54:54.8009 (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: _vxF_zRvMwWfXgg51TvtOw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:55:10 -0000 SGksDQoNCj4gT24gMjIgRmViIDIwMTcsIGF0IDA4OjQ5LCBKT1JESSBQQUxFVCBNQVJUSU5FWiA8 am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+IHdyb3RlOg0KPiANCj4gSSB0aGluayB2ZW5kb3Jz IGRvbuKAmXQgc2VlIHRoaXMgYXMgZGlmZmVyZW50IGVxdWlwbWVudC4NCj4gDQo+IEnigJltIHdv cmtpbmcgaW4gYWxsIHRoZSBSSVIgcmVnaW9ucywgbm90IGp1c3QgU3BhaW4sIGFuZCBtb3N0IG9m IG15IGN1c3RvbWVycyBhcmUgc21hbGwgYW5kIG1lZGl1bSBJU1BzOyBzb21lIGFyZSBiaWcgb25l cy4NCj4gDQo+IEFsbCB0aGVtIGZvbGxvdyB0aGUgbW9kZWwgSSBtZW50aW9uIGJlZm9yZS4gSWYg dGhleSBwbGFjZSBiaWcgb3JkZXJzLCB0aGV5IHNwZWFrIGRpcmVjdGx5IHRvIHRoZSBDUEUgbWFu dWZhY3R1cmVyLCBzb21ldGltZXMgdGhleSBhZ3JlZSBvbiBzcGVjaWZpYyBmaXJtd2FyZSBtb2Rp ZmljYXRpb25zLg0KPiANCj4gQnV0IGluIGFsbCB0aGUgY2FzZXMsIGVuZC11c2VycyBjYW4gYnV5 IHRoZWlyIG93biBDUEUsIHJlcGxhY2UgdGhlIG9uZSBwcm92aWRlZCBieSB0aGUgSVNQLCBvciBz ZXR1cCB0aGUgb25lIGZyb20gdGhlIElTUCBpbiDigJxicmlkZ2XigJ0gbW9kZSBhbmQgdXNlIHRo ZWlyIG93biBiZWhpbmQgdGhlIElTUCBvbmUuDQo+IA0KPiBJIGRvbuKAmXQgdGhpbmsgdmVuZG9y cyBtYWtlIGEgZGlmZmVyZW5jZSwgaW4gZmFjdCwgYWxsIHRoZSByb3V0ZXJzIHRoYXQgdXAgdG8g bm93IEnigJl2ZSBzZWVuIHByb3ZpZGVkIGFuZCBtYW5hZ2VkIGJ5IHRoZSBJU1BzLCBjYW4gYmUg YWxzbyBhY3F1aXJlZCBpbiByZXRhaWwgc3RvcmVzLCBJbnRlcm5ldCwgZXRjLiAoc29tZXRpbWVz IHNhbWUgcHJvZHVjdCBkaWZmZXJlbnQgbGFiZWwpLg0KPiANCj4gSW4gYWxsIG15IGN1c3RvbWVy cyBhbmQgYWxsIHdoYXQgSeKAmXZlIHNlZW4gdXAgdG8gbm93LCBldmVuIGlmIHRoaXMgQ1BFIGlz IG1hbmFnZWQsIHRoaXMgbWFuYWdlbWVudCBjYW4gYmUgZGlzYWJsZSBieSB0aGUgdXNlcnMsIGJl Y2F1c2UgdGhleSBoYXZlIHRoZSBsZWdhbCByaWdodCB0byBkbyBzbyAoaWYgd2Ugd2FudCB0byBn byB0byB0aGF0IHBvaW50KS4gVGhleSBqdXN0IG5lZWQgdG8gdXNlIHRoZSBzYW1lIHBhcmFtZXRl cnMvcHJvdG9jb2xzIGFzIHRoZSBvcmlnaW5hbCBJU1Agc3VwcGxpZWQgZGV2aWNlIHdhcyBoYXZp bmcgKG9yIGFzIHNhaWQgaGF2ZSBpdCBjb25maWd1cmVkIGluIGJyaWRnZSBtb2RlKS4NCj4gDQo+ IFNvIHRoZSBwb2ludCBoZXJlIGlzOiBJIGRvbuKAmXQgdGhpbmsgdGhlIHZlbmRvcnMgZG8gZGlm ZmVyZW50IHRoaW5ncyBmb3IgdGhlIHByb2R1Y3RzIHRoYXQgZ28gZGlyZWN0bHkgdG8gdGhlIElT UCBhbmQgdGhlIHJldGFpbCBtYXJrZXQuIFNvbWV0aW1lcyB0aGUgZGlmZmVyZW5jZSBpcyBvbmx5 IHRoYXQgdGhlIHByb2R1Y3RzIGZvciB0aGUgSVNQIGhhdmUg4oCcc29tZSBleHRyYeKAnSBmdW5j dGlvbnMgb3IgY29tZSBwcmUtY29uZmlndXJlZCBpbiBzb21lIHdheSwgc28gSSBkb27igJl0IHNl ZSB3ZSBuZWVkIHRvIGhhdmUgZGlmZmVyZW50IGRvY3VtZW50cy4NCj4gDQo+IE1vcmVvdmVyLCBJ U1BzIHRhbGtpbmcgdG8gdmVuZG9ycyAodXN1YWxseSBiaWcgSVNQcykgd2lsbCB0YWtlIDcwODQg KG9yIGEgcG9zc2libGUgc3VjY2Vzc29yKSwgYXMgYSBzdGFydGluZyBwb2ludCAoYXMgdGhleSBk byB0b2RheSksIGFuZCBhc2sgdGhlIG1hbnVmYWN0dXJlciB0byBhZGQgd2hhdCB0aGV5IG5lZWQg KGV2ZW4gaWYgaXQgaXMgbm90IOKAnHN0YW5kYXJk4oCdKS4NCg0KSXQgc2VlbXMgb25lIG9wdGlv biB0byBpcyB0byBoYXZlIGEgYmFzZSBkb2N1bWVudCAod2hpY2ggbWlnaHQgYmUgNzA4NC1iaXMp IGFuZCB0aGVuIGhhdmUgYSBkb2N1bWVudCB0aGF0IHByZXNlbnRzIGRlcGxveW1lbnQgc2NlbmFy aW9zIGFuZCByZWNvbW1lbmRzIHNwZWNpZmljIGZ1bmN0aW9uYWxpdHkgZm9yIHRob3NlIHNjZW5h cmlvcy4gRm9yIGV4YW1wbGUsIEhOQ1AgaXMgY2VydGFpbmx5IGltcG9ydGFudCBpbiBzb21lIHNj ZW5hcmlvcy4gU3VjaCBhIGNvbXBsZW1lbnRhcnkgZG9jdW1lbnQgY291bGQgYWxzbyBjaXRlIHRo ZSBzb3VyY2VzIEJhcmJhcmEgcmVmZXJzIHRvLiBUaGlzIG1pZ2h0IGFsc28gYmUgYSB3YXkgdG8g cHJlc2VudCB0aGUg4oCcdHJhbnNpdGlvbuKAnSBtZWNoYW5pc21zIGluIGEgbW9yZSBjb2hlcmVu dCB3YXkuDQoNClRpbQ0KDQo+IFNhbHVkb3MsDQo+IEpvcmRpDQo+IA0KPiANCj4gLS0tLS1NZW5z YWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6IEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWls LmNvbT4NCj4gUmVzcG9uZGVyIGE6IDxmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+DQo+IEZlY2hh OiBtacOpcmNvbGVzLCAyMiBkZSBmZWJyZXJvIGRlIDIwMTcsIDk6MjINCj4gUGFyYTogSk9SREkg UEFMRVQgTUFSVElORVogPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0KPiBDQzogInY2b3Bz QGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQo+IEFzdW50bzogUmU6IFt2Nm9wc10gTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wYWxldC12Nm9wcy1yZmM3MDg0LWJpcy0wMC50 eHQNCj4gDQo+IA0KPj4gT24gRmViIDIxLCAyMDE3LCBhdCAxMTo0NyBQTSwgSk9SREkgUEFMRVQg TUFSVElORVogPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPiB3cm90ZToNCj4+IA0KPj4gTm90 IGJlaW5nIGEgbmF0aXZlIEVuZ2xpc2ggc3BlYWtlciBJIHJlYWxseSBmZWVsIHRoYXQgSeKAmW0g aW4gdGhlIGxpbWl0IHRvIHVuZGVyc3RhbmQgY29ycmVjdGx5IHdoYXQgaXMgYSDigJxyZXRhaWzi gJ0gdmVuZG9yIGFuZCB3aGF0IGFyZSB0aGUgb3RoZXIgdHlwZXMsIHNvIHRvIHVuZGVyc3RhbmQg d2hhdCBtYWtlcyB0aGVtIGRpZmZlcmVudCBpbiB0ZXJtcyBvZiByZXF1aXJlbWVudHMuDQo+IA0K PiAgICBJIHRoaW5rIHNoZSBpcyBjb21wYXJpbmcgZXF1aXBtZW50IHRoYXQgaXMgc29sZCB0byBh biBJU1AgYW5kIHVzZWQgaW4gYSBtYW5hZ2VkIHNlcnZpY2UgKHdoaWNoIHdvdWxkIGJlIHNwZWNp ZmllZCBieSBhIENhYmxlIExhYnMgb3IgQnJvYWRiYW5kIEZvcnVtIGRvY3VtZW50KSB0byBlcXVp cG1lbnQgdGhhdCBpcyBzb2xkIGluIGEgc3RvcmUsIHB1cmNoYXNlZCBieSB0aGUgdXNlciwgYW5k IGluc3RhbGxlZCBieSB0aGVtLiBJIGRvbid0IGtub3cgd2hhdCB5b3UgaGF2ZSBpbiBTcGFpbiwg YnV0IHdlIGhhdmUgYm90aCB0eXBlcyBvZiBzZXJ2aWNlOyB0aGUgcm91dGVyIGluIG15IGhvbWUg d2FzIHB1cmNoYXNlZCBieSBtZSBhbmQgaXMgbm90IG1hbmFnZWQgYnkgbXkgSVNQLCBidXQgQVQm VCAoYW5kIG90aGVyIElTUHMpIGhhdmUgZXF1aXBtZW50IHRoYXQgdGhleSBpbnN0YWxsIGFzIHBh cnQgb2YgYSBzZXJ2aWNlIG1hbmFnZWQgYnkgdGhlIElTUC4NCj4gDQo+IA0KPiANCj4gDQo+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gSVB2NCBpcyBv dmVyDQo+IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiBodHRwOi8vd3d3 LmNvbnN1bGludGVsLmVzDQo+IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ryb25p YyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9y IGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcs IGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24s IGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCj4gDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMg bWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From nobody Wed Feb 22 02:00: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 4671F1296C5 for ; Wed, 22 Feb 2017 02:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 22_hx2vvoMKD for ; Wed, 22 Feb 2017 02:00:05 -0800 (PST) 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 6422F1296B4 for ; Wed, 22 Feb 2017 02:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487757602; x=1488362402; 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=H0RSprjEvPlYim0lIRYvn3h9f +IisHhjZlLgtnPcdy4=; b=U7Vdo/fsUyGfhwub1gk/+quHe7hPWTfFxexX3abT1 6cPBXZ98pxKheTadYaBqASvHE6eLJMw/hKf9Rst6Jtl39+y++4uGrM5pXdwc1x7q KckNbV+pBW9o4PZ9Pp/ki1vo0jAXnsTJxMbjEEX5PFghvqpcsl6edswnMtv6xBRd XA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=fPUjGk3E1oeoCa4mp4eNHMQc1FnZp2/0L+jgU89J3tCqsB5H94bi0MDIHk1c zntAsNM37DWyajzca+idztTDOyWs4HqDv/93/gdl0dybpttBmQmKLKpTn TqcW4T0RhqyM8BwyuTOxN8ZpJDzcS7WBp6rs9gzP5LVwuT/cbI7h0w=; X-MDAV-Processed: mail.consulintel.es, Wed, 22 Feb 2017 11:00:02 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 22 Feb 2017 10:59:59 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005371869.msg for ; Wed, 22 Feb 2017 10:59:57 +0100 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:170222:md50005371869::g65uKrZK8an9h7yE:00000jXZ X-Return-Path: prvs=1226ba9495=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 22 Feb 2017 10:59:55 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <40AD9A16-3B48-4D93-A593-1393754EE4E5@consulintel.es> Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 10:00:07 -0000 Hi Mikael, You=E2=80=99re right, this should be included as part of the requirements, = even if we don=E2=80=99t go for new transition mechanisms in a RFC7084, a = =E2=80=93bis version is needed for DS-LITE to support that. While reading the document I=E2=80=99m wondering if anyone believes there i= s a need for a new DHCP option for 464XLAT configuration with DHCPv6. I don= =E2=80=99t think so, because in this case, all the =E2=80=9Cinfo=E2=80=9D i= s provided via the DNS64 responses, but I may be missing something. Anyone = having a different view? Regards, Jordi =20 -----Mensaje original----- De: Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Responder a: Fecha: martes, 21 de febrero de 2017, 14:23 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7= 084-bis-00.txt =20 Hi, =20 another potential mechanism to be included in 7084bis. =20 https://tools.ietf.org/html/rfc8026 =20 This should probably be supported by a 7084bis device. If there are=20 mechanisms in 7084bis not in RFC8026, that should probably be added. =20 Also, please do not downgrade MUST requirements in 7084 to anything les= s=20 in 7084bis. That means an ISP supporting for instance DS.lite can have= =20 reasonable "trust" in that a 7084bis device will still support this. =20 We don't want to drive ISPs to support all/most mechanisms just because= =20 the CEs don't support at least one mandatory one (and that this changed= =20 over time). =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 Wed Feb 22 12:09: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 114F6129AB3 for ; Wed, 22 Feb 2017 12:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8w8MYfU3_Snl for ; Wed, 22 Feb 2017 12:09:51 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AAA129A98 for ; Wed, 22 Feb 2017 12:09:51 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id z128so5018042pgb.0 for ; Wed, 22 Feb 2017 12:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ChAca7crkd10hnKGd/LbykNIJEXTxmcvTkLn3VKP3DU=; b=YrMuSRV/KyEJzSknaydn0mwE6k6qZ6d5rd7Gx4JDIe1u15+Q8YuKgjSEB1VzpQTmFZ ah/u21VGvNYxcuJGQrkcCCfXOcHG9MS9QKAjBpK2tsyWtg00j/fpnX9g35nIhBSOJ+zC vNOJZGRxvUIVRGIriGwB18h1DGvodMV2iN48jMHaVqcHfYZg1gORlb3U5qHyAsqi3qa9 R0PDvMsV9pSZUiNpGDF43rp2anWGxQFfSe0JHFh2zFK+mY5DfspsOMUmDLjXS66RpJgc wWohfdOUM1zspUTBuzvE75vAu7En59b8sP1On2Yq0VI2TAIo3e8s3kz5lww2EkZERxKu vHcQ== 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=ChAca7crkd10hnKGd/LbykNIJEXTxmcvTkLn3VKP3DU=; b=C1iGEn0O0UGtUEyEl6Ki4whpFTb3TNy9D2F7Cb48Dif/u4nkV3FSMT8gPCfqlkGYhh cnxgBekqTSuclU8csDTz67Zqw6WPzRk8w/VOItuZEod1e2eAG8rc1IE4I/qVYiqJOxH5 02D6i5YzMKs36aPe5aDxjb8l8qs9/IjTGkpCA1VJMnOR1VYVIK0AaDP+Jo+v6983veR3 3YsoByMrOiJ4/X5pu+xfykbl8ERGEhFbYMx7GSiBXFtysYyrFvTn3IY4iL95ehB2DZdv Jzz/93T+Cdgbl4SwfmKU93kgEymzLqS4ICSTywclj5pxfcakLqE4iDcYisZuIjGe/PWN QtEA== X-Gm-Message-State: AMke39nU5bld7cuwDv7hxoLYT2UzBjw9PPUQsiYDR9xMkoTH+UgYnfRbrHBDtM1rf74uBs5d X-Received: by 10.99.172.88 with SMTP id z24mr39851273pgn.12.1487794190677; Wed, 22 Feb 2017 12:09:50 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id q64sm5297535pga.0.2017.02.22.12.09.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 12:09:50 -0800 (PST) From: james woodyatt Message-Id: <19187C71-2C50-4C8E-AA2B-006FA7E573F3@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8CEAAF1D-3310-466C-A5E9-6D6FE4476C47" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 22 Feb 2017 12:09:48 -0800 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:09:53 -0000 --Apple-Mail=_8CEAAF1D-3310-466C-A5E9-6D6FE4476C47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 21, 2017, at 16:41, STARK, BARBARA H wrote: >=20 > Sorry, James, I disagree. > The charter of v6ops is still doing things that help get IPv6 rolled = out. Which is exactly what these ISPs are asking for help with. Which = has nothing to do with multi-router home network topologies. > =20 > I believe a very targeted document to meet the needs of these ISPs is = what we should be aiming for. Hi Barbara, Please let me explain why that posture actually makes the roll out of = IPv6 more difficult rather than less difficult. Consider the case of = Thread=E2=84=A2 border routers, which I am involved in the process of = defining the best practices for implementation in the Thread Group. = > The networks behind these border routers are IPv6-only. They are 6LoWPAN = mesh networks. They are typically implemented in devices that join home = LAN segments with Wi-Fi=E2=84=A2. If IETF updates RFC 7084 without including a strong recommendation to = provide HNCP services on the LAN interfaces, it will serve as a very = strong signal to groups like Thread=E2=84=A2, which are currently = working on such border routers, that IETF does not believe routers = serving residential subnets should be provisioned with sufficient = address space to support downstream routers, like Thread=E2=84=A2 border = routers. That=E2=80=99s a big deal. It will have serious consequences. People working on this stuff here at Google currently observe in the = wild IPv6 home gateways, presumably RFC 7084 ones, that do not respond = positively to DHCP-PD requests, either because they do not receive = delegations of more space than a single /64 from service providers, or = they do not have sufficient remaining space to respond positively to = DHCP-PD requests because all the prefix space has been consumed by other = clients. So, how does one imagine such border routers will make hosts on those = IPv6-only links behind them reachable via the public IPv6 Internet? = There are several alternatives available in the event that RFC 7084 is = updated without a recommendation to implement HNCP. Here are some ideas = that I=E2=80=99m seeing my colleagues=E2=80=94 experts in the field=E2=80=94= seriously promote as things that SHOULD be done in that event: 1. Use NAT66 (not NPTv6, NAT66 with address and port translation) to = masquerade the entire mesh behind the border router as the same IPv6 = host on the home LAN segment (my hunch is this is the most likely = alternative to be implemented, not the least, and for reasons that are = very difficult to counter). 2. Use ND Proxy to masquerade the entire mesh behind the border router = as the same Wi-Fi MAC address (this has problems related to = interoperability with various Wi-Fi implementations, and it makes some = people I know nervous, hence the attraction to NAT66 which trades those = problems for more familiar problems already well understood in the IPv4 = world). 3. Use NAT64+DNS64 to masquerade the entire mesh behind the border = router as the same IPv4 host on the home LAN and just forget entirely = about IPv6 (this is a required capability for dealing with IPv4-only = service providers, which do still exist, sadly, and the idea we are = considering here is to just never bother doing more than NAT64+DNS64 and = therefore hope the whole IPv6 on the public Internet just blows over). I don=E2=80=99t know about the rest of the V6OPS working group, but I = think all three of these alternatives are terrible for everyone. Hence, = it would be better if RFC 7084 is updated to include a strong = recommendation to implement the HOMENET protocols. Just my 0.02 euros, = your mileage may vary, offer not valid in the Bear Flag Republic. Barbara, and anyone else taking a similar view, please please please = reconsider your position. --james woodyatt > --Apple-Mail=_8CEAAF1D-3310-466C-A5E9-6D6FE4476C47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 21, 2017, at 16:41, STARK, BARBARA H <bs7652@att.com> = wrote:

Sorry, James, I disagree.
The charter of v6ops is still doing things that help get IPv6 = rolled out. Which is exactly what these ISPs are asking for help with. = Which has nothing to do with multi-router home network topologies.
 
I believe a very targeted document to meet the = needs of these ISPs is what we should be aiming = for.

Hi = Barbara,

Please let me explain why = that posture actually makes the roll out of IPv6 more difficult rather = than less difficult. Consider the case of Thread=E2=84=A2 border = routers, which I am involved in the process of defining the best = practices for implementation in the Thread Group.


The networks behind = these border routers are IPv6-only. They are 6LoWPAN mesh networks. They = are typically implemented in devices that join home LAN segments with = Wi-Fi=E2=84=A2.

If IETF updates RFC 7084 without including a strong = recommendation to provide HNCP services on the LAN interfaces, it will = serve as a very strong signal to groups like Thread=E2=84=A2, which are = currently working on such border routers, that IETF does not believe = routers serving residential subnets should be provisioned with = sufficient address space to support downstream routers, like Thread=E2=84=A2= border routers.

That=E2=80=99s a big deal. It will have serious = consequences.

People working on this stuff here at Google currently observe = in the wild IPv6 home gateways, presumably RFC 7084 ones, that do not = respond positively to DHCP-PD requests, either because they do not = receive delegations of more space than a single /64 from service = providers, or they do not have sufficient remaining space to respond = positively to DHCP-PD requests because all the prefix space has been = consumed by other clients.

So, how does one imagine such border routers will make hosts = on those IPv6-only links behind them reachable via the public IPv6 = Internet? There are several alternatives available in the event that RFC = 7084 is updated without a recommendation to implement HNCP. Here are = some ideas that I=E2=80=99m seeing my colleagues=E2=80=94 experts in the = field=E2=80=94 seriously promote as things that SHOULD be done in that = event:

1. Use = NAT66 (not NPTv6, NAT66 with address and port translation) to masquerade = the entire mesh behind the border router as the same IPv6 host on the = home LAN segment (my hunch is this is the most likely alternative to be = implemented, not the least, and for reasons that are very difficult to = counter).

2. = Use ND Proxy to masquerade the entire mesh behind the border router as = the same Wi-Fi MAC address (this has problems related to = interoperability with various Wi-Fi implementations, and it makes some = people I know nervous, hence the attraction to NAT66 which trades those = problems for more familiar problems already well understood in the IPv4 = world).

3. Use = NAT64+DNS64 to masquerade the entire mesh behind the border router as = the same IPv4 host on the home LAN and just forget entirely about IPv6 = (this is a required capability for dealing with IPv4-only service = providers, which do still exist, sadly, and the idea we are considering = here is to just never bother doing more than NAT64+DNS64 and therefore = hope the whole IPv6 on the public Internet just blows over).

I don=E2=80=99t know = about the rest of the V6OPS working group, but I think all three of = these alternatives are terrible for everyone. Hence, it would be better = if RFC 7084 is updated to include a strong recommendation to implement = the HOMENET protocols. Just my 0.02 euros, your mileage may vary, offer = not valid in the Bear Flag Republic.

Barbara, and anyone else taking a = similar view, please please please reconsider your position.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_8CEAAF1D-3310-466C-A5E9-6D6FE4476C47-- From nobody Thu Feb 23 03: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 1EEEA1296C3 for ; Thu, 23 Feb 2017 03:07:55 -0800 (PST) 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=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 Fa1P7WmnELhz for ; Thu, 23 Feb 2017 03:07:52 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40137.outbound.protection.outlook.com [40.107.4.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0463B129480 for ; Thu, 23 Feb 2017 03:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GkSZShgneiOVmwd1IGgLb4zjxaG4CMrxWhQ02PvIrj4=; b=XtuAK2fZRnyzPNiHrOzM8fBiaP826cVETJDBjCKLZT1BSxAWmfQb32H7AZYi4qlDFZahzefj2JmevjwTGUbabhXk9QKU7RqdtIlFttEsp9W9W110YBqDevfIuPA64OleCfkfeUM+gjylhOg9AxzsGq/ti7Mh47P98IK6iokmwPc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by HE1PR0701MB3001.eurprd07.prod.outlook.com (10.168.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Thu, 23 Feb 2017 11:07:49 +0000 Message-ID: <050c01d28dc4$afe39600$4001a8c0@gateway.2wire.net> From: t.petch To: Fred Baker , IPv6 Ops WG References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 23 Feb 2017 11:04:36 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: AM4PR0101CA0064.eurprd01.prod.exchangelabs.com (10.165.22.160) To HE1PR0701MB3001.eurprd07.prod.outlook.com (10.168.93.135) X-MS-Office365-Filtering-Correlation-Id: 19cf8e3a-368e-43e5-54b2-08d45bdc34a2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 3:pQDhHl2U6mKbarraat6kQZyxc0PXAdHeFCTwTRxXf8NxOi0ktm2ev6jeLkQBwomlA1FI2DY8DJYKDjPlVScDYcGEtPX04M7vgr2qtUCTela3wWKDjMrvYLs66a8eH64kJ+upyH5HTXMfAvrrHmG4QiyqB2jHo/sCIKLU39OvhN74a1D/5KYSiYx+y2r/mEaVlEpkbU8YXofbLGpnLOYrtAdHu6X+toxduY7NgPQEWKyPbX0gHSumK+pdXYYF3+UF3YNBkgZkS2LGV/qUs6AgSQ==; 25:Q18fH/ouxhN/zb8VhzDBPsDoeGovr8KTTmRujjYsGyk9DR+zIf78eiEsX1XGsRqLHIKzmHp5fFGr+IIF7nXchEr/OO4I134nj/2PoZ6+Swj7D7to3+92oNYrl3wbGg/JATqm4YLjtigBakLVWL1Uss4jNSdMz9wixbALhNwrUg1pNXz6XKOmqlI5oZ2cAAn1RJlQPTBQXbEHknloaGXDTBCmpOOjX6XSPITGAsQZQheUNwFGdYsGXFQdxRWj7cKFs5Lv1NX6c4iW6Ira1/KELbJzXcmrXN8lBcFiDG/rSyNu8/1yM9+3cHxOsHxVG2+ZOV8EFSkB8tNR0d87c6x3crWK4yC6GEVa47GftqWeZRKYbg7Gsfbs0cs5WFsgovBlpgBYrbRXS52JYrgQtvQAEMbQlz3cYIa5Oadu+eATEcvFP+5HfM3a3e2uaZOZkocA3O++rV6OyRjBrpr10ftJxg== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 31:pvUE22AexT08nauiCIIkq1D45cmaZtA9dbtInKxR6SAdIy/kp3bGJo0sW+GNE1s7bsA5UiuLSDZk2FJz+goS7n04ctAs2MPYbtI5JgbZgqWYrm5vRTxA3UbVvj04Mh4iB8MdpubKvu22I255RvDt9vzL4li4oCbF8fErQGDOY3lLn0Qcz3vXBXG7letQfKqYtJBhdOtd3tIriLFamGtLpsyKtnGUsINocUOWCW1mf4jeLLK2XHFlFxaSZGyd5EhjO2KYai2EKRJZjoOPK2KPvw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(97927398514766); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:HE1PR0701MB3001; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 4:B1zfSbkwU/fo7ct/9LdrXSwE2KuQD7qvqDsXLr6YdpapX/hd/lR8K416L8clnZYGKSjXMUv+6SxGwnFsP2hYvScSxaqi5IDDyNAGhrPw2m0SAWhJz6qbsVP9DasefAKKmOxL9onWflCFtBkXqSfHE83+oZG/NOsOcn0b8cDASJWhIC3bjm6dwOCAOhMev4vsTWQwnGkErkOQje5tFukeabGp1cI8IwNK4G1dfxNjnvJQpKYq6xtbi/ZFUV8KygotCcOMJHCht79fqqe1uI+BqxNMkWyjoakAQyG+3GP80A2vwSFwEh3ea44pxfhoCjHIW5FZOC7VzLrxLetch7vvsGfRvlc9ngLn1hZjzlvgUeCv8bA/tOe9p1/jincUqBnmqUa1vxDAGJNf4cY+ppl6UUa6VqaX7Va2IxvhNfExdmqHfRW07ju5XC4N77eS8dmWZWQ+jYLpiOFgjKyEenNGGS4O03/m68c0BNd62FnhYbUJxMQKCGJCcZdubFoiydlbU22HdIlbkurswghWMLc/lANvAnjCeENkMLKoz7CDBA5i41oFva0DZpNfAK/jQ1oUEFFstFLenASsyRzx0QoewUK3tT1xISmrM3bOzIPX38RedJlQJlRx3SMztd5aNky9I6/Hl7RlTAOFbqtOBu5Y8Q== X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(377454003)(13464003)(199003)(24454002)(51444003)(189002)(33646002)(38730400002)(6496005)(53936002)(6246003)(93886004)(116806002)(44736005)(230700001)(50986999)(25786008)(81686999)(81816999)(9686003)(106356001)(6486002)(76176999)(101416001)(97736004)(189998001)(105586002)(305945005)(14496001)(84392002)(7736002)(2906002)(61296003)(50466002)(42186005)(23676002)(68736007)(92566002)(86362001)(1456003)(1556002)(81156014)(81166006)(8676002)(229853002)(4720700003)(6666003)(50226002)(5660300001)(6116002)(47776003)(66066001)(44716002)(3846002)(62236002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3001; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDE7MjM6YzVjY0szd2tweGphd1dyckRPYmVPREY3?= =?utf-8?B?dVdKNFRJNTBJSHl5aXozbWV2RjlVUHFkSTR0WTRad3NJR21VTHN4aGFrQk1W?= =?utf-8?B?UjFnbFVNUHlxNmMyQzFzQk9hS3hKSUpWeTV1djcvWmFRbDZhejEwd2xiUFVK?= =?utf-8?B?V0R6aWE1VmRGREtLeXJ2TW9ZdUdUUjdSU1NwRGh1NjQ1cUJFZVIzSXlMSjRU?= =?utf-8?B?cWdUNlF5RWlIbG5XTXcvSnNRUkk1UTNKQldxUUxVQndiTnN4M2ZZcXBJMWIx?= =?utf-8?B?bjNSMXptWHI5VmR2NU9pdTk5SnQ4MVVmWWxRTldNNFUvRExLMjlLZ1ptSTFo?= =?utf-8?B?R2dORkVEM3drSDhXLzJuZmoweTVZWGQ0U1ZPd2kzYVhiZHNzbDVaKzlJOHVi?= =?utf-8?B?STl1Rko4Qm13dTJHZWRkWjJjTUo2UDFsZlA4Y0pRMmJ5K2lyYmt0UDdFQXpi?= =?utf-8?B?ME1MOEJTUGJ0K0JuWXY1VVNYWlFFYnZCWlZXQzNwQjFYUEEwVWFnb3dqdVh0?= =?utf-8?B?ZVRnazNSZER4M000SFNOYlZSakdSNVZlTitFQWVvemFrZFFkOVg4ZlNJU0hI?= =?utf-8?B?SG9lNW5rNy9vU1JDdFFKQktKQUE3OUF3N0pMUlU1VEVTS3ZlRm5HemlySFl4?= =?utf-8?B?dE40STJMc3pRUzJOWlpnMmpzZFdpWlZOQTdNTWd1cEZSdkR5TzB4U3dLcWFJ?= =?utf-8?B?R3hMSzJON3RsMk4xWmEwRE5FaUV4bmxIaXVaYlE1UHhwWGhtTlpoVmpwekZC?= =?utf-8?B?MHNKc2g0SUV4THZidzRNRHIxNEVCMlplSVhQUFJNdUxRRXgyU2lVQ1BVVjVL?= =?utf-8?B?Z2tOOGpleVUyNVFMaEFWZ2xFTEpXemFGMTNvNzU0U0EzZSt0bkV0UkV2SjBI?= =?utf-8?B?ZmdDTXV0VmIyMVpDUXBwVVZ2aHBDMXJscW91aEpUblFIRzY1YVltNWx2RER5?= =?utf-8?B?bnV2dnJPWUhQcE9pMEdRb0kxVGNrK1pEYlBHVWdZZXpDL3FxNDFXS0xBMW9W?= =?utf-8?B?a3hSUmNJelFnYVpQU2dtVGFlbkErRWVza0lMN0VNRmpBdm0wblVnNnIxNkZN?= =?utf-8?B?dTRGbFdUQ0JUSCs5a1c0aVZWbHpFendsc1UvcVVYTmtLczkrUHk3U0ZjS1dC?= =?utf-8?B?cjZOVkViZVJYWTlyMWpOL2c4dUhSOWkzVHpuQmozM25NZG95R3RwVGFpV2JC?= =?utf-8?B?bktXMTFRRUlyMGxKVUh1SFhQUzRvNS9pcXZ2b05NdHpxR1VrZmMwbjJyRDV0?= =?utf-8?B?SEhncmd1SUl4azIvRUR6Y3ZpU2N4T1F5UC9ENklyYXpRQmpUMTdrTWp0V1Ix?= =?utf-8?B?OThjTjRFdmtiLzZHRVdHNk16cWJLY3c4cE0yaDlkd2xSWEl4WWp4QmJtSTRD?= =?utf-8?B?aEVTUHQ0ZXl2aGJibWJPN0JoNXJOajNBZVpaQzF5V1FSL3pwZFdKcFlxU1hk?= =?utf-8?B?TGtHd3A0REtheCtxNzdvR3RCblNjRnlaVTRhalRxbllRUnZvTTFRUUxGZVVH?= =?utf-8?B?MmJSc3hVMlVnaGw4NlBpdE16cXA5R0hEK0hlUkZHL2pnMEFkTHl4QnRKWkVV?= =?utf-8?B?UndkQ1FQTWo2YkFmeE9JSWR2d3VsTUpRcVFlWUZmd2pZOFhNR0U5NDFlLzlm?= =?utf-8?B?bi9pOTlRckpRMk0vaTR2c2dXRmkvcWtleVpNdU55WUE5SlBoTmVhSHhaaEVV?= =?utf-8?B?WUVMb3BlL295eFRnZXpmZ1RlN3UyYmc1NytvbE9Jelo0cU9KZWRjMWM4dzdh?= =?utf-8?B?N0hpdlRRS0VCczJUSHRWUWxqUXVFL1N6cDM5S1ZuOFc0dlpCYTkzcnJRNnlu?= =?utf-8?B?MjlWcDc5aE12aDZSNUVHUlhsbXdTL0RLcE95ZDdRVXV5TU4xVkM3WWhpSmo2?= =?utf-8?B?WTZsd2JpRkNiMUFtZ1g4cE13Qm02NUdaNWcyVTQ5SEVQMTFHb3puT1VyZ3Bl?= =?utf-8?B?c0tsSnlYR0hTUVE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 6:uUb2FuXK9HXr176KZU9StjiSmhTazb9hxy4OKB/kQ5J9znBbOUY3Q2mhvpxqSn827r4VGuRUqXvrlMscbC5lyJ5PAEr1SCMuFGxJyqEmg10UDcG68EzoX1/mat0SzrXtTDA2shddeMOE9CI0u11bzHLWmC7er1XLIu2kkEsDRTWHjmmsoj+VC7xTEFUNyyMGU9CZQLRaFk9yFFNRQJvde2aV1tE6BFLmKOnQy1hBmlCYF9CCSUNiXuuJJAJ/xWX0Vu5LgZXbp/nrOBBjDXmYvF9bAvAxOc64zPeUaSxlwCDyplJnbzDIe8iosungUEEadwyOAoLvJZ4szgFt3OGNTnmJ7BFJ3SN/ojv39+ZwFkHnnErnq8eKzxMfvWWB4dtB66wuDAAOZH0RJAjLYLoJOA==; 5:I2vyAhf7DjSlZRASO7Av8lst2D7d892m00bMBmlJd3gp6VToK6vtT0Q3x/adj8A6yhyhsaSrvjGfMRe6G9uVN8BDBKCmSVSgvFtt5x4gotT0/JAwvi+uFQiOSluRvvlPtkblZmjGuRxwaM8OLl/hJQ==; 24:q9h8E5ZZTCNf5WlY+jCjoNd2bKft3UDJ+Uubf/c4Xk9qh0Yzc8BWZF0EKE8Hkrqh787aTcdVzkLtY+7Ymo0awPPpKOIKh9SxsoJAkOGgOdI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 7:XDnAiL2zq1WuZTZzfM9twILqyxQq/t5VztXZOBck8iq8REZL7opVvN408mriIqviMpwNAyvB4rSwi/OjjRbo8pIwVPVDDC7v0BybMQbURViVMiLeRz1TQkja3/ldd5ZEJIy8Z95jrbOv6nClJ3b5XFtTc4MTPzwrkMCblw8JVMBV5uURQYi9bV5wfrNKDqJmaUBAJEBjROl9Cn8u4EOLsIaITF4abctVpcEn+NrFzWVPcT106zvIfxkUa9hK0J986FhcQ6syakT4/sk52kHSIPmluhwcVJL2RSbgKgEUaNQVWh1yLpp9Uqg2mw5japY/XHW70CDfZHEv6hMGSzHoFw== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2017 11:07:49.6496 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3001 Archived-At: Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 11:07:55 -0000 ----- Original Message ----- From: "Fred Baker" Sent: Wednesday, February 22, 2017 1:09 AM > This argument is essentially what I was referring to with respect to draft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812 didn't have to address. They include, at least, ISP, content network, data center, enterprise, residential, IoT, and mobile wireless networks. Those markets have differing non-exclusive sets of requirements. > > Let me throw a question to the working group. One way to approach this is to try to push requirements for all of those markets into one document, which is what I think James is trying to do. Another way is to separate them, which is what I think Barbara is trying to do. I'm not going to say that either is automatically right or automatically wrong, but they are different, and I have visions of an argument that takes forever, boils blood, and nobody wins, if we don't systematically address it. > Separate. I think that most of the requirements documents fail, at least in part, because they end up as the logical OR of everyone's wish list. Look, for example, at the little discussion currently in progress on the wisdom or otherwise of /64. Any one marketplace has its own clear view but merge them together and you have a slight lack of agreement. So let's have sets of requirements focussed on a marketplaces, separately documented. I always find Barbara's comments most insightful because she is describing a world I have no knowledge of, of whose requirements I would otherwise be unaware of; merge them into everyone else's and I would be wondering what on earth is this doing here. Tom Petch > I see two approaches that might be considered reasonable. One would be to add a section about residential networks (which are definitively not ISP networks, but use routers that might also be used as ISP "customer-edge" routers) to the document, stating that it is requirements for routers that might be used within a multi-router residential network including the router connected to the ISP; the other would be to invite a separate document that addresses residential networks. > > If we take the latter approach, we might as well also invite separate documents (or in the former approach, separate sections) describing requirements for IPv6 routers in ISP, content network, data center, enterprise, IoT, and mobile wireless networks. This might be one of those, and draft-ali might be one of those. I suspect we will find that a lot of the requirements are in fact common, and could be described in a core document. But I don't know of any ISPs suggesting the use of HNCP, residential networks discussing RPL, or yada yada yada. > > Opinions? > > On Feb 21, 2017, at 4:41 PM, STARK, BARBARA H wrote: > > > > The charter of v6ops is still doing things that help get IPv6 rolled out. Which is exactly what these ISPs are asking for help with. Which has nothing to do with multi-router home network topologies. > > > > I believe a very targeted document to meet the needs of these ISPs is what we should be aiming for. > > Barbara From nobody Thu Feb 23 11:00: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 1A3A812973E; Thu, 23 Feb 2017 11:00:20 -0800 (PST) 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 1-4EOuf3CMBh; Thu, 23 Feb 2017 11:00:18 -0800 (PST) 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 01B451295B7; Thu, 23 Feb 2017 11:00:17 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org (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 v1NJ0Ein095260 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 19:00:14 GMT (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.foobar.org Message-ID: <58AF313D.3020905@foobar.org> Date: Thu, 23 Feb 2017 19:00:13 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.10 (Macintosh/20170123) MIME-Version: 1.0 To: ietf@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , IETF discussion list Subject: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:00:20 -0000 as it's currently worded, draft-ietf-6man-rfc4291bis seems to prohibit the implementation of any interface netmask != /64: > However, the Interface ID of > all unicast addresses, except those that start with the binary value > 000, is required to be 64 bits long. This has substantial operational consequences in the ipv6 world because if it's implemented as stated, it will cause production ipv6 networks to break. The ipv6 operational community may have opinions on the wisdom of mandating new behaviour which would cause their networks to fall over, so it would probably be a good idea to notify v6ops@ietf about the existence of this draft so that the folks over there get a look-in before a consensus call is made. As far as I can tell, this notification never happened. Nick From nobody Thu Feb 23 11:07:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20285129A42 for ; Thu, 23 Feb 2017 11:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PK71NDrh_RNf for ; Thu, 23 Feb 2017 11:07:34 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CC61297E7 for ; Thu, 23 Feb 2017 11:07:33 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0FD42617AF for ; Thu, 23 Feb 2017 20:07:31 +0100 (CET) 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 84BF6602C7; Thu, 23 Feb 2017 20:07:30 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 7780170D93; Thu, 23 Feb 2017 20:07:30 +0100 (CET) Date: Thu, 23 Feb 2017 20:07:30 +0100 From: Gert Doering To: Nick Hilliard Message-ID: <20170223190730.GL2367@Space.Net> References: <58AF313D.3020905@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58AF313D.3020905@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:07:36 -0000 Hi, On Thu, Feb 23, 2017 at 07:00:13PM +0000, Nick Hilliard wrote: > as it's currently worded, draft-ietf-6man-rfc4291bis seems to prohibit > the implementation of any interface netmask != /64: > > > However, the Interface ID of > > all unicast addresses, except those that start with the binary value > > 000, is required to be 64 bits long. > > This has substantial operational consequences in the ipv6 world because > if it's implemented as stated, it will cause production ipv6 networks to > break. Unless I'm totally mistaken this wording has been in "the appropriate RFC" (4291?) since the beginning of time. Well, 4291 only mentions this in passing, and points to 3587 [GLOBAL], which points to [ARCH] with this sentence [ARCH] also requires that all unicast addresses, except those that start with binary value 000, have Interface IDs that are 64 bits long and to be constructed in Modified EUI-64 format. [ARCH] is 3513, and states For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. which very much sounds like the sentence above. > The ipv6 operational community may have opinions on the wisdom of > mandating new behaviour which would cause their networks to fall over, > so it would probably be a good idea to notify v6ops@ietf about the > existence of this draft so that the folks over there get a look-in > before a consensus call is made. As far as I can tell, this notification > never happened. It's not a new mandate - but doing this document, a discussion might be in order on whether it should still be worded as strictly. But since nobody seemed to care for the last 14 years (3513 is standard track, published April 2003), why should people or vendors bother to follow RFC mandates now...? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Feb 23 11:09: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 E7711129967; Thu, 23 Feb 2017 11:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 DegD2DTE-m-2; Thu, 23 Feb 2017 11:09:02 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 61B391297DE; Thu, 23 Feb 2017 11:08:59 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1cgyl4-0004E2-ML (job@us.ntt.net); Thu, 23 Feb 2017 19:08:55 +0000 Date: Thu, 23 Feb 2017 20:08:46 +0100 From: Job Snijders To: Nick Hilliard Message-ID: <20170223190846.GS89584@hanna.meerval.net> References: <58AF313D.3020905@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58AF313D.3020905@foobar.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:09:03 -0000 On Thu, Feb 23, 2017 at 07:00:13PM +0000, Nick Hilliard wrote: > as it's currently worded, draft-ietf-6man-rfc4291bis seems to prohibit > the implementation of any interface netmask != /64: > > > However, the Interface ID of > > all unicast addresses, except those that start with the binary value > > 000, is required to be 64 bits long. > > This has substantial operational consequences in the ipv6 world because > if it's implemented as stated, it will cause production ipv6 networks to > break. > > The ipv6 operational community may have opinions on the wisdom of > mandating new behaviour which would cause their networks to fall over, > so it would probably be a good idea to notify v6ops@ietf about the > existence of this draft so that the folks over there get a look-in > before a consensus call is made. As far as I can tell, this notification > never happened. This is not 'new', but it is a re-iteration of (in my opinion) a specification of a non-optimal addressing architecture. Aside from the newness, I agree with you. I would've hoped that when a document like this is revised after 10+ years, people would think to ask and include in dialogue the actual ipv6 operators whether reality is aligned with the documented architecture. rfc4291 (2006) "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." rfc3513 (2003) "For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. rfc2373 (1998) "The format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have to have 64-bit interface identifiers in EUI-64 format. See section 2.5.1 for definitions." Kind regards, Job From nobody Thu Feb 23 12:42: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 8B1DE12A2AC; Thu, 23 Feb 2017 12:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 o0XIwXazwQVq; Thu, 23 Feb 2017 12:42:53 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 C8D4E12A2C3; Thu, 23 Feb 2017 12:42:52 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id h65so1827523uah.0; Thu, 23 Feb 2017 12:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NMcxeJtsHtXvnQzih2JYZheUYftgMUF2Wr7A2ggwIEM=; b=Jk7aeqZdCHhIEGUPTz5gwgSyuZjTXtLa7n4LTutewLeMW+OpZ7KG6CLd1GtAziFauH zWMEC8HN02iwyilEiG43Tm6mPEYbg7spbCUzf0VmTDZtRVz4zKmAi8H0kNENP04wRRg5 WLM6Xb7iQyRJ8A1wbVFU+Ia0Oxq9mlyFXQ46meVstlH/mcIvvgqwIjcLGY5BDj1TPZKz ylP5hhxvlkS+xSSabayV9+T6AK+n4P+wQENCJAVScz9aPoHMIbA5iRlOOukfTwcXiCZR BRLMASBOtzZvUdg4tlsQb1+B3odqEmeFf0VHIFlUL/MvYRKi2e7Try7LlBI3YA4KBTHV Ag0Q== 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=NMcxeJtsHtXvnQzih2JYZheUYftgMUF2Wr7A2ggwIEM=; b=Jbj4m9HTaBvvkdZrhejUL3M2QAk2rxKI8NK+yGtNfxxiahnPhZY3ruQkgNlptagAbp KCzWYQ9BjslL5tFUF7crGYOSeBtfSEFowK0odfUtkUdCYFEkd4gBdixaeAMKjNsi3M1P zI0Z7lYx1PRFcoDbmnz8PPkAP4ozIbp5jOTmzqMRfV1GQt92ZbGk0o8AbGy4RFMfolio JrYz98jokPrHRQVRfbh0Epd3ovB/hza7kJB/uEeScHNQonbk1xRqNii/IlEMGmTDb4YR PovH4hgSZ74T/v7BwUeOWHFRHANJlS+oIFG1Ye/x2A0U0pgLQ0AUyp4gZuEtBAVGpdlk 8iSA== X-Gm-Message-State: AMke39kv2O9Pwj1i9LaNLxQd6tdotsmu9duU48joRTYNeEi9iHQfKeanRaU6GNEXjK9KxlrU+LWYCcgu6CJobQ== X-Received: by 10.176.74.86 with SMTP id r22mr10848568uae.18.1487882571891; Thu, 23 Feb 2017 12:42:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.2 with HTTP; Thu, 23 Feb 2017 12:42:21 -0800 (PST) In-Reply-To: <58AF313D.3020905@foobar.org> References: <58AF313D.3020905@foobar.org> From: Mark Smith Date: Fri, 24 Feb 2017 07:42:21 +1100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 20:42:54 -0000 On 24 February 2017 at 06:00, Nick Hilliard wrote: > as it's currently worded, draft-ietf-6man-rfc4291bis seems to prohibit > the implementation of any interface netmask != /64: > >> However, the Interface ID of >> all unicast addresses, except those that start with the binary value >> 000, is required to be 64 bits long. > The thing is this is not new text, it has been in RFC4291 for 11 years. c.f., 2.5.1. It can't be changed without invalidating all of the other RFCs that have utilised 64 bit identifiers. > This has substantial operational consequences in the ipv6 world because > if it's implemented as stated, it will cause production ipv6 networks to > break. Going by the millions of IPv6 deployments now, it has been implemented as stated. > > The ipv6 operational community may have opinions on the wisdom of > mandating new behaviour which would cause their networks to fall over, There is and should be no new behaviour in RFC4291bis, it is a tidy up to advance it along the standard track. > so it would probably be a good idea to notify v6ops@ietf about the > existence of this draft so that the folks over there get a look-in > before a consensus call is made. As far as I can tell, this notification > never happened. > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 23 14:05: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 AEC53129B45 for ; Thu, 23 Feb 2017 14:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 hEua_eypEpiC for ; Thu, 23 Feb 2017 14:05:35 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1451B129B67 for ; Thu, 23 Feb 2017 14:05:34 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1D16A617C9 for ; Thu, 23 Feb 2017 23:05:32 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D205A60ED1; Thu, 23 Feb 2017 23:05:31 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id C797D704D8; Thu, 23 Feb 2017 23:05:31 +0100 (CET) Date: Thu, 23 Feb 2017 23:05:31 +0100 From: Gert Doering To: Mark Smith Message-ID: <20170223220531.GU2367@Space.Net> References: <58AF313D.3020905@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:05:37 -0000 Hi, On Fri, Feb 24, 2017 at 07:42:21AM +1100, Mark Smith wrote: > It can't be changed without invalidating all of the other RFCs that > have utilised 64 bit identifiers. Except for the few that explain how to use /126 or /127, right? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Feb 23 14:15: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 F24E0129B0F; Thu, 23 Feb 2017 14:14:54 -0800 (PST) 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 rwLrawZw8dUh; Thu, 23 Feb 2017 14:14:53 -0800 (PST) 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 40A4A1299E3; Thu, 23 Feb 2017 14:14:53 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org (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 v1NMEovl018459 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 22:14:51 GMT (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.foobar.org Message-ID: <58AF5ED9.7060006@foobar.org> Date: Thu, 23 Feb 2017 22:14:49 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.10 (Macintosh/20170123) MIME-Version: 1.0 To: Gert Doering References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> In-Reply-To: <20170223190730.GL2367@Space.Net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:14:55 -0000 Gert Doering wrote: > Unless I'm totally mistaken this wording has been in "the appropriate > RFC" (4291?) since the beginning of time. it has, but it was updated over the years by several other drafts which proposed the use of other appropriate interface netmasks, including e.g. rfcs 6164 and 7608. The importance of 7608 is that netmasks longer than /64 have no relevance unless there are interface netmasks longer than /64. > But since nobody seemed to care for the last 14 years (3513 is > standard track, published April 2003), why should people or vendors > bother to follow RFC mandates now...? If the IETF mandates something that's both unenforceable and which will cause breakage if implemented, this makes the IETF look rather foolish. Nick From nobody Thu Feb 23 14:44: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 6CEE2129BD8; Thu, 23 Feb 2017 14:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 rEQYbLj2eVLu; Thu, 23 Feb 2017 14:43:57 -0800 (PST) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28BC129BC9; Thu, 23 Feb 2017 14:43:57 -0800 (PST) Received: from [10.61.217.135] (unknown [173.38.220.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id D46D9564671; Thu, 23 Feb 2017 23:43:53 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Pierre Pfister In-Reply-To: Date: Thu, 23 Feb 2017 23:43:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> References: <58AF313D.3020905@foobar.org> To: Mark Smith X-Mailer: Apple Mail (2.3259) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Feb 23 23:43:55 2017 +0100 (CET)) Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:44:00 -0000 > Le 23 f=C3=A9vr. 2017 =C3=A0 21:42, Mark Smith = a =C3=A9crit : >=20 > On 24 February 2017 at 06:00, Nick Hilliard wrote: >> as it's currently worded, draft-ietf-6man-rfc4291bis seems to = prohibit >> the implementation of any interface netmask !=3D /64: >>=20 >>> However, the Interface ID = of >>> all unicast addresses, except those that start with the binary = value >>> 000, is required to be 64 bits long. >>=20 >=20 > The thing is this is not new text, it has been in RFC4291 for 11 > years. c.f., 2.5.1. And during those 11 years. Nobody implemented this rule specific to = ::/3. >=20 > It can't be changed without invalidating all of the other RFCs that > have utilised 64 bit identifiers. Those "other RFCs" have nothing to do with being part of ::/3 or not. They require an interface identifier of 64 bits long. The fact that a protocol does not work in some conditions does not = invalidate the protocol. e.g. the fact that SLAAC over Ethernet doesn't work when IID is not 64 = doesn't mean the IID could not be 64 bits long. It just means that under those = conditions, SLAAC would not work. And those conditions are perfectly well defined in those "other RFCs". - Pierre >=20 >> This has substantial operational consequences in the ipv6 world = because >> if it's implemented as stated, it will cause production ipv6 networks = to >> break. >=20 > Going by the millions of IPv6 deployments now, it has been implemented > as stated. >=20 >>=20 >> The ipv6 operational community may have opinions on the wisdom of >> mandating new behaviour which would cause their networks to fall = over, >=20 > There is and should be no new behaviour in RFC4291bis, it is a tidy up > to advance it along the standard track. >=20 >=20 >> so it would probably be a good idea to notify v6ops@ietf about the >> existence of this draft so that the folks over there get a look-in >> before a consensus call is made. As far as I can tell, this = notification >> never happened. >>=20 >> Nick >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 23 17:40: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 2A4FD12941D; Thu, 23 Feb 2017 17:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nGTFyTOatFgs; Thu, 23 Feb 2017 17:40:48 -0800 (PST) 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 ED588129442; Thu, 23 Feb 2017 17:40:47 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id r136so4942294vke.1; Thu, 23 Feb 2017 17:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S9I9YVAnPKuidA8zDysqxD1jEvjZqbe7JxhRRZXuC04=; b=XQst6W2DRh13j1dygMU9oOOY3IMMSdftoRPmRky+fe8dMvLfqlbEDri4K1OcpIOOca 2Ypi25MGSAK9ybK7WAVUOoEowJz984IKEZNRsq+nDUTHuOPp0wG5yhrbG1beAu11XQCV v0mFdT/VrMaF8mHvC0gTaOqvui8lfkvtNKIboG1iea2rk/h4f3VUxLDSSOyFEYnECuFu EQ8d2sc4yJsx26aI6adThsjnDxVoo2xA7BF8+8K9XZEBNdpyLkP0y/C0L8BbNEU5KRIc WvMjnpuzP7cHGWT/3RuSDAZwUxcf1WaiomGEBL23pF0dsTBY73mEnlwzcX66Kjz/igya SjEQ== 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=S9I9YVAnPKuidA8zDysqxD1jEvjZqbe7JxhRRZXuC04=; b=nmrQen4bSEVstiNyj5Jfr123zU2E3YZ4Of7pMltigYjcrt/rpFW50oZSnhsj9ctdmN osm+pLHtoGieVsMWIW7jyDUPI24m/nX3uiGStjyruaOfM+7ose9qyQRQSaJNAayA807X 2Eu0Ve0CXV2CMnW8qq3aRtXf1KSDXn51W2oQOzI/ltpb595TZP/VXs/sr8C9miEakIZ/ SbirrAczSo1nNNShS2XZkM+IB5kSfGrqerZbds5XDm+WQJ+co7MBi1HiGy990t5JxcXW RKaM1i7PxTnkahQYtrdc3bhpj8o6R9eH5SmLkItfxhdJfa1nem4T0Mm3xF/Wb0S6BMtv cCgw== X-Gm-Message-State: AMke39kvriBaG7qb6rdsidWf15vJgU7qmKld90JcuiQJGOpj2L2z6ZF4fo+MWxIDpb9GC5TeYwJft6t4LB6k7w== X-Received: by 10.31.54.85 with SMTP id d82mr65083vka.25.1487900447059; Thu, 23 Feb 2017 17:40:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.2 with HTTP; Thu, 23 Feb 2017 17:40:46 -0800 (PST) Received: by 10.159.38.2 with HTTP; Thu, 23 Feb 2017 17:40:46 -0800 (PST) In-Reply-To: <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> References: <58AF313D.3020905@foobar.org> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> From: Mark Smith Date: Fri, 24 Feb 2017 12:40:46 +1100 Message-ID: To: Pierre Pfister Content-Type: multipart/alternative; boundary=001a114384ac9bb5d305493cd165 Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 01:40:50 -0000 --001a114384ac9bb5d305493cd165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24 Feb. 2017 09:43, "Pierre Pfister" wrote: > Le 23 f=C3=A9vr. 2017 =C3=A0 21:42, Mark Smith a= =C3=A9crit : > > On 24 February 2017 at 06:00, Nick Hilliard wrote: >> as it's currently worded, draft-ietf-6man-rfc4291bis seems to prohibit >> the implementation of any interface netmask !=3D /64: >> >>> However, the Interface ID of >>> all unicast addresses, except those that start with the binary value >>> 000, is required to be 64 bits long. >> > > The thing is this is not new text, it has been in RFC4291 for 11 > years. c.f., 2.5.1. And during those 11 years. Nobody implemented this rule specific to ::/3. > > It can't be changed without invalidating all of the other RFCs that > have utilised 64 bit identifiers. Those "other RFCs" have nothing to do with being part of ::/3 or not. They require an interface identifier of 64 bits long. The fact that a protocol does not work in some conditions does not invalidate the protocol. e.g. the fact that SLAAC over Ethernet doesn't work when IID is not 64 doesn't mean the IID could not be 64 bits long. It just means that under those conditions, SLAAC would not work. And those conditions are perfectly well defined in those "other RFCs". A non-SLAAC example. "Unicast-Prefix-based IPv6 Multicast Addresses" https://tools.ietf.org/html/rfc3306 That example and many others are described in "Analysis of the 64-bit Boundary in IPv6 Addressing" https://tools.ietf.org/rfc/rfc7421 Surely everybody here saying change it or abandon it have read that RFC so they fully understand the consequences of what they're suggesting, right? I'm pretty sure it has been referenced in at least one version of the text I've seen in the discussion. - Pierre > >> This has substantial operational consequences in the ipv6 world because >> if it's implemented as stated, it will cause production ipv6 networks to >> break. > > Going by the millions of IPv6 deployments now, it has been implemented > as stated. > >> >> The ipv6 operational community may have opinions on the wisdom of >> mandating new behaviour which would cause their networks to fall over, > > There is and should be no new behaviour in RFC4291bis, it is a tidy up > to advance it along the standard track. > > >> so it would probably be a good idea to notify v6ops@ietf about the >> existence of this draft so that the folks over there get a look-in >> before a consensus call is made. As far as I can tell, this notification >> never happened. >> >> Nick >> >> _______________________________________________ >> 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 --001a114384ac9bb5d305493cd165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24 Feb. 2017 09:43, "Pierre Pfister" <pierre.pfister@darou.fr> wrote:
> Le 23 f=C3=A9vr. 2017 =C3=A0 21:42, Mark Smith <markzzzsmith@gmail.com> a =C3=A9crit :
>
> On 24 February 2017 at 06:00, Nick Hilliard <nick@foobar.org> wrote:
>> as it's currently worded, draft-ietf-6man-rfc4291bis seems to = prohibit
>> the implementation of any interface netmask !=3D /64:
>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 However, the Interface ID of
>>>=C2=A0 =C2=A0all unicast addresses, except those that start wit= h the binary value
>>>=C2=A0 =C2=A0000, is required to be 64 bits long.
>>
>
> The thing is this is not new text, it has been in RFC4291 for 11
> years. c.f., 2.5.1.

And during those 11 years. Nobody implemented this rule specific to := :/3.

>
> It can't be changed without invalidating all of the other RFCs tha= t
> have utilised 64 bit identifiers.

Those "other RFCs" have nothing to do with being part of ::= /3 or not.
They require an interface identifier of 64 bits long.
The fact that a protocol does not work in some conditions does not invalida= te the protocol.
e.g. the fact that SLAAC over Ethernet doesn't work when IID is not 64 = doesn't mean
the IID could not be 64 bits long. It just means that under those condition= s, SLAAC would not work.
And those conditions are perfectly well defined in those "other RFCs&q= uot;.

A non-SLAAC example.

"Un=
icast-Prefix-based IPv6 Multicast Addresses"

<= /div>

That example and many ot= hers are described in

"Analysis of th= e 64-bit Boundary in IPv6 Addressing"
https://tools.ietf.org/rfc/rfc7421
Surely e=
verybody here saying change it or abandon it have read that RFC so they ful=
ly understand the consequences of what they're suggesting, right? I'=
;m pretty sure it has been referenced in at least one version of the text I=
've seen in the discussion.



- Pierre

>
>> This has substantial operational consequences in the ipv6 world be= cause
>> if it's implemented as stated, it will cause production ipv6 n= etworks to
>> break.
>
> Going by the millions of IPv6 deployments now, it has been implemented=
> as stated.
>
>>
>> The ipv6 operational community may have opinions on the wisdom of<= br> >> mandating new behaviour which would cause their networks to fall o= ver,
>
> There is and should be no new behaviour in RFC4291bis, it is a tidy up=
> to advance it along the standard track.
>
>
>> so it would probably be a good idea to notify v6ops@ietf about the=
>> existence of this draft so that the folks over there get a look-in=
>> before a consensus call is made. As far as I can tell, this notifi= cation
>> never happened.
>>
>> Nick
>>
>> _______________________________________________
>> 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=


--001a114384ac9bb5d305493cd165-- From nobody Thu Feb 23 18:59: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 4FBC212948C; Thu, 23 Feb 2017 18:59:01 -0800 (PST) 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_HELO_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 CPmtm7snISwa; Thu, 23 Feb 2017 18:58:59 -0800 (PST) Received: from tsinghua.edu.cn (smtp39.tsinghua.edu.cn [166.111.204.63]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8BD1294C6; Thu, 23 Feb 2017 18:58:57 -0800 (PST) Received: from [10.235.234.125] (unknown [58.200.235.39]) by app1 (Coremail) with SMTP id CsxvpgAnLUVtoa9YcixcAg--.1596S2; Fri, 24 Feb 2017 10:58:55 +0800 (CST) Message-ID: <58AF9C78.2000106@cernet.edu.cn> Date: Fri, 24 Feb 2017 10:37:44 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gert Doering References: <58AF313D.3020905@foobar.org> <20170223220531.GU2367@Space.Net> In-Reply-To: <20170223220531.GU2367@Space.Net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: CsxvpgAnLUVtoa9YcixcAg--.1596S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU5h7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26r1I6r4UM28EF7xvwVC0I7IYx2IY 6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2js IEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAK zVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx 8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxkIecxEwVAFwVW8JwCF04k20xvY0x0E wIxGrwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMI IF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVF xhVjvjDU0xZFpf9x0UUjRlUUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 02:59:01 -0000 Gert Doering 写é“: > Hi, > > On Fri, Feb 24, 2017 at 07:42:21AM +1100, Mark Smith wrote: > >> It can't be changed without invalidating all of the other RFCs that >> have utilised 64 bit identifiers. >> > > Except for the few that explain how to use /126 or /127, right? > +1, plus exceptions for the IPv4-translatable IPv6 address defined in RFC6052. I suggest just provide pointers to those RFCs in rfc4291bis. xing > Gert Doering > -- NetMaster > From nobody Thu Feb 23 19:19: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 A849E129CC8; Thu, 23 Feb 2017 19:19:07 -0800 (PST) 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 H5jXleS87i6u; Thu, 23 Feb 2017 19:19:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D071294F2; Thu, 23 Feb 2017 19:19:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ch6PM-0006BO-Ml; Fri, 24 Feb 2017 03:19:01 +0000 Date: Fri, 24 Feb 2017 10:18:56 +0700 Message-ID: From: Randy Bush To: Gert Doering In-Reply-To: <20170223190730.GL2367@Space.Net> References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:19:07 -0000 > But since nobody seemed to care for the last 14 years this is false. some people have been fighting this for 20 years. though the first years were more concentrated on fighting the TLS/NLA insanity, which makes this /64 mess look minor. for those of us trying to deal with classful ipv6 for the last 20 years, this /64 issue is the last clean-up. randy From nobody Thu Feb 23 19:23: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 2892F1294F9; Thu, 23 Feb 2017 19:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJZz0tlQUNZm; Thu, 23 Feb 2017 19:23:40 -0800 (PST) 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 CC17D1294E6; Thu, 23 Feb 2017 19:23:39 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id b16so8434913qte.0; Thu, 23 Feb 2017 19:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pssrw9zN7R2F8P++BFcEQ5oJLN3jkQhljrBedOh0GSA=; b=gOVcb9RXh2OOuOgLp37K8/Y6gGekpPVPL27DRlRVTdmIiAqg5oazilL8kwqpiZXmPA 1WkqjnpQJVjo3iS42OqGcyn7u4vr1QHcrr0So7BFp9Wse0S7Qe5ejEVMFjqLDNQmYUDx SWVFCUlHFfO19M/yAqgOTkZFZXWtNMmfpd5fVli2332q8mrvIujiWroTqbVN+eKoqLtb KsHbybosJV3mn8jrOvFTOllwfSEi3O/A3FD8jtgYwLWX9XQ2S/p48kl4wV1H+fs7AB6U u39UnxARXI2JXclXGDUL61l5ouSEjq8CNgi40ORbbvFGi6mCBylFS80ErQgn8be9pHNd kiaw== 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=pssrw9zN7R2F8P++BFcEQ5oJLN3jkQhljrBedOh0GSA=; b=oAPYPVV6GqjiqHyD1rGVHEUq2zLdbpbx3Uq6wS2RTV9PdmVEPom3KqQDoqbsYpVlPh 25ph2pOSWYIgDJ6/9TuROOqiYE8R005zMceNIQpaMd9RtQvJxPzRK3vw/5yoLb/XS7h4 nfg3Iy1HUP5wg0Oe2jqys3bTR0RTlIdI+NyxZknm/UU3IwUyVxLFMrwPraX62FdCBUqA ZT8eyzP2NE5wuCjZDyn6vfE7Y3o7uKF+vZHMwG0vmWFemjIcmmYvFnctnN1nGsjpCR9b 5u3JXPBxOO03MKW3Vc3u9RpV5TC/Nrc9nqbXEVXxZiBAkbpwIzzdk9K/UNPQngHTEY/h r/3Q== X-Gm-Message-State: AMke39kXiW1okBJlcao52oxfaFHEUkUNtiuL52ioV2m2rs2tq6v00yRMRGmEJtsB9PUD4/6efDa5qxeET7SM4A== X-Received: by 10.237.33.47 with SMTP id 44mr501114qtc.100.1487906618930; Thu, 23 Feb 2017 19:23:38 -0800 (PST) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.91.71 with HTTP; Thu, 23 Feb 2017 19:23:38 -0800 (PST) In-Reply-To: References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> From: Christopher Morrow Date: Thu, 23 Feb 2017 22:23:38 -0500 X-Google-Sender-Auth: 96LWu__n4j4Jrug8wcpC5BcFd4I Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c0c5e527afc3705493e419e Archived-At: Cc: IPv6 Operations , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:23:41 -0000 --94eb2c0c5e527afc3705493e419e Content-Type: text/plain; charset=UTF-8 On Thu, Feb 23, 2017 at 10:18 PM, Randy Bush wrote: > > But since nobody seemed to care for the last 14 years > > this is false. some people have been fighting this for 20 years. > though the first years were more concentrated on fighting the TLS/NLA > insanity, which makes this /64 mess look minor. for those of us trying > to deal with classful ipv6 for the last 20 years, this /64 issue is the > last clean-up. > > The original message in the thread about this draft: " > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'IP Version 6 Addressing Architecture' > as Internet Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting." Nothing in the past really matters here, what matters is: "Is the bis draft all set, did we fix all the things which must be fixed before this draft becomes a real 'standard'?" "no, I don't think we did" - randy (as strawman arguer) Folk's frustrations are coming out, deep breath and think before 'send' please... we're all really trying to do the right thing, yes? --94eb2c0c5e527afc3705493e419e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 23, 2017 at 10:18 PM, Randy Bush <randy@psg.com>= wrote:
> But since nobody seemed to care for the last 14 years

this is false.=C2=A0 some people have been fighting this for 20 year= s.
though the first years were more concentrated on fighting the TLS/NLA
insanity, which makes this /64 mess look minor.=C2=A0 for those of us tryin= g
to deal with classful ipv6 for the last 20 years, this /64 issue is the
last clean-up.


The original message= in the thread about this draft:
" > The IESG has received a req= uest from the IPv6 Maintenance WG (6man) to
> consider the fol= lowing document:
> - 'IP Version 6 Addressing Architecture= '
> =C2=A0 <draft-ietf-6man-rfc4291bis-07.txt> as In= ternet Standard
>=C2=A0
> The IESG plans to make = a decision in the next few weeks, and solicits
> final comment= s on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-03-0= 1. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the=
> beginning of the Subject line to allow automated sorting.&q= uot;

Nothing in the past really matters here, what= matters is: "Is the bis draft all set, did we fix all the things whic= h must be fixed before this draft becomes a real 'standard'?"<= br>
"no, I don't think we did" - randy (as stra= wman arguer)

Folk's frustrations are coming ou= t, deep breath and think before 'send' please... we're all real= ly trying to do the right thing, yes?

--94eb2c0c5e527afc3705493e419e-- From nobody Thu Feb 23 19:28: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 10EDB1294C7 for ; Thu, 23 Feb 2017 19:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 JGcXn8_xkP9m for ; Thu, 23 Feb 2017 19:28:17 -0800 (PST) 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 A3DF51294F2 for ; Thu, 23 Feb 2017 19:28:17 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 40so6360452uau.2 for ; Thu, 23 Feb 2017 19:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s4vyK5ldz5TueiqH3lARdNq3Xp9lOKbsNUOLq78LjVI=; b=GZEjp1DNL/AUkoySM+4jN1Z0xpGIWnXib6S8NJNyM2oaSMf4EG/AAP33RUVreCPBKo hYvhlrzEu68r1lkCsdI8qZ6FFl2H4LxoxvWdAOwiV9bHF9GCtsXl0Gk922BU6NBq19r0 M28dSF/um9tsF3wclTvXFzbGwEK3b9i4Bowacc1VxwJWrI8pvGoHlqnXgKE/NYeViyCm eUqK9kfPp2jWYtI3Hb44phMP2dMjpujHxAQXTx561Qwv9eosZDeXVjNB3PnJi6qVo45Y kFmCkV3hBC4AVVR+33fICmjjSWoAAUFF7B6YBNkruo/2WdHSlhXElZPpinteRqOx7tEJ L05Q== 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=s4vyK5ldz5TueiqH3lARdNq3Xp9lOKbsNUOLq78LjVI=; b=dfbZRtFDvx1xfnYOyYf+s6QLyw96KB28lxya9R92+gW5K+/u/Qhzx5y3O+7p3C200e Fq8ooY3eTr6oNbnEDXxwzOwCI0hzeST1lcp+efhhy5K1083hk1RbZqDyF0EeTjVmS83s 6jT18EVt+VB6AJU94XjBfFn7bOQnQunWoAhOjaife+JwB+kNjDuZhfsWOaBj5mGFDw2u L/w0chhTG4iM2UNEnodOp6jV71x2thPIAEckIlYtTtQnCaQPLqdG+4m1674PgHtVep6D 8cbJk+LmYxuG0ARmLZMLNirDY/ZVvSiw1ndVcoeMqaiP8IAluaPOOeevLZKOQbus3Ef4 rfeQ== X-Gm-Message-State: AMke39l+5EpOOTDZvDtyvGKdMIC1t/S6xXZdE+I5aD6TXMpvvTLAtU40pY+IAis86EbQXFwu+oogZzphWFdn6i6h X-Received: by 10.159.36.56 with SMTP id 53mr281429uaq.124.1487906896476; Thu, 23 Feb 2017 19:28:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 23 Feb 2017 19:27:55 -0800 (PST) In-Reply-To: <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> References: <58AF313D.3020905@foobar.org> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> From: Lorenzo Colitti Date: Fri, 24 Feb 2017 12:27:55 +0900 Message-ID: To: Pierre Pfister Content-Type: multipart/alternative; boundary=001a113e1ca006a6d605493e52b0 Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:28:20 -0000 --001a113e1ca006a6d605493e52b0 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 24, 2017 at 7:43 AM, Pierre Pfister wrote: > > The thing is this is not new text, it has been in RFC4291 for 11 > > years. c.f., 2.5.1. > > And during those 11 years. Nobody implemented this rule specific to ::/3. > I can implement it today in some of our code if you like :-). But it seems unlikely to make a difference, since the rule only applies to unicast addresses in ::/3, and no such addresses have been released to the RIRs. That in turn is unlikely to change until we run out of 2000::/3, and even then we'll likely move on to allocating addresses out of 4000::/3 instead of from ::/3. --001a113e1ca006a6d605493e52b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 24, 2017 at 7:43 AM, Pierre Pfister <pierre.pfister@darou.= fr> wrote:
> The thing is this is not new text, it has been in RFC4291 for 11
> years. c.f., 2.5.1.

And during those 11 years. Nobody implemented this rule specific to = ::/3.

I can implement it today in some = of our code if you like :-). But it seems unlikely to make a difference, si= nce the rule only applies to unicast addresses in ::/3, and no such address= es have been released to the RIRs. That in turn is unlikely to change until= we run out of 2000::/3, and even then we'll likely move on to allocati= ng addresses out of 4000::/3 instead of from ::/3.
--001a113e1ca006a6d605493e52b0-- From nobody Thu Feb 23 19:32: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 A9345129D28 for ; Thu, 23 Feb 2017 19:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7ybl2LW3B2L8 for ; Thu, 23 Feb 2017 19:32:17 -0800 (PST) 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 3A74C129D16 for ; Thu, 23 Feb 2017 19:32:17 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 40so6396436uau.2 for ; Thu, 23 Feb 2017 19:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t4y5wcXECAV7DVhZQcYWJTDXR3jfLJ8vuOjkcvPv+mE=; b=Vmmxb15WSUYP1Q8yKTo6agYLo3xvTdOOAlCMvEKvFMnkJc92qIVX5QS2ENlLyNDQHy pJTleb+0kDFs3AawBtvpCTRp/gEpKalo1ef2O9XMLh/a4nhNrPLQnzDlXwAYP7KpGrOQ N/xgGtSqLSH7y+huIM54v1SuD9Kns8udba+dompwtnuwuA7iHqGzGRdQQ83tGe1k/UL1 ljYdXRdz+BQnbQu5YZP+RVsTPUynY71SU0dGPzY+1P0mzo6n2YgIN1pqBlDqvsuwW1yB 9AMLiKqP9fjgYsKrJwTx3q1AVTS+Epyjy1raRP8fe4W3LwzMX+YjV35ADZ/H7HIbZDyY soBQ== 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=t4y5wcXECAV7DVhZQcYWJTDXR3jfLJ8vuOjkcvPv+mE=; b=lJ+/1H9vWKoleWOritTsD6/maVRlPAQU+DtHrFXtpfnqvK2JAWJsZWle88BuEZJ0/1 QSdfescecU+JyqSCdLQp8kVs2ySnuzYGxcnAVxSmWI4BLye90EOeq8kWMvKTEqvv+tjZ F3uzCWZe2qeGnZdAFxmsnvnu3fsP7OjRVF23Bo5v4mD/4xCp3FfxZrVZjwNotLYXs9Ci Z/yRmjCpAQe+NH6vFqOP/VKb4qu+56eLPfQnUO/Tt5II4YJhFU3y3UyM0J86yvOPbcYk l3f1NuEJWhKyPG04bqy2CxqrUbk15zRZpd2jLmHfBKJHBuXWEaCjaYCR4xPyTTPS3CD6 TO1g== X-Gm-Message-State: AMke39mjm9kzijoKnmpWftrjcm+hWFYqMtEADxN8LBFG0+aktFcNXuxsh7CjWMptAfHAY1DWi2S8QlKduT0m/k7s X-Received: by 10.176.17.108 with SMTP id g44mr244957uac.30.1487907136135; Thu, 23 Feb 2017 19:32:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 23 Feb 2017 19:31:55 -0800 (PST) In-Reply-To: <58AF9C78.2000106@cernet.edu.cn> References: <58AF313D.3020905@foobar.org> <20170223220531.GU2367@Space.Net> <58AF9C78.2000106@cernet.edu.cn> From: Lorenzo Colitti Date: Fri, 24 Feb 2017 12:31:55 +0900 Message-ID: To: Xing Li Content-Type: multipart/alternative; boundary=f4030435b5704f3d1305493e6025 Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:32:19 -0000 --f4030435b5704f3d1305493e6025 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 24, 2017 at 11:37 AM, Xing Li wrote: > Except for the few that explain how to use /126 or /127, right? >> >> > > +1, plus exceptions for the IPv4-translatable IPv6 address defined in > RFC6052. I suggest just provide pointers to those RFCs in rfc4291bis. > Yes, seems like those should be documented too. In fact, perhaps a general exception for IPv6 addresses where the only non-zero bits in the IID are an IPv4 address? --f4030435b5704f3d1305493e6025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 24, 2017 at 11:37 AM, Xing Li <xing@cernet.edu.cn> = wrote:
Except for the few that explain how to use /126 or /127, righ= t?
=C2=A0

+1, plus exceptions for the IPv4-translatable IPv6 address defined in RFC60= 52. I suggest just provide pointers to those RFCs in rfc4291bis.

Yes, seems like those should be documented too. I= n fact, perhaps a general exception for IPv6 addresses where the only non-z= ero bits in the IID are an IPv4 address?
--f4030435b5704f3d1305493e6025-- From nobody Thu Feb 23 19:34: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 1C63E129CE5 for ; Thu, 23 Feb 2017 19:34:55 -0800 (PST) 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 Wd1MdehwVIJS for ; Thu, 23 Feb 2017 19:34:53 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFCF1294FE for ; Thu, 23 Feb 2017 19:34:53 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x75so5869346vke.2 for ; Thu, 23 Feb 2017 19:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s1zq4usS5Z971djrHB8lo+vtcQTbmhSjrDqhENeX4nQ=; b=Ue170Oaz/8sP2fttfe948jFt8LgAPo4OtAEgpLMDBNAotDJsHkZtVRkWFGVo2n/Yz8 Ic3xFhe5aVkY3aMhNxZtigfxMvVthyKC1z73OEsjLwFgGwINnQxtRQXLm9R6pcYtgpzu bRTJucmJSq06mQt883fpPLkgFOqg2H4NfW3iDQyboU6NftaVvcO7vntdaB+LOS+Xa6Hn fud0f9S9PM97TMwpY/XjVulI7iyemBeVupynM3A/wgZSTIQRTP+BZRVxAwPY8CKpuhNg VNkOUWR+wUNlp9h9YnfJzS56DAFboXkRsVWSr50jYlzpJprZr6/sCQMGjKhQe8hd76tf Flcg== 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=s1zq4usS5Z971djrHB8lo+vtcQTbmhSjrDqhENeX4nQ=; b=f8SY6evkSHlQi8W/NeLxbxFz4eADnBhy2mRDKMtktCXA+lFN38ub/06DIcx92n1vri Gpj8d/8qvfl9RyFGF2tp3itnm0L9Me5P5qtTBcj5kZktjL9kHbsQJLZrrY0JfUmEMdvi 4XNNcBN+xb/xIpq8MDc6BVVs3mO1DBsVDuPLK2Bi2PZSA5Xczc8ZerIPUupguSavSGbm y5vAG/xux4GXAW+QCu8p/3urzPCLtlogHgVhEFTAp/AN0joaMJ8/S0AOD0RF3aEGETw2 w27NN4jv0aYLaWG7NEqJ0dlFADUxjLbgI2IDWMnHmb4Vwa4+1p8Jbp0aURBXVs+3p6Jn e2Tw== X-Gm-Message-State: AMke39l7ylJXhHL4hunR7o/RY4TTa8IHC5awiediu3z/+pxTOclVVJIhdjVSGaXRu7sbxlEfIw0vGOPdalmKgs1+ X-Received: by 10.31.150.134 with SMTP id y128mr220761vkd.102.1487907292689; Thu, 23 Feb 2017 19:34:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 23 Feb 2017 19:34:32 -0800 (PST) In-Reply-To: References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> From: Lorenzo Colitti Date: Fri, 24 Feb 2017 12:34:32 +0900 Message-ID: To: Christopher Morrow Content-Type: multipart/alternative; boundary=001a1141d600a410a205493e6977 Archived-At: Cc: Randy Bush , IPv6 Operations , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:34:55 -0000 --001a1141d600a410a205493e6977 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow < morrowc.lists@gmail.com> wrote: > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting." > > Nothing in the past really matters here, what matters is: "Is the bis > draft all set, did we fix all the things which must be fixed before this > draft becomes a real 'standard'?" > I don't think you can say nothing in the past matters here. We know that there have been host implementations that relied on this guarantee, and we have to consider that if we change the standard, those implementations will become non-compliant. --001a1141d600a410a205493e6977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 24, 2017 at 12:23 PM, Christopher Morrow <morrowc.lists@gmai= l.com> wrote:
> The IES= G plans to make a decision in the next few weeks, and solicits
&g= t; final comments on this action. Please send substantive comments to the
> ietf@ietf.= org mailing lists by 2017-03-01. Exceptionally, comments may be
> sent to iesg@iet= f.org instead. In either case, please retain the
> beginni= ng of the Subject line to allow automated sorting."

Nothing in the past really matters here, what matters is: "Is t= he bis draft all set, did we fix all the things which must be fixed before = this draft becomes a real 'standard'?"
=

I don't think you can say nothing in t= he past matters here. We know that there have been host implementations tha= t relied on this guarantee, and we have to consider that if we change the s= tandard, those implementations will become non-compliant.
=
--001a1141d600a410a205493e6977-- From nobody Thu Feb 23 19:38: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 1BDE11294DA; Thu, 23 Feb 2017 19:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o22hmu46kqgP; Thu, 23 Feb 2017 19:38:16 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0E59E1294C7; Thu, 23 Feb 2017 19:38:16 -0800 (PST) Received: from [IPv6:2603:3015:3603:8e00:c505:8fff:dbfd:7e6f] (unknown [IPv6:2603:3015:3603:8e00:c505:8fff:dbfd:7e6f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 1EB23540BCD; Thu, 23 Feb 2017 22:37:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jared Mauch In-Reply-To: Date: Thu, 23 Feb 2017 22:37:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <28DBAE9B-1E48-4246-8EB7-2F0723D0BD32@puck.nether.net> References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Operations , Christopher Morrow , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:38:17 -0000 > On Feb 23, 2017, at 10:34 PM, Lorenzo Colitti = wrote: >=20 > On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow = wrote: > > The IESG plans to make a decision in the next few weeks, and = solicits > > final comments on this action. Please send substantive comments to = the > > ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments = may be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting." >=20 > Nothing in the past really matters here, what matters is: "Is the bis = draft all set, did we fix all the things which must be fixed before this = draft becomes a real 'standard'?" >=20 > I don't think you can say nothing in the past matters here. We know = that there have been host implementations that relied on this guarantee, = and we have to consider that if we change the standard, those = implementations will become non-compliant. This has always been the case and was a big excuse given by Cisco back = in the 1990s for not fixing the directed-broadcast problem. For progress to occur sometimes a prior behavior will become invalid, if = we can=E2=80=99t handle this then there=E2=80=99s no hope. I don=E2=80=99= t live in a world without hope. - Jared= From nobody Thu Feb 23 19:41: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 E5D2B129D50; Thu, 23 Feb 2017 19:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXyWN4MwBqrA; Thu, 23 Feb 2017 19:41:45 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 8C459129D51; Thu, 23 Feb 2017 19:41:44 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id n21so8609286qta.1; Thu, 23 Feb 2017 19:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iy9/NLfT2inTbMQsVJPcTux3WMus8X+6dLgtbVXSxWE=; b=H+kqfvbr6GDnNUkQZ19rFi9xa8zsRfUshNbR1tyiLZtuI/cCI+qJ95steDULY1dgze KGYFJUp8aIms6ID77V8cSW89lrDZ0fz4vksTxQ4q917yCntm8kIZtQ8jYTsYhO57EmF/ a6QRtdEQdNu4zEieGfUZBNcAjANBHEoI05ND7C9cJICHfbsvGVCkgsAOVfkRQg+6Tir8 fyeSE3I1+wIXvNz22rH4DlqhJs0gH6naZOnzzfaC6M82ehnd9ptpXbVYo32lPEANSZvx uoaSFmlfNoopAp4IXU8DSGxb4so2EMyuSEb/RSEn6s6DQ1Sz6DOQjcgotLw9+2FS1mRq 6wNw== 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=iy9/NLfT2inTbMQsVJPcTux3WMus8X+6dLgtbVXSxWE=; b=dLgd2fx/I37yl7yEiuKCyUFmq5sj33P/HgLUjXWqQ3KnM60zbAwt8A06GLW366LX7K 3CwW8o/8KXSoekO3EuT4eYF3E1aEARwDxsb5FnE1hT4tWmUSvp2WXyTPh0Aj7Sm8oLgE BHoKG91d9k9aABXUu1kWg5EBTOERnTlybB3lOOY1L23FfYRlzMlB5INJH/fMNNN1ZvFy fPJaxq1elYjcyMkK3h1m6esLHq0ubCsXyLGqmZH2y92+z9xlJvElgoZexARVZNbZthEt B/LBqF4mWPe+o4jmzFgIjbPCz0qUj9XhxK1kKCq5vfOipHxz5an1CVSGV9fYIJcBVuIs b3gA== X-Gm-Message-State: AMke39njug8+NRhet417fQfWr5tk48/9jfXzfCj7p6kwMMeHRnlFa5Dj9fCzZMEz5+MsGaiFLBvJZNP42S0lXA== X-Received: by 10.200.54.13 with SMTP id m13mr544368qtb.214.1487907703625; Thu, 23 Feb 2017 19:41:43 -0800 (PST) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.91.71 with HTTP; Thu, 23 Feb 2017 19:41:43 -0800 (PST) In-Reply-To: References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> From: Christopher Morrow Date: Thu, 23 Feb 2017 22:41:43 -0500 X-Google-Sender-Auth: OLTLickTXSE0eqfxvTFWx0d-Fe8 Message-ID: To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a1139f8ea2221b605493e82fe Archived-At: Cc: Randy Bush , IPv6 Operations , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:41:47 -0000 --001a1139f8ea2221b605493e82fe Content-Type: text/plain; charset=UTF-8 gosh people are being literal today :) On Thu, Feb 23, 2017 at 10:34 PM, Lorenzo Colitti wrote: > On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow < > morrowc.lists@gmail.com> wrote: > >> > The IESG plans to make a decision in the next few weeks, and solicits >> > final comments on this action. Please send substantive comments to the >> > ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments may >> be >> > sent to iesg@ietf.org instead. In either case, please retain the >> > beginning of the Subject line to allow automated sorting." >> >> Nothing in the past really matters here, what matters is: "Is the bis >> draft all set, did we fix all the things which must be fixed before this >> draft becomes a real 'standard'?" >> > > I don't think you can say nothing in the past matters here. We know that > there have been host implementations that relied on this guarantee, and we > have to consider that if we change the standard, those implementations will > become non-compliant. > I don't think the proposed (now 160+ messages back) text really says: "FREE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64 because the application you are being placed into requires it (slac, blah and blah and ilnp and blah - see rfc7k) then do that, else any other prefix length works" how's that not 'ok' for host folks? "Hi, my host is going to be in a slaac world.. so /64 it is!" --001a1139f8ea2221b605493e82fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
gosh people are being literal today :)

On Thu, Feb 23, 2017 at 10:34 PM,= Lorenzo Colitti <lorenzo@google.com> wrote:
On Fri, Feb 24, 2017 at 12:23 PM, Christo= pher Morrow <morrowc.lists@gmail.com> wrote:
> The IESG plans to make a decision in the nex= t few weeks, and solicits
> final comments on this action. Ple= ase send substantive comments to the
> ietf@ietf.org mailing lists by 2017-03-01. = Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, pl= ease retain the
> beginning of the Subject line to allow autom= ated sorting."

Nothing in the past really mat= ters here, what matters is: "Is the bis draft all set, did we fix all = the things which must be fixed before this draft becomes a real 'standa= rd'?"

I don't think you can say nothing in the past matters here. We know = that there have been host implementations that relied on this guarantee, an= d we have to consider that if we change the standard, those implementations= will become non-compliant.

I don't think t= he proposed (now 160+ messages back) text really says: "FREE FOR ALL&l= t; NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64 beca= use the application you are being placed into requires it (slac, blah and b= lah and ilnp and blah - see rfc7k) then do that, else any other prefix leng= th works"

how's that not 'ok' for host folks? "Hi, my host = is going to be in a slaac world.. so /64 it is!"
--001a1139f8ea2221b605493e82fe-- From SRS0=3dbs=2F=darou.fr=pierre.pfister@bounces.m4x.org Thu Feb 23 22:58: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 98DD31295C1; Thu, 23 Feb 2017 22:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 h2pckoc5-FDg; Thu, 23 Feb 2017 22:58:52 -0800 (PST) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E281295BC; Thu, 23 Feb 2017 22:58:51 -0800 (PST) Received: from [10.61.217.135] (unknown [173.38.220.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 7990656475D; Fri, 24 Feb 2017 07:58:47 +0100 (CET) From: Pierre Pfister Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_764C52CD-FD2D-4EAF-BC8D-CD381224AE4B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 07:58:46 +0100 In-Reply-To: To: Lorenzo Colitti References: <58AF313D.3020905@foobar.org> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> X-Mailer: Apple Mail (2.3259) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Feb 24 07:58:48 2017 +0100 (CET)) Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 07:00:07 -0000 --Apple-Mail=_764C52CD-FD2D-4EAF-BC8D-CD381224AE4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Le 24 f=C3=A9vr. 2017 =C3=A0 04:27, Lorenzo Colitti = a =C3=A9crit : >=20 > On Fri, Feb 24, 2017 at 7:43 AM, Pierre Pfister = > wrote: > > The thing is this is not new text, it has been in RFC4291 for 11 > > years. c.f., 2.5.1. >=20 > And during those 11 years. Nobody implemented this rule specific to = ::/3. >=20 > I can implement it today in some of our code if you like :-). Good luck getting that upstreamed ! ;-) > But it seems unlikely to make a difference, since the rule only = applies to unicast addresses in ::/3, and no such addresses have been = released to the RIRs. That in turn is unlikely to change until we run = out of 2000::/3, and even then we'll likely move on to allocating = addresses out of 4000::/3 instead of from ::/3. So what you are saying is that all currently assigned unicast addresses = are out of the ::/3 prefix.=20 Meaning that, according to proposed standard, I should not be able to = configure on-link prefixes of length different than 64 with currently = assigned unicast addresses. At least Linux, Windows, Apple, Cisco, and probably all mature IPv6 = stacks, would let you configure prefixes of length different than 64. - Pierre --Apple-Mail=_764C52CD-FD2D-4EAF-BC8D-CD381224AE4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Le 24 f=C3=A9vr. 2017 =C3=A0 04:27, Lorenzo Colitti <lorenzo@google.com> = a =C3=A9crit :

On Fri, Feb 24, 2017 at 7:43 AM, Pierre Pfister = <pierre.pfister@darou.fr> wrote:
> = The thing is this is not new text, it has been in RFC4291 for 11
> years. c.f., 2.5.1.

And during those 11 years. Nobody implemented this rule specific = to ::/3.

I can implement it today in some of our = code if you like :-). =

Good luck getting that upstreamed ! ;-)

But it seems unlikely to make a = difference, since the rule only applies to unicast addresses in ::/3, = and no such addresses have been released to the RIRs. That in turn is = unlikely to change until we run out of 2000::/3, and even then we'll = likely move on to allocating addresses out of 4000::/3 instead of from = ::/3.

So what you are saying is that all currently assigned unicast = addresses are out of the ::/3 prefix. 
Meaning = that, according to proposed standard, I should not be able to configure = on-link prefixes of length different than 64 with currently assigned = unicast addresses.
At least Linux, Windows, Apple, = Cisco, and probably all mature IPv6 stacks, would let you configure = prefixes of length different than 64.

- Pierre

= --Apple-Mail=_764C52CD-FD2D-4EAF-BC8D-CD381224AE4B-- From nobody Thu Feb 23 23: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 464D31295EC for ; Thu, 23 Feb 2017 23:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 NSdRUoVZDnn4 for ; Thu, 23 Feb 2017 23:55:44 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF54A128E18 for ; Thu, 23 Feb 2017 23:55:43 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 28803616AD for ; Fri, 24 Feb 2017 08:55:42 +0100 (CET) X-SpaceNet-Relay: true 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 D085F600EA; Fri, 24 Feb 2017 08:55:41 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id C1EC38705; Fri, 24 Feb 2017 08:55:41 +0100 (CET) Date: Fri, 24 Feb 2017 08:55:41 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20170224075541.GV2367@Space.Net> References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: Randy Bush , IPv6 Operations , Christopher Morrow , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 07:55:46 -0000 Hi, On Fri, Feb 24, 2017 at 12:34:32PM +0900, Lorenzo Colitti wrote: > I don't think you can say nothing in the past matters here. We know that > there have been host implementations that relied on this guarantee, and we > have to consider that if we change the standard, those implementations will > become non-compliant. Details, please. Besides SLAAC not working (because not defined), which implementations will not work with non-/64 network length? You might know, but if you say "we know", it's not including myself (yet). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Feb 23 23:59: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 26BEB129622 for ; Thu, 23 Feb 2017 23:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 Rc0xTynnMacD for ; Thu, 23 Feb 2017 23:59:42 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC5A12961E for ; Thu, 23 Feb 2017 23:59:42 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A52F06080F for ; Fri, 24 Feb 2017 08:59:40 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 628A7600EA; Fri, 24 Feb 2017 08:59:40 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 53B638762; Fri, 24 Feb 2017 08:59:40 +0100 (CET) Date: Fri, 24 Feb 2017 08:59:40 +0100 From: Gert Doering To: Pierre Pfister Message-ID: <20170224075940.GW2367@Space.Net> References: <58AF313D.3020905@foobar.org> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 07:59:44 -0000 Hi, On Thu, Feb 23, 2017 at 11:43:52PM +0100, Pierre Pfister wrote: > >>> However, the Interface ID of > >>> all unicast addresses, except those that start with the binary value > >>> 000, is required to be 64 bits long. > >> > > > > The thing is this is not new text, it has been in RFC4291 for 11 > > years. c.f., 2.5.1. > > And during those 11 years. Nobody implemented this rule specific to ::/3. The point is not "specific rule for ::/3". The point is that this is a explicit rule for all that is *not* ::/3, with an exception(!) for ::/3. ... and still there are other RFCs that permit /126 and /127, so this definitely needs rewording to match current reality. 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 Fri Feb 24 00:16: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 BB9301293F9 for ; Fri, 24 Feb 2017 00:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=unavailable 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 wZtCxoYePqYa for ; Fri, 24 Feb 2017 00:16:09 -0800 (PST) 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 56D12129489 for ; Fri, 24 Feb 2017 00:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487923968; x=1488528768; 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=z6tVewotDTpHumkSMjftf5FjL 4K8e8oMpUJ1pC8/l0E=; b=EeHHv8+LMMYjWICNZ894FgGLU8sfsAum/RHysmjvH xyGT242qHOiqS5jx/cYaRPYsgZtSPNEnVxFvgxrC1fD6lh/gn4x7iMG6cVEtPRHG FVu1asZy18V8t8h64VaBi8SKAeR/uqB9QjdtRLZVIfDfWLQcs43pp7fB7sEw1a7M e0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=f/RWR1bMrqMJjWUDI/PoaeZ43DOmvn7AA9VoZy+hCBpOsKU0KNQggaxxa0id pplF6avUJZCsi6bFN8PR3623X815vP4QwmOSWInKs70WDX+1SGPZ1ley9 WoZ6mbLzfUQz9Iv1nsa9230efZCi5XozxVUoFKZsOuv9PeVsdNTmYI=; X-MDAV-Processed: mail.consulintel.es, Fri, 24 Feb 2017 09:12:48 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 24 Feb 2017 09:12:47 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005373437.msg for ; Fri, 24 Feb 2017 09:12:46 +0100 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:170224:md50005373437::ia0y3qZufXEUdWw1:00000E1b X-Return-Path: prvs=1228d0687a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Fri, 24 Feb 2017 09:12:45 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations , IETF Message-ID: <4BC61E42-0A36-44E9-8FB9-2062547D939F@consulintel.es> Thread-Topic: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets References: <58AF313D.3020905@foobar.org> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> <20170224075940.GW2367@Space.Net> In-Reply-To: <20170224075940.GW2367@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 08:16:12 -0000 I wonder if anyone knows (or if there is an easy way to check, I doubt), if= other STD documents have similar situations. I mean, we define STDs, it takes long time to do so and meanwhile is still = an RFC or even after a document is already an STD, there may be text sectio= ns that don=E2=80=99t reflect market reality, or some very specific excepti= ons (such as in this case /126-/127), that make sense (or not), but in any = case, the STD is not being modified again and again. I=E2=80=99m sure this happens in any kind of documents in other business an= d life fields, for example, there may be generic laws, and afterwards, the = generic law is not modified for many many many years, but =E2=80=9Cexceptio= n rules=E2=80=9D are created for those laws. So, are we spending too much time in this and is not really necessary? Can we live with the actual text with has been in the market, and working w= ell, for =E2=80=9Cx=E2=80=9D years? Can we make too many (or few very important) changes in an RFC in the way t= o STD, or we need first to have those changes in an RFC for =E2=80=9Cx=E2= =80=9D years and =E2=80=9Cn=E2=80=9D verified implementations, before we mo= ve to STD? If the answer is no, is the balance between living with the curr= ent text but moving to STD a better option than waiting for =E2=80=9Cx=E2= =80=9D years again? Regards, Jordi =20 -----Mensaje original----- De: ietf en nombre de Gert Doering Responder a: Fecha: viernes, 24 de febrero de 2017, 8:59 Para: Pierre Pfister CC: IPv6 Operations , Mark Smith , = IETF Asunto: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets Hi, =20 On Thu, Feb 23, 2017 at 11:43:52PM +0100, Pierre Pfister wrote: > >>> However, the Interface I= D of > >>> all unicast addresses, except those that start with the binary = value > >>> 000, is required to be 64 bits long. > >>=20 > >=20 > > The thing is this is not new text, it has been in RFC4291 for 11 > > years. c.f., 2.5.1. >=20 > And during those 11 years. Nobody implemented this rule specific to := :/3. =20 The point is not "specific rule for ::/3". The point is that this is a explicit rule for all that is *not* ::/3, with an exception(!) for ::/3= . =20 ... and still there are other RFCs that permit /126 and /127, so this definitely needs rewording to match current reality. =20 Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? =20 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Cule= mann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 =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 Fri Feb 24 01: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 5D7F912962F for ; Fri, 24 Feb 2017 01:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 gB0ZXE3aPLfG for ; Fri, 24 Feb 2017 01:04:52 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9B5129417 for ; Fri, 24 Feb 2017 01:04:51 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id a5so3894394ybb.2 for ; Fri, 24 Feb 2017 01:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a6X9Bzeq6OsBAUXlzB7crz5OZvOY0BLRF7nEOmhGQX0=; b=LagyxujdrtgkpIsXPbgmjpxv9wTHE77HQzp98ca+9W8SCB1woAcMlW11TsbwrTblfG wJJN8x70HNju7B20Ozr1uwbSPc5r0yrSlmZRt36XSEWqzijF5iu2P9i0w344BeZddgTE 66/HQ4xfMoR1qKVaXkTHzDSOkiTXeVioMpgZeRyVCt8cHNzXs3XanCLfuQ7N78A4KX+a U5z0wuf6f3d7X2DvBnB4JBZ08dNWChXoyxzu2hwYa9W3mP1l3JCxOwsT4vSlMADa6sbc hl28WZ4cHo/kfWWOcyT33+/vIzq0izOCTK06uJlpyoeGctgd82AE9HPTahC7tODOVh5N ptbQ== 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=a6X9Bzeq6OsBAUXlzB7crz5OZvOY0BLRF7nEOmhGQX0=; b=PiAl2T/NO/WOBsto856T5DJvZQ+yZKwuYVo9BKXD3G5Ia0FdI17WqK1J2dyWbaBwv3 m5nkc3S8bXaxOIHHDNqjhsSM5jLlIF+k/Y0CG2r9htc6aDMmpxXsAOEm+yY2PU6XDUfU tgr/lldqn+xJHpaWVxXWfA2BlJlLQ4Jfow8/GGUaxBGaaJA79a/TUod5mNonoEOH5tut mmkswdzBhZwLWO+WvuakspsDArTAOsmYapE0sMGkWpF+MnZObNhQ7gawqbs/QDAEK0/t kk1xWQnbzkyHWgJWJv51veczjfRFKW9uLENtQuXZWOwPpPOg2qv+UBfx6C4TiHOMErj+ l0Qw== X-Gm-Message-State: AMke39lCzXG5MNDMa1NVCvFp9+T8V7Dkqnw9f09Z65a3XrIX/l8DTcDkkrSMrcEuhime7LN4fuCn4iPzp/9uiTbW X-Received: by 10.37.7.5 with SMTP id 5mr898956ybh.8.1487927090807; Fri, 24 Feb 2017 01:04:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Fri, 24 Feb 2017 01:04:30 -0800 (PST) In-Reply-To: References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> From: Erik Kline Date: Fri, 24 Feb 2017 18:04:30 +0900 Message-ID: To: Christopher Morrow Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c069d44bc06ee054943050e" Archived-At: Cc: IPv6 Operations , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 09:04:53 -0000 --94eb2c069d44bc06ee054943050e Content-Type: multipart/alternative; boundary=94eb2c069d44b34b39054943051c --94eb2c069d44b34b39054943051c Content-Type: text/plain; charset=UTF-8 On 24 February 2017 at 12:41, Christopher Morrow wrote: > gosh people are being literal today :) > > > On Thu, Feb 23, 2017 at 10:34 PM, Lorenzo Colitti > wrote: > >> On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow < >> morrowc.lists@gmail.com> wrote: >> >>> > The IESG plans to make a decision in the next few weeks, and solicits >>> > final comments on this action. Please send substantive comments to the >>> > ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments >>> may be >>> > sent to iesg@ietf.org instead. In either case, please retain the >>> > beginning of the Subject line to allow automated sorting." >>> >>> Nothing in the past really matters here, what matters is: "Is the bis >>> draft all set, did we fix all the things which must be fixed before this >>> draft becomes a real 'standard'?" >>> >> >> I don't think you can say nothing in the past matters here. We know that >> there have been host implementations that relied on this guarantee, and we >> have to consider that if we change the standard, those implementations will >> become non-compliant. >> > > I don't think the proposed (now 160+ messages back) text really says: > "FREE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64 > because the application you are being placed into requires it (slac, blah > and blah and ilnp and blah - see rfc7k) then do that, else any other prefix > length works" > > how's that not 'ok' for host folks? "Hi, my host is going to be in a slaac > world.. so /64 it is!" > For manual assignment among consenting adults: as you like it. (For all prefixes longer than /64, the trailing 64bits would still end up being unique; there is no real issue here.) And I gather everyone agrees that at a minimum the /127 RFC and other working-group-graduated documents should be suitably incorporated and referenced. Otherwise, this feels like another round of "why isn't IPv6 just 128bit IPv4?" IMHO having /64 as the logical unit of allocation to network leaves is a very good thing. --94eb2c069d44b34b39054943051c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 4 February 2017 at 12:41, Christopher Morrow <morrowc.lists@gmail.c= om> wrote:
gosh people are being literal today :)


On Thu, Feb 23, 2017 at 10= :34 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
On Fri, Feb 24, 2017 at 12:23 PM, Christopher = Morrow <morrowc.lists@gmail.com> wrote:
> The IESG plans to make a decision in the next fe= w weeks, and solicits
> final comments on this action. Please = send substantive comments to the
> ietf@ietf.org mailing lists by 2017-03-01. Exce= ptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please= retain the
> beginning of the Subject line to allow automated= sorting."

Nothing in the past really matters= here, what matters is: "Is the bis draft all set, did we fix all the = things which must be fixed before this draft becomes a real 'standard&#= 39;?"

I= don't think you can say nothing in the past matters here. We know that= there have been host implementations that relied on this guarantee, and we= have to consider that if we change the standard, those implementations wil= l become non-compliant.

I don&#= 39;t think the proposed (now 160+ messages back) text really says: "FR= EE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to = use /64 because the application you are being placed into requires it (slac= , blah and blah and ilnp and blah - see rfc7k) then do that, else any other= prefix length works"

how's that not 'ok' for host folks? "= Hi, my host is going to be in a slaac world.. so /64 it is!"

For manual assignment among consenting a= dults: as you like it. =C2=A0(For all prefixes longer than /64, the trailin= g 64bits would still end up being unique; there is no real issue here.)

And I gather everyone agrees that at a minimum the /1= 27 RFC and other working-group-graduated documents should be suitably incor= porated and referenced.

Otherwise, this feels like= another round of "why isn't IPv6 just 128bit IPv4?" =C2=A0IM= HO having /64 as the logical unit of allocation to network leaves is a very= good thing.
--94eb2c069d44b34b39054943051c-- --94eb2c069d44bc06ee054943050e 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgMJbHtC8TD9gEBCWdYPd7KXgHNPynakex unaQoeTDyE0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjI0 MDkwNDUxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBABCOP27IZPTdX0ksQA85erQvjhpuEjzlClQljCNJYLpWb2HNZvpK UVx+p5w2XR8RFuAw0uZts7q8L+V41aEQ7clcvTVVzQ3f5u8wGtL3+uiGBcDQI6fmPv+bmf4dNqAf yNqaTNWFEV/q/DM8AXxorlcAAFn0UDWXw6VNwFXl/lHmaSkArnuL/4yMwXmuMf1xurG7t+blRIqP nfjm+wKZJ0OlFDYhMkr/6/Ska1A+WtcWJYjIA0FVLBZ3+uvlpc2Bh/u+kqYQgTeItPJcE0qLfQ/3 ZK+am1mAYnwwi2OAQp+S/d/BwSnif4cMFaR6iXOmFAB5cZ5iryVGsn58OfAHRi0= --94eb2c069d44bc06ee054943050e-- From nobody Fri Feb 24 01:33: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 9AC34126FDC for ; Fri, 24 Feb 2017 01:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 jR18m4B2ZFD6 for ; Fri, 24 Feb 2017 01:33:11 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54931294D5 for ; Fri, 24 Feb 2017 01:33:10 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 31FE5616AD for ; Fri, 24 Feb 2017 10:33:09 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E4F7A602B6; Fri, 24 Feb 2017 10:33:08 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id D60B5154D3; Fri, 24 Feb 2017 10:33:08 +0100 (CET) Date: Fri, 24 Feb 2017 10:33:08 +0100 From: Gert Doering To: Erik Kline Message-ID: <20170224093308.GA2367@Space.Net> References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary="Vm3jasITniUHaScm" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IPv6 Operations , Christopher Morrow , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 09:33:13 -0000 --Vm3jasITniUHaScm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Feb 24, 2017 at 06:04:30PM +0900, Erik Kline wrote: > IMHO having /64 as the logical unit of allocation to network leaves > is a very good thing. Why, exactly, except "because it was decided to be that way, many years ago"? (Not that I have any plans to fight that particular windmill, but /64 never made sense to me, after all the more interesting aspects of 8+8 never happened, and thus, effectively, IPv6 today is "IPv4 with longer addresses" as far as "hosts attaching to networks" and "routing" is concerned...)=20 Wasting half the address space and then having to start arguments on the amount of subnets available to home users ("can we give them a=20 /48, or will we run out?", "can we give ISPs enough space so they can give all their users a /48, or do we need to make this a /56?", "how much conservation is required by ISPs?") is major silliness - something like a /96 would have served the aspect "more machines than you can imagine per subnet" perfectly well. SLAAC would have been a bit more challenging, but "use the MAC address" was not *such* a good idea=20 either. 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 --Vm3jasITniUHaScm Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIODwYJKoZIhvcNAQcCoIIOADCCDfwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggslMIIFcjCCBFqgAwIBAgICAQIwDQYJKoZIhvcNAQEFBQAwgZQxCzAJBgNVBAYTAkRF MQ8wDQYDVQQHEwZNdW5pY2gxFDASBgNVBAoTC1NwYWNlTmV0IEFHMR4wHAYDVQQLExVaZXJ0 aWZpemllcnVuZ3NzdGVsbGUxGTAXBgNVBAMTEFNwYWNlTmV0IFJvb3QgQ0ExIzAhBgkqhkiG 9w0BCQEWFGRhdGFjZW50ZXJAc3BhY2UubmV0MB4XDTExMTAxOTE2MjAzM1oXDTI2MTAxNTE2 MjAzM1owgZQxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNzcDExFDASBgNVBAoTC1NwYWNlTmV0 IEFHMR8wHQYDVQQLExZad2lzY2hlbnplcnRpZml6aWVydW5nMRswGQYDVQQDExJTcGFjZU5l dCBMZXZlbDIgQ0ExIzAhBgkqhkiG9w0BCQEWFGRhdGFjZW50ZXJAc3BhY2UubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0TZfc3M8GIjLwvISEA8/c5DYYOzGk82PdjkK LzV0KWg5fOL5XN3QZMNjhspIrwNX4KlUfhhlV6XQ0XoYByJ9OS6IeUgK2DeRrCqZ1FC9zxWD MUy56Uq5cULUH+dGRUTnCYUX55VNpVYG8OSSIHO8wl0AsSArTevBkLySdoDNXxeQjEaNPQFG BANiDYCyOtjswsFGM7HleGUfEDgkqFbwsXrcroHL6FIfTQoVQWEN3fY2JbbLXN+xcqOEd4Ih HfDnPCFtiS3ahAJjEOQ42mcfCpwambPX2fHBGhWuQLEropKoy7ba5DVcs/BhsdLxV2Bs/dPx 7ZVEmYLak+hZk1DatwIDAQABo4IByjCCAcYwHQYDVR0OBBYEFI/AuOF8TILZ9MBdi4dYqe5E gHR2MIHBBgNVHSMEgbkwgbaAFGcpxe17gXP8uKsBPqyov4kcFy7koYGapIGXMIGUMQswCQYD VQQGEwJERTEPMA0GA1UEBxMGTXVuaWNoMRQwEgYDVQQKEwtTcGFjZU5ldCBBRzEeMBwGA1UE CxMVWmVydGlmaXppZXJ1bmdzc3RlbGxlMRkwFwYDVQQDExBTcGFjZU5ldCBSb290IENBMSMw IQYJKoZIhvcNAQkBFhRkYXRhY2VudGVyQHNwYWNlLm5ldIIBZTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBvjBMBggrBgEFBQcBAQRAMD4wPAYIKwYBBQUHMAKGMGh0dHA6Ly9ldWts aWQuc3BhY2UubmV0L2NlcnQvc3BhY2VfU3BhY2VSb290LmNlcjBBBgNVHR8EOjA4MDagNKAy hjBodHRwOi8vZXVrbGlkLnNwYWNlLm5ldC9jZXJ0L3NwYWNlX1NwYWNlUm9vdC5jcmwwEQYJ YIZIAYb4QgEBBAQDAgEGMB8GA1UdEQQYMBaBFGRhdGFjZW50ZXJAc3BhY2UubmV0MA0GCSqG SIb3DQEBBQUAA4IBAQAJ0v/AgH8QHyr+bWIavj/z7ITuqPGWEloPbcuw/icljb4mLmAsp8d9 q77k7mXxgzqBmxIrwcuEdL3l22ZrTnWikiYrKMQ97UssNubnVd6p3hD+nOmygusHJ+drSie8 siFokUjlo8tv+bQzriKtLNuwNKHAFvSH3lypBiQvDAyS7ylTgkfM7BDuaLYw3xsBPvCPRI+U /nzh6ACofz+vogWm5VshW+GhqFQBqcL+gMTm1iW8xLNZ0Z542sTdvSK59YgC/Bhp5kXckgFY IMGI5F2LJ83Iw/izBl5aD5j9Cnv/d341fIUvzSHXoXOIYT7UP/pjvZAk1xD332WWfEahTO4O MIIFqzCCBJOgAwIBAgICAzEwDQYJKoZIhvcNAQELBQAwgZQxCzAJBgNVBAYTAkRFMQwwCgYD VQQIEwNzcDExFDASBgNVBAoTC1NwYWNlTmV0IEFHMR8wHQYDVQQLExZad2lzY2hlbnplcnRp Zml6aWVydW5nMRswGQYDVQQDExJTcGFjZU5ldCBMZXZlbDIgQ0ExIzAhBgkqhkiG9w0BCQEW FGRhdGFjZW50ZXJAc3BhY2UubmV0MB4XDTE2MTEwMjEwNTAyM1oXDTE3MTExNjEwNTAyM1ow gZcxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNzcDExDzANBgNVBAcTBk11bmljaDEUMBIGA1UE ChMLU3BhY2VOZXQgQUcxDjAMBgNVBAsTBXVzZXJzMRUwEwYDVQQDEwxHZXJ0IERvZXJpbmcx HTAbBgkqhkiG9w0BCQEWDmdlcnRAc3BhY2UubmV0MQ0wCwYDVQQrEwRnZXJ0MIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAstQ0lY62WmGZV1NxsT80jMBo1ilFOOo0B2lWYAkK lr0N5gwZOtu6WvGf7kFboCBqGUu+++ZPi6DdOqfyCwgPttrIVJxUHExSaWon0xjvgCvSgfLr dmI4mgm/wAwaStY8cxvO+u0LgKxW2SBxCsba9nVIhMlK/848VhUV0kqunpxwdEk71a65K6J6 UMhMLmyjBHN4lvY54GkfJGRVQneh4is1TraTOTBSEMIfKSe6osiwhqrgW9pORQi1p/0eoitn 5Hv92XZ44zSY7uPD8i5DTuO5oT4AUMMbWSW9k8XwlRLezXs2OBtLExn8eLJCFNAOgtL56F/+ ZN6IGhRmW0CC4wIDAQABo4ICADCCAfwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw JwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDAzAdBgNVHQ4EFgQUwLN/ sVI7xvpVzcIu9GdYLQ3eysowgcIGA1UdIwSBujCBt4AUj8C44XxMgtn0wF2Lh1ip7kSAdHah gZqkgZcwgZQxCzAJBgNVBAYTAkRFMQ8wDQYDVQQHEwZNdW5pY2gxFDASBgNVBAoTC1NwYWNl TmV0IEFHMR4wHAYDVQQLExVaZXJ0aWZpemllcnVuZ3NzdGVsbGUxGTAXBgNVBAMTEFNwYWNl TmV0IFJvb3QgQ0ExIzAhBgkqhkiG9w0BCQEWFGRhdGFjZW50ZXJAc3BhY2UubmV0ggIBAjBO BggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9ldWtsaWQuc3BhY2UubmV0L2Nl cnQvc3BhY2VfU3BhY2VMZXZlbDIuY2VyMBkGA1UdEQQSMBCBDmdlcnRAc3BhY2UubmV0MB8G A1UdEgQYMBaBFGRhdGFjZW50ZXJAc3BhY2UubmV0MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9ldWtsaWQuc3BhY2UubmV0L2NlcnQvc3BhY2VfU3BhY2VMZXZlbDIuY3JsMA0GCSqGSIb3 DQEBCwUAA4IBAQCbUZCcxxopU5RD9+BfA9u+uhqEl/C45p/7y8/m4ANphan0GCGlTSl8tWZ0 bU+IIOrqG94W9v0MGOUnVUNgHD5VVt9MPZFxUsGn6Ac5CWbAhqClABxZbcQLROguG9JYfTmX Zebl19iUN7vbKvv9U1IFQBGDBlpnm1PtypqsuwXQYQHSZD31XsV7ALMIzAaYhkts9xOySFfm zPlFj3D8pj/vUfbcqaNNOgiZLqEXb71ynXQcA1cEr2iDCLWejfq3BJoxP3fZLjwBY9us7td0 LtRoha/nVvx0HHXFVI1XDwH7tGtN80LzprNTcWltcWEjwk6gD2CNakhew0P2hzIMzEjIMYIC rjCCAqoCAQEwgZswgZQxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNzcDExFDASBgNVBAoTC1Nw YWNlTmV0IEFHMR8wHQYDVQQLExZad2lzY2hlbnplcnRpZml6aWVydW5nMRswGQYDVQQDExJT cGFjZU5ldCBMZXZlbDIgQ0ExIzAhBgkqhkiG9w0BCQEWFGRhdGFjZW50ZXJAc3BhY2UubmV0 AgIDMTANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzAyMjQwOTMzMDhaMC8GCSqGSIb3DQEJBDEiBCCPryq6YSGoFf9Tnf+4 GhmvTmB53d1SHPz20WGjK8hstTB5BgkqhkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCk m96+Ec5VC6JQ1N6jTtpJKaa2hqg2ch+JbwUVeIVn9sQa3YZk+0AURAa5R+RmeTZdrmMBsB2U 04sID/BFxmJxrsowfxB01Ygfjl7Wz6qSMweLKgF7gI1lXXYF/kLLiE79s7IuCpWBxGWhsNWK UY5bWFiQNc18djh+ph6nDSrqBCHj1XuO+LObjxbJuBqFYcWUTxIHBqfgTZxfuXIOxENsApDM X96ZiBN6Gr8WcX84ZMlLeSeIuViYKP5HSnGsTTharHkh9FRcVdJPAq9IQeUQtN69dbd7XW9D EkACDI2VLs3cRHwGnxhtnpYAIPYvgMJS00k7yrRyrsLWv4p5oEPb --Vm3jasITniUHaScm-- From nobody Fri Feb 24 02:14: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 D8AD7129676; Fri, 24 Feb 2017 02:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oKz1aVNXZhX; Fri, 24 Feb 2017 02:14:35 -0800 (PST) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::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 56292129673; Fri, 24 Feb 2017 02:14:35 -0800 (PST) Received: by mail-wr0-x242.google.com with SMTP id o22so807465wro.3; Fri, 24 Feb 2017 02:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FZ0baErIUGCekm4au6TcF8NiTjxl7cwQFZFrCSiS+o0=; b=bLUtSwHCkR/C+pOT0TdkdT88855Ohs1Nc5ba2aVJw/Mxv8ga3p+qhHfUod3i5I91gM a8pWD51f71oF3R+JtfrHLVDhc74WCXuTpyHk8qB1usLFpUINMhH7lMBVRedN9HqiJSdz wT3zmqZdsxU8wgliw/iMLaiU3dTIiGN8RZsEMKufQNfQZFUxL5A5ihQ/F2BOWa4E63+o PJIQka9COtx0Mq6wAXydkzYETZpZmoN28ZpCM4eiwpjyco/kmYM9kwRhSmicS2d7HKo5 Tu8DOnc2TPziOwC2JjWn/lNvRVlIC37peHBbq8WADINICukHsRfhgAebnrPuHHiVKOUf /SwA== 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=FZ0baErIUGCekm4au6TcF8NiTjxl7cwQFZFrCSiS+o0=; b=VZMaSKDKRShZqogq1pMQMxkDD3WZxbmhygViSCKLZ4/Zg3BCPGPEF+zll+lnntT8y+ IkMzKDBVgTKiAK8gVra5AKaSlUNRSfHezoUfhrPhvhQSH8ECv0ds/232wjOOmxlFQ224 wevxt5806GlhuhP/c/jSKWb6eKA40oZFugY9fivy3ZYj1CjIAQtt2sXww1bt1yeUG1Wc /Opyu4tuyGuMBQejJJRnw+wC22hDzhH/8tycH1RLeMP7nQIK7JWNzhrzkp8l2lxxx8Zl lm1p30rHubnw6iB7r6+fOo7CColTeyxtBnk8dA9FJkyjxERVAx0mCTqIFRmEAiHwQy8k 8Zbg== X-Gm-Message-State: AMke39muaFkSQWnz2AVM1Sd7Hvjh6eL06Gogze34d3XxAuzOK0gUFtAUkc3705kpGMv9Aw== X-Received: by 10.223.171.30 with SMTP id q30mr1777170wrc.61.1487931273768; Fri, 24 Feb 2017 02:14:33 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 65sm9703579wri.53.2017.02.24.02.14.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 02:14:33 -0800 (PST) From: Yoav Nir Message-Id: <9311B0B8-FCB5-4D1B-8107-BB3EB94C0C23@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B3822E44-4025-40A6-840C-59E9AFF766CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 12:14:29 +0200 In-Reply-To: <20170224093308.GA2367@Space.Net> To: Gert Doering References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> <20170224093308.GA2367@Space.Net> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Operations , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 10:14:37 -0000 --Apple-Mail=_B3822E44-4025-40A6-840C-59E9AFF766CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Feb 2017, at 11:33, Gert Doering wrote: >=20 > Hi, >=20 > On Fri, Feb 24, 2017 at 06:04:30PM +0900, Erik Kline wrote: >> IMHO having /64 as the logical unit of allocation to network leaves >> is a very good thing. >=20 > Why, exactly, except "because it was decided to be that way, many = years > ago"? >=20 > (Not that I have any plans to fight that particular windmill, but /64 > never made sense to me, after all the more interesting aspects of 8+8 > never happened, and thus, effectively, IPv6 today is "IPv4 with longer > addresses" as far as "hosts attaching to networks" and "routing" is > concerned...) >=20 > Wasting half the address space and then having to start arguments on > the amount of subnets available to home users ("can we give them a > /48, or will we run out?", "can we give ISPs enough space so they can > give all their users a /48, or do we need to make this a /56?", "how > much conservation is required by ISPs?") is major silliness - = something > like a /96 would have served the aspect "more machines than you can > imagine per subnet" perfectly well. And you can see RFC 5739 on how a /64 subnet is required for each road = warrior connected to a VPN. You=E2=80=99d need a /56 or /48 to do what = a /24 does in IPv4. Yoav --Apple-Mail=_B3822E44-4025-40A6-840C-59E9AFF766CE 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----- iQEcBAEBCgAGBQJYsAeGAAoJELhJCxUKWMyZ8aIH/2QhVzkDHEuZivs9EVcB9ntd LoaQ139TS/PLh97sTYCFi2qEYywQYjh1MFMaC8yhoeUYGwyICJJcgXtWhqXMNTNq zWyh8dUzbytfq7ObKlvF0SNGTkjHLFDCiVrvEHR7JgpPJhsGfsDvFYx6fdIKF+gX UC4IKTuNpE4Tcw8nkQK7qEz8i7MPUz5I/601/5wBsYYoC7OSGSJcwIzmFICYxAk2 U0QFPhXF4aBCungQWBOHiX4B/KUbn2kBntwGY8D0cRVGn490180q9CgcQ8PfYn4S hLqbf/nKjmDrsUAhoPuOMm+mzAnPIqR/N6xrGGPqgxH0OBxkh99jDxUpE09EcB4= =szsy -----END PGP SIGNATURE----- --Apple-Mail=_B3822E44-4025-40A6-840C-59E9AFF766CE-- From nobody Fri Feb 24 02:49: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 EEECF12960E; Fri, 24 Feb 2017 02:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cpkf6mX42eb; Fri, 24 Feb 2017 02:49:18 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854701293EE; Fri, 24 Feb 2017 02:49:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 19E934D; Fri, 24 Feb 2017 11:49:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1487933354; bh=GmwOp+6KsJIGltn4ugf ocqrJmJJztHGCrt4RUtX6ris=; b=Q+qOv285OSsXAiLXtCYvieG1C4q938HXdPy hQmH116v6Fy8XIYQhqGYUJK4SJt40kdDpND4b+HxiUd9cfy1cmShJ3LEAgiiPTjc iwV38g1LXDbkb6yNpTk8tTQPjS4btB5bhtPTx0aT82IWi+6eJkKp067NkHQ8CGtq JKdkDKt4= 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 E0ak9ho2-clV; Fri, 24 Feb 2017 11:49:14 +0100 (CET) Received: from [IPv6:2003:8:27:8600:9c7c:7f36:b525:f0d8] (unknown [IPv6:2003:8:27:8600:9c7c:7f36:b525:f0d8]) (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 23F434C; Fri, 24 Feb 2017 11:49:14 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <5B82833D-FFF8-45C1-A38D-F8CB81766BB7@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_709CA215-A7EE-4036-9179-3EB961F089DB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 11:49:13 +0100 In-Reply-To: <20170224093308.GA2367@Space.Net> To: =?utf-8?Q?Gert_D=C3=B6ring?= References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> <20170224093308.GA2367@Space.Net> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Operations , Christopher Morrow , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 10:49:20 -0000 --Apple-Mail=_709CA215-A7EE-4036-9179-3EB961F089DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > something like a /96 would have served the aspect "more machines than = you can > imagine per subnet" perfectly well. Yeah, I wish we had chose something like that in the past as well :( Cheers, Sander --Apple-Mail=_709CA215-A7EE-4036-9179-3EB961F089DB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICARMwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTUwNTExMDg1MjM1WhcNMTgwODIz MDg1MjM1WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAFhAYYTBnxV8QzZPT+qs+WLWNRKL 4JQq0dpmSleofioAUrHj8m2BITvJY1pnIY7mdegJXic6+/uCKMAG8FrA6tSNu/hUoTXYMVcUUih5 xZyCWsIFmSBbTuel0nmPvZDayelIwi7GDN0u9IvrmyinSiYJ5jjgiKg3Z1HmMP5t9MR8vpS38bxT WKef8RlACK9jeynmk2U8PFRT+ZVYDW3Us8z4wje+g+q0aEm8UZzoYE245C6aFBqiXS56AN9VcK2C 9Z4wSBnq+I0wRof0BIYIh7V1cFCtz3uhdcbVbfKPHP2GGv69nz/jqSz9hPbIEhC3/kv11FHvIA2x t1scHJOw5DPKaogCtp4BEiOayepZRYo8SCILVTUH07QEP+6D/nLQnNavQT2ClQaSq9ufuD689TvC r5BApB8glktKaPzsiW5gQncIp4GyY593cGkBdh2jPAVpYCyAG96xtY6E0NsjgoghSojeHRfaZOmR iDfaszo4JlIer+VPTcsIl984275cOE/LJcXLSb3AA9AyffEr+6Eszs6HzkfWlzdTedGbqPFhkSlg gBCTZAz/MCT//MVZiDq542xAU8nBpfKWfOyL3oK2PPQAGdpGxFNRzCBngi64n0mB+JrNS44j6WyP qWp2IGSu05o7x6lcUgsjtNmpYvZy4NoyPu4je4+QuzBpFYgCMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB EzAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAyMjQxMDQ5MTRaMCMGCSqGSIb3DQEJBDEWBBTV92Dq4nMex1fovbfiRDLrsU82LjCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBEzCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgETMA0GCSqG SIb3DQEBAQUABIGAVgvbmNg/VDStJ1ciLsm7Ag+DbDdiVHsx7BhGbFu4SCO5kNt8OMLHIAOpESkd FwDh/UxO8ne71pHXzqE+FdIbX76IqInuhC9EbLcGJX0ELDlEYfJSNhNRBPrwYWq30wRwDyjTYrso /Qn94Lpooo83G/uWVJk0Eb85ZZ/eymHFQpEAAAAAAAA= --Apple-Mail=_709CA215-A7EE-4036-9179-3EB961F089DB-- From nobody Fri Feb 24 04: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 DA68B129DC3 for ; Fri, 24 Feb 2017 04:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.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, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 07WvAa1y3ohN for ; Fri, 24 Feb 2017 04:53:03 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E650129DBD for ; Fri, 24 Feb 2017 04:53:03 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1OCr1l9011749 for ; Fri, 24 Feb 2017 13:53:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F49F207F4E for ; Fri, 24 Feb 2017 13:53:01 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 04D6B207F48 for ; Fri, 24 Feb 2017 13:53:01 +0100 (CET) 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 v1OCr0tK001502 for ; Fri, 24 Feb 2017 13:53:00 +0100 To: v6ops@ietf.org References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> From: Alexandre Petrescu Message-ID: Date: Fri, 24 Feb 2017 13:52:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 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] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 12:53:05 -0000 Le 24/02/2017 à 04:23, Christopher Morrow a écrit : > > > On Thu, Feb 23, 2017 at 10:18 PM, Randy Bush > wrote: > > > But since nobody seemed to care for the last 14 years > > this is false. some people have been fighting this for 20 years. > though the first years were more concentrated on fighting the TLS/NLA > insanity, which makes this /64 mess look minor. for those of us trying > to deal with classful ipv6 for the last 20 years, this /64 issue is the > last clean-up. > > > The original message in the thread about this draft: > " > The IESG has received a request from the IPv6 Maintenance WG (6man) to >> consider the following document: >> - 'IP Version 6 Addressing Architecture' >> as Internet Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2017-03-01. > Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, > please retain the >> beginning of the Subject line to allow automated sorting." > > Nothing in the past really matters here, what matters is: "Is the bis > draft all set, did we fix all the things which must be fixed before this > draft becomes a real 'standard'?" For information, in addition to this '64' matter, there is an additional nit in 4291bis that has been discussed in the past: is fe80::/64 or a /10? 4291bis contradicts 2464bis on this matter too. And there is this '000' that is discussed now too. Alex > "no, I don't think we did" - randy (as strawman arguer) > > Folk's frustrations are coming out, deep breath and think before 'send' > please... we're all really trying to do the right thing, yes? > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Feb 24 05:13: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 3AEDB129739; Fri, 24 Feb 2017 05:13:18 -0800 (PST) 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 Wce4dxZqxr6X; Fri, 24 Feb 2017 05:13:16 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F88E1296F9; Fri, 24 Feb 2017 05:13:16 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DAEE2AB; Fri, 24 Feb 2017 14:13:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1487941993; bh=0jsdXUHbLZ6uEJzxsNu6KN/Q4ecYEuVN2Ve+Uomh2oc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sDbx+IxuNqn8hOSjU/MgaEz+mHtTGqR6B8Yku2Rrsvs8TTycU05nQUli6VMmAfpKw z7ZTrU8Q9q7y/afRXgyeuB1JGAfq/iQb92aXYMKxz3ogwC7fw48+Kp/sJqXNHGLhSp mwNNu/uysPT9cjEkP4wp3BREVG0EcpfxbcbKO3q4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D8A6AAA; Fri, 24 Feb 2017 14:13:13 +0100 (CET) Date: Fri, 24 Feb 2017 14:13:13 +0100 (CET) From: Mikael Abrahamsson To: IPv6 Operations In-Reply-To: Message-ID: References: <58AF313D.3020905@foobar.org> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> 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: Cc: IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 13:13:18 -0000 On Fri, 24 Feb 2017, Pierre Pfister wrote: > At least Linux, Windows, Apple, Cisco, and probably all mature IPv6 > stacks, would let you configure prefixes of length different than 64. I just came back from PTO not reading IETF email for 5-6 weeks, and read up on this thread. I just want to state my opinion that whatever text we come up with should reflect current operational reality, in that SLAAC A=1 only works on /64, and that people use all kinds of subnet sizes when manually configuring interfaces. If current code doesn't treat 000::/3 in any special case, then documents should reflect this. Mandating /64 only for any IPv6 use case doesn't reflect reality as I see it. I don't want to see A=1 /64 SLAAC requirement relaxed either. I just want the -bis document to reflect what is currently in the field and we know works. Nothing more, nothing less. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 24 05: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 4C3C51296F5 for ; Fri, 24 Feb 2017 05:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 4UsGpuo7-s48 for ; Fri, 24 Feb 2017 05:20:04 -0800 (PST) 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 40EAA12945D for ; Fri, 24 Feb 2017 05:20:04 -0800 (PST) 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 v1ODGJx0004172; Fri, 24 Feb 2017 08:19:57 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 28tcvu028w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Feb 2017 08:19:57 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1ODJtuT015321; Fri, 24 Feb 2017 08:19:56 -0500 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 v1ODJnKY015251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Feb 2017 08:19:50 -0500 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 24 Feb 2017 13:19:34 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.76]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0319.002; Fri, 24 Feb 2017 08:19:34 -0500 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , IPv6 Ops WG Thread-Topic: [v6ops] Requirements for IPv6 routers in various locations Thread-Index: AQHSjKhXtHWDIHJXh0Km1yvSz3xBHaF0jVsAgAADQACAAHJfgIABs1Qw Date: Fri, 24 Feb 2017 13:19:33 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DACA276@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> <65EF9449-6FCC-4666-983F-E33E9812C9F3@consulintel.es> In-Reply-To: <65EF9449-6FCC-4666-983F-E33E9812C9F3@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.252.217] 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-02-24_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702240130 Archived-At: Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 13:20:05 -0000 PiBDYW4gd2UgZGVmaW5lIHdoYXQgaXMgYSBjdXN0b21lciBlZGdlPw0KDQpSRkMgNzA4NCBhbHJl YWR5IGluY2x1ZGVzIGEgZGVmaW5pdGlvbiBvZiB3aGF0IGl0IG1lYW5zOg0KDQpJUHY2IEN1c3Rv bWVyIEVkZ2UgUm91dGVyOg0KYSBub2RlIGludGVuZGVkIGZvciBob21lIG9yIHNtYWxsLW9mZmlj ZSB1c2UgdGhhdCBmb3J3YXJkcyBJUHY2IHBhY2tldHMgbm90IGV4cGxpY2l0bHkgYWRkcmVzc2Vk IHRvIGl0c2VsZi4gIFRoZSBJUHY2IENFIHJvdXRlciBjb25uZWN0cyB0aGUgZW5kLXVzZXIgbmV0 d29yayB0byBhIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29yay4NCg0KSSB3b3VsZCBzdWdnZXN0IG5v dCB0cnlpbmcgdG8gY2hhbmdlIHRoaXMgZGVmaW5pdGlvbiBvZiB0aGlzIHRlcm0sIGJlY2F1c2Ug SSB0aGluayB0aGF0IHdvdWxkIGJlIGNvbmZ1c2luZy4gSWYgYSBtb3JlIGVuY29tcGFzc2luZyB0 ZXJtIGlzIG5lZWRlZCwgSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY3JlYXRlIGEgbmV3 IHRlcm0uDQpJIHdvdWxkIGFsc28gYmUgc3Ryb25nbHkgb3Bwb3NlZCB0byBhbnkgYXR0ZW1wdCBh dCBhIFJGQyA3MDg0IHVwZGF0ZSB0aGF0IGNoYW5nZWQgdGhlIHNjb3BlIG9mIFJGQyA3MDg0Lg0K DQo+IDEpIFB1cmUgcmVzaWRlbnRpYWwNCj4gMikgUmVzaWRlbnRpYWwgd2l0aCBzbWFsbCBob21l IG9mZmljZQ0KPiAzKSBSZXNpZGVudGlhbC90ZWNoaWUgKHdpdGggb3Igdy9vIGhvbWUgb2ZmaWNl KSB0aGF0IGhhdmUgZXhwb3J0ZWQgc2VydmljZXMNCj4gKGVtYWlsIHNlcnZlciwgd2ViIHNlcnZl ciwgVlBOIHNlcnZlciwgZXRjLikuDQo+IDQpIFNtYWxsIGhvbWUgb2ZmaWNlDQo+IDUpIFNNRXMg d2l0aCBqdXN0IHVzZSBJbnRlcm5ldCBmb3Ig4oCcYnJvd3NpbmfigJ0sIGVtYWlsaW5nLCBldGMu DQo+IDYpIFNNRXMgYXMgaW4gdGhlIHByZXZpb3VzIGNhc2UgdGhhdCBhbHNvIGhhdmUgZXhwb3J0 ZWQgc2VydmljZXMgKGVtYWlsDQo+IHNlcnZlciwgd2ViIHNlcnZlciwgVlBOIHNlcnZlciwgZXRj LikuDQoNCkNsZWFybHksIDEsIDIsIGFuZCA0IGFyZSBpbmNsdWRlZCBpbiB0aGUgUkZDIDcwODQg ZGVmaW5pdGlvbi4gSWYgdGhlIG5lZWRzIG9mIDMsIDUsIGFuZCA2IGFyZSBtZXQgYnkgYSBkZXZp Y2UgZGVzaWduZWQgZm9yIDEvMi80LCB0aGVuIHRoZXkgYXJlIGNlcnRhaW5seSB3ZWxjb21lIHRv IHVzZSBpdC4gSWYgc3VjaCBhIGRldmljZSBkb2VzIG5vdCBtZWV0IHRoZSBuZWVkcyBvZiAzLzUv NiwgdGhlbiBpdCBkb2Vzbid0IG1lZXQgdGhlaXIgbmVlZHMuDQoNCkJhcmJhcmEgDQo= From nobody Fri Feb 24 05: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 EACBF129735 for ; Fri, 24 Feb 2017 05:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 D-7Q_t5w8acB for ; Fri, 24 Feb 2017 05:32:27 -0800 (PST) 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 C17E6129712 for ; Fri, 24 Feb 2017 05:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487943140; x=1488547940; 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=eRSvNQMTTxTLIKXwZ3APFwOiE D1OttSW7UJaJAP9dII=; b=m/CSJG1ScUfVwPVLkIkEIL9TXiA6YMqBflSup0uiu 0+ByL7+rXp1hgj72sb8heJtjCrzUVBiVoqL/doK+6clWm7CBL3v1VtFexPq5p5+3 pXKqrsHZUvEjqzG9gKuvz4h6uITO9C7AQrBqa+waQOQN5TZhS29PGnBlVF9aA7CE Fc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=jm6g74HG9e5TX7q9DoSEWV7M2FWNh7fqJJxxSz6hrbQmsdCOqLU2MhlTHU7R 0bjzBkyYHjxX5+9i+bxpO23xtOcVapqt1WmxcuAL4JItyR+e5oANBZAuJ 0lGz3GbjtUrn7k7E+09ozi/uARMtpZ3S3C1hfww73AUWEIZK6pXizU=; X-MDAV-Processed: mail.consulintel.es, Fri, 24 Feb 2017 14:32:20 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 24 Feb 2017 14:32:17 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005373615.msg for ; Fri, 24 Feb 2017 14:32:17 +0100 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:170224:md50005373615::h/IdfD8bBs26qIVi:00000PPi X-Return-Path: prvs=1228d0687a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Fri, 24 Feb 2017 14:32:13 +0100 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: <24EBE27C-C207-4025-AC2F-8D55617A56EB@consulintel.es> Thread-Topic: [v6ops] Requirements for IPv6 routers in various locations References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> <65EF9449-6FCC-4666-983F-E33E9812C9F3@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DACA276@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DACA276@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 13:32:29 -0000 Hi Barbara, Then fully agree ! I think the main difference between the =E2=80=9C2 groups=E2=80=9D that you= differentiate is that in the second group the CE needs to support the abil= ity to either being setup as a =E2=80=9Cbridge=E2=80=9D or be able to have = a DMZ or to allow ports/protocols forwarding. Actually, I even think that 5 is part of your =E2=80=9Cfirst=E2=80=9D group= (so together are 1, 2, 4 and 5) and only 3 and 6 are in the second group. So, according to this, I don=E2=80=99t see the need to have 2 different doc= uments, just un update of the RFC7084 (and as you said, not changing the de= finition of the terms neither the scope). Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: viernes, 24 de febrero de 2017, 14:19 Para: "jordi.palet@consulintel.es" , IPv6 Ops W= G Asunto: RE: [v6ops] Requirements for IPv6 routers in various locations > Can we define what is a customer edge? =20 RFC 7084 already includes a definition of what it means: =20 IPv6 Customer Edge Router: a node intended for home or small-office use that forwards IPv6 packets= not explicitly addressed to itself. The IPv6 CE router connects the end-u= ser network to a service provider network. =20 I would suggest not trying to change this definition of this term, beca= use I think that would be confusing. If a more encompassing term is needed,= I think it would be better to create a new term. I would also be strongly opposed to any attempt at a RFC 7084 update th= at changed the scope of RFC 7084. =20 > 1) Pure residential > 2) Residential with small home office > 3) Residential/techie (with or w/o home office) that have exported se= rvices > (email server, web server, VPN server, etc.). > 4) Small home office > 5) SMEs with just use Internet for =E2=80=9Cbrowsing=E2=80=9D, emaili= ng, etc. > 6) SMEs as in the previous case that also have exported services (ema= il > server, web server, VPN server, etc.). =20 Clearly, 1, 2, and 4 are included in the RFC 7084 definition. If the ne= eds of 3, 5, and 6 are met by a device designed for 1/2/4, then they are ce= rtainly welcome to use it. If such a device does not meet the needs of 3/5/= 6, then it doesn't meet their needs. =20 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 Fri Feb 24 06:34: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 F224C1296AB for ; Fri, 24 Feb 2017 06:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 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, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 y_3uWPBxX_yA for ; Fri, 24 Feb 2017 06:34:44 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B20F1295F7 for ; Fri, 24 Feb 2017 06:34:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1OEYgIV017984 for ; Fri, 24 Feb 2017 15:34:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 055C120B79F for ; Fri, 24 Feb 2017 15:34:42 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EFDA720B781 for ; Fri, 24 Feb 2017 15:34:41 +0100 (CET) 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 v1OEYf4w023554 for ; Fri, 24 Feb 2017 15:34:41 +0100 To: v6ops@ietf.org References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> From: Alexandre Petrescu Message-ID: Date: Fri, 24 Feb 2017 15:34:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 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] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 14:34:46 -0000 Le 24/02/2017 à 10:04, Erik Kline a écrit : > On 24 February 2017 at 12:41, Christopher Morrow > > wrote: > > gosh people are being literal today :) > > > On Thu, Feb 23, 2017 at 10:34 PM, Lorenzo Colitti > wrote: > > On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow > > wrote: > >> The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send substantive >> comments to the ietf@ietf.org mailing lists >> by > 2017-03-01. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either > case, please retain the >> beginning of the Subject line to allow automated sorting." > > Nothing in the past really matters here, what matters is: "Is the bis > draft all set, did we fix all the things which must be fixed before > this draft becomes a real 'standard'?" > > > I don't think you can say nothing in the past matters here. We know > that there have been host implementations that relied on this > guarantee, and we have to consider that if we change the standard, > those implementations will become non-compliant. > > > I don't think the proposed (now 160+ messages back) text really says: > "FREE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use > /64 because the application you are being placed into requires it > (slac, blah and blah and ilnp and blah - see rfc7k) then do that, > else any other prefix length works" > > how's that not 'ok' for host folks? "Hi, my host is going to be in a > slaac world.. so /64 it is!" > > > For manual assignment among consenting adults: as you like it. (For > all prefixes longer than /64, the trailing 64bits would still end up > being unique; there is no real issue here.) I disagree. There are still problems with that. For example when manually adding an address w/o specifying a plen it is a 64 route that pops up as a 'connected' route in the routing table. That's not normal. Nobody told it 64 yet it shows there. It's like in IPv4 adding 1.1.1.1 a /8 pops there because it's a class A. Alex > And I gather everyone agrees that at a minimum the /127 RFC and > other working-group-graduated documents should be suitably > incorporated and referenced. > > Otherwise, this feels like another round of "why isn't IPv6 just > 128bit IPv4?" IMHO having /64 as the logical unit of allocation to > network leaves is a very good thing. > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Feb 24 07:04: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 CCF5C129DDC; Fri, 24 Feb 2017 07:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlDm0y-IR0BK; Fri, 24 Feb 2017 07:04:13 -0800 (PST) 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 00AC1129C51; Fri, 24 Feb 2017 07:04:12 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id x35so18641362qtc.2; Fri, 24 Feb 2017 07:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=A9+asw9Bmo07PkGbQ7wn/YiAE86xsNYaxCiuOCSvxyc=; b=XI5JNa+ZNgTNE3VVWXQWGhbNV+SYF3HuSqWibhkCmxJ9i1QvGAHQD4AjbdnSrM9X2Q L4N1xKW2IyFUOY0AQVzXkTVszn2cmk8XiWllzD77WuDPK8SND9RToLoEOsjjN4FkZcPJ 6My1kgFj0QGkpQxZv5OiqOmj7PZoNYCUuuBKtH3+hqHKn9y/TNLi75nkKrm80xbFB7dC EIZrw0LQp9dAu/iou4GUs2Kx/LNg4R85kADaUIg09XKHO2APYOmwOwDu2u2Szw+P0tCF tBDwPnftu41nZ3xMOFydPcyq3NUZK2m5Tkk3oGRQnaXGtTKtL/s33tNd7/LcS+gSyjv1 rO1w== 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=A9+asw9Bmo07PkGbQ7wn/YiAE86xsNYaxCiuOCSvxyc=; b=MLUOr3sChjrgJ4sPM3iI6RmRTYFe5RNIbRo5z2hwFfh/no6RGCYd3hSW6N99IVW+TG smyiT+F1adyP7v8f+tlF3idN3NIBEN/fJGgIcmj2YmoBJQ2SQ3aLkMBgfEHRfv7agSbL yJwm0h/SY8nvBuKg8kgKOutbKO5jIfj2UOnmguYNo7uC+RdINwVS30QjB+mTz42UfL/S wivwh6AHiNshNSb3zSlwV5YYvU1i3vwZkyM5beYtKDkrABuZO7Uk0MAP0SqS9NnWy8qJ rOIbEo5pLkFSl6ZUJY3l2+ex+0iDDtWBRXfddDMgd3nvEL5c1zaXHtTOS0uwi4lR1ojs WfyQ== X-Gm-Message-State: AMke39lmNEGJY85d5W2Pv1Igclo8C0jiCDErzJtmyY5GO8FIf14HbBzXg8blGed2WKJRDldzUnR3jPZ/HKxShQ== X-Received: by 10.200.53.209 with SMTP id l17mr2903513qtb.281.1487948651902; Fri, 24 Feb 2017 07:04:11 -0800 (PST) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.91.71 with HTTP; Fri, 24 Feb 2017 07:04:11 -0800 (PST) In-Reply-To: References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> From: Christopher Morrow Date: Fri, 24 Feb 2017 10:04:11 -0500 X-Google-Sender-Auth: _JVotMiJb4KUvHpx3vUJPz_KiwU Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=001a1143c7b0d774d20549480a54 Archived-At: Cc: IPv6 Operations , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 15:04:15 -0000 --001a1143c7b0d774d20549480a54 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 24, 2017 at 4:04 AM, Erik Kline wrote: > On 24 February 2017 at 12:41, Christopher Morrow > wrote: > >> gosh people are being literal today :) >> >> >> On Thu, Feb 23, 2017 at 10:34 PM, Lorenzo Colitti >> wrote: >> >>> On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow < >>> morrowc.lists@gmail.com> wrote: >>> >>>> > The IESG plans to make a decision in the next few weeks, and solicits >>>> > final comments on this action. Please send substantive comments to the >>>> > ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments >>>> may be >>>> > sent to iesg@ietf.org instead. In either case, please retain the >>>> > beginning of the Subject line to allow automated sorting." >>>> >>>> Nothing in the past really matters here, what matters is: "Is the bis >>>> draft all set, did we fix all the things which must be fixed before this >>>> draft becomes a real 'standard'?" >>>> >>> >>> I don't think you can say nothing in the past matters here. We know that >>> there have been host implementations that relied on this guarantee, and we >>> have to consider that if we change the standard, those implementations will >>> become non-compliant. >>> >> >> I don't think the proposed (now 160+ messages back) text really says: >> "FREE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64 >> because the application you are being placed into requires it (slac, blah >> and blah and ilnp and blah - see rfc7k) then do that, else any other prefix >> length works" >> >> how's that not 'ok' for host folks? "Hi, my host is going to be in a >> slaac world.. so /64 it is!" >> > > For manual assignment among consenting adults: as you like it. (For all > prefixes longer than /64, the trailing 64bits would still end up being > unique; there is no real issue here.) > > I agree. > And I gather everyone agrees that at a minimum the /127 RFC and other > working-group-graduated documents should be suitably incorporated and > referenced. > > I think that's in the proposed text, yes... or easily is a list of [this][that][theother] > Otherwise, this feels like another round of "why isn't IPv6 just 128bit > IPv4?" IMHO having /64 as the logical unit of allocation to network leaves > is a very good thing. > For enduser deployment picking 'something' (/64 is perfectly fine) is totally sane, and already in the proposed text. The sticking point isn't so much: "ipv6 is ipv4 with more bits" (which the network treats it as) but: "hey, we know we allocate longer prefixes all the time for 'reasons' on things that have bespoke config, let's not make that harder by letting vendors/etc take shortcuts... acknowledge the fact that we really do have interfaces with >/64 deployed. I don't see how that damages network-ops folks, nor host-ops, nor developers. There is certainly a discussion for 'not this list' about networking providers doing 'short sighted' things on their network with respect to attached customers, but... that's not this document and not this discussion and not this list (except as an opionion/editorial piece). --001a1143c7b0d774d20549480a54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 24, 2017 at 4:04 AM, Erik Kline <ek@google.com> = wrote:
On 24 February = 2017 at 12:41, Christopher Morrow <morrowc.lists@gmail.com> wrote:
gosh people= are being literal today :)

=

On Thu, Feb 23, 2= 017 at 10:34 PM, Lorenzo Colitti <lorenzo@google.com> wrote= :
On Fri, Feb 24, 2017 at 12:23 PM, Chr= istopher Morrow <morrowc.lists@gmail.com> wrote:
> The IESG plans to make a decision in the= next few weeks, and solicits
> final comments on this action.= Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-03-= 01. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case= , please retain the
> beginning of the Subject line to allow a= utomated sorting."

Nothing in the past really= matters here, what matters is: "Is the bis draft all set, did we fix = all the things which must be fixed before this draft becomes a real 'st= andard'?"

I don't think you can say nothing in the past matters here. We k= now that there have been host implementations that relied on this guarantee= , and we have to consider that if we change the standard, those implementat= ions will become non-compliant.

I don&#= 39;t think the proposed (now 160+ messages back) text really says: "FR= EE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to = use /64 because the application you are being placed into requires it (slac= , blah and blah and ilnp and blah - see rfc7k) then do that, else any other= prefix length works"

how's that not 'ok' for host folks? "= Hi, my host is going to be in a slaac world.. so /64 it is!"

For manual assignment among = consenting adults: as you like it. =C2=A0(For all prefixes longer than /64,= the trailing 64bits would still end up being unique; there is no real issu= e here.)


=
I agree.
=C2=A0
<= div>And I gather everyone agrees that at a minimum the /127 RFC and other w= orking-group-graduated documents should be suitably incorporated and refere= nced.


I think that's in the proposed text, yes... or easily is a list of [t= his][that][theother]
=C2=A0
<= div dir=3D"ltr">
=
Otherwise, this feels like another round of "why isn't = IPv6 just 128bit IPv4?" =C2=A0IMHO having /64 as the logical unit of a= llocation to network leaves is a very good thing.

For enduser deploym= ent picking 'something' (/64 is perfectly fine) is totally sane, an= d already in the proposed text. The sticking point isn't so much: "= ;ipv6 is ipv4 with =C2=A0more bits" (which the network treats it as) b= ut: "hey, we know we allocate longer prefixes all the time for 're= asons' on things that have bespoke config, let's not make that hard= er by letting vendors/etc take shortcuts... acknowledge the fact that we re= ally do have interfaces with >/64 deployed.

I don't see how that damages n= etwork-ops folks, nor host-ops, nor developers.

There is certainly a discussion f= or 'not this list' about networking providers doing 'short sigh= ted' things on their network with respect to attached customers, but...= that's not this document and not this discussion and not this list (ex= cept as an opionion/editorial piece).
--001a1143c7b0d774d20549480a54-- From nobody Fri Feb 24 08:24: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 A89791299AE; Fri, 24 Feb 2017 08:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAoWXPWu_RZi; Fri, 24 Feb 2017 08:24:08 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A7212988C; Fri, 24 Feb 2017 08:24:08 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 0EBD14D9AD; Fri, 24 Feb 2017 16:24:08 +0000 (UTC) Date: Fri, 24 Feb 2017 16:24:08 +0000 From: heasley To: JORDI PALET MARTINEZ Message-ID: <20170224162408.GD93870@shrubbery.net> References: <58AF313D.3020905@foobar.org> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> <20170224075940.GW2367@Space.Net> <4BC61E42-0A36-44E9-8FB9-2062547D939F@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BC61E42-0A36-44E9-8FB9-2062547D939F@consulintel.es> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IPv6 Operations , IETF Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 16:24:09 -0000 Fri, Feb 24, 2017 at 09:12:45AM +0100, JORDI PALET MARTINEZ: > So, are we spending too much time in this and is not really necessary? > > Can we live with the actual text with has been in the market, and working well, for “x†years? > > Can we make too many (or few very important) changes in an RFC in the way to STD, or we need first to have those changes in an RFC for “x†years and “n†verified implementations, before we move to STD? If the answer is no, is the balance between living with the current text but moving to STD a better option than waiting for “x†years again? I prefer the document is fixed now; start the process of fixing classful implementations now, rather than in x years - or please save operators from those x+ years of pain. From nobody Fri Feb 24 09:50: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 B3D9812943F for ; Fri, 24 Feb 2017 09:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Xj_6EKyDOFxn for ; Fri, 24 Feb 2017 09:50:16 -0800 (PST) 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 68EFC12944A for ; Fri, 24 Feb 2017 09:50:16 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id z128so14051427pgb.0 for ; Fri, 24 Feb 2017 09:50:16 -0800 (PST) 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=u+o65mu/Y0BoXJrj/BbREVtUNk4kHTeA3U83kUywvG8=; b=j5hynpqipDpKCtgw90ETLoZoMBX8A0sBYrvZ4vmbKmgVmY5YeOHPbrUsJ6lwGATZbx qTzH9D/016i8UC7KfQwrVpBudOJ78UdfJnkI01zUOYtiO3R/kH9jZUIHqg5PoXhgTTjE +PkFS/515hZxQ3CxpJACcNXHE//GLdw6ug67VqPs0hg4ZORE6+/rOk1Ljji2hp7Vd6bq x5UPJOKyCutInjub/o+WP7UJxa3ncAo8YD0uOMmXHXBVcS0sqRu6xN/KYldt6A52zUci A1HI4Ghq/W81ta0Zyp9PXM63X9kCFoTIXndO5yC4QabDHPf8i/GWlIpFWBXFvnBAUglQ Ndng== 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=u+o65mu/Y0BoXJrj/BbREVtUNk4kHTeA3U83kUywvG8=; b=MFBd5yMxQXf8HHE8+PRT4rjT6rNCGReJXZdMgZ/ONSpdG+f87Sj6xOjVmBnQjQNDmm KH8RRlVvxA3biybYv4UCcohOVoSjpXZi5UwEuZr0an+OloeHok20daKcrNL9ViXoS1RY yT1UGpEXCrdBsfvTL+LYq7oeFT1Xk5TBRcI2aN9Vh8wVxgrgrszs+CAVAhFlfDANmySX uVo3bWtAAilpficX1NbRq9O3OUHGWHo7izKWkf0MkLV8sIfvTEwF3Q7SJMflJAcQp/pR PUQqGO1IC5ejHgbEr6GjcJGjo/AMcagYH236zFc3uob1ZQLAMH8Cq6SlekoHZ1lbjwxO QHTA== X-Gm-Message-State: AMke39lYPeNWlQDUvara3MaFoIFxhwbHiZnhBOeX4zU4aleOpNZFKCJ0fgYYw/ARG9jT7SwI X-Received: by 10.99.168.2 with SMTP id o2mr4852527pgf.159.1487958615696; Fri, 24 Feb 2017 09:50:15 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id t12sm16289263pfg.14.2017.02.24.09.50.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 09:50:14 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_C64962F9-19F2-4104-B78F-94858CBE1BF1" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 09:50:23 -0800 References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> To: IPv6 Ops WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:50:17 -0000 --Apple-Mail=_C64962F9-19F2-4104-B78F-94858CBE1BF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 21, 2017, at 17:09, Fred Baker wrote: >=20 > Let me throw a question to the working group. One way to approach this = is to try to push requirements for all of those markets into one = document, which is what I think James is trying to do. Another way is to = separate them, which is what I think Barbara is trying to do. I'm not = going to say that either is automatically right or automatically wrong, = but they are different, and I have visions of an argument that takes = forever, boils blood, and nobody wins, if we don't systematically = address it. For the record, this misrepresents me. I do NOT want to push = requirements for all the various IPv6 router deployment scenarios into a = single document. I want to see RFC 7084 updated with its focus on = residential gateways retained. I do NOT believe that all routers should = feature implementations of Home Network Control Protocol (HNCP) = services. In = > I = gave my reasoning in support of requiring residential gateways to = implement HNCP services, and I don=E2=80=99t see how any of my comments = there could be easily misinterpreted as a call to apply this requirement = to all IPv6 routers. If anyone is taking the position that Fred ascribes to me in this = comment, I=E2=80=99m not sure who it is. --james woodyatt > --Apple-Mail=_C64962F9-19F2-4104-B78F-94858CBE1BF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 21, 2017, at 17:09, Fred Baker <fredbaker.ietf@gmail.com> wrote:

Let me throw a question to the working group. = One way to approach this is to try to push requirements for all of those = markets into one document, which is what I think James is trying to do. = Another way is to separate them, which is what I think Barbara is trying = to do. I'm not going to say that either is automatically right or = automatically wrong, but they are different, and I have visions of an = argument that takes forever, boils blood, and nobody wins, if we don't = systematically address it.

For the record, this misrepresents me. = I do NOT want to push requirements for all the various IPv6 router = deployment scenarios into a single document. I want to see RFC 7084 = updated with its focus on residential gateways retained. I do NOT = believe that all routers should feature implementations of Home Network = Control Protocol (HNCP) services. In <https://www.ietf.org/mail-archive/web/v6ops/current/msg25497.ht= ml> I gave my reasoning in support of requiring residential = gateways to implement HNCP services, and I don=E2=80=99t see how any of = my comments there could be easily misinterpreted as a call to apply this = requirement to all IPv6 routers.

If anyone is taking the position that = Fred ascribes to me in this comment, I=E2=80=99m not sure who it = is.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_C64962F9-19F2-4104-B78F-94858CBE1BF1-- From nobody Fri Feb 24 11:56: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 0F3821294EF for ; Fri, 24 Feb 2017 11:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 w5tqIWzb_GnO for ; Fri, 24 Feb 2017 11:56:52 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5DC1294EC for ; Fri, 24 Feb 2017 11:56:49 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0B57660F00 for ; Fri, 24 Feb 2017 20:56:47 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id BB104600E4; Fri, 24 Feb 2017 20:56:46 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id AD2DC70A76; Fri, 24 Feb 2017 20:56:46 +0100 (CET) Date: Fri, 24 Feb 2017 20:56:46 +0100 From: Gert Doering To: Christopher Morrow Message-ID: <20170224195646.GI2367@Space.Net> References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IPv6 Operations , ietf Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 19:56:54 -0000 Hi, On Fri, Feb 24, 2017 at 10:04:11AM -0500, Christopher Morrow wrote: > For enduser deployment picking 'something' (/64 is perfectly fine) is > totally sane, and already in the proposed text. The sticking point isn't so > much: "ipv6 is ipv4 with more bits" (which the network treats it as) but: > "hey, we know we allocate longer prefixes all the time for 'reasons' on > things that have bespoke config, let's not make that harder by letting > vendors/etc take shortcuts... acknowledge the fact that we really do have > interfaces with >/64 deployed. +1 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 Fri Feb 24 12:48: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 7ED42129507; Fri, 24 Feb 2017 12:48:43 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" 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 DdPXfYSVf2v4; Fri, 24 Feb 2017 12:48:41 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 61080129502; Fri, 24 Feb 2017 12:48:39 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1chMn7-0000DhC; Fri, 24 Feb 2017 21:48:37 +0100 Message-Id: To: ietf@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> In-reply-to: Your message of "Fri, 24 Feb 2017 10:04:11 -0500 ." Date: Fri, 24 Feb 2017 21:48:36 +0100 Archived-At: Cc: IPv6 Operations , Christopher Morrow Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:48:43 -0000 >For enduser deployment picking 'something' (/64 is perfectly fine) is >totally sane, and already in the proposed text. The sticking point isn't so >much: "ipv6 is ipv4 with more bits" (which the network treats it as) but: >"hey, we know we allocate longer prefixes all the time for 'reasons' on >things that have bespoke config, let's not make that harder by letting >vendors/etc take shortcuts... acknowledge the fact that we really do have >interfaces with >/64 deployed. I wonder if (in typical IPv4 fashion) we mix address configuration with onlink prefixes. There are three generic address configuration mechanisms, SLAAC, DHCP IA_NA, and manual. Of these only SLAAC cares about the prefix length. And there are good reasons to keep SLAAC at 64 bits. (If would strongly suggest to not pick a random 32 bit IID, combine it with a /96 and then hope that duplicate addresses detection in all cases will safe the day. So for longer prefixes, use DHCP or manual configuration.) For DHCP and manual configuration, an address is just that, an address. So in that case, the prefix length actually refers to the length of the onlink prefix. Note that RFC 4861 (Neighbor Discovery) already specifies that an onlink prefix can have arbitrary length. So it safe to assume that hosts can support arbitrary length onlink prefixes. Otherwise those host implementations are already broken. DHCP doesn't have a prefix length, so that's not an issue. So that leaves hosts that mistakenly combine manual address configuration with implicit onlink prefix configuration and an arbitrary restriction on the prefix length. It is safe to declare those hosts broken. From nobody Mon Feb 27 07:22: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 CC96612A10A for ; Mon, 27 Feb 2017 07:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Y0P_xhXfJe0V for ; Mon, 27 Feb 2017 07:21:55 -0800 (PST) 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 82A3512A0E2 for ; Mon, 27 Feb 2017 07:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488208911; x=1488813711; 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=MIgC+cBnd4onvqpThMJRm6sZJ KZ7s9hT4ASuvaye4Og=; b=G4VWNFzN9/T3Tmqa764EtWv4WbjEHBdUGzY+n4zI1 YffQfSa7EZi7ftNyln38BM9V3m7fEi9ajVM/Tpda3/Luv+h1IFpcuCE+zrcHPRy/ nfmwd46d9V7qzxYiqcLmOfvdRhYK3Fr826uPYHqY52Kl6tRjwMqgVm9Dur2WepdK Yc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=V8xy73xhnCp1sJ7aibc8A92aLH5sDyWsW/SngI2vzQaY2gvGFT96uzIvVcLP 4WtT9xeM4VEylkxLUmYj5fTf7AN0n/KkOgWE7mOjwnEWAQdecTUAGkwuj leEb01y2ol2P8Md/40+kVEwHXfUgJ8rqnSKEEnP1pU2WSwfCBHoXFA=; X-MDAV-Processed: mail.consulintel.es, Mon, 27 Feb 2017 16:21:51 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 27 Feb 2017 16:21:50 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005375098.msg for ; Mon, 27 Feb 2017 16:21:49 +0100 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:170227:md50005375098::iizxU6qP0BTztIp4:00002ah6 X-Return-Path: prvs=1231b8dbd5=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Mon, 27 Feb 2017 16:21:48 +0100 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: <1BE1CAD4-138D-4AE4-8AD0-2334465A2D86@consulintel.es> Thread-Topic: [v6ops] Requirements for IPv6 routers in various locations References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <03B10A5B-ABE3-4515-90B9-D16A41039229@google.com> <2D09D61DDFA73D4C884805CC7865E6114DAC7803@GAALPA1MSGUSRBF.ITServices.sbc.com> <65EF9449-6FCC-4666-983F-E33E9812C9F3@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DACA276@GAALPA1MSGUSRBF.ITServices.sbc.com> <24EBE27C-C207-4025-AC2F-8D55617A56EB@consulintel.es> In-Reply-To: <24EBE27C-C207-4025-AC2F-8D55617A56EB@consulintel.es> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Requirements for IPv6 routers in various locations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:22:01 -0000 Hi all, I=E2=80=99ve submitted a new version for this document. Barbara, after thinking again for several hours on this classification, I= =E2=80=99ve the feeling that all those cases have the same requirements as = the ones in the original document. Let me explain why. Those 2 cases that n= eed to =E2=80=9Cexport services=E2=80=9D (by means of DMZ, virtual host, po= rt/protocol forwarding, etc.), actually will need that only for IPv4 (becau= se the private addresses behind NAT), and this is already supported by all = the devices in the market, so we don=E2=80=99t need to have any =E2=80=9Cne= w=E2=80=9D IPv4 requirements for that. For IPv6, well, you have GUA, so being all the addresses global, they are a= lways reachable, right? Of course, it will be good that any IPv6 CE has a c= onfigurable firewall, and may be enabled by default, but I recall in the or= iginal document, there is already text about that, so probably we don=E2=80= =99t want to change it. So according to this, and responding to Fred comments on the decision about= one or several documents for different scenarios, I think that leaving out= special requirements for data-centers, content-providers, big enterprises,= etc., the requirements for a CE =E2=80=9Cbaseline=E2=80=9D are the same in= all the cases, and the differences are more related to more memory, more i= nterfaces/types/speed, performance, etc. So, in my opinion, this document is good for most of the residential users,= SOHO, SMEs, and probably some degree of medium-to-big organizations, and m= ay be, if we want other scenarios we can either =E2=80=9Cupgrade=E2=80=9D t= his document to include them, or have other documents that state as =E2=80= =9Cbaseline=E2=80=9D this document to avoid repeating text. I think the sec= ond option is close to what Tim suggested. So, the new version is: https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis/ Let me try to summarize the main changes: 1) 6rd and DS-Lite are back SHOULD as in the original document. 2) Requirements for 464XLAT, MAP-E/T, lw4o6 and 6in4 are now completed, and= all them are SHOULD, same as 6rd and DS-Lite. 3) Added a section =E2=80=9CUsage Scenarios=E2=80=9D to clarify what I indi= cated above. 4) Added, as SHOULD, support for HNCP as a LAN requirement. 5) Added requirement for support of DHCPv6 S46 priority option RFC8026. 6) Added requirement for support of DHCPv4-over-DHCPv6 (DHCP4o6) transport = RFC7341. Comments? Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de JORDI PALET MARTINEZ Responder a: Fecha: viernes, 24 de febrero de 2017, 14:32 Para: IPv6 Ops WG Asunto: Re: [v6ops] Requirements for IPv6 routers in various locations Hi Barbara, =20 Then fully agree ! =20 I think the main difference between the =E2=80=9C2 groups=E2=80=9D that= you differentiate is that in the second group the CE needs to support the = ability to either being setup as a =E2=80=9Cbridge=E2=80=9D or be able to h= ave a DMZ or to allow ports/protocols forwarding. =20 Actually, I even think that 5 is part of your =E2=80=9Cfirst=E2=80=9D g= roup (so together are 1, 2, 4 and 5) and only 3 and 6 are in the second gro= up. =20 So, according to this, I don=E2=80=99t see the need to have 2 different= documents, just un update of the RFC7084 (and as you said, not changing th= e definition of the terms neither the scope). =20 Regards, Jordi =20 =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: viernes, 24 de febrero de 2017, 14:19 Para: "jordi.palet@consulintel.es" , IPv6 O= ps WG Asunto: RE: [v6ops] Requirements for IPv6 routers in various locations =20 > Can we define what is a customer edge? =20 RFC 7084 already includes a definition of what it means: =20 IPv6 Customer Edge Router: a node intended for home or small-office use that forwards IPv6 pac= kets not explicitly addressed to itself. The IPv6 CE router connects the e= nd-user network to a service provider network. =20 I would suggest not trying to change this definition of this term, = because I think that would be confusing. If a more encompassing term is nee= ded, I think it would be better to create a new term. I would also be strongly opposed to any attempt at a RFC 7084 updat= e that changed the scope of RFC 7084. =20 > 1) Pure residential > 2) Residential with small home office > 3) Residential/techie (with or w/o home office) that have exporte= d services > (email server, web server, VPN server, etc.). > 4) Small home office > 5) SMEs with just use Internet for =E2=80=9Cbrowsing=E2=80=9D, em= ailing, etc. > 6) SMEs as in the previous case that also have exported services = (email > server, web server, VPN server, etc.). =20 Clearly, 1, 2, and 4 are included in the RFC 7084 definition. If th= e needs of 3, 5, and 6 are met by a device designed for 1/2/4, then they ar= e certainly welcome to use it. If such a device does not meet the needs of = 3/5/6, then it doesn't meet their needs. =20 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 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 Tue Feb 28 00:13: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 CE6A41294EA for ; Tue, 28 Feb 2017 00:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qakiH1IzSkPg for ; Tue, 28 Feb 2017 00:13:43 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB64B1294E9 for ; Tue, 28 Feb 2017 00:13:42 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 87FD280B11; Tue, 28 Feb 2017 09:13:39 +0100 (CET) References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> To: IPv6 Operations From: Fernando Gont X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> Message-ID: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> Date: Tue, 28 Feb 2017 05:13:25 -0300 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: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 08:13:46 -0000 Folks, Based on a recent discussion regarding the problem of conveying DNS information in IPv6 networks, we have submitted this short I-D, in the hopes of getting the aforementioned problem solved. Your feedback will be appreciated. Thanks! Fernando (and co-autors) -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-host-configuration-00.txt Date: Mon, 27 Feb 2017 23:51:03 -0800 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , Madelen Garcia Corbo , Madelen Corbo , Guillermo Gont A new version of I-D, draft-gont-v6ops-host-configuration-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-host-configuration Revision: 00 Title: On the Dynamic/Automatic Configuration of IPv6 Hosts Document date: 2017-02-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configuration-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00 Abstract: IPv6 has two different mechanisms for dynamic/automatic host configuration: SLAAC and DHCPv6. These two mechanisms allow for the configuration of IPv6 addresses and a number of network parameters. While there is overlap in the parameters that can be configured via these two protocols, different implementations support only subsets of such parameters with either mechanism, or have no support for DHCPv6 at all. This document analyzes a problem that arises from this situation, and mandates that all host implementations support RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 functionality in RFC 3315. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Feb 28 02:13: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 352CA128E18 for ; Tue, 28 Feb 2017 02:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-jiitKN8RiA for ; Tue, 28 Feb 2017 02:13:36 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804EA126FDC for ; Tue, 28 Feb 2017 02:13:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id BC4334E; Tue, 28 Feb 2017 11:13:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1488276811; bh=bntzltvEL+QeHhAJrFLQeJSynV/x Z5Nz57/Or1VDAlA=; b=J2IACSZXHmHEJvkD09RtSRP2K2gmkP+YVSwisMSOvRWe lrNjtPD0kk/WBEoFqP1rb13I5k+jH/M20SbcWrRtCLGT2Z/xuBSB0PY6JWh+JBM2 gWOM/t6v8yHfW45NjifMuEpOoLvnLm5Whl3f7w76kh85grHROrsiOHC2Wly1zT4= 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 DXOsR9zGrayf; Tue, 28 Feb 2017 11:13:31 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:519e:48c4:a4fb:7ef3] (unknown [IPv6:2a02:a213:a300:9300:519e:48c4:a4fb:7ef3]) (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 B7D154D; Tue, 28 Feb 2017 11:13:31 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_13FD5D23-9774-4717-96D1-51732D0C894D"; 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: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> Date: Tue, 28 Feb 2017 11:13:34 +0100 Message-Id: References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:13:38 -0000 --Apple-Mail=_13FD5D23-9774-4717-96D1-51732D0C894D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Fernando, > Based on a recent discussion regarding the problem of conveying DNS > information in IPv6 networks, we have submitted this short I-D, in the > hopes of getting the aforementioned problem solved. > > Your feedback will be appreciated. Good starting point for this discussion. Thanks! Sander --Apple-Mail=_13FD5D23-9774-4717-96D1-51732D0C894D 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----- iQEcBAEBCAAGBQJYtU1OAAoJEKAtA7D+JBO53iIH/0FJroEXd2yl8Ey4641ErrsB LVFPIfTj+P9uSns7dPBAez+XtcRgy5lmVblOqFFSvZU+zCx9CJ91B2kG9iFl9HGI w/rY1UEfrKCgmY2hPhT+3LdK51uvj7ljQ8Z2oL75i+uwTO2tHCwdUS7cSMu0oLyW 53vZFtNq2t5h5MnWt2umXj4m3teUaGuI8pE5KVAuK8JRz4fvKK0+UU8IVtCIqqBl OzK0YcUj+DqIzdLX8F3w6IeFRnF2II6C5QonYO7YeETT5+MSKCuDVPwev09FeKcS zUUU52An6WEQBAPWlo2OCyywI2bAcNwAkWMyIB3Eh4f0VKWAJY/nup5+P6res5U= =6phS -----END PGP SIGNATURE----- --Apple-Mail=_13FD5D23-9774-4717-96D1-51732D0C894D-- From nobody Tue Feb 28 02:19: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 5F23B128E18 for ; Tue, 28 Feb 2017 02:19:04 -0800 (PST) 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 q91La5M5XDCU for ; Tue, 28 Feb 2017 02:19:02 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 8E6B612706D for ; Tue, 28 Feb 2017 02:19:02 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id d1so4925323ywd.2 for ; Tue, 28 Feb 2017 02:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u+3PNGZ90D9IwX2Ejp4u+90QQCG71n2tOiLQboN8Nms=; b=GABqxDH14x5pyrN4e88oLriwn0wMyZyhNGdmCm4nDCRTkTDuCSNwXFKu9D4fKLOeAW dQ67GOf/HZRxm8l/Cdo5vKxz7RnwI2WMMdsAmkMvpOd+kjxC/2jj1FCFUBNE0cWbBgqq xm873g0+dQsDU+UDB5BfSeIKzd5lA92NGWPLHyM/MY2YCRDp3x4NfzPYng3waJGrLrhy 02esqnrDVEnF1huuCuE8EtdtWE7f4fjKNAOQK4xwJtdKMQJfiblcRk4XpMAGU9Nc72OC a9YPKSmwUvPQKVbHd7zELSD2nMl+9chjSSz1dJCyNuh+XLtz/NMyyXr0zYGhX2OIXBh3 pwFw== 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=u+3PNGZ90D9IwX2Ejp4u+90QQCG71n2tOiLQboN8Nms=; b=XNiwGsptiiqmx7/t7e/ElN+K4VVeSEL/L/ANC+cXcPe5immNQZJRZMB7jX7R8YdEhu 1njCPQ1PcHE8AdXz1+0Bz+aQ2OCQ1dC7M3ZIs5urRGWtoy+ScY8vHNN0ltW1rOX0Zs8O 5PzZS4lkQ+Krf62h7qBl0pr5v8XKxAbtfp4GP+Moy+8wQiF88jM/vv/nWLaTvhWPAF1S oxa3hqgjzXPDhRy4QLcazdYjfZLRw59JuFGJcjd+wGWNZCrcjuTj0tpqHMaYnuc+ohiX VxmJXdjwByuL8wO5ssVlLW5D23h+r5rLYenBuaKHw+ImbIVE9aDamhenJC9NCICUN/jo nLTg== X-Gm-Message-State: AMke39ke/RXaMQjN+pF6msXZBm1ranVsaUhi6YMXwCFVd29iQDqSa+t9H6iG2W3Dq26aj07wsnUW8iAEwqk8IzTc X-Received: by 10.129.183.18 with SMTP id v18mr374422ywh.217.1488277141601; Tue, 28 Feb 2017 02:19:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Tue, 28 Feb 2017 02:18:41 -0800 (PST) In-Reply-To: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> From: Erik Kline Date: Tue, 28 Feb 2017 19:18:41 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1bddf25f95b605499486ac" Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:19:04 -0000 --94eb2c1bddf25f95b605499486ac Content-Type: multipart/alternative; boundary=94eb2c1bddf25aa54805499486d8 --94eb2c1bddf25aa54805499486d8 Content-Type: text/plain; charset=UTF-8 I oppose sneaking DHCPv6 as a MUST in this document: IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], and the stateless DHCPv6 mechanism specified in [RFC3315]. No. On 28 February 2017 at 17:13, Fernando Gont wrote: > Folks, > > Based on a recent discussion regarding the problem of conveying DNS > information in IPv6 networks, we have submitted this short I-D, in the > hopes of getting the aforementioned problem solved. > > Your feedback will be appreciated. > > Thanks! > Fernando (and co-autors) > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-host-configuration-00.txt > Date: Mon, 27 Feb 2017 23:51:03 -0800 > From: internet-drafts@ietf.org > To: Fernando Gont , Gert Doering > , Madelen Garcia Corbo , > Madelen Corbo , Guillermo Gont > > > > A new version of I-D, draft-gont-v6ops-host-configuration-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-v6ops-host-configuration > Revision: 00 > Title: On the Dynamic/Automatic Configuration of IPv6 Hosts > Document date: 2017-02-27 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-host- > configuration-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00 > > > Abstract: > IPv6 has two different mechanisms for dynamic/automatic host > configuration: SLAAC and DHCPv6. These two mechanisms allow for the > configuration of IPv6 addresses and a number of network parameters. > While there is overlap in the parameters that can be configured via > these two protocols, different implementations support only subsets > of such parameters with either mechanism, or have no support for > DHCPv6 at all. This document analyzes a problem that arises from > this situation, and mandates that all host implementations support > RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 > functionality in RFC 3315. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c1bddf25aa54805499486d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I oppose sneaking DHCPv6 as a MUST in this document:
<= br>
=C2=A0 =C2=A0IPv6 hosts MUST support the SLAAC DNS optio= ns specified in [RFC6106],
=C2=A0 =C2=A0and the stateless DHCPv6 = mechanism specified in [RFC3315].

No.
<= /div>

On 28 Februa= ry 2017 at 17:13, Fernando Gont <fgont@si6networks.com> = wrote:
Folks,

Based on a recent discussion regarding the problem of conveying DNS
information in IPv6 networks, we have submitted this short I-D, in the
hopes of getting the aforementioned problem solved.

Your feedback will be appreciated.

Thanks!
Fernando (and co-autors)




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-host-configuration-00.txt
Date: Mon, 27 Feb 2017 23:51:03 -0800
From: internet-drafts@ietf.org<= /a>
To: Fernando Gont <fgont@si6net= works.com>, Gert Doering
<gert@space.net>, Madelen Garci= a Corbo <madelen.garcia16@= gmail.com>,
Madelen Corbo <madelen.gar= cia16@gmail.com>, Guillermo Gont
<ggont@si6networks.com><= br>

A new version of I-D, draft-gont-v6ops-host-configuration-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-v6ops-host-co= nfiguration
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On the Dynamic/Automatic Configura= tion of IPv6 Hosts
Document date:=C2=A0 2017-02-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:
https://www.ietf.org/= internet-drafts/draft-gont-v6ops-host-configuration-00.txt Status:
https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/
Htmlized:
https://tools.ietf.org/html/d= raft-gont-v6ops-host-configuration-00


Abstract:
=C2=A0 =C2=A0IPv6 has two different mechanisms for dynamic/automatic host =C2=A0 =C2=A0configuration: SLAAC and DHCPv6.=C2=A0 These two mechanisms al= low for the
=C2=A0 =C2=A0configuration of IPv6 addresses and a number of network parame= ters.
=C2=A0 =C2=A0While there is overlap in the parameters that can be configure= d via
=C2=A0 =C2=A0these two protocols, different implementations support only su= bsets
=C2=A0 =C2=A0of such parameters with either mechanism, or have no support f= or
=C2=A0 =C2=A0DHCPv6 at all.=C2=A0 This document analyzes a problem that ari= ses from
=C2=A0 =C2=A0this situation, and mandates that all host implementations sup= port
=C2=A0 =C2=A0RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6
=C2=A0 =C2=A0functionality in RFC 3315.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

--94eb2c1bddf25aa54805499486d8-- --94eb2c1bddf25f95b605499486ac 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgs1psyuSKOZLmWxpS4XOBXpXiZ++vYHlQ sTR0lvCepT4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjI4 MTAxOTAxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAAO0N/tmoIOtmqfQuYG9IelELyndAQ/RpQ8R4lRF23vwqjZfNehN oPx6MRuYPPHJ8CtgB0VicALUJdbkF0h8IF8VFLqyMSzcXyDa4Ja+YMN3egVgkFruoSDl4CqK6NGx JUdegXLvfo9FyaRA1uVFFiamkAAN7SAjuxmq5vLuCbnIbNePT13QXlSAynKNOaY8UGLllNO1VmVZ jc47idBTQzQAdiNZq8NRPMciP/wcQSE8YOy04IVOFh/S3q84BaZZwBsSK5yEfn6SbtND9VboPBmh 87Jq1xPMsRRtfUlDur1L5l8ehP+1grrbRzkmSQiDhuxcrBSoQqUIIkCorKbuhcU= --94eb2c1bddf25f95b605499486ac-- From nobody Tue Feb 28 02:28: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 6D5E112706D for ; Tue, 28 Feb 2017 02:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-gbz0pOM4CW for ; Tue, 28 Feb 2017 02:28:12 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B49126FDC for ; Tue, 28 Feb 2017 02:28:12 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 AB3AC806CE; Tue, 28 Feb 2017 11:28:09 +0100 (CET) To: Erik Kline References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> Date: Tue, 28 Feb 2017 07:27:53 -0300 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 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:28:14 -0000 Hello, Erik, On 02/28/2017 07:18 AM, Erik Kline wrote: > I oppose sneaking DHCPv6 as a MUST in this document: > > IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], > and the stateless DHCPv6 mechanism specified in [RFC3315]. > > No. May I ask the basis on which you opposed? P.S.: Please not that we're not required the IA_NA part, but just stateles part -- i.e., so that DHCPv6 can be employed to convey additional configuration information (*not* addresses). 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 Feb 28 02:29: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 5EFEB12706D for ; Tue, 28 Feb 2017 02:29:20 -0800 (PST) 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 w8p_h_jx7EXI for ; Tue, 28 Feb 2017 02:29:19 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA64126FDC for ; Tue, 28 Feb 2017 02:29:18 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id v200so5052994ywc.3 for ; Tue, 28 Feb 2017 02:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aLDrxtYZI4IF5B1ZemwhTxr01HHCSVRsroreeWXPH98=; b=PM1JmujRUelm7UQODRdcZg2f7a9tr1441Q45Q5L/EeqNJOurTura2i789LV1mZMDtg PYzc4dw7RcODTKAXryBTZLYeT1U+ehLntEOkNuk+bAfJSjL2Ol5dWS09vJmj9kWODpi0 vhQdyq0NpwhiB9DEDEovgxfw1kccz2Yn/OvEJn3Vjir1FqH+vb6eaIK/X5mO7QKPnT7G vrfWpxEZRP1GJoDiowd5nzQkQvxZVhGtYpgVb0HA+Fx3kTO5tSqGDCcMEuHFz+Jp9TZg bEScthQO769b06N/x+ln16Oh/Ka5uuZcfDt2u4FhediPt/JjMrcge7SoCncXmsEWaeKM jPuw== 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=aLDrxtYZI4IF5B1ZemwhTxr01HHCSVRsroreeWXPH98=; b=Xcd32CRn9I5fkgZHmEhRsHxfOR1CxkzGHfueW4SmzqvW2PdjpDhaulh+4W+kinzD3Z ftB3Un3hzNdNjN2Ol8Z0qQ0ZbJJk0ztBLO8ZqnPRZWzvkmitb8Pc+A+CR2Wfh+Tj2CjE HMWQg2UorRORs5Ra4YzfO9TRP3pCrreBW0RNR7Ej12PxPH5QwfBFbLxgFdtL8qDytRVg J3YfyF0gUMmayKhn+4iZwe9G2b1En/MyBhADgmBORevt8QV7zqjH9cB4qz8e29g3N4jU /uf79DrDX8K8p4FTNv42+q6Yf0ctqOuVbT2oHFWVdopZifu4KIj2eEBb2EWrccjmOVGT q90g== X-Gm-Message-State: AMke39lI6uZHS/DeLKPpTD3cUf2nhTkTHAjm6d+YCkKw8AmbSvgUJyYcH7ewpJ9QVG2z4AuBfQKtRf5n+mU3cach X-Received: by 10.129.115.68 with SMTP id o65mr541363ywc.55.1488277757861; Tue, 28 Feb 2017 02:29:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Tue, 28 Feb 2017 02:28:57 -0800 (PST) In-Reply-To: <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> From: Erik Kline Date: Tue, 28 Feb 2017 19:28:57 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1149359c1a961f054994ab80" Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:29:20 -0000 --001a1149359c1a961f054994ab80 Content-Type: multipart/alternative; boundary=001a1149359c15ffa4054994abee --001a1149359c15ffa4054994abee Content-Type: text/plain; charset=UTF-8 Because DHCPv6 of any form is not a host requirement (or at least not last I checked). On 28 February 2017 at 19:27, Fernando Gont wrote: > Hello, Erik, > > On 02/28/2017 07:18 AM, Erik Kline wrote: > > I oppose sneaking DHCPv6 as a MUST in this document: > > > > IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], > > and the stateless DHCPv6 mechanism specified in [RFC3315]. > > > > No. > > May I ask the basis on which you opposed? > > P.S.: Please not that we're not required the IA_NA part, but just > stateles part -- i.e., so that DHCPv6 can be employed to convey > additional configuration information (*not* addresses). > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --001a1149359c15ffa4054994abee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Because DHCPv6 of any form is not a host requirement (or a= t least not last I checked).

On 28 February 2017 at 19:27, Fernando Gont <fgont@si= 6networks.com> wrote:
Hello= , Erik,

On 02/28/2017 07:18 AM, Erik Kline wrote:
> I oppose sneaking DHCPv6 as a MUST in this document:
>
>=C2=A0 =C2=A0 IPv6 hosts MUST support the SLAAC DNS options specified i= n [RFC6106],
>=C2=A0 =C2=A0 and the stateless DHCPv6 mechanism specified in [RFC3315]= .
>
> No.

May I ask the basis on which you opposed?

P.S.: Please not that we're not required the IA_NA part, but just
stateles part -- i.e., so that DHCPv6 can be employed to convey
additional configuration information (*not* addresses).

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





--001a1149359c15ffa4054994abee-- --001a1149359c1a961f054994ab80 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg73iWpMsLhagsj0XYSAyoZrQwJMUqa3Uv pN00CDvpAyEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjI4 MTAyOTE4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACPautu8MmtPrj1ywoRe+iQCqAtpDgr4P0lleGA/Hi+MLBayoOwu 4x+72bpFs4nH/MkIFmdY/tp2K1CGEnV/7aXN3ZEA1clYYDVzQ5VT1fOtv65OQdjWl0J8IGZIkF09 t02/tXN2NYPSe/vF3j9X3oT5ockLVNw2FWYFM1cFVrp5YMMps6ipBvqrmQT5TjoIGBx3p2kGDScC aChC9Wn0HDCPjzVjRHSFXaPbuBuo/86/7FlBfUw6dAhgVhsL+yBPXDlfkj1tEUE7qYNvJc/Zt23b m8QgDF647lqPLaQ3xX+jjv+iszl3YFBVNTBYxT9oK8W40UClErm/LaQo5oEDAAo= --001a1149359c1a961f054994ab80-- From nobody Tue Feb 28 02:33: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 E3AC9129410 for ; Tue, 28 Feb 2017 02:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OMSsMGEgoC1T for ; Tue, 28 Feb 2017 02:33:53 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE45126FDC for ; Tue, 28 Feb 2017 02:33:53 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Feb 2017 10:33:52 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 659F2D788A; Tue, 28 Feb 2017 02:33:52 -0800 (PST) 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=+4aJepAPAbSiD989kmf24B1a/cw=; b= YVq7WnPcmF+SAA9f0yqgD5Q52Jdi7T8/4iNrS5Fyq0Nn3RFtgbGQV4mTQE1eQhtG uYt0QGtycxhrODhzBT2NH/A6AeiNhPl5OTAo6iETZEhsOoKPzp8Apxq2MXNoAaXx xxoltmZnnrAWnTeEOBfaHqzG5d8qRvDFqyg/Nm4UYG8= 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=Q+lASAFnW4aJ6ZpVZUE3sfb TnHBoGl8sNzhqaRRA9Vfql0aRtx/rmweIXpHN2E67qua/YLnpzT4kGN8xYmRSJkD RWQruA6GKK7eD8/MWiuyNoc9sDY7k0z83jU4ubAjMl20CItl/xASd0DQqQlKV66f VLdjekooSJPwFfcf5z2s= 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 E5796D788D; Tue, 28 Feb 2017 02:33:51 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5AEE68FD8698; Tue, 28 Feb 2017 11:33:50 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6097BB24-69B1-4546-913D-A79F9F403A34"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 28 Feb 2017 11:33:49 +0100 In-Reply-To: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> To: Fernando Gont References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:33:55 -0000 --Apple-Mail=_6097BB24-69B1-4546-913D-A79F9F403A34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fernando, Why wouldn't these changes go in the IPv6 node requirements document? Ole > On 28 Feb 2017, at 09:13, Fernando Gont wrote: >=20 > Folks, >=20 > Based on a recent discussion regarding the problem of conveying DNS > information in IPv6 networks, we have submitted this short I-D, in the > hopes of getting the aforementioned problem solved. >=20 > Your feedback will be appreciated. >=20 > Thanks! > Fernando (and co-autors) >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-host-configuration-00.txt > Date: Mon, 27 Feb 2017 23:51:03 -0800 > From: internet-drafts@ietf.org > To: Fernando Gont , Gert Doering > , Madelen Garcia Corbo , > Madelen Corbo , Guillermo Gont > >=20 >=20 > A new version of I-D, draft-gont-v6ops-host-configuration-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. >=20 > Name: draft-gont-v6ops-host-configuration > Revision: 00 > Title: On the Dynamic/Automatic Configuration of IPv6 = Hosts > Document date: 2017-02-27 > Group: Individual Submission > Pages: 6 > URL: > = https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configuration-0= 0.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00 >=20 >=20 > Abstract: > IPv6 has two different mechanisms for dynamic/automatic host > configuration: SLAAC and DHCPv6. These two mechanisms allow for the > configuration of IPv6 addresses and a number of network parameters. > While there is overlap in the parameters that can be configured via > these two protocols, different implementations support only subsets > of such parameters with either mechanism, or have no support for > DHCPv6 at all. This document analyzes a problem that arises from > this situation, and mandates that all host implementations support > RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 > functionality in RFC 3315. >=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.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_6097BB24-69B1-4546-913D-A79F9F403A34 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 iQIcBAEBCgAGBQJYtVIOAAoJEL7aWKiYQt925NUP/0vZyLHOyuXwI9f3dn9rsWVl FlG7ausG2jTKR0MbCCSJf4/5pyBe6QPqtWOQA8RR/zR1Ldx0W59e8Dns4dCDt+Sr m+PZMPT2Ejy6VRIFBSS5BwclMCVhcuRmA5QLaf7RYdI0MDCY8Py9ZiTwsxm0JLQO SZIkUYhyICTMmY4DQxdYzInNGG8r/CHlAVbfOx/hxrsMzSSjvMTy1k/RPjG10jaM RlIZzAX5qcXKM2kc7PZgw6cIp9nmQI0eL3wmJVr3gC6viucxZkfntX8vApgdhKqO d7TJYc9kCCOJp/lKw/PwrAQ5dxmjqcZM8Q80KYvhLnh988W0iXLvHbtB9hfqyqJc +kGZPy1f1vot5CSTA4u4Qsh4cpQ9lhv5bM3oRHiyHfg8gDbZvDwxCsuWF7qUsFBU TEfG2SIS9SBkF81f2E2oW7Za+IEeI614xSN0AsgWGfXP8pFkz/Dq++cuqqkHc7uP YP7ra4H3u3UiV1pwfAO5mNENtnRUWnhJ/6Ukv4EHYu0I1lHVR0KpQI9skoVH3WEb DR4wijD4z8yC/3IQdOM8YucNV47T4C3tsMhr3NiK/WZzN1faBdLg+xzBCoZG7rin LZqWxtR6fz0P0XaiGNgsBaBgpH/agDQYSMzcmaGk0yGxsGsF+c8NEAlPQLlc0RXT +4uxAn+nmrvwulJF6PrF =/j6Q -----END PGP SIGNATURE----- --Apple-Mail=_6097BB24-69B1-4546-913D-A79F9F403A34-- From nobody Tue Feb 28 02: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 4C812126FDC for ; Tue, 28 Feb 2017 02:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 H9Ez8q9NbSht for ; Tue, 28 Feb 2017 02:39:30 -0800 (PST) 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 4EC101294E2 for ; Tue, 28 Feb 2017 02:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488278365; x=1488883165; 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=uiUC9qIW4eQL817HH9XsifTxg gi2uE/BugTUMjXJjo8=; b=AtGdPrNeKqW0QOZBf9ff/ltNIaWO+MnRkTZ0v2BXG FIj/VPZcZJptvf48Izpy4Ra3nSM7xVH0ejib0sbQRK70sJsGDdihSY2Ck575aZct cRZjPXP1hlNAAwpYeGs1FzUWtnolbBbssqpmQwgl9/iDJ5nhUPHBJycx0FieJ+qo SY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=K/rrdK68H2d+Dn+g3Z0cZNU63exrjV1vCji4qlCgedndPhSnYkR31680WsuB Zs8+N88NqcHgHveXpMnz+SkRHBRUUDEGX0WuQKyDfj1wRhBqROhzl+zfH I+c/ChGDbo6iQXno+1VWPfitCkV0ieuQMKhl6CRORab6jlglOBLaCo=; X-MDAV-Processed: mail.consulintel.es, Tue, 28 Feb 2017 11:39:25 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 28 Feb 2017 11:39:24 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005375643.msg for ; Tue, 28 Feb 2017 11:39:23 +0100 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:170228:md50005375643::6rNxV0cZIxHv7O3R:00006/WN X-Return-Path: prvs=123297a6ff=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 28 Feb 2017 11:39:18 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:39:32 -0000 +1 I think the IPv6 node requirements is the right document to update with thi= s. For the router requirements part, the requirements in this document are alr= eady being required by RFC7048 and also in the =E2=80=93bis draft. https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-01 Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: martes, 28 de febrero de 2017, 11:33 Para: Fernando Gont CC: IPv6 Operations Asunto: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notificatio= n for draft-gont-v6ops-host-configuration-00.txt) Fernando, =20 Why wouldn't these changes go in the IPv6 node requirements document? =20 Ole =20 > On 28 Feb 2017, at 09:13, Fernando Gont wrote= : >=20 > Folks, >=20 > Based on a recent discussion regarding the problem of conveying DNS > information in IPv6 networks, we have submitted this short I-D, in th= e > hopes of getting the aforementioned problem solved. >=20 > Your feedback will be appreciated. >=20 > Thanks! > Fernando (and co-autors) >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-host-configuration-00.txt > Date: Mon, 27 Feb 2017 23:51:03 -0800 > From: internet-drafts@ietf.org > To: Fernando Gont , Gert Doering > , Madelen Garcia Corbo , > Madelen Corbo , Guillermo Gont > >=20 >=20 > A new version of I-D, draft-gont-v6ops-host-configuration-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. >=20 > Name: draft-gont-v6ops-host-configuration > Revision: 00 > Title: On the Dynamic/Automatic Configuration of IPv6 Hosts > Document date: 2017-02-27 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configurat= ion-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00 >=20 >=20 > Abstract: > IPv6 has two different mechanisms for dynamic/automatic host > configuration: SLAAC and DHCPv6. These two mechanisms allow for th= e > configuration of IPv6 addresses and a number of network parameters. > While there is overlap in the parameters that can be configured via > these two protocols, different implementations support only subsets > of such parameters with either mechanism, or have no support for > DHCPv6 at all. This document analyzes a problem that arises from > this situation, and mandates that all host implementations support > RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 > functionality in RFC 3315. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Feb 28 02: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 8EACC126FDC for ; Tue, 28 Feb 2017 02:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-EZH5-kiD04 for ; Tue, 28 Feb 2017 02:46:24 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D514129453 for ; Tue, 28 Feb 2017 02:46:24 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 6D03C8043C; Tue, 28 Feb 2017 11:46:21 +0100 (CET) To: Erik Kline References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 28 Feb 2017 07:42:32 -0300 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 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:46:25 -0000 Well, that's part of the reason for writing the I-D :-) RDNSS is not part of router requirements, and we're requiring it on the router side. i.e., we want IPv6 networks to be able to provide DNS info in whatver way they please, and for IPv6 hosts to be able to get such info. Nowadays, yu generally can configure DNS info in DHCPv6, but hosts do not even implement the stateless DHCPv6 part. And there are networks in which folks want to provide DNS info with RDNSS, but routers don't support it. That's bad. The current workaround is that folks end up relying on the DNS info conveyed via DHCPv4. But that is not only bad, but also inadequate since IPv4 is supposed to go away (eventually). Thanks, Fernando On 02/28/2017 07:28 AM, Erik Kline wrote: > Because DHCPv6 of any form is not a host requirement (or at least not > last I checked). > > On 28 February 2017 at 19:27, Fernando Gont > wrote: > > Hello, Erik, > > On 02/28/2017 07:18 AM, Erik Kline wrote: > > I oppose sneaking DHCPv6 as a MUST in this document: > > > > IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], > > and the stateless DHCPv6 mechanism specified in [RFC3315]. > > > > No. > > May I ask the basis on which you opposed? > > P.S.: Please not that we're not required the IA_NA part, but just > stateles part -- i.e., so that DHCPv6 can be employed to convey > additional configuration information (*not* addresses). > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 28 02:46: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 2A545129503 for ; Tue, 28 Feb 2017 02:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJRdkmPsR1Qn for ; Tue, 28 Feb 2017 02:46:29 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D39129501 for ; Tue, 28 Feb 2017 02:46:29 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 BD3E18043C; Tue, 28 Feb 2017 11:46:25 +0100 (CET) To: otroan@employees.org References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 28 Feb 2017 07:46:15 -0300 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=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:46:30 -0000 On 02/28/2017 07:33 AM, otroan@employees.org wrote: > > Why wouldn't these changes go in the IPv6 node requirements document? I guess they could. But for timeliness sake, it's probably better to tackle this problem in a very short and "to the point" document. A possible rev of the node reqs is going to take waaaay longer to get done. 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 Feb 28 02:53: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 B1766129500 for ; Tue, 28 Feb 2017 02:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Mt-2OncNg5SY for ; Tue, 28 Feb 2017 02:53:17 -0800 (PST) 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 E39201294FE for ; Tue, 28 Feb 2017 02:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488279195; x=1488883995; 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=l74CpVV0YEWnjy5jhhmwbTgIe JJR9wHAdgkKf/n9EF8=; b=pzwwjn9f576IWmGf3DSSHWWTJbiF5TehEmrUbwPBS a2evPx21JAlzYbIZ2rDF8sWDofa+LMpUk7JMliThzfUdIe57P6Vk6BWfCZrEv8dU EosZJ11PNzv9YPVNbYAm3KBfs0JMnfWGLk0U7jOHekor++RjExERdMtRVkf1Nk0Z 5w= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=rLMSgKlQjaIti63+MDsCJpw3ihRXPJyNbejv7O3SHvG6zWWoYZf5B8FtOuMF TFY9AKn70DaQVofKijISrlVyl0i2Y9A/x7GhNKyg4OjyAeaW3RarswhRT RfA8ornPxhXIWd7oBNGfybXiFdzqI1nr0sfL2o+kt/Q9ahOd4TnFoQ=; X-MDAV-Processed: mail.consulintel.es, Tue, 28 Feb 2017 11:53:15 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 28 Feb 2017 11:53:14 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005375651.msg for ; Tue, 28 Feb 2017 11:53:14 +0100 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:170228:md50005375651::zJ+sJWHF+WEX/1Io:00002p9w X-Return-Path: prvs=123297a6ff=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 28 Feb 2017 11:53:12 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> Thread-Topic: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:53:19 -0000 I think today LANs must be dual-stack, if you want to avoid all kind or problems, so if the IPv6 node requirements take a bit extra time to update, should not be a problem, because you can use DNS with IPv4 on a dual-stack LAN. That said, the RFC7084 states: L-11: The IPv6 CE router MUST support providing DNS information in the Router Advertisement Recursive DNS Server (RDNSS) and DNS Search List options. Both options are specified in [RFC6106]. And of course, a router is a node, so: G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node Requirements specification [RFC6434]. Regards, Jordi -----Mensaje original----- De: v6ops en nombre de Fernando Gont Responder a: Fecha: martes, 28 de febrero de 2017, 11:42 Para: Erik Kline CC: IPv6 Operations Asunto: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) Well, that's part of the reason for writing the I-D :-) RDNSS is not part of router requirements, and we're requiring it on the router side. i.e., we want IPv6 networks to be able to provide DNS info in whatver way they please, and for IPv6 hosts to be able to get such info. Nowadays, yu generally can configure DNS info in DHCPv6, but hosts do not even implement the stateless DHCPv6 part. And there are networks in which folks want to provide DNS info with RDNSS, but routers don't support it. That's bad. The current workaround is that folks end up relying on the DNS info conveyed via DHCPv4. But that is not only bad, but also inadequate since IPv4 is supposed to go away (eventually). Thanks, Fernando On 02/28/2017 07:28 AM, Erik Kline wrote: > Because DHCPv6 of any form is not a host requirement (or at least not > last I checked). > > On 28 February 2017 at 19:27, Fernando Gont > wrote: > > Hello, Erik, > > On 02/28/2017 07:18 AM, Erik Kline wrote: > > I oppose sneaking DHCPv6 as a MUST in this document: > > > > IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], > > and the stateless DHCPv6 mechanism specified in [RFC3315]. > > > > No. > > May I ask the basis on which you opposed? > > P.S.: Please not that we're not required the IA_NA part, but just > stateles part -- i.e., so that DHCPv6 can be employed to convey > additional configuration information (*not* addresses). > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -- 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 ********************************************** 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 Tue Feb 28 02:53: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 7F26A1294FE for ; Tue, 28 Feb 2017 02:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_jAF_W1jizW for ; Tue, 28 Feb 2017 02:53:28 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0A7129505 for ; Tue, 28 Feb 2017 02:53:27 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 7ED4580138; Tue, 28 Feb 2017 11:53:24 +0100 (CET) To: jordi.palet@consulintel.es, IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 28 Feb 2017 07:53:19 -0300 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 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:53:33 -0000 On 02/28/2017 07:39 AM, JORDI PALET MARTINEZ wrote: > +1 > > I think the IPv6 node requirements is the right document to update with this. Eventually it can be taken up by that document. Based on the number of changes that are probably going to be applied to a bis of such RFC, that one is not going to get done very timely, though. Besides, we hope that this being an operations wg, the discussion can be more pragmatic than religious. > For the router requirements part, the requirements in this document are already being required by RFC7048 and also in the –bis draft. > > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-01 That's one specific type of router. 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 Feb 28 02:56: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 A3B0F12950A for ; Tue, 28 Feb 2017 02:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Fq8TjUwpKkbj for ; Tue, 28 Feb 2017 02:56:30 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC31129508 for ; Tue, 28 Feb 2017 02:56:30 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Feb 2017 10:56:30 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0DCC6D788B; Tue, 28 Feb 2017 02:56:30 -0800 (PST) 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=ydiq9KZ5CnKWz14I1VIU27MG7e8=; b= nhLuCx+GpXqtMHlfODICUnLh64HEfKkw3s+XHEf3AtN4NBQ8wjP7oGsAm5uRKkXw GKrwFryjc77FVs4eKyO+rGPneKt4tFqr1nK9f9lj5aJyXgqsl7la/2eJi2UeEeo2 oDfS6rbK9ijlmFTx7QDLkZefWjHW9OOiyBv6RMpm454= 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=Zy18XE+wEFDH9NRm+9Pyg4P QQ4bVqhgfq6LIkY4Q0M7oqmMOhUAxuoEH9ioBiz0b7w+edeL4LdQH3JsDgpj+qw2 54dY2zz95uOQP780n3o2cKATI5hlTY1fhCwtJkiZjDCVf0twkfGOv+o5seBbARuk TIhw0B+LnKLpnWW1me44= 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 D65B0D788A; Tue, 28 Feb 2017 02:56:29 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 552F38FDFB40; Tue, 28 Feb 2017 11:56:28 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_38F005CD-635E-4A76-992C-823EA46B193D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 28 Feb 2017 11:56:27 +0100 In-Reply-To: To: Fernando Gont References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 10:56:31 -0000 --Apple-Mail=_38F005CD-635E-4A76-992C-823EA46B193D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fernando, >> Why wouldn't these changes go in the IPv6 node requirements document? >=20 > I guess they could. But for timeliness sake, it's probably better to > tackle this problem in a very short and "to the point" document. In my not particularly humbler opinion we don't need yet another RPF = style RFC. > A possible rev of the node reqs is going to take waaaay longer to get = done. The revision of the node reqs is currently underway. https://tools.ietf.org/html/draft-clw-rfc6434-bis-00 Ole --Apple-Mail=_38F005CD-635E-4A76-992C-823EA46B193D 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 iQIcBAEBCgAGBQJYtVdcAAoJEL7aWKiYQt927PQQAJh4shJgsbW+zSjhHLXvGTei jyP62NRPxRcSMJyOz9idDjreZJHHbQ/2+aVyzhybwmN2DYDKfPsCLemPPgGsfe+3 yAQ95nIoQrQRzTtWkPDA9wNeon22cFa2Ks7G8qDK/2xfS0tTQRPcJA6ObycpVDWe RCCoLMjAs1i4Qhf/bOH2YHyaW1oLDg1TmevDIGYbEHTxbNXLAWYDAaPE9NXJif3e goUVQK8chOqtqmsNaVDns1rRKppftApmp59c82IYrh6ITvh9c67uZjtVdOKayxbN S3Vj+jhFIJ0b488qnBYCjojMma2SZNJlJwC0q3iCOmNEw+S6jgxMVhB2REwSkqq3 Ze3WS/LSf4q65DR4/V/J+DCfUyMYlAjNSpi+2eSv5LN72WxSfmFPxCszBbRiC/Gn y6VNk3aHp1R+Iyuk9boE+BPpN1/OqHalYa27rDJawGF8ZoVuQe0GaGR8zsR9bOFl NncZxdmFaV/+JIzo8aSnlvma97Vlh1YufEEO4wAvssLYJhHj9PDlgCqBKVkaCElw 8BHAQuofKM0/9LEu0WTr43d8H+hM+Am/2HZWbhdhIB/Sp0xC3L9YZGyqTOokW8tN /e68SkwMi5W8XlW/5dWM97BazjFJzfyJ8v9+BX+T2Qc48yP28YcKcpJojHSTjcg8 NdbYbsTDp0k9DBqe0wvn =Zej5 -----END PGP SIGNATURE----- --Apple-Mail=_38F005CD-635E-4A76-992C-823EA46B193D-- From nobody Tue Feb 28 03: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 E41C612950C for ; Tue, 28 Feb 2017 03:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRzuDGNatx4f for ; Tue, 28 Feb 2017 03:05:00 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6ECF129504 for ; Tue, 28 Feb 2017 03:05:00 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 484258095F; Tue, 28 Feb 2017 12:04:57 +0100 (CET) To: jordi.palet@consulintel.es, IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> Date: Tue, 28 Feb 2017 08:04:48 -0300 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: <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 11:05:02 -0000 On 02/28/2017 07:53 AM, JORDI PALET MARTINEZ wrote: > I think today LANs must be dual-stack, if you want to avoid all kind > or problems, Actually, I've seen/read a lot of bragging about IPv6-only nets. Including IPv6-only mobiles. > so if the IPv6 node requirements take a bit extra time > to update, should not be a problem, because you can use DNS with IPv4 > on a dual-stack LAN. If an IETF IPv6 group's solution to an IPv6 problem is to rely on IPv4, I'm afraid we'll have a hard time to be taken seriously by the folks that we expect to deploy v6 (and by others, too). 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 Feb 28 03: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 044C412950C for ; Tue, 28 Feb 2017 03:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 wZk1xm_xRHRB for ; Tue, 28 Feb 2017 03:13:16 -0800 (PST) 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 58792126FDC for ; Tue, 28 Feb 2017 03:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488280392; x=1488885192; 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=hU4qDXsxIKnnxcLOjgiDSnJdg Y9DQZIAwhPJ4eiPW1o=; b=hPSlX+TYNuHhpgCTiES6nidOjicdwRHnFOvKLdRnK 6Ll+aHVaH9LFSPRlU+Zs9+RxtVHPXXDcEixCPBRyTIg52DIWR+6qxqpeIJbTUO92 xw/Qo00QT2TcDyvVa9leEbghNyez5yt79/JlRQpXV08XIUjgi5HikdUhBANjeC+F NQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=E9bBybRdIeCKqcnAzi0FtWV3DNFnoh+KEfsR1O/KfFKZK0F+xkoE/PILgQmf cFUSyBcIgI1yEaR2OTS5J0ezEH6B4WihAqz7SQxYLnk5iNZntuJr7sDzG RCY7oEcs5Jc+BmQjBU+cPa8e5gTfnHtyBFHG8INfRHKNO8gEx76hj4=; X-MDAV-Processed: mail.consulintel.es, Tue, 28 Feb 2017 12:13:12 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 28 Feb 2017 12:13:11 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005375672.msg for ; Tue, 28 Feb 2017 12:13:11 +0100 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:170228:md50005375672::zVQeS+quI4Ak5rWp:00002XjP X-Return-Path: prvs=123297a6ff=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 28 Feb 2017 12:13:00 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> In-Reply-To: <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 11:13:18 -0000 Yes, but the =E2=80=9Conly-IPv6=E2=80=9D is the WAN link. The LANs (and the apps) in the cellular network are dual-stack, by means of= 464XLAT. If you don=E2=80=99t keep dual-stack =E2=80=9Cinside=E2=80=9D the= cellular device or LANs in a home/enterprise environment, many old applica= tions stop working. I agree that this is the target at the end, but we should not force it, bec= ause we don=E2=80=99t have the power to pay for the cost of all the users i= n the world to =E2=80=9Cupgrade=E2=80=9D their apps and devices. I wish we = could do it! I=E2=80=99m trying to be very pragmatic. Regards, Jordi =20 -----Mensaje original----- De: Fernando Gont Responder a: Fecha: martes, 28 de febrero de 2017, 12:04 Para: , IPv6 Operations Asunto: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notificatio= n for draft-gont-v6ops-host-configuration-00.txt) On 02/28/2017 07:53 AM, JORDI PALET MARTINEZ wrote: > I think today LANs must be dual-stack, if you want to avoid all kind > or problems, =20 Actually, I've seen/read a lot of bragging about IPv6-only nets. Including IPv6-only mobiles. =20 =20 > so if the IPv6 node requirements take a bit extra time > to update, should not be a problem, because you can use DNS with IPv4 > on a dual-stack LAN. =20 If an IETF IPv6 group's solution to an IPv6 problem is to rely on IPv4, I'm afraid we'll have a hard time to be taken seriously by the folks that we expect to deploy v6 (and by others, too). =20 Cheers, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 =20 =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 Tue Feb 28 03:15: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 80B6212950C for ; Tue, 28 Feb 2017 03:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Isx_9tiz6Yip for ; Tue, 28 Feb 2017 03:15:22 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068C0126FDC for ; Tue, 28 Feb 2017 03:15:21 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 975C18095F; Tue, 28 Feb 2017 12:15:18 +0100 (CET) To: otroan@employees.org References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <4f757481-9795-287d-ad85-e1438a13798b@si6networks.com> Date: Tue, 28 Feb 2017 08:14:59 -0300 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=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 11:15:23 -0000 On 02/28/2017 07:56 AM, otroan@employees.org wrote: > Fernando, > >>> Why wouldn't these changes go in the IPv6 node requirements document? >> >> I guess they could. But for timeliness sake, it's probably better to >> tackle this problem in a very short and "to the point" document. > > In my not particularly humbler opinion we don't need yet another RPF style RFC. I wished we didn't, but the problem needs to get solved. >> A possible rev of the node reqs is going to take waaaay longer to get done. > > The revision of the node reqs is currently underway. > https://tools.ietf.org/html/draft-clw-rfc6434-bis-00 It's great that this is going to happen, but it's gonna take ages. 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 Feb 28 03:21: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 F199B129526 for ; Tue, 28 Feb 2017 03:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05qvV7ko_CgD for ; Tue, 28 Feb 2017 03:21:08 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D0F129524 for ; Tue, 28 Feb 2017 03:21:08 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 5A238806B8; Tue, 28 Feb 2017 12:21:04 +0100 (CET) To: jordi.palet@consulintel.es, IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 28 Feb 2017 08:20:58 -0300 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 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 11:21:10 -0000 On 02/28/2017 08:13 AM, JORDI PALET MARTINEZ wrote: > Yes, but the “only-IPv6†is the WAN link. See section "Testing has its challenges" of -- that should really be unacceptable for this group. > I agree that this is the target at the end, but we should not force > it, because we don’t have the power to pay for the cost of all the > users in the world to “upgrade†their apps and devices. I wish we > could do it! I’m trying to be very pragmatic. We certainly should not force ipv6-only. That said, it should be possible for folks to do it without having to deal with this kind of mess. 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 Feb 28 03:23: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 2246912948A for ; Tue, 28 Feb 2017 03:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Plqp31R1R43T for ; Tue, 28 Feb 2017 03:23:47 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E93B7126FDC for ; Tue, 28 Feb 2017 03:23:46 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cifsf-0000GrC; Tue, 28 Feb 2017 12:23:45 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> In-reply-to: Your message of "Tue, 28 Feb 2017 08:04:48 -0300 ." <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> Date: Tue, 28 Feb 2017 12:23:44 +0100 Archived-At: Cc: Fernando Gont Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 11:23:49 -0000 In your letter dated Tue, 28 Feb 2017 08:04:48 -0300 you wrote: >On 02/28/2017 07:53 AM, JORDI PALET MARTINEZ wrote: >> I think today LANs must be dual-stack, if you want to avoid all kind >> or problems, > >Actually, I've seen/read a lot of bragging about IPv6-only nets. >Including IPv6-only mobiles. > >> so if the IPv6 node requirements take a bit extra time >> to update, should not be a problem, because you can use DNS with IPv4 >> on a dual-stack LAN. > >If an IETF IPv6 group's solution to an IPv6 problem is to rely on IPv4, >I'm afraid we'll have a hard time to be taken seriously by the folks >that we expect to deploy v6 (and by others, too). For the node requirements document, I think it would be nice if we could add something like 'hosts that implement DNS (stub) resolver functionality SHOULD try to obtain a list of DNS resolvers using DHCPv6 if the O bit is set in a Router Advertisement.' For the people who want to run IPv6 only, it would be nice if they would publish a BCP how their preferred solution handles DNSSEC local validation for IPv4 addresses. My preferred solution for an IPv6-only backbone is that customer edge routers (or in general any router that connects ordinary hosts) offers dual stack in one form or another. From nobody Tue Feb 28 03:38: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 8DB69129487 for ; Tue, 28 Feb 2017 03:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=unavailable 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 zm0cJ8mTwnPN for ; Tue, 28 Feb 2017 03:38:06 -0800 (PST) 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 02A3A12952F for ; Tue, 28 Feb 2017 03:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488281425; x=1488886225; 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=BQMWmLUSE5jrowgXZBkHUbyHo hYOLD24TDJ1+35+Uus=; b=JLDRJU1OIG1vpAcNfVxpQcvdraIw1ir9ntogJmHmL 1dDz6Y9DvsTQV/Ben1E1crjWI7B10JipP7w9tpZOgfC5S99FcAvG04PAhExmIhHc y99pzdU3QKzxQNX+ixx1kbrQbTvd5l/ZnigPXzPt3Awge8FPjd21GA9dxN4cjY5v 58= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=rXK4G5YKRZ/FgzGjoQhcQWZ4NgYAXcp1AxMyWCLtgJNi7ok3jxjmzCV6adKx ekjqhnSopbqSOfjL7Goc7+yMSM2YSBEOjq1BdzA0ciR2cYPDBViev8jxK j+0z142zo5YQOnjgNa42jnuZrnkp4PUM+IoeVLG5dIhe7bKQc8atMI=; X-MDAV-Processed: mail.consulintel.es, Tue, 28 Feb 2017 12:30:25 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 28 Feb 2017 12:30:24 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005375686.msg for ; Tue, 28 Feb 2017 12:30:24 +0100 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:170228:md50005375686::9DXhACs7A2O+f7gj:00001rBC X-Return-Path: prvs=123297a6ff=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 28 Feb 2017 12:30:23 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <0529424E-F09D-4B54-8D0D-F491B53E234E@consulintel.es> Thread-Topic: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 11:38:07 -0000 Just to be clear, I=E2=80=99m for what the document proposes, but not the w= ay to do it, because is not realistic. If you do IPv6-only today in the LAN, the problem you have is not the DNS, = is not being able to access even local resources in your home or enterprise= network. I agree is a target, but it can be aligned, in terms of time, wit= h the update of the node requirements doc. As said, it will be wonderful to throw away all the IPv4-only cameras, smar= t-TVs, etc, but is not going to happen, so suggesting to users to use IPv6-= only in their LANs, is a very bad and unrealistic advice, and even if it wi= ll be very nice, we should target for that in 2-3 years from now (and proba= bly will take even longer). I prefer less documents even if they take a bit extra time (at least in thi= s case), but more complete and talking more issues at the same time. In gen= eral I would agree on doing a short and quick document (for any urgent issu= e that the IETF needs to resolve) if it can be done in a matter of a couple= of months because the world has a =E2=80=9Creal=E2=80=9D problem and all t= he vendors will provide updates right now, etc., but I don=E2=80=99t think = this is the case. Regards, Jordi =20 -----Mensaje original----- De: Fernando Gont Responder a: Fecha: martes, 28 de febrero de 2017, 12:20 Para: , IPv6 Operations Asunto: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notificatio= n for draft-gont-v6ops-host-configuration-00.txt) On 02/28/2017 08:13 AM, JORDI PALET MARTINEZ wrote: > Yes, but the =E2=80=9Conly-IPv6=E2=80=9D is the WAN link. =20 See section "Testing has its challenges" of -- that should really be unacceptable for this group. =20 =20 =20 > I agree that this is the target at the end, but we should not force > it, because we don=E2=80=99t have the power to pay for the cost of al= l the > users in the world to =E2=80=9Cupgrade=E2=80=9D their apps and device= s. I wish we > could do it! I=E2=80=99m trying to be very pragmatic. =20 We certainly should not force ipv6-only. That said, it should be possible for folks to do it without having to deal with this kind of me= ss. =20 Thanks, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 =20 =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 Tue Feb 28 03:47: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 3007612950D for ; Tue, 28 Feb 2017 03:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VG_Zrvjbw3z for ; Tue, 28 Feb 2017 03:47:29 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5412F12946F for ; Tue, 28 Feb 2017 03:47:29 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 A9FA380729; Tue, 28 Feb 2017 12:47:26 +0100 (CET) To: jordi.palet@consulintel.es, IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> <0529424E-F09D-4B54-8D0D-F491B53E234E@consulintel.es> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <87e0ba75-75e4-42f3-ee4b-b2a5ee133589@si6networks.com> Date: Tue, 28 Feb 2017 08:47:17 -0300 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: <0529424E-F09D-4B54-8D0D-F491B53E234E@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 11:47:31 -0000 On 02/28/2017 08:30 AM, JORDI PALET MARTINEZ wrote: > I prefer less documents even if they take a bit extra time (at least > in this case), but more complete and talking more issues at the same > time. In general I would agree on doing a short and quick document > (for any urgent issue that the IETF needs to resolve) if it can be > done in a matter of a couple of months because the world has a “real†> problem and all the vendors will provide updates right now, etc., but > I don’t think this is the case. I'm not arguing in favor of IPv6-only. I'm saying that the current situation wrt what is described in our I-D is really bad. The quicker this is done, the sooner folks have a document to throw at vendors to get this support implemented. If we wait 2-3 years to get a rev of the node reqs rfc, *that* is when folks will be able to *start to* ask vendors to get this support implemented. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 28 04: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 C3DC8129537 for ; Tue, 28 Feb 2017 04:07:13 -0800 (PST) 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 iJon68EEF1Ll for ; Tue, 28 Feb 2017 04:07:11 -0800 (PST) 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 2E52F12943A for ; Tue, 28 Feb 2017 04:07:11 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id C377B24AE08; Tue, 28 Feb 2017 12:06:58 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BDDE216008D; Tue, 28 Feb 2017 12:06:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9CCF116008C; Tue, 28 Feb 2017 12:06:57 +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 E0QiNNbhOXQ5; Tue, 28 Feb 2017 12:06:57 +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 0542E160055; Tue, 28 Feb 2017 12:06:57 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8A853657C002; Tue, 28 Feb 2017 23:06:53 +1100 (EST) To: Philip Homburg From: Mark Andrews References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> In-reply-to: Your message of "Tue, 28 Feb 2017 12:23:44 +0100." Date: Tue, 28 Feb 2017 23:06:53 +1100 Message-Id: <20170228120653.8A853657C002@rock.dv.isc.org> Archived-At: Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 12:07:13 -0000 In message , Philip Homburg writes: > In your letter dated Tue, 28 Feb 2017 08:04:48 -0300 you wrote: > >On 02/28/2017 07:53 AM, JORDI PALET MARTINEZ wrote: > >> I think today LANs must be dual-stack, if you want to avoid all kind > >> or problems, > > > >Actually, I've seen/read a lot of bragging about IPv6-only nets. > >Including IPv6-only mobiles. > > > >> so if the IPv6 node requirements take a bit extra time > >> to update, should not be a problem, because you can use DNS with IPv4 > >> on a dual-stack LAN. > > > >If an IETF IPv6 group's solution to an IPv6 problem is to rely on IPv4, > >I'm afraid we'll have a hard time to be taken seriously by the folks > >that we expect to deploy v6 (and by others, too). > > For the node requirements document, I think it would be nice if we could add > something like 'hosts that implement DNS (stub) resolver functionality SHOULD > try to obtain a list of DNS resolvers using DHCPv6 if the O bit is set in > a Router Advertisement.' > > For the people who want to run IPv6 only, it would be nice if they would > publish a BCP how their preferred solution handles DNSSEC local validation > for IPv4 addresses. What issue to you see that needs a BCP because I can't see one. > My preferred solution for an IPv6-only backbone is that customer edge > routers (or in general any router that connects ordinary hosts) offers > dual stack in one form or another. > > _______________________________________________ > 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 Tue Feb 28 04:26: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 492C81295CC for ; Tue, 28 Feb 2017 04:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.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=1, 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 nD1WqIUFnagy for ; Tue, 28 Feb 2017 04:26:48 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA7D1295B4 for ; Tue, 28 Feb 2017 04:26:48 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id x24so11234147uab.0 for ; Tue, 28 Feb 2017 04:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FgiDuDfM2Lj/YzADj24h9ScSSrlGj9v6e1Qn/sLGuks=; b=Vqdf67bjxe7vXnxq+KKcleuZ4pY5T4/6qAYSGbA4T9eai5l5ioWDUHu84No8+9L9jx 6j0Y003/v+MKIhQHm3RxfSOXwmQEPSifTJKs9r5jSn7Gp213ZUip0N4PZtHVNrQuobXW zLbGMSZDRPAISQ6edOsDeEHU8v5bZ/iGOp5TRBASWB+3RFgM5FmIMPDjXTupCtTD4t9R AT0nbiAgqxlsiVXb3urDFW4CfXgahrdGKKaf3QFMAX5R5Xl7SIYhk/++tKg0beb5G/DK 2iw368VRHubVWRCFXmnTsJTI5+Tc9o3QzostYeTAXYGaTXWTLj3bGI8lIw74Xj7miMtp iy5A== 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=FgiDuDfM2Lj/YzADj24h9ScSSrlGj9v6e1Qn/sLGuks=; b=lSRdXa/1Fb0OZTmrZEFZdWQFsAkp5Vf/1ye7ItcwybmdkALoYyfbM2r5puOmUfwTg9 yVCzyxFz4HOgRGei5Q3RVr3jbwZneZzU7dUm57wRlFip8rnl8+sfAP0MWr7kHS5Y/qBD 36hN8yihZ1NUf/Ww7TNhSLEjOsMeC/eacw8Bm5Q4iGv53zlK5CZcMfJaLyGtKc87FAvF WwhPAyu38fXJWAJ/OsQ+7SvlTaUSXrDwSUoMcmKdm02u5PJ7j+PAdPhXeP7IyPYDBnJm bdho/b4GKk2BhINH+l8TIep+wlwEsh02No26tszpo34BeWu/HHmGJ3aerpg8tGhKatvh RiEw== X-Gm-Message-State: AMke39lKRQw/RF4UYX4/W2q6Hmtw87sA2AbCRNQhwjVR48yRVGAu1pu2GzYuMaAkyA6qwZjUVkn4fipTPc6qvw== X-Received: by 10.159.40.226 with SMTP id d89mr834836uad.98.1488284807609; Tue, 28 Feb 2017 04:26:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.2 with HTTP; Tue, 28 Feb 2017 04:26:47 -0800 (PST) Received: by 10.159.38.2 with HTTP; Tue, 28 Feb 2017 04:26:47 -0800 (PST) In-Reply-To: References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> From: Mark Smith Date: Tue, 28 Feb 2017 23:26:47 +1100 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=94eb2c122f844841840549964fd4 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 12:26:50 -0000 --94eb2c122f844841840549964fd4 Content-Type: text/plain; charset=UTF-8 On 28 Feb. 2017 21:29, "Erik Kline" wrote: Because DHCPv6 of any form is not a host requirement (or at least not last I checked). So how do hosts get configured with more than DNS addresses and IPv6 addresses? I'm not particularly fond of setting my devices real time clocks manually, and in b dune environments, getting time from external NTP sources is going to be unacceptable. How can hosts be automatically configured with local time zone Information? What about the many other useful parameters that can be configured with DHCPv6 options? http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2 What alternative method is available and implementations commonly exist to solve these sorts of problems if stateless DHCPv6 is not the solution? Regards, Mark On 28 February 2017 at 19:27, Fernando Gont wrote: > Hello, Erik, > > On 02/28/2017 07:18 AM, Erik Kline wrote: > > I oppose sneaking DHCPv6 as a MUST in this document: > > > > IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], > > and the stateless DHCPv6 mechanism specified in [RFC3315]. > > > > No. > > May I ask the basis on which you opposed? > > P.S.: Please not that we're not required the IA_NA part, but just > stateles part -- i.e., so that DHCPv6 can be employed to convey > additional configuration information (*not* addresses). > > 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 --94eb2c122f844841840549964fd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 28 Feb. 2017 21:29, "Erik Kline" <ek@google.com> wrote:
Because DHCPv6 of any form is not a h= ost requirement (or at least not last I checked).
<= /div>

So how do hosts ge= t configured with more than DNS addresses and IPv6 addresses?

I'm not particularly fond of sett= ing my devices real time clocks manually, and in b dune environments, getti= ng time from external NTP sources is going to be unacceptable.

How can hosts be automatically confi= gured with local time zone Information?

What about the many other useful parameters that can be con= figured with DHCPv6 options?



What alt= ernative method is available and implementations commonly exist to solve th= ese sorts of problems if stateless DHCPv6 is not the solution?

Regards,
Mark=


On 28 Feb= ruary 2017 at 19:27, Fernando Gont <fgont@si6networks.com> wrote:
Hello, Erik,

On 02/28/2017 07:18 AM, Erik Kline wrote:
> I oppose sneaking DHCPv6 as a MUST in this document:
>
>=C2=A0 =C2=A0 IPv6 hosts MUST support the SLAAC DNS options specified i= n [RFC6106],
>=C2=A0 =C2=A0 and the stateless DHCPv6 mechanism specified in [RFC3315]= .
>
> No.

May I ask the basis on which you opposed?

P.S.: Please not that we're not required the IA_NA part, but just
stateles part -- i.e., so that DHCPv6 can be employed to convey
additional configuration information (*not* addresses).

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.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


--94eb2c122f844841840549964fd4-- From nobody Tue Feb 28 04: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 6ED671295DB for ; Tue, 28 Feb 2017 04:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 U7uNG-QsMh9o for ; Tue, 28 Feb 2017 04:33:13 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 B1A4D1295D1 for ; Tue, 28 Feb 2017 04:33:13 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id 40so11401012uau.2 for ; Tue, 28 Feb 2017 04:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AfPqiDIMoiBMNXM8arxFzpbiMU8bN9Mtys1HVuPxBRU=; b=BnS5r21gU281LeBSyy2rPA6WP55n9mt1ORuYiWkMfyR3Iz0bFZ6618zSqg7mbLBjrU VH68Tn9ZAAITsjgEDFOEwykjsPTV+Uoue0KRk4fcqYn8fPIB9bdNM+6EGRzPgGx+2nrS pB8IntGPxs0V6Ha5ZAYZiEQMyEMPVLkuK9H273Foq7MXMTrC7l5BB1jVxqMozigGb3tF /16Ll88/ipnrsPgqDSpcvjFpMEEd8kBVmYozBfbVYb1L4NnPM2QGyIXXWFfKudXTj4lC b5URKuEbXNemWAIuK03klI81d4wtgiHEJmeYN3D6yDpPnMiuGYFxtfOSQ1PwmuXsxws8 8I4A== 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=AfPqiDIMoiBMNXM8arxFzpbiMU8bN9Mtys1HVuPxBRU=; b=CoqNS5GVIRRVKBibuWA8nkuzn5Mu7W4zMKZsAmWmt2FZ+DGrMVYWOenSKhbWJiLNRb iQyHe9ZsPVg/PtdGQ5SnjzEs1tLfhKqSpLsc8ZKp3/RoMu//9vlN4B5cpH8oMoY88L0s l3YorCGmp7k1Ae1U9I+/si0Bb7lcqgY9E8MM7Jki/ULo1SapHc6b0UT0giOKuGZmcZIv 1ygvBwOIyrUp+f+/adLzAPN0baFMTHqF1CSoATiazboysZgQT/khYL1ZJhVdYAy/rWri oJeMonSZdtGwiEx1idodWKGNq/l7VCPlM3Uv2PIuOrrBZ7x+wJIJKLH13ESnfDPbPkY7 tkyw== X-Gm-Message-State: AMke39nJVVmtYoGuFybDGAmV6T+F3rcE3UOh+3pC29kLJ//uSLeBo4+Ls27B2iEUmddJ5TvwIHpIYEavXK2Mjxa6 X-Received: by 10.31.5.13 with SMTP id 13mr787911vkf.156.1488285192494; Tue, 28 Feb 2017 04:33:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 28 Feb 2017 04:32:51 -0800 (PST) In-Reply-To: References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> From: Lorenzo Colitti Date: Tue, 28 Feb 2017 21:32:51 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a1143d9c6398f41054996666f Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 12:33:15 -0000 --001a1143d9c6398f41054996666f Content-Type: text/plain; charset=UTF-8 On Tue, Feb 28, 2017 at 7:42 PM, Fernando Gont wrote: > The current workaround is that folks end up relying on the DNS info > conveyed via DHCPv4. But that is not only bad, but also inadequate since > IPv4 is supposed to go away (eventually). > I would suggest: - When IPv4 goes away, replace DHCPv4 with stateless DHCPv6. - Until then, use RDNSS. Stateless DHCPv6 is worse than RDNSS in many ways. Most importantly, it's not suited to mobile nodes and unmanaged networks because: 1. It's impossible to communicate quickly to hosts when something has changed, you have to wait for the hosts to ask again. 2. Even if you crank the lifetimes to the minimum level, it's impossible to change anything more quickly than 10 minutes. See RFC 4242 section 3.1. 3. On links where transmitting is expensive, such as wifi, it's more expensive to transmit a packet than to passively receive a multicast RA. I don't see why we should require hosts to implement stateless DHCPv6. If anything, we should require that they support RDNSS. It's much easier to implement RDNSS than stateless DHCPv6 since all IPv6 nodes are required to support SLAAC and the amount of extra code to implement RDNSS once you have a working SLAAC implementation is near zero. --001a1143d9c6398f41054996666f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 7:42 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
The = current workaround is that folks end up relying on the DNS info
conveyed via DHCPv4. But that is not only bad, but also inadequate since IPv4 is supposed to go away (eventually).

I would suggest:
  • When IPv4 goes away, replace DHCPv4 w= ith stateless DHCPv6.
  • Until then, use RDNSS.
Stat= eless DHCPv6 is worse than RDNSS in many ways. Most importantly, it's n= ot suited to mobile nodes and unmanaged networks because:
    It's impossible to communicate quickly to hosts when something has cha= nged, you have to wait for the hosts to ask again.
  1. Even if you cran= k the lifetimes to the minimum level, it's impossible to change anythin= g more quickly than 10 minutes. See RFC 4242 section 3.1.
  2. On links = where transmitting is expensive, such as wifi, it's more expensive to t= ransmit a packet than to passively receive a multicast RA.
I = don't see why we should require hosts to implement stateless DHCPv6. If= anything, we should require that they support RDNSS.

<= div>It's much easier to implement RDNSS than stateless DHCPv6 since all= IPv6 nodes are required to support SLAAC and the amount of extra code to i= mplement RDNSS once you have a working SLAAC implementation is near zero.
--001a1143d9c6398f41054996666f-- From nobody Tue Feb 28 04:39: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 411FF1295DE for ; Tue, 28 Feb 2017 04:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sZbQ7wtgsz9S for ; Tue, 28 Feb 2017 04:39:40 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A34E1295DD for ; Tue, 28 Feb 2017 04:39:40 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 40so11564982uau.2 for ; Tue, 28 Feb 2017 04:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JItRqFnfvVOJdM4yYk/A0tljnABbbib6516btQpktfY=; b=jyryN0xy0T0MUFfTjSh69rIrOczy47Gv+UE4FSMZM3uYhCYhkUgsGIOj3IpP5cgKiB 4ovPw1CpWtUgi2oQ1SGOe50U+r1i1tlFqKZp1NQullhDPqYfdxBQEWs5ulYsonpgCEGD fYhB38zju9eOSWtXY4W7p6QNXdqQYwUHLF/P1Mzc2ifZmVuH1tmd2K90Atc9A1ULFcfp WDerevxiGvSX5c8FZ+7PLtJz5iRMSO7/tAynNmtTTazzmPwkwK8DW1PxpYNLKSEcese3 z/XzU5oq2pfv/TNcikyB6vffZvjvJVyuUdQD1zT4L1R39hjZtZy72qpbBc7xJBECz2IQ kbNw== 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=JItRqFnfvVOJdM4yYk/A0tljnABbbib6516btQpktfY=; b=jH2qrxoI18egWEw1vA/UCZqWlu9ODsfgOEuO+9GbIgBKVjGwMs84XJnyuxQqcUdCcB kzkAH/RTGUvrEYyaZ4WMwCTInUAhDXGDqOPnYJYmuH1dWnUE7P09JKZ91Uhw9cgnQbH5 0ylg3c/P4OA//w/UyKfSxDBgczNSbwZPxCeFXTJkBfWFWw3V4RwCsKFPcbtU1xYWfkPg fScF/VqcOPN/FKzcNicqP/uuN2kNeWmdqMudJ4tELwzKyzw3zFRzisg8cOTX6X28FWyd sBR7bw9Pwk6R9FwrETIkBd2Gx+w8vw0Gu0i/Jb1g0HctgUXkxOZouo+1v4qLTD63R0Of Jslw== X-Gm-Message-State: AMke39k2O/NEg+0Z+wOnpWtHfAJqvtCbVk/6a9JiuOgRWWKf+84AFmE8RrQv8E+IIacRjrbTfq9ohosWJpHkmdLW X-Received: by 10.176.1.5 with SMTP id 5mr611687uak.30.1488285579248; Tue, 28 Feb 2017 04:39:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 28 Feb 2017 04:39:18 -0800 (PST) In-Reply-To: References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> From: Lorenzo Colitti Date: Tue, 28 Feb 2017 21:39:18 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a113d058c472f7c0549967d1e Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 12:39:42 -0000 --001a113d058c472f7c0549967d1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 8:20 PM, Fernando Gont wrote: > > Yes, but the =E2=80=9Conly-IPv6=E2=80=9D is the WAN link. > > See section "Testing has its challenges" of > -- that > should really be unacceptable for this group. > The thing that struck me the most about it is that an enterprise-class router was able to send RAs but did not have support to send RDNSS options. That's a completely trivial addition to the code. It's good that their vendor built it. --001a113d058c472f7c0549967d1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 8:20 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
> Y= es, but the =E2=80=9Conly-IPv6=E2=80=9D is the WAN link.

See section "Testing has its challenges" of
<https://blog.apnic.net/2017/01/19/= ipv6-only-at-microsoft/>=C2=A0 -- that
should really be unacceptable for this group.

The thing that struck me the most about it is that an enterprise-cla= ss router was able to send RAs but did not have support to send RDNSS optio= ns. That's a completely trivial addition to the code. It's good tha= t their vendor built it.
--001a113d058c472f7c0549967d1e-- From nobody Tue Feb 28 04:42:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6DC1295E3 for ; Tue, 28 Feb 2017 04:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ipjqdziCqQgc for ; Tue, 28 Feb 2017 04:41:56 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 82CC11295E1 for ; Tue, 28 Feb 2017 04:41:56 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cih6J-0000GOC; Tue, 28 Feb 2017 13:41:55 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> <20170228120653.8A853657C002@rock.dv.isc.org> In-reply-to: Your message of "Tue, 28 Feb 2017 23:06:53 +1100 ." <20170228120653.8A853657C002@rock.dv.isc.org> Date: Tue, 28 Feb 2017 13:41:54 +0100 Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 12:41:58 -0000 >> For the people who want to run IPv6 only, it would be nice if they would >> publish a BCP how their preferred solution handles DNSSEC local validation >> for IPv4 addresses. > >What issue to you see that needs a BCP because I can't see one. There seems to be a lot of thinking along the lines of 'we provide NAT64 and DNS64 and that's it'. And then maybe some hand waving about hosts doing 464xlat or everybody fixing their code to not use IPv4 literals. Note that we are talking about host requirements. Every setup where the CPE does DS-Lite or MAP-E/MAP-T, etc. doesn't require host changes. So if IPv6-only means no connection all to the IPv4 world, then it's fine. But IPv6-only seems to be used in many contexts to imply NAT64. From nobody Tue Feb 28 04:45: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 3C2DE1295EB for ; Tue, 28 Feb 2017 04:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZH2s9-9aM2R for ; Tue, 28 Feb 2017 04:45:26 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15AA1295DB for ; Tue, 28 Feb 2017 04:45:26 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 E267180EA4; Tue, 28 Feb 2017 13:45:23 +0100 (CET) To: Lorenzo Colitti References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> Date: Tue, 28 Feb 2017 09:45:17 -0300 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 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 12:45:28 -0000 On 02/28/2017 09:32 AM, Lorenzo Colitti wrote: > On Tue, Feb 28, 2017 at 7:42 PM, Fernando Gont > wrote: > > The current workaround is that folks end up relying on the DNS info > conveyed via DHCPv4. But that is not only bad, but also inadequate since > IPv4 is supposed to go away (eventually). > > > I would suggest: > > * When IPv4 goes away, replace DHCPv4 with stateless DHCPv6. Problem benig that not all host implementations support DHCPv6. > * Until then, use RDNSS. Problem being that not all host implementations support RDNSS. > Stateless DHCPv6 is worse than RDNSS in many ways. Are you suggesting that we provide guidance on this topic? -- If so, that'd be fine to me. -- So far, the current version of the doc just aims at having both options on the table. But I'd be fine with providing guidance. > Most importantly, > it's not suited to mobile nodes and unmanaged networks because: > > 1. It's impossible to communicate quickly to hosts when something has > changed, you have to wait for the hosts to ask again. > 2. Even if you crank the lifetimes to the minimum level, it's > impossible to change anything more quickly than 10 minutes. See RFC > 4242 section 3.1. > 3. On links where transmitting is expensive, such as wifi, it's more > expensive to transmit a packet than to passively receive a multicast RA. > > I don't see why we should require hosts to implement stateless DHCPv6. 1) so that for networks in which they want to convey DNS info in DHCPv6, they can. Besides, DHCPv6 is isefull for all sorts of other information. > If anything, we should require that they support RDNSS. That was the intent (I was assuming the SHOULD in node reqs, but maybe we should clarify this, and probably even raise the requirement to MUST) > It's much easier to implement RDNSS than stateless DHCPv6 since all IPv6 > nodes are required to support SLAAC and the amount of extra code to > implement RDNSS once you have a working SLAAC implementation is near zero. The intent is that nodes support both options. Hence, no matter what the network employs to convey DNS info, the host is able to learn it. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 28 04: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 B3DC71295E1 for ; Tue, 28 Feb 2017 04:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epe46qCAI7dG for ; Tue, 28 Feb 2017 04:48:01 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC04D1295DB for ; Tue, 28 Feb 2017 04:48:00 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 0A58580EA4; Tue, 28 Feb 2017 13:47:57 +0100 (CET) To: Lorenzo Colitti References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 28 Feb 2017 09:47:52 -0300 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 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 12:48:04 -0000 On 02/28/2017 09:39 AM, Lorenzo Colitti wrote: > On Tue, Feb 28, 2017 at 8:20 PM, Fernando Gont > wrote: > > > Yes, but the “only-IPv6†is the WAN link. > > See section "Testing has its challenges" of > > -- that > should really be unacceptable for this group. > > > The thing that struck me the most about it is that an enterprise-class > router was able to send RAs but did not have support to send RDNSS > options. That's a completely trivial addition to the code. It's good > that their vendor built it. ast time I checked, their vendor *didn't* built it. Other folks have reported that, when asking router vendors about RDNSS support, they responded "we don't implement it, and we don't have any plans to do so". That's why our doc requires router suppor for RDNSS, such that if that's your preferred choice for conveying DNS info, you have the necessary support in your router. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 28 05:42: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 B827C129532 for ; Tue, 28 Feb 2017 05:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 jY5WwEA-Lhaz for ; Tue, 28 Feb 2017 05:42:24 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C458B129529 for ; Tue, 28 Feb 2017 05:42:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1SDgLHE003441 for ; Tue, 28 Feb 2017 14:42:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0C90C2055A7 for ; Tue, 28 Feb 2017 14:42:21 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 03675202223 for ; Tue, 28 Feb 2017 14:42:21 +0100 (CET) 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 v1SDgKqk023315 for ; Tue, 28 Feb 2017 14:42:20 +0100 To: v6ops@ietf.org References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> From: Alexandre Petrescu Message-ID: Date: Tue, 28 Feb 2017 14:42:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 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] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 13:42:26 -0000 Le 28/02/2017 à 11:28, Erik Kline a écrit : > Because DHCPv6 of any form is not a host requirement (or at least not > last I checked). I just checked and DHCPv6 is there by default on my windows office computer... hope not breaking something... Alex > > On 28 February 2017 at 19:27, Fernando Gont > wrote: > > Hello, Erik, > > On 02/28/2017 07:18 AM, Erik Kline wrote: > > I oppose sneaking DHCPv6 as a MUST in this document: > > > > IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], > > and the stateless DHCPv6 mechanism specified in [RFC3315]. > > > > No. > > May I ask the basis on which you opposed? > > P.S.: Please not that we're not required the IA_NA part, but just > stateles part -- i.e., so that DHCPv6 can be employed to convey > additional configuration information (*not* addresses). > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Feb 28 05:46: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 8F491129529 for ; Tue, 28 Feb 2017 05:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ZJpP8SPSFzAy for ; Tue, 28 Feb 2017 05:46:15 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E352A129521 for ; Tue, 28 Feb 2017 05:46:14 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 40so13463656uau.2 for ; Tue, 28 Feb 2017 05:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eFL8z1p49hM8j5c/pwWnflh3AaEsYI8krROSknBsGio=; b=PuGleGVW2ucrbztQfofQAXMkOUieqpJqn23Ya5cFeQUpHF9/x14edsPm0HdCoP7ADd /0B1Tc9lnqoxM+hg3d6+Tb9VX/yzFkIO4ZFw4+aD9X3VJaNgZ8GXfymHzEbqhbeEzkqA gBhZUDu31Q+o6Ia0AfhLQnGrO0YRCYZT5XacQbS+A+f8m889++O+RIkcPCwapBeORXrf mYTw13898zS8sqlx+0b0g1P3AzeeW3rxbrLAySTfkDVKc66NDBpev0B1d2B+Lhh2LhuM rC8UHJ1DDruO6DA8wTNZFyfu7xynUGZ2fc8+GTSw7oSeRXkKTdoWgogM51f3OeCRTZxY Xtiw== 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=eFL8z1p49hM8j5c/pwWnflh3AaEsYI8krROSknBsGio=; b=dqxLZIaHB+N/1/sYLoMSZVvILX3StYSX+v6LQ+OVvbcnU+Uu7VEAMkdrsKeZEAnzTp jbIRDWjOtBNSNkBn6JeZzDF4/N6Z8zBdKUO1vKRoqpV0RTtpGn10I90Bm7NK9qrMQbLd EPdiSUyttWcxBR90Z0S5M2uqHWf1pjXPmzHm6/g3mPVfR3zYihiyampSMMryQZKYErcq HQ3LlemmJdqEHiEIlS3cMdZjVXj0E7D2qiQcO3l8bYFeHc1Lz8xPXBMWMYisbzFoXoox afkjqtXzK1bAQropmDaVrMEx0+rAy6itr5qwCj9wWfjxXpUltvvxwGKT1HPiMf5pjDWc 4D8g== X-Gm-Message-State: AMke39nIrMUCnqa9FdbAtrJhvu/MQEvBtxKvbJIwTzmSSy1f4MHUBmDkmMKvtnZ2GqHMzzbj9syQLCAiVTiGq3p9 X-Received: by 10.31.59.197 with SMTP id i188mr759231vka.45.1488289573862; Tue, 28 Feb 2017 05:46:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 28 Feb 2017 05:45:53 -0800 (PST) In-Reply-To: <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> From: Lorenzo Colitti Date: Tue, 28 Feb 2017 22:45:53 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=001a1142f1786002860549976b17 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 13:46:22 -0000 --001a1142f1786002860549976b17 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 28, 2017 at 9:45 PM, Fernando Gont wrote: > > * When IPv4 goes away, replace DHCPv4 with stateless DHCPv6. > > Problem benig that not all host implementations support DHCPv6. > > > * Until then, use RDNSS. > > Problem being that not all host implementations support RDNSS. > Actually, no problem. All implementations support DHCPv4, so for as long as you run DHCPv4 with RDNSS things work. Then, when you replace DHCPv4 with DHCPv6, all implementations support either DHCPv6 or RDNSS and things still work. > Stateless DHCPv6 is worse than RDNSS in many ways. > > Are you suggesting that we provide guidance on this topic? -- If so, > that'd be fine to me. -- So far, the current version of the doc just > aims at having both options on the table. But I'd be fine with > providing guidance. > Personally I'm fine with providing guidance that all implementations should support RDNSS, but a) I doubt we'll reach consensus, and b) I don't think it will matter even if we do. > I don't see why we should require hosts to implement stateless DHCPv6. > > 1) so that for networks in which they want to convey DNS info in DHCPv6, > they can. > "Hosts should do something so that networks can do what they want"? Is that going to be sufficient motivation? The incentives don't seem to align very well. --001a1142f1786002860549976b17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 9:45 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
>=C2=A0 =C2=A0* When= IPv4 goes away, replace DHCPv4 with stateless DHCPv6.

Problem benig that not all host implementations support DHCPv6.

>=C2=A0 =C2=A0* Until then, use RDNSS.

Problem being that not all host implementations support RDNSS.

Actually, no problem. All implementations support D= HCPv4, so for as long as you run DHCPv4 with RDNSS things work. Then, when = you replace DHCPv4 with DHCPv6, all implementations support either DHCPv6 o= r RDNSS and things still work.

> Stateless DHCPv6 is worse than RDNSS in many w= ays.

Are you suggesting that we provide guidance on this topic? -- If so,=
that'd be fine to me. -- So far, the current version of the doc just aims at having=C2=A0 both options on the table. But I'd be fine with providing guidance.

Personally I'm = fine with providing guidance that all implementations should support RDNSS,= but a) I doubt we'll reach consensus, and b) I don't think it will= matter even if we do.

<= span class=3D"">> I don't see why we should require hosts to impleme= nt stateless DHCPv6.

1) so that for networks in which they want to convey DNS info in DHC= Pv6,
they can.

"Hosts should do somethi= ng so that networks can do what they want"? Is that going to be suffic= ient motivation? The incentives don't seem to align very well.
--001a1142f1786002860549976b17-- From nobody Tue Feb 28 05:47: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 210E912952E for ; Tue, 28 Feb 2017 05:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 nXsWoTxnCU1Y for ; Tue, 28 Feb 2017 05:47:01 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D32F12953A for ; Tue, 28 Feb 2017 05:47:00 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 72so13428887uaf.3 for ; Tue, 28 Feb 2017 05:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6bqLI0F8vW+vIhYZ4AZWLj0kzLTF68Yg1v3TKKCPCTI=; b=v2WnyN7oxsJ8iehVulXWKAW9dd6ZqckDfdvH9MmVkuWGKDO1fyZgO8Bj+w2FI/tfPS aH7jIi/dIVn9YuOg35IKjXMZcX1VSB0PHboMDYEdSzXt0HNC0Zy2pAzNvmA90fcDr9Wy LijXGFZWGEtPahrUJ72GPbGBl3eZXV09can6jEeNuvMjcQItUt4HFC8jaMCu2lKA2dN4 ++x3Op7k2KyXrXolZqIsOxw0JT1fyeBqiviYwcR6d0NMxA0NJxiLHDr2FJw+x25asXqA cA6dCI2gm6XZ+OtDAvT6/84KzzQhSgWweK1fXdVhm6A3+ofQSUCxWgSE77fMS3FhzadD RiMw== 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=6bqLI0F8vW+vIhYZ4AZWLj0kzLTF68Yg1v3TKKCPCTI=; b=J7IDsPffeuMOqhhLerPsgRa23d5BpB8jSowPomwlqT/ASTdcLSv5UpLQbNgNyMXNQm J18UQ4TqNL2FddvYjpRD94GdNuLc6dSobLTZUVCZuv8G59rAN5W4wwY2DLd3NIhls/FS J1tqX5E4jCqnZTdvwJgfypmFyvFYHHVvYpY3jUt03OUtl8mJJHywtc5075oZ6TKd6qXX qSjN1wKLvDWs98w26ginGWlmlbrTJkfrqLsUW+204mPAtf+Z1u9rKil61o5zjc77dH4/ ZMn401KsHmtKaXgzW1X5KS0yxFhRnaFUp4rjvflS4wNxmDsNnvA0qhs+1MGPUto+HGsz FS/A== X-Gm-Message-State: AMke39lRHUg0qUyth7fSHRbmrZfvSJEnv80vK4yPctyPSVCu8Mvt3FGyW19+k1JRSzMLrwl4Imqi8Iks7Lw/kFLy X-Received: by 10.159.40.202 with SMTP id d68mr1113478uad.122.1488289619310; Tue, 28 Feb 2017 05:46:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 28 Feb 2017 05:46:38 -0800 (PST) In-Reply-To: References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> From: Lorenzo Colitti Date: Tue, 28 Feb 2017 22:46:38 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=94eb2c12382e15566e0549976e25 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 13:47:02 -0000 --94eb2c12382e15566e0549976e25 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 28, 2017 at 9:47 PM, Fernando Gont wrote: > > The thing that struck me the most about it is that an enterprise-class > > router was able to send RAs but did not have support to send RDNSS > > options. That's a completely trivial addition to the code. It's good > > that their vendor built it. > > ast time I checked, their vendor *didn't* built it. They did build it. The article says "we are currently testing new code from the router vendor which supports RDNSS". --94eb2c12382e15566e0549976e25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 9:47 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
> The thing that struck me the = most about it is that an enterprise-class
> router was able to send RAs but did not have support to send RDNSS
> options. That's a completely trivial addition to the code. It'= s good
> that their vendor built it.

ast time I checked, their vendor *didn't* built it.
=

They did build it. The article says "we are curren= tly testing new code from the router vendor which supports RDNSS".
--94eb2c12382e15566e0549976e25-- From nobody Tue Feb 28 06:06: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 C59D4129586 for ; Tue, 28 Feb 2017 06:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSHes5P66JKQ for ; Tue, 28 Feb 2017 06:06:05 -0800 (PST) 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 1E084129578 for ; Tue, 28 Feb 2017 06:06:04 -0800 (PST) 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 E6EF427327 for ; Tue, 28 Feb 2017 15:06:01 +0100 (CET) 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 D5C6816545C for ; Tue, 28 Feb 2017 15:06:01 +0100 (CET) Received: by ws26.ernw.net (Postfix, from userid 1002) id 10B7B391E6; Tue, 28 Feb 2017 15:06:02 +0100 (CET) Date: Tue, 28 Feb 2017 15:06:02 +0100 From: Enno Rey To: v6ops@ietf.org Message-ID: <20170228140602.GD75080@ernw.de> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.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] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:06:08 -0000 Hi, On Tue, Feb 28, 2017 at 02:42:07PM +0100, Alexandre Petrescu wrote: > > > Le 28/02/2017 ? 11:28, Erik Kline a ?crit : > > Because DHCPv6 of any form is not a host requirement (or at least not > > last I checked). > > I just checked and DHCPv6 is there by default on my windows office > computer... hope not breaking something... well, looking at https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/ it might actually be that the combination of DHCPv6 being enabled by default on Win systems and its current behavior leads to unexpected behavior in some networks... best Enno > > Alex > > > > > On 28 February 2017 at 19:27, Fernando Gont > > wrote: > > > > Hello, Erik, > > > > On 02/28/2017 07:18 AM, Erik Kline wrote: > > > I oppose sneaking DHCPv6 as a MUST in this document: > > > > > > IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], > > > and the stateless DHCPv6 mechanism specified in [RFC3315]. > > > > > > No. > > > > May I ask the basis on which you opposed? > > > > P.S.: Please not that we're not required the IA_NA part, but just > > stateles part -- i.e., so that DHCPv6 can be employed to convey > > additional configuration information (*not* addresses). > > > > 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 > > > > _______________________________________________ > 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 Feb 28 06:27: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 2708C129598 for ; Tue, 28 Feb 2017 06:26:59 -0800 (PST) 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 joIsoE0v-u93 for ; Tue, 28 Feb 2017 06:26:58 -0800 (PST) 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 9FB87129563 for ; Tue, 28 Feb 2017 06:26:57 -0800 (PST) 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 v1SEQtu2039280 for ; Tue, 28 Feb 2017 15:26:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C7724201019 for ; Tue, 28 Feb 2017 15:26:55 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BDC21200BCA for ; Tue, 28 Feb 2017 15:26:55 +0100 (CET) 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 v1SEQsmn026182 for ; Tue, 28 Feb 2017 15:26:55 +0100 To: v6ops@ietf.org References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> From: Alexandre Petrescu Message-ID: <3ae7f57e-d7ef-2dd6-cc63-fd5c6f4e7163@gmail.com> Date: Tue, 28 Feb 2017 15:26:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:26:59 -0000 Le 28/02/2017 à 12:04, Fernando Gont a écrit : > On 02/28/2017 07:53 AM, JORDI PALET MARTINEZ wrote: >> I think today LANs must be dual-stack, if you want to avoid all kind >> or problems, > > Actually, I've seen/read a lot of bragging about IPv6-only nets. > Including IPv6-only mobiles. I would not call that bragging, and I understand the pride of people doing IPv6-only networks. I share that. However, I would be careful with statements that claim some smartphone devices do IPv6-only on an IPv6-only cellular network. Just type ifconfing and route on them and IPv4 addresses show up. >> so if the IPv6 node requirements take a bit extra time >> to update, should not be a problem, because you can use DNS with IPv4 >> on a dual-stack LAN. > > If an IETF IPv6 group's solution to an IPv6 problem is to rely on IPv4, > I'm afraid we'll have a hard time to be taken seriously by the folks > that we expect to deploy v6 (and by others, too). I agree with you. But let me show you otherwise too. It depends how this IPv6-DNS-Server -in-RA, or -in-DHCPv4, or -in-DHCPv6 is done; let me explain. On an office network I am familiar with typing ipconfig /all showed me to my great surprise an IPv6 Address for the DNS Server. I have no idea where it comes from: is it from DHCPv4? Is it self-derived from an IPv4 address? After some digging I realize it comes from the IETF meeting! I only go there some every 4 months, but it got on my PC forever. Is it normal? Certainly not - it is a full error and IETF should stop configuring such an IPv6 address on my computer for more than the duration of the IETF meeting :-) I dont care whether it is with RA or with DHCPv6, but must be conditioned by lifetime. Also, another office network I am familiar with has no IPv6 support, but it has many Hosts that speak much IPv6 ("chatter") even though the routers dont forward to Internet. These protocols are: ICMPv6, DHCPv6, MDNS, LLMNR, SSDP, HTTP, TCP. Wireshark shows them. They come from Macs, PCs and linuces. To the IPv6 deployer this is a very encouraging sign - s/he doesnt have do anything and IPv6 is there :-) But from other standpoints (e.g. security), this is far from normal, because we want this office network to be IPv4 only, at this time. How can we get rid of these IPv6 messages? (remark this is an inverse problem to that of deploying IPv6). Among these IPv6 protocols sitting there by default, using MDNS means there is no need for a DNS address (neither from DHCPv6 nor DHCPv4, nor from RA). The DNS requests are sent to a dedicated mcast address, hoping someone will reply. So, even if one wanted to deliver the IPv6 DNS address to end users, maybe neither DHCPv6 nor DNS are needed, and MDNS would be sufficient. Finally, RFC6106 does not offer a means for the Host to request the address of the DNS server, AFAIK (e.g. option in RS called 'request DNS address'). Whereas it should be the Host that should be answered, not imposed. As such, it would be good if an RS requested the address of a DNS server. RFC6106 doesnt, AFAIK. Alex > > Cheers, > From nobody Tue Feb 28 06:44: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 EC6111295A1 for ; Tue, 28 Feb 2017 06:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXRFUENAPQ6N for ; Tue, 28 Feb 2017 06:44:00 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id B0E5A1295AD for ; Tue, 28 Feb 2017 06:43:59 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cij0P-0000EFC; Tue, 28 Feb 2017 15:43:57 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4F6B3113-9C1F-4F2F-ABE5-8701E38BB832@consulintel.es> <99e8a81a-6e24-e5fc-1453-8b71c740109e@si6networks.com> <3ae7f57e-d7ef-2dd6-cc63-fd5c6f4e7163@gmail.com> In-reply-to: Your message of "Tue, 28 Feb 2017 15:26:40 +0100 ." <3ae7f57e-d7ef-2dd6-cc63-fd5c6f4e7163@gmail.com> Date: Tue, 28 Feb 2017 15:43:56 +0100 Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:44:02 -0000 > On an office network I am familiar with typing ipconfig /all showed > me to my great surprise an IPv6 Address for the DNS Server. I have > no idea where it comes from: is it from DHCPv4? Is it self-derived > from an IPv4 address? After some digging I realize it comes from > the IETF meeting! I only go there some every 4 months, but it got > on my PC forever. Is it normal? Certainly not - it is a full > error and IETF should stop configuring such an IPv6 address on my > computer for more than the duration of the IETF meeting :-) I dont > care whether it is with RA or with DHCPv6, but must be conditioned > by lifetime. If you have a mobile device, then if it moves to a different network it should flush (or at least validate) its network parameters. Otherwise you would force everybody to use insanely short life times. Say if you walk from the IETF meeting to a restaurant and your PC would still try to use the addresses and resolvers it got at the meeting network. > Also, another office network I am familiar with has no IPv6 support, > but it has many Hosts that speak much IPv6 ("chatter") even though > the routers dont forward to Internet. These protocols are: ICMPv6, > DHCPv6, MDNS, LLMNR, SSDP, HTTP, TCP. Wireshark shows them. They > come from Macs, PCs and linuces. To the IPv6 deployer this is a > very encouraging sign - s/he doesnt have do anything and IPv6 is > there :-) But from other standpoints (e.g. security), this is far > from normal, because we want this office network to be IPv4 only, > at this time. How can we get rid of these IPv6 messages? (remark > this is an inverse problem to that of deploying IPv6). Great, so the 'dentist office' scenario is actually working. If you want to tell your systems that there is no IPv6, then you would have to invent a DHCPv4 option for that. Most people consider it a feature that you can just connect a bunch of hosts without infrastructure and it just works. > Finally, RFC6106 does not offer a means for the Host to request > the address of the DNS server, AFAIK (e.g. option in RS called > 'request DNS address'). Whereas it should be the Host that should > be answered, not imposed. As such, it would be good if an RS > requested the address of a DNS server. RFC6106 doesnt, AFAIK. RS is a Router Solicitation. Let's not abuse it even further. If you want to solicit DNS information, send a DHCPv6 information request. From nobody Tue Feb 28 11:16: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 B0C4312968A for ; Tue, 28 Feb 2017 11:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 BblRdeaMUR1V for ; Tue, 28 Feb 2017 11:16:41 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12D6129689 for ; Tue, 28 Feb 2017 11:16:40 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 72so24794928uaf.3 for ; Tue, 28 Feb 2017 11:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YB+CfAraKuwfD5NrZEpfmWMcbJ9Ui0IlER/hQ61b8y0=; b=YxJVNWXkf4K3ebdaYojcz95444jexRdynlQ+ULZ2Mma1fQnDcRAwiwCrtbGxtRUuDk PT32q43e1S8vgyG83p+yriam4UWwUiqaFRoIZA4ErcGBzx/EmHOtcEiU4C0VuBp3eS8m y/p2wGfmh+9M783BBYSfgs1j0ELGgAL48WzZ4FXitjlfzXppPpIXdbgYcuwP4mqNY0tc 6ROBZl1EIenMrhkUEw0BTE1kG8R3WdvUh2Gvz4OQyn+XR7HmxQ+MfwmSPBXbIrCHMGxD cwlXlG7z9Oi3tdwCiHRQplTz+8NM6gSYIvKrpKJDothz5OvmTo3HVmJMPTwMdbrWxyA7 6ikg== 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=YB+CfAraKuwfD5NrZEpfmWMcbJ9Ui0IlER/hQ61b8y0=; b=GNuQd/DIICvQtT36keMyIK4YTfHDL8WtQNm/Zub62ptrvfVyR8n7jWaeVFjlWB4ZwB fnITJJ1Vdh5sFOL02QF4BVMupFhj4XAYvqha7+hrx2gVYLQQO8BajuHzFcu59GLOoTXr REyXB4M8h5fHh26T66d/GueLM5BqWjSZ3mR+ubfHPYkD/VmbJ/uJZ3GM/wbwtQnCFLje 2wruuYYAMglg8V02c5b/A1JB5mcKvFf4bnpoLAY5APfMxx/upvilgxFj5shgeBg3g91u irjleiifBKQXZR73j0n8SepOHPDBT8PaUtFdx5AqZ+nnVluMhaoHnriOld7w218Ve1bH en1Q== X-Gm-Message-State: AMke39kptLMVAPyP0l7g9YtnAn7iqCieutihxX0FvnKBjUsz8l1FancvLNOVSItYqg+95ydFVx1eiJn2VTIfxQ== X-Received: by 10.31.108.147 with SMTP id j19mr1493370vki.149.1488309399950; Tue, 28 Feb 2017 11:16:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.2 with HTTP; Tue, 28 Feb 2017 11:16:09 -0800 (PST) In-Reply-To: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> From: Mark Smith Date: Wed, 1 Mar 2017 06:16:09 +1100 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:16:41 -0000 Hi, On 28 February 2017 at 19:13, Fernando Gont wrote: > Folks, > > Based on a recent discussion regarding the problem of conveying DNS > information in IPv6 networks, we have submitted this short I-D, in the > hopes of getting the aforementioned problem solved. > > Your feedback will be appreciated. > OK! First thought is that I think a different term than "SLAAC" should be used, as SLAAC is just an address configuration method/mechanism that uses RA PIO options (which is all that is described in RFC4862). It doesn't configure anything else, so for SLAAC, the second part of this sentence in the abstract isn't correct - "These two mechanisms allow for the configuration of IPv6 addresses and a number of network parameters." What you're really mandating here is host support for and processing of RA Recursive DNS Options and DNS Search List Options. They're from the set of options that can be carried in RAs, and RAs are specified in RFC4861, "Neighbor Discovery in IPv6". I think I'd also be more specific in the description of the issue. I read it as being general enough that it is implying that RAs and DHCPv6 are equal mechanisms for configuring any of hosts' parameters, where as really there are only two specific overlaps, and the specific issues that are addressed in this draft exist because of these specific overlaps: - interface addresses - DNS parameters Inadvertently encouraging this view that RAs and DHCPv6 are equals will only further encourage more options or capabilities to be duplicated in either of them, creating more implementation confusion, and requiring further drafts such as this. The problem will get worse not better. If we cannot deprecate any of the conflicting methods, in the least we can try to ensure this problem doesn't happen again. Regards, Mark. > Thanks! > Fernando (and co-autors) > > > From nobody Tue Feb 28 11:53: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 DC563127071 for ; Tue, 28 Feb 2017 11:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s-lYn3T9yQn8 for ; Tue, 28 Feb 2017 11:53:06 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCD9126579 for ; Tue, 28 Feb 2017 11:53:05 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F0B2B617F4 for ; Tue, 28 Feb 2017 20:53:03 +0100 (CET) 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 9DD4F615D2; Tue, 28 Feb 2017 20:53:03 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 8550B704BE; Tue, 28 Feb 2017 20:53:03 +0100 (CET) Date: Tue, 28 Feb 2017 20:53:03 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20170228195303.GU2367@Space.Net> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:53:09 -0000 Hi, On Tue, Feb 28, 2017 at 10:45:53PM +0900, Lorenzo Colitti wrote: > Actually, no problem. All implementations support DHCPv4, so for as long as > you run DHCPv4 with RDNSS things work. Then, when you replace DHCPv4 with > DHCPv6, all implementations support either DHCPv6 or RDNSS and things still > work. Real people are trying to build v6-only networks today, and run into massive problems due to the combination of "one major OS vendor refuses to do stateless DHCPv6, and one major router vendor refuses to implement RDNSS". So, they cannot reasonably implement what should have been the default for new deployments years ago, and need to add IPv4 purely because IETF failed to very clearly mandate what router and host OS vendors need to provide, so a network can run v6-only today... Well done, folks. 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 Feb 28 12:29: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 2591D1296C7 for ; Tue, 28 Feb 2017 12:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FqtcPtLjU-SD for ; Tue, 28 Feb 2017 12:29:19 -0800 (PST) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1B81296BB for ; Tue, 28 Feb 2017 12:29:19 -0800 (PST) Received: from [192.168.1.23] (dusted.otenet.gr [195.167.126.245]) by calypso.otenet.gr (ESMTP) with ESMTPSA id 751A113804D; Tue, 28 Feb 2017 22:29:16 +0200 (EET) To: jordi.palet@consulintel.es, v6ops@ietf.org References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> From: Yannis Nikolopoulos Message-ID: <73771501-23f6-6117-28ca-f779682311f2@otenet.gr> Date: Tue, 28 Feb 2017 22:29:16 +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: <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:29:21 -0000 Hi, I just don't get why is lw4o6 differentiated from MAP. To me, it does not make sense that one is optional and the other two are not. The rationale does not help much either regards, Yannis On 02/21/2017 11:11 AM, JORDI PALET MARTINEZ wrote: > Hi, > > I’ve submitted a -bis draft for updating RFC7084 (Basic Requirements for IPv6 Customer Edge Routers). > 1) Considering that there’re no more IPv4 addresses and according to my experience with service providers, they will prefer to avoid dual stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to be changed to MAY. > > 2) At the same time, I’ve included lw4o6, also with MAY. The rationale for this: Many service providers try to avoid the CGN, and lw4o6 is a way to do so, without increasing the cost of the CE. Basically, a CE that supports a regular IPv4 NAT+DS-Lite, is already capable of supporting lw4o6. The cost in terms of CE flash memory for DS-Lite is about 1Kb. The open source package available for DS-Lite that I’ve been digging-in takes 6Kb, but already includes also support for both MAP versions. > > 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those protocols are the 3 alternatives that a service provider has to deploy IPv6-only WAN, but at the same time provide dual-stack in the LANs, with practically the same functionalities or even more, that what CGN requires. At the service provider network, it requires, instead of CGN, a stateful NAT64 (which cellular providers are already using) or a Border Relay (for MAP). Basically, a CE needs only 3Kbytes of code in the flash to support CLAT (the CE part of 464XLAT). The support for MAP (both versions and also lw6o4), requires about 6Kb. > > Regards, > Jordi > > > From nobody Tue Feb 28 12:42: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 CF8311296F2 for ; Tue, 28 Feb 2017 12:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 h4Om23ze7uAd for ; Tue, 28 Feb 2017 12:42:47 -0800 (PST) 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 E47761296CB for ; Tue, 28 Feb 2017 12:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488314564; x=1488919364; 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=ICaIu/376YtcCnECs1i7QcBWh 3K2VijXeBc/+rHML1c=; b=hz8D6W3PR7KbdJQCtcURWZuOxWJXwXvJ0NbRSzGWI HipdtbnNyhBYQE7w2BbRJY/Wzwn1G6FFGB2u1JaruQtwar+jIzzg9hgQEJ68TjnL lSG6ZaQeAPVK1YZrRjgtXh9LFdn/f4pHY/e81JQ8lP7Zxy8AzVopKuMwm+vd/IB1 B4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=HyEi5CLehyIOKq5wxzxMD46GKcr8KkfuQzDANSSMYFqrq5+6n+83ewqtiy7+ Xj7vO5ujaYBVE8SBKZygUznPtf39W2TA1SmK0iIMax8Sq8HLW7ffnGW55 Qo2sFqOHs4nmjvs7n0gyRjanr2jYZiQgvu8i+PVQjx1As1yernFrYw=; X-MDAV-Processed: mail.consulintel.es, Tue, 28 Feb 2017 21:42:44 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 28 Feb 2017 21:42:43 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005375987.msg for ; Tue, 28 Feb 2017 21:42:42 +0100 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:170228:md50005375987::024xoICU3RYHc1AK:00000RZZ X-Return-Path: prvs=123297a6ff=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 28 Feb 2017 21:42:39 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <5E812E8E-EECA-4F2F-8408-BAA73A3A7524@consulintel.es> Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <73771501-23f6-6117-28ca-f779682311f2@otenet.gr> In-Reply-To: <73771501-23f6-6117-28ca-f779682311f2@otenet.gr> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:42:49 -0000 Hi Yannis, I=E2=80=99m not sure to understand your point. Unless I did a mistake while editing the draft, all them are with SHOULD. Regards, Jordi =20 -----Mensaje original----- De: Yannis Nikolopoulos Responder a: Fecha: martes, 28 de febrero de 2017, 21:29 Para: , Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7= 084-bis-00.txt Hi, =20 I just don't get why is lw4o6 differentiated from MAP. To me, it does= =20 not make sense that one is optional and the other two are not. The=20 rationale does not help much either =20 =20 regards, =20 Yannis =20 =20 On 02/21/2017 11:11 AM, JORDI PALET MARTINEZ wrote: > Hi, > > I=E2=80=99ve submitted a -bis draft for updating RFC7084 (Basic Requi= rements for IPv6 Customer Edge Routers). =20 =20 > 1) Considering that there=E2=80=99re no more IPv4 addresses and accor= ding to my experience with service providers, they will prefer to avoid dua= l stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to be = changed to MAY. > > 2) At the same time, I=E2=80=99ve included lw4o6, also with MAY. The = rationale for this: Many service providers try to avoid the CGN, and lw4o6 = is a way to do so, without increasing the cost of the CE. Basically, a CE t= hat supports a regular IPv4 NAT+DS-Lite, is already capable of supporting l= w4o6. The cost in terms of CE flash memory for DS-Lite is about 1Kb. The op= en source package available for DS-Lite that I=E2=80=99ve been digging-in t= akes 6Kb, but already includes also support for both MAP versions. > > 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those protoco= ls are the 3 alternatives that a service provider has to deploy IPv6-only W= AN, but at the same time provide dual-stack in the LANs, with practically t= he same functionalities or even more, that what CGN requires. At the servic= e provider network, it requires, instead of CGN, a stateful NAT64 (which ce= llular providers are already using) or a Border Relay (for MAP). Basically,= a CE needs only 3Kbytes of code in the flash to support CLAT (the CE part = of 464XLAT). The support for MAP (both versions and also lw6o4), requires a= bout 6Kb. > > Regards, > Jordi > =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 Tue Feb 28 12:45: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 4AC321296B6 for ; Tue, 28 Feb 2017 12:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcdpLCVKx-uJ for ; Tue, 28 Feb 2017 12:45:19 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C3B1296CB for ; Tue, 28 Feb 2017 12:45:19 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 9E63F80634; Tue, 28 Feb 2017 21:45:16 +0100 (CET) To: Mark Smith References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 28 Feb 2017 17:41:21 -0300 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 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:45:20 -0000 Hello, Mark, On 02/28/2017 04:16 PM, Mark Smith wrote: > First thought is that I think a different term than "SLAAC" should be > used, as SLAAC is just an address configuration method/mechanism that > uses RA PIO options (which is all that is described in RFC4862). SLAAC is more than that. Loo at the plethora of RA options that have been specified --- including e.g. RIO and RDNSS > It > doesn't configure anything else, so for SLAAC, the second part of this > sentence in the abstract isn't correct - "These two mechanisms allow > for the configuration of IPv6 addresses and a number of network > parameters." Routes, DNS information... > What you're really mandating here is host support for and processing > of RA Recursive DNS Options and DNS Search List Options. They're from > the set of options that can be carried in RAs, and RAs are specified > in RFC4861, "Neighbor Discovery in IPv6". That said, if you can suggest an alternative title, please do. > I think I'd also be more specific in the description of the issue. I > read it as being general enough that it is implying that RAs and > DHCPv6 are equal mechanisms for configuring any of hosts' parameters, > where as really there are only two specific overlaps, and the specific > issues that are addressed in this draft exist because of these > specific overlaps: We'll try to clarify this. That said, if you have specific suggestions in that respect, please do let us know. > Inadvertently encouraging this view that RAs and DHCPv6 are equals > will only further encourage more options or capabilities to be > duplicated in either of them, creating more implementation confusion, > and requiring further drafts such as this. The problem will get worse > not better. If we cannot deprecate any of the conflicting methods, in > the least we can try to ensure this problem doesn't happen again. We tried to stay away from religious debates. Just note that DNS info can be configured with both, and that the current state of affairs is a mess. 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 Feb 28 12:51: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 30F651296FA for ; Tue, 28 Feb 2017 12:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 apqpWMV0X1mK for ; Tue, 28 Feb 2017 12:51:19 -0800 (PST) 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 0FF981296F9 for ; Tue, 28 Feb 2017 12:51:19 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id 25so10239285pgy.0 for ; Tue, 28 Feb 2017 12:51:19 -0800 (PST) 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=YhvtSPRiEUiJyq/yEOOpvEG0fs6HRqSvovulcf918IA=; b=cP/dKgONnosTIZHmCu2ETWVjG6hzNdoPY+ApOlcF4Mh2wpydVqMqWYwB4SdxnYHNu5 mkcJMyRRAXkzos270N26UlMKHI0FxGD9navXJzZKh42waxlgMMuo+cZksJS3CBeQUto7 HO+KXl23FKuaIrEhU/mg/HvQee84nMw/kY03Q1X7iFMUbF5NlJyx/zMry3yhezyXiLLi 7msSWO91NAsZcH0FQefeTGW8tuC0a9Fp7CTSmP6IOr+V2Kwwdr9yEhQoWKUuSlRmkLzL h7XLdzaEnDzuDfGVvun/SmCcPm+bQuIFbfqwZZS4kjfHSZJnvAq/0XMs/oxgPHB0QtLf XFRQ== 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=YhvtSPRiEUiJyq/yEOOpvEG0fs6HRqSvovulcf918IA=; b=N5g8EAhSPTvmtzZXkOGDH/od9eckze5IdWAb2rc8/fTHdk5A/ghmYhZNPjObeqDh81 n88sSXN0BXtBEB1QBevruIYBxisa/hoKO7J/SmY7xFdFQ6wmxlxSqmD+dDr90awtuMnA nX9DAWqDIOHJK5LIvcd7tKJMvERUzhgtaDk3waEZwH/6UDpU1mY2l3Fchm7r19rz62s+ Io+qGYtCV7eZguneEq+UsqcD2xyAreAf6Bbite5QrjM4uh5bxM/T/kTktsVcGvL6/Lw4 rZ6lEW/hUPgQjKYyNv4Qy0KNeHg9lwwTUjrkyJXLZBx678Gngh9IGFTmyUWV9KS0oOKi EvUw== X-Gm-Message-State: AMke39l/ZD9k9HsfZZ5Q+8P7wB8oX7tX+oLnCw8tzImvQ7SsQpiMWnJpmWuUh9mFexCOXRsv X-Received: by 10.99.112.75 with SMTP id a11mr4618943pgn.7.1488315078336; Tue, 28 Feb 2017 12:51:18 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id r12sm5982428pgn.26.2017.02.28.12.51.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 12:51:17 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_26C2DD37-977F-48D3-A1C8-6B80113DA820" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 28 Feb 2017 12:51:16 -0800 References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> To: IPv6 Operations In-Reply-To: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> Message-Id: <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:51:20 -0000 --Apple-Mail=_26C2DD37-977F-48D3-A1C8-6B80113DA820 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 28, 2017, at 00:13, Fernando Gont wrote: >=20 > This document [=E2=80=A6mandates=E2=80=A6] the stateless DHCPv6 = functionality in RFC 3315. This proposes a requirement for IPv6 host implementations that I have to = oppose. My reasoning follows: p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive = notifications that previously provided information has become invalid. = It=E2=80=99s very important that hosts receive timely notifications when = DNS server addresses are not valid anymore, otherwise they must rely on = heuristics for detecting the difference between transient and persistent = DNS server unavailability. These heuristics come with significant cost = to user experience and should therefore be avoided. RDNSS provides this = facility, whereas Stateless DHCPv6 does not. p2. On networks where all the routers are sending RA messages with O = flag cleared, I=E2=80=99d prefer that hosts weren=E2=80=99t constantly = trying to discover undeployed DHCPv6 servers. On such networks, IPv6 = addresses for DNS servers should only be available by manual = configuration. This may, in fact, be a perfectly reasonable = configuration for transitional dual-stack networks where DNS servers are = only available automatically by IPv4 and not IPv6. --james woodyatt > --Apple-Mail=_26C2DD37-977F-48D3-A1C8-6B80113DA820 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 28, 2017, at 00:13, Fernando Gont <fgont@si6networks.com> wrote:

This document [=E2=80=A6mandates=E2=80=A6] the stateless DHCPv6 functionality in RFC = 3315.

This proposes a requirement for IPv6 = host implementations that I have to oppose. My reasoning = follows:

p1. = Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive = notifications that previously provided information has become invalid. = It=E2=80=99s very important that hosts receive timely notifications when = DNS server addresses are not valid anymore, otherwise they must rely on = heuristics for detecting the difference between transient and persistent = DNS server unavailability. These heuristics come with significant cost = to user experience and should therefore be avoided. RDNSS provides this = facility, whereas Stateless DHCPv6 does not.

p2. On networks where all the routers = are sending RA messages with O flag cleared, I=E2=80=99d prefer that = hosts weren=E2=80=99t constantly trying to discover undeployed DHCPv6 = servers. On such networks, IPv6 addresses for DNS servers should only be = available by manual configuration. This may, in fact, be a perfectly = reasonable configuration for transitional dual-stack networks where DNS = servers are only available automatically by IPv4 and not IPv6.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_26C2DD37-977F-48D3-A1C8-6B80113DA820-- From nobody Tue Feb 28 13:23: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 2B37112950B for ; Tue, 28 Feb 2017 13:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 512hpaucdIIa for ; Tue, 28 Feb 2017 13:23:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9F91294E2 for ; Tue, 28 Feb 2017 13:23:52 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 96CE980EFB; Tue, 28 Feb 2017 22:23:49 +0100 (CET) To: james woodyatt , IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> Date: Tue, 28 Feb 2017 18:12:07 -0300 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: <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:23:54 -0000 Hello, James, On 02/28/2017 05:51 PM, james woodyatt wrote: > On Feb 28, 2017, at 00:13, Fernando Gont > wrote: >> >> This document […mandates…] the stateless DHCPv6 functionality in RFC 3315. > > This proposes a requirement for IPv6 host implementations that I have to > oppose. My reasoning follows: > > p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive > notifications that previously provided information has become invalid. > It’s very important that hosts receive timely notifications when DNS > server addresses are not valid anymore, otherwise they must rely on > heuristics for detecting the difference between transient and persistent > DNS server unavailability. If your network has such a requirement, use RDNSS rather than SLAAC. We're not mandating what you must *use*. Actually, we want to allow you to make that choice. Right now, you can't. Because Google's Android refuses to implement stateless DHCPv6, and MS Windows and a number of router vendors refuse to implement RDNSS. > p2. On networks where all the routers are sending RA messages with O > flag cleared, I’d prefer that hosts weren’t constantly trying to > discover undeployed DHCPv6 servers. On such networks, IPv6 addresses for > DNS servers should only be available by manual configuration. This may, > in fact, be a perfectly reasonable configuration for transitional > dual-stack networks where DNS servers are only available automatically > by IPv4 and not IPv6. I beg to differ. It seems totally unreasonable to me that folks have to resort to manual configuration (?!?) because two vendors are playing a rather silly game for which the folks deploying IPv6 networks pay the price. "You each name yourselves king, yet the kingdom bleeds." -- George R.R. Martin: A Clash of Kings 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 Feb 28 14:19: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 47D3C12706D for ; Tue, 28 Feb 2017 14:19:24 -0800 (PST) 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 36rgV-6-tvD9 for ; Tue, 28 Feb 2017 14:19:23 -0800 (PST) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D677C128DF6 for ; Tue, 28 Feb 2017 14:19:22 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) id <0OM300A00UZWJL00@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Tue, 28 Feb 2017 16:19:21 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.2.28.220917, AntiVirus-Engine: 5.33.0, AntiVirus-Data: 2017.1.25.5330001, SenderIP=207.46.163.117 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0117.outbound.protection.outlook.com [207.46.163.117]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPS id <0OM300L32VC84860@smtpauth3.wiscmail.wisc.edu>; Tue, 28 Feb 2017 16:19:21 -0600 (CST) Authentication-results: spf=none (sender IP is ) smtp.mailfrom=dale.carder@wisc.edu; Received: from localhost (47.41.164.78) by CY1PR06MB2124.namprd06.prod.outlook.com (10.166.193.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Tue, 28 Feb 2017 22:19:19 +0000 Date: Tue, 28 Feb 2017 16:19:11 -0600 From: "Dale W. Carder" To: james woodyatt Message-id: <20170228221911.GA45649@cs-it-6805697.local> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> In-reply-to: <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-Originating-IP: [47.41.164.78] X-ClientProxiedBy: BY2PR1001CA0009.namprd10.prod.outlook.com (10.164.163.147) To CY1PR06MB2124.namprd06.prod.outlook.com (10.166.193.25) X-MS-Office365-Filtering-Correlation-Id: 2fd96f0c-848f-445f-688c-08d46027d719 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR06MB2124; X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB2124; 3:LEJXj0TQ8dfwAVR/lcLYtT2RwGQCaz050pBjlDo3D3QL6oW9b9DHBpOjxBq3FZhpuntoFzmziwzA2CRls6u1tLufOgKxBW8bJan+HHo/QSmVxaZfgmdc6zgSu9mP35AaYNZuThBs+hJNdDUpGaNUZyDPvmrO5X1lI0VkNRhuQdVy5s1VJEGGdZTuZDKbpolYDy9ShrJGN1IvtcG4rgnqXgRBI7QcXW9rWdehqsF/EHTpPoy3LKuq7QnOhr1FW0chI46v9qQSY/uAr7e5c0aUvI1fXeClatSRPZ8u1KKTxJA=; 25:KpC7ZaSDLExsdshxc+oAG9kYkgj3FykyFxcMNoXzonQzbXjCpxQBqlNMLZ1+Uklih7KPfGXhUeKdZtk9pMkOM/Vd7YhLMn184R+hHCj5AYIkDbistbTIfO6LJIdmw+bDXbz1/zZe9jFYZmrzC42Tspet3/7Ho0879NZZmAxsRgSkmbaqK5jg00CTJcB2OthOrsPVyZShARrK7Po52rxipP7WsVKghwotZ920VvbtBBtxqRmAT3B68qqaWbuAfrlCVE8AnG92h+fTt2rInO4IRyFdSu+JTelS2o8ouF0jwSRSXHEOVeD6ScDKlXl0MRNGhWraXwzMNfAQU4Ztio0SEu/4HZ5DHOLFud6CAeEvJAKj1FFrvtZdmWHOg4SF1RlpzFDUaP0e0pYj7CHyh3DTFAOdR6ckPz0vLe2lxL1SddgU7CQvFLXgAZeLJ2wpQXFF8AcNiG8eA+Q6qvVx+DUHMQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB2124; 31:Oj64F/eFpEN1zfw5rBSpMg0nVI5BL3gxP+8wMaoHE2L0riCdooGYoL+LKiVdYsGMxDjipET63sWGDxa4RJip5GF7C7qUhZpMbkrGjUrFiFV+/LDEIwQeJnYSrE3z6Stpvt7Y+0mTfzMdc29vrutltYjo3Oq+wO3Zet5St3fYOAdy6zL9gJtAcDF5yJVgf4+44d9nZXhC4U19nJrHFry5Km0ZvcgZAi6raOWVTJzwtoXtNz4UmalVOHmrFgfiBm/Z; 20:DxwcOsArgdkizZDsGE2RhwtiQUMsan1mKoDoqN4Fe34xBKh+15vqr1VHupZwgaoYGJin15ImSvvBqnT3VdtxDaRhYcRLu5Vt6w7oh7Eyql13nYRyzybgUl8YCZpl7XdCEiU0S+EbnSCKAkIA8GrkkNv8OJPEVhJdxU+WHdc3034DzQkuj0Xt0yG9UPlfzg2fGtjTTlPoRirrkverOUDH8pHiVCTPpi46aqaX6QvwPkG4RQoqm3S6k/VVvrt3LWgZEAJvbneyNyTqIZ1TIiK+JUG5uOzyr0VNvtw1xjmJzPTAXBs7tmBDS3yN4AqBZTJFpJMleNUQL0pBg4jiRryyimGGfKZfm7z2GdsojhBIB/g= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(211936372134217); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:CY1PR06MB2124; BCL:0; PCL:0; RULEID:; SRVR:CY1PR06MB2124; X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB2124; 4:hHZB7KR2i6YdttqOixlfwrFWKVr665OQT0ZB82ebeUvtyXmDxor0hz1NDWF2jeEjXBG7FOXKiA5tupqYSbcX/gCKRjNPtevZqHD1mTUo2eKP5rQF5Lj0oYDMXpyUhWEVHwlp/QPurZ1WtvcrCvSuYCDazZuPEyTKh5n9HevMCNUXyW/OMaJ4DTzBLAo2F1hJR/u2m9lYBH6gFe4cDEjtW71Kx+RFFIMpmt+V0s+ldtq1NW3HhEHC2cXlDx7eiX1F30M8VnONUreJ65ZNynLBBhlCmZXl2DPUmWKu74u+SVvlSAU/QcB7yrkVzUREMXVUWMc6ch0qcds36ti3FZGs+hjxzOds/Oa3Aw+LHH0+SduXO3NwfxfaARSL2kl2WbBWsoAgRH38QG7+NKCkuIWvmOY1Ek/J18dGG+B274dAktKVuZBMXsEGEsxPHUtkgEBQQ50JBB2slIVOnOBSuhgbfXn9ggFNd8phdyq7k3f3lSO2K77btF5L6wCzsbcpPcy4dlG1xxOyQ7zydeqdUeUHlxTKk/F9P+lvwzIXUML2KmzkVKb7TphGokBbgTceo1K6NcsT+TE8ukfB4Q3Lfqj+r97Ejzq0nzuSok08PMV57UnCIznoucLqpdU7qwv8j2Jz58kjsy1cOA+7MxGWY9keVHcPzxxf+IzgZyZCISg2FhBBblpn0fRCWxCaDlKiTawVTY5m5/xvKAJV/bSPDOrznQ== X-Forefront-PRVS: 0232B30BBC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(39850400002)(39450400003)(39410400002)(39860400002)(39840400002)(199003)(24454002)(189002)(47776003)(97736004)(189998001)(110136004)(66066001)(6666003)(2906002)(38730400002)(6496005)(50466002)(15650500001)(98436002)(6246003)(4326008)(42186005)(53936002)(83506001)(92566002)(1076002)(9686003)(105586002)(76506005)(4001350100001)(88552002)(6116002)(305945005)(23676002)(7736002)(3846002)(2950100002)(6486002)(76176999)(229853002)(75432002)(25786008)(54356999)(68736007)(50986999)(8676002)(81156014)(6916009)(101416001)(81166006)(33656002)(230783001)(106356001)(5660300001)(2870700001)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR06MB2124; H:localhost; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: wisc.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA2TUIyMTI0OzIzOkJCSTEyQmFINk5IZW9VclFaMmhwZUwrWk9q?= =?utf-8?B?WjdRZ1NpMDM1eU0welVFemhpOFowaU9IT2NFQ2ZlbTcrVzRwWCtxb0o5UzJv?= =?utf-8?B?WURqbHA4cXVyMnlURi9OVEZIWHJJWnBrYmxwdElET21sL1psYnI4SEZzK2hq?= =?utf-8?B?NjNwOTRYa1ZaNGNCalJiZVJLM0pPNjVFS3pIaDVWZE9xVnk2Y2JwQ2IzWEZy?= =?utf-8?B?YnMrY1lkMy9sMGV4MHdsb3EwOHM3ampJK1lHRENUdW5WN1JlWDdkcTk1Qys1?= =?utf-8?B?WXhqd1RNZkUzSlhsS2hEeWZITmRIS3M1bi9wQ2ZhbEdNVVEvTm1lcm0wMEhv?= =?utf-8?B?bis4YndmZEtMaEZQN1JJQkJvejBoTUpLZS9lQVJyNWowMXRQdklnWVozSDBi?= =?utf-8?B?ZmFRMjZEd3BOdUlud2N5djFEQ1doMm16U3ZMeUVkdVRKNE80b1dRQWdlNlFO?= =?utf-8?B?Vkk5QVVJK2ZnQlM5MFliWk80VXdoaGNpc1VPTXRKS0trenc4L2RFc0RnTkJO?= =?utf-8?B?WlY5K1NhSW1zM0F3d3VxYWUzVGZubEVkTzI1bGc5ai9mL011aktRMCs4ZE9r?= =?utf-8?B?aE95ZTZUdk1seFJoUDdqTWNuZUpVVE1FVEtkQlNlWlh0ZzNBcUJOc3NCR2NP?= =?utf-8?B?d0s5VElYdnVZZXNmc0lSZXNvcWVoS09QejBxRnNmYzRzcnF1YjczYmhKSjRX?= =?utf-8?B?dm9YVUVxMXVBbTk3OXFScmhFZUF0U2hJeGRkeUhjb011QUxtSmFNWXlWV1hM?= =?utf-8?B?U1VCVDRmSUhxYnlmUDVkNkg0TFhuK3pXaHF6UGRMZXYxQ2R6a3F2dVE5V2Zy?= =?utf-8?B?WWRXbXp2MVpGb1h4MVFZMmIxM01SbGtjV3psRk9LTm1RV2piMEZ3cHo0ZlI1?= =?utf-8?B?Q0hhTVliYk56eXpRS3hROENMVXJERVIrSktkT3FHNk1MaGhTNFBjMXUxeHJF?= =?utf-8?B?bThQSnZlSm8ydG5vUHVrWUwwTEdWQ21JZHJtTVFOWEt5bFBzVkNZN28rbzJW?= =?utf-8?B?bk55T1RGUmg3bGVFbnl4dzdUTG44a1B1akpnWDE1OVRKL3Z2dzhDZHlOMjF3?= =?utf-8?B?V0ZQR0p0Tm11bXExRkV5SjFoYjAwR3NySXlmVmh0YTVsaXpBUG5rS0ZHQkkw?= =?utf-8?B?T05hS0VIMk5zUzlrVzd4RXp2UVBYb3Z2alJudWVRTVNCOFdwMlFTS1E1dWhM?= =?utf-8?B?bWpINm5YTWlBRHFrK2dOd1RxMnpoMVBDOWRJUG5iZS9VbEJ6QU9KclpYK2p3?= =?utf-8?B?LzZvd2ptT0dnb1hsdHErbWNQeGNoU1ZxZlc2aG4rR1BReDBDTEd6YUhwbzhm?= =?utf-8?B?WFNrRE16bHRUWkFpZEZyZ08zc09QaU1HKzF0NFdSTFdhQU90YkhMdVp1WmVZ?= =?utf-8?B?eG1JaXp6ZGxwaGx4Ym54UGJJNUtDQlZyVFdUMHVzY0wvNzQwWEFOTjZtWnVI?= =?utf-8?B?Vjg1Sm5zUW4raHFucnArelAxaEhQNVNFNVVNbDNHcHYrZm5vSlVGQ1BRTnpp?= =?utf-8?B?cG1reVRlMTJ4ZUJPUHdkaXc1TE9RdWRSY3d0aFlYMFRpTDJieXRVb2xReDdF?= =?utf-8?B?UXJHaUF3VkI0TXRsOG54dE1IdmhkUHpxN2dVMjg1MzFUK3l4L2F5RmNiSURC?= =?utf-8?B?dDZUNzFsVFpzdm9ac2JobllYY0NlWXF6eXlHVW05bHZ5anBKRTl1UUVpYWFQ?= =?utf-8?B?NGoyNWFnaXN6clBGdXdDOVd0cjFlU1FEL3ZBN2wzaUN0SHVua24yV0xyazFp?= =?utf-8?B?MmZqWXp0ZmRGVTQ5Qzh4YVgwQ3FRNnA1dkZFa0JRK25PN2VYVTZyeDczZ2cr?= =?utf-8?B?NlJJellPaW54SlR3bFQ1dEx1blZUWTk5azFhSi91R2xhTkprYUZyaS9sa005?= =?utf-8?B?SDlIRFE1azRiUS85b2pqUHp5L0NDajNMaHp5Q1cvdGR2djFpU253WW5IMERp?= =?utf-8?B?bHlZbW5XV3k0RERrMkhpNUErcHg2YS82aWxuRXdVdDlZQTFKRThkbmE1eW5q?= =?utf-8?Q?E8xCPQ?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB2124; 6:JXIqtxfFZPjJw174aQPtq7Ocz9ekkQrep1aic5nwGeCZ648ZgRswRXq44/PoCLmPWcyT/mObP0IJVCrcqZg5uq4iHYCy0f9DZmJ7yRlxK5NgNiSrjcOl523mLF6P/gsUI6wPtbJa6r7y/mGM2CVZn0eRyVMwp1QloHCH5D08qANZfLHeuk1ba82GSIcOQ82LMf39KqiiZjhF9qJDBiMbAw1OsQNAkQ3la0QoOhlYu9izcqFKWin7Gxw63oNgyEVbltVU8LnT/MwURg2PGuRxcbte3qL4Pdik/PbsvymS6nHjxp0NLLzrMSuLfTNM1unJ9b/WZyP3fcB1KSboEVdDzUx707WpeR+Lr1gLG72PfGGLb6dUeTlWsqccBFa5jCQqME5PwMGhOrvnk0FRxJE2Ya2OC24HQ5oqA7+hs+VBBDo=; 5:yChbUrIEiAWw43PCjoitUr0+h6hWNnwS+grK40lFx8n5KWBGFI5q+jHXuFcYs2CAcROPJHQbK2QpA0If4E57a71Fi4tYnmMZLggadgjDXbFjU7KzyY+HYTYV5rkm5fahSeUK625vEnlelyVYc74w5Q==; 24:+XNs66aquf30rYTR8ARklAaxN3hI8ZDBDueSGmNQJSrR6nX9OOIBmCtB1lKZSIYnQqQ22tvZezC42ki0bFXSdvx2xEvCVQGrbFdyewEBEpI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB2124; 7:eBDXFW/fpupikT2GcjW6czW8dYkptM//htsKHDBjJarC00eWhnNhaE+qjap3s/qfrB4DN2zaazuIn3WgOoHW9ttJkNbIMUnRH2C0e1eJmFaEcPPMXO8Yu2FlJYo45M8Ljza4XzElIDXkKhUnciIUHyObrtcDQ0nfuuPB6BDcIzY0K/myyN7UEWo4CCz3miGPQbX1A5+hvLgpbTe1z6nCudkk0ruABiH0qWoT9gELwEKfEGR4R8q+QxZ5tMIDdGSDD0cV8yU+KSPK5f2+Vk7rZCekKTqNLTJx+bBktjICufCMvGg9ZoC88fuza7jTW7aylSfUffRhG4l9nZdmd4QwHw== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2017 22:19:19.2808 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR06MB2124 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:19:24 -0000 Thus spake james woodyatt (jhw@google.com) on Tue, Feb 28, 2017 at 12:51:16PM -0800: > On Feb 28, 2017, at 00:13, Fernando Gont wrote: > > > > This document […mandates…] the stateless DHCPv6 functionality in RFC 3315. > > > This proposes a requirement for IPv6 host implementations that I have to oppose. My reasoning follows: > > p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive notifications that previously provided information has become invalid. It’s very important that hosts receive timely notifications when DNS server addresses are not valid anymore, otherwise they must rely on heuristics for detecting the difference between transient and persistent DNS server unavailability. These heuristics come with significant cost to user experience and should therefore be avoided. RDNSS provides this facility, whereas Stateless DHCPv6 does not. A robust implementation might still want to rely on heuristics. Updating a RDNSS server list especially with today's sad state of router configuration management likely means making configuration changes on every subinterface of every router. So, this is realistically not going to happen except for environments that have specifically automated this task. Compare that to an environment that forwards all dhcp to a centralized cluster where a configuration change will be made in one spot. I hope that helps clarify an operational issues with this approach. > p2. On networks where all the routers are sending RA messages with O flag cleared, I’d prefer that hosts weren’t constantly trying to discover undeployed DHCPv6 servers. Agreed. Plus it chews up air time. Dale From nobody Tue Feb 28 14:30: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 865FE1293F3 for ; Tue, 28 Feb 2017 14:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Dev5XIOXSiLS for ; Tue, 28 Feb 2017 14:30:13 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CE31293EE for ; Tue, 28 Feb 2017 14:30:13 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id p5so11345241pga.1 for ; Tue, 28 Feb 2017 14:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GNT5t9Dbm3TqsJhAMj8ZJdLU5kvSjw7GNSjh1ngAijw=; b=WCe5nsgF1s9gPo8j5SmYVfkBQSisgUhNtuCDCKYhiTNC+5RynhraoEY6dsLQtwVBm6 IcECqbAFZzpylNNLsLJODf+GxnYy3oq3txXQoXhetSdAVqsUQVMxyM6tigIkdLkBlebo NUUmuGY3JmQBxbEHIIK4R7S3AEnhdrj7/yaRNrUeBMj7wP8kzePA0WuOtk0xaYzAEdRo Z3mRMnDOxZxiQWP92POTEWU1SODGm4dYyQWTA6VQ6nwW5fGd7gvNXaE8PoTZsSU+QHuB lmRnTP0NrBG6hgMtcVvqQ0LBKeHb5Xu19mk4S2Nck4brc/eS1fp/DDcaoaT7BAsn2f+L 6agQ== 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=GNT5t9Dbm3TqsJhAMj8ZJdLU5kvSjw7GNSjh1ngAijw=; b=Jjj5rIb7PYqUhxRNoP4G/exQh5glHLavfQE3lUb8Yb6p4EBFX6hRljqfSR7beO/OD9 8XAqSDBbw5fjaejDEeNNM03JIVtgNcoHMDBxi7eBpuM9hWwRk5P/aCWEQZEkxvlVZcgQ 4zJCMTaeqj8g1QUSIP2SQiJXjwL0KJJn3Wk6Qgj4TO5IgVtGqklhCwFmoIJsB9OA43OZ FQAw03NmfVCW/pkGkmlwsXUKQd2ezsomgWTg1sLARG+xkKa3WUDPKV51gdPI2f0+VIDz LAhaLFpLfaRynFTs8vctCTM0vws0YaBVjINj2m6GedcyDVwftdkrFYq87fWhId4OVoFt TSfw== X-Gm-Message-State: AMke39l95UipyZIFFEOMAZ0lOeH3oNh/LHXjEEoMGgzso6N+zenvdelZGFXnOnCA7AGJd2EU X-Received: by 10.84.216.29 with SMTP id m29mr6007325pli.158.1488321012514; Tue, 28 Feb 2017 14:30:12 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id i3sm2794134pfk.47.2017.02.28.14.30.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 14:30:11 -0800 (PST) From: james woodyatt Message-Id: <018E18A6-D487-4B87-94C8-848F83E9C145@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BB0EA9C9-0DD3-4D4F-8FD9-30DCEB7036B4" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 28 Feb 2017 14:30:10 -0800 In-Reply-To: <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> To: Fernando Gont References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:30:14 -0000 --Apple-Mail=_BB0EA9C9-0DD3-4D4F-8FD9-30DCEB7036B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hola Fernando, On Feb 28, 2017, at 13:12, Fernando Gont wrote: > On 02/28/2017 05:51 PM, james woodyatt wrote: >> On Feb 28, 2017, at 00:13, Fernando Gont = wrote: >>>=20 >>> This document [=E2=80=A6mandates=E2=80=A6] the stateless DHCPv6 = functionality in RFC 3315. >>=20 >> This proposes a requirement for IPv6 host implementations that I have = to >> oppose. My reasoning follows: >>=20 >> p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to = receive >> notifications that previously provided information has become = invalid. >> It=E2=80=99s very important that hosts receive timely notifications = when DNS >> server addresses are not valid anymore, otherwise they must rely on >> heuristics for detecting the difference between transient and = persistent >> DNS server unavailability. >=20 > If your network has such a requirement, use RDNSS rather than SLAAC. > We're not mandating what you must *use*. [=E2=80=A6] That=E2=80=99s a very puzzling statement. Here=E2=80=99s exactly what = your draft says would be Best Current Practice: >>>> 3. Requirements for IPv6 Hosts >>>>=20 >>>> IPv6 hosts MUST support the SLAAC DNS options specified in = [RFC6106], and the stateless DHCPv6 mechanism specified in [RFC3315]. How is it possible to =E2=80=9Csupport=E2=80=9D RFC 3315 in a device = that will never use it? I really want to know how I=E2=80=99m going to = conform with this Best Current Practice in IPv6-capable host devices = that my employers sell that never under any circumstances send a DHCPv6 = Discover packet. I was imagining that your MUST here amounts to saying that our = IPv6-capable host devices MUST use RFC 3315 to obtain DNS server = addresses whenever RA messages do not provide them in RDNSS options. = That sounds like you=E2=80=99re mandating what we MUST do. How am I misunderstanding? >> p2. On networks where all the routers are sending RA messages with O >> flag cleared, I=E2=80=99d prefer that hosts weren=E2=80=99t = constantly trying to >> discover undeployed DHCPv6 servers. On such networks, IPv6 addresses = for >> DNS servers should only be available by manual configuration. This = may, >> in fact, be a perfectly reasonable configuration for transitional >> dual-stack networks where DNS servers are only available = automatically >> by IPv4 and not IPv6. >=20 > I beg to differ. It seems totally unreasonable to me that folks have = to > resort to manual configuration (?!?) because two vendors are playing a > rather silly game for which the folks deploying IPv6 networks pay the = price. I agree that=E2=80=99s a bad situation, but I disagree that it=E2=80=99s = a =E2=80=9Csilly game=E2=80=9D =E2=80=94 and I disagree that publishing = this draft as Best Current Practice would be helpful. Indeed, I think it = would entangle IETF itself in a very serious (and not at all silly) = marketplace dispute in which IETF should take care=E2=80=94 indeed, I = can see how people might think IETF is explicitly chartered=E2=80=94 to = maintain neutrality. If a vendor of host equipment refuses to implement RFC 6106, they are = telling their customers that their systems are only suitable for use on = the IPv6 networks where DHCPv6 is available. I don=E2=80=99t think = publishing a BCP declaring such hosts non-conforming will change their = minds. Those vendors clearly believe DHCPv6 should be a requirement for = their customers despite IETF maintaining its optionality. Making it = mandatory would be taking sides with these vendors. Likewise, if a vendor of host equipment chooses to implement RFC 6106 = and refuses to implement RFC 3315, they are telling their customers that = their systems are suitable for use everywhere except on networks where = hosts are required to implement DHCPv6 despite IETF maintaining that = DHCPv6 is purely optional. Those vendors think DHCPv6 should remain = optional just as current IETF standards and Best Current Practice = explain. Making it mandatory would be taking sides against these = vendors. Shorter james: IETF should not take sides in this marketplace dispute. --james woodyatt > --Apple-Mail=_BB0EA9C9-0DD3-4D4F-8FD9-30DCEB7036B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hola Fernando,

On Feb 28, 2017, at 13:12, Fernando Gont <fgont@si6networks.com> wrote:
On 02/28/2017 05:51 = PM, james woodyatt wrote:
On Feb 28, 2017, at = 00:13, Fernando Gont <fgont@si6networks.com> wrote:

This document [=E2=80=A6mandates=E2= =80=A6] the stateless DHCPv6 functionality in RFC 3315.

This proposes a requirement for = IPv6 host implementations that I have to
oppose. My = reasoning follows:

p1. Stateless DHCPv6 = [RFC 3315] lacks a mechanism for hosts to receive
notifications that previously provided information has become = invalid.
It=E2=80=99s very important that hosts receive = timely notifications when DNS
server addresses are not = valid anymore, otherwise they must rely on
heuristics for = detecting the difference between transient and persistent
DNS server unavailability.

If your network has such a requirement, use RDNSS rather than = SLAAC.
We're not mandating what you must *use*. = [=E2=80=A6]

That=E2=80=99s a very puzzling statement. Here=E2=80= =99s exactly what your draft says would be Best Current = Practice:

3. =  Requirements for IPv6 Hosts

IPv6 hosts MUST support the SLAAC DNS options specified in = [RFC6106], and the stateless DHCPv6 mechanism specified in = [RFC3315].
=

How is it possible to =E2=80=9Csupport=E2=80= =9D RFC 3315 in a device that will never use it? I really want to know = how I=E2=80=99m going to conform with this Best Current Practice in = IPv6-capable host devices that my employers sell that never under any = circumstances send a DHCPv6 Discover packet.

I was imagining that your MUST here amounts to = saying that our IPv6-capable host devices MUST use RFC 3315 to obtain = DNS server addresses whenever RA messages do not provide them in RDNSS = options. That sounds like you=E2=80=99re mandating what we MUST = do.

How am I = misunderstanding?

p2. On networks where all the routers are sending RA messages = with O
flag cleared, I=E2=80=99d prefer that hosts = weren=E2=80=99t constantly trying to
discover undeployed = DHCPv6 servers. On such networks, IPv6 addresses for
DNS = servers should only be available by manual configuration. This may,
in fact, be a perfectly reasonable configuration for = transitional
dual-stack networks where DNS servers are = only available automatically
by IPv4 and not IPv6.

I beg to differ. It seems totally = unreasonable to me that folks have to
resort to manual = configuration (?!?) because two vendors are playing a
rather= silly game for which the folks deploying IPv6 networks pay the = price.

I agree = that=E2=80=99s a bad situation, but I disagree that it=E2=80=99s a = =E2=80=9Csilly game=E2=80=9D =E2=80=94 and I disagree that publishing = this draft as Best Current Practice would be helpful. Indeed, I think it = would entangle IETF itself in a very serious (and not at all silly) = marketplace dispute in which IETF should take care=E2=80=94 indeed, I = can see how people might think IETF is explicitly chartered=E2=80=94 to = maintain neutrality.

If a vendor of = host equipment refuses to implement RFC 6106, they are telling their = customers that their systems are only suitable for use on the IPv6 = networks where DHCPv6 is available. I don=E2=80=99t think publishing a = BCP declaring such hosts non-conforming will change their minds. Those = vendors clearly believe DHCPv6 should be a requirement for their = customers despite IETF maintaining its optionality. Making it mandatory = would be taking sides with these vendors.

Likewise, if a vendor of host equipment chooses to = implement RFC 6106 and refuses to implement RFC 3315, they are telling = their customers that their systems are suitable for use everywhere = except on networks where hosts are required to implement DHCPv6 despite = IETF maintaining that DHCPv6 is purely optional. Those vendors think = DHCPv6 should remain optional just as current IETF standards and Best = Current Practice explain. Making it mandatory would be taking sides = against these vendors.

Shorter = james: IETF should not take sides in this marketplace dispute.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_BB0EA9C9-0DD3-4D4F-8FD9-30DCEB7036B4-- From nobody Tue Feb 28 14:38: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 F159612973D for ; Tue, 28 Feb 2017 14:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6WlaHMbfImD for ; Tue, 28 Feb 2017 14:38:06 -0800 (PST) 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 935D2129696 for ; Tue, 28 Feb 2017 14:30:27 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id b129so11354402pgc.2 for ; Tue, 28 Feb 2017 14:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SUIRLmYGae2bXZzivm+38r6AEopm1Vn+EPII35R1Oj4=; b=MrdZHmH7JRa+w9TLWrNQvqLgSu1J8ciJpP2ZF0e/f/CTdpAAMdylp0dKs+/dUZYidW nwGOs1tpUJ8KT7K9ZbX4zKDKRTk9gJ5KRG6kUfHwsBXneJa9BpEoHcONMlCU4pOqj1rg pzA1EfRka0uDDRr1Azf+nh7BGMnRTgY+56fYHN7wSrEgBg7fs1SnNtB1iq/GojIaKgec ShpweSsQhw8/ABqkWEC4iFjfxPqW3NiUnko9AYLyjgcyonmPr+gMQ1A55Op9ZrAEe5pw Dg8QSz4RKT4406a2SFkENIDgoklSKoh7IZ8aHs7s8HPMwk8HY9w4WHuEiALRsVQ4hgoM ZbDQ== 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=SUIRLmYGae2bXZzivm+38r6AEopm1Vn+EPII35R1Oj4=; b=o6rsKJJgIpT1lim01rkKftuu1dCWMTMrWk/0Zu/llepkP/QYu7x1uiRT3ROOLJSiee 8rYvHpExlToyWnN/wPP1hqX59/YPlKyf+y1Kj7iSIQbGzdI5LiVMZiJYW1UqMYtrgT34 yCdHOUyuy3HVQgH0Lc1lBwpK56hhl9ekAGw/iF6t1BDuvB7uz8VJ5l1bH6AtXC9yrdV8 mt7IhMG7cQKNNPMCCEnB4OCjNxH2L7QbvbYFpnnwDulQ2M73OAQOGPJiw3CWQWByNRO/ DTFMuyS3FIRip3Ct561QffplwTHZx6XQ0eUbsdIoH7Qmh2auXvBVw1vS9R/JslJogOy5 qXUA== X-Gm-Message-State: AMke39kn1RPwwJePQf6S8RfUq4DrNR/3pvlSEPF5OKunAgjats5Z22hfeMELHBUL7sIEjQ== X-Received: by 10.99.137.66 with SMTP id v63mr4921446pgd.207.1488321026952; Tue, 28 Feb 2017 14:30:26 -0800 (PST) Received: from ?IPv6:2406:e007:794c:1:28cc:dc4c:9703:6781? ([2406:e007:794c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 67sm6088099pfd.120.2017.02.28.14.30.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 14:30:26 -0800 (PST) To: Fernando Gont , james woodyatt , IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 1 Mar 2017 11:30:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:38:07 -0000 On 01/03/2017 10:12, Fernando Gont wrote: ... > If your network has such a requirement, use RDNSS rather than SLAAC. > > We're not mandating what you must *use*. Actually, we want to allow you > to make that choice. Right now, you can't. Because Google's Android > refuses to implement stateless DHCPv6, and MS Windows and a number of > router vendors refuse to implement RDNSS. This is the point. We are supposed to care about interoperbility, and this is a breakage in interoperability specification, which has led to breakage in real-world interoperability. Our bad. There's another closely related breakage, which is the absence of default router signalling in DHCPv6. That means that even if a site must use DHCPv6 for configuring stuff that RAs cannot configure, they must also use RAs for configuring stuff that DHCPv6 cannot configure. Something like bad systems design. Brian From nobody Tue Feb 28 14: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 D9B8D129504 for ; Tue, 28 Feb 2017 14:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSQ8Q_4SR0M2 for ; Tue, 28 Feb 2017 14:46:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5219112940D for ; Tue, 28 Feb 2017 14:46:37 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 BA89E80A00; Tue, 28 Feb 2017 23:46:34 +0100 (CET) To: james woodyatt References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> <018E18A6-D487-4B87-94C8-848F83E9C145@google.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <1fa6d2b1-3d8a-fae9-8037-f928a47c0b01@si6networks.com> Date: Tue, 28 Feb 2017 19:45:18 -0300 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: <018E18A6-D487-4B87-94C8-848F83E9C145@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:46:40 -0000 Hola, James, ;-) On 02/28/2017 07:30 PM, james woodyatt wrote: > Hola Fernando, > > On Feb 28, 2017, at 13:12, Fernando Gont > wrote: >> On 02/28/2017 05:51 PM, james woodyatt wrote: >>> On Feb 28, 2017, at 00:13, Fernando Gont >> > wrote: >>>> >>>> This document […mandates…] the stateless DHCPv6 functionality in RFC >>>> 3315. >>> >>> This proposes a requirement for IPv6 host implementations that I have to >>> oppose. My reasoning follows: >>> >>> p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive >>> notifications that previously provided information has become invalid. >>> It’s very important that hosts receive timely notifications when DNS >>> server addresses are not valid anymore, otherwise they must rely on >>> heuristics for detecting the difference between transient and persistent >>> DNS server unavailability. >> >> If your network has such a requirement, use RDNSS rather than SLAAC. >> We're not mandating what you must *use*. […] > > That’s a very puzzling statement. Here’s exactly what your draft says > would be Best Current Practice: > >>>>> 3. Requirements for IPv6 Hosts >>>>> >>>>> IPv6 hosts MUST support the SLAAC DNS options specified in >>>>> [RFC6106], and the stateless DHCPv6 mechanism specified in [RFC3315]. > > How is it possible to “support†RFC 3315 in a device that will never use > it? If it's a host, whether you use it or not will depend on the network: whether it does only SLAAC, stateful DHCPv6, or stateless DHCPv6. So, in our case, what we want is that, if the network does stateless DHCPv6, you (host) can do it. Similarly, we want that if the network coveys DNS information in RDNSS options, all hosts can learn that info from such options. And that if you have a router impementation with SLAAC support, that it is able to send RDNSS options. We don't say (and don't want to) which of the possible options is the most desirable. It's up to the network to decide what's the best model for them. The goal is that, whatever an admin decides, he knows that all attached systems will be able to learn DNS information. > I really want to know how I’m going to conform with this Best > Current Practice in IPv6-capable host devices that my employers sell > that never under any circumstances send a DHCPv6 Discover packet. Implement stateless DHCPv6. I you receive an RA with the O bit set, query the network for config information. > I was imagining that your MUST here amounts to saying that our > IPv6-capable host devices MUST use RFC 3315 to obtain DNS server > addresses whenever RA messages do not provide them in RDNSS options. What we say is: If the RAs don't provide DNS information, and the O bit is set, query additional config information via DHCPv6. >>> p2. On networks where all the routers are sending RA messages with O >>> flag cleared, I’d prefer that hosts weren’t constantly trying to >>> discover undeployed DHCPv6 servers. On such networks, IPv6 addresses for >>> DNS servers should only be available by manual configuration. This may, >>> in fact, be a perfectly reasonable configuration for transitional >>> dual-stack networks where DNS servers are only available automatically >>> by IPv4 and not IPv6. >> >> I beg to differ. It seems totally unreasonable to me that folks have to >> resort to manual configuration (?!?) because two vendors are playing a >> rather silly game for which the folks deploying IPv6 networks pay the >> price. > > I agree that’s a bad situation, but I disagree that it’s a “silly game†> — and I disagree that publishing this draft as Best Current Practice > would be helpful. Indeed, I think it would entangle IETF itself in a > very serious (and not at all silly) marketplace dispute in which IETF > should take care— indeed, I can see how people might think IETF is > explicitly chartered— to maintain neutrality. If an IPv6 deployment doesn't work 8as in this case), the talk is not about neutrality, but about broken specs. > If a vendor of host equipment refuses to implement RFC 6106, they are > telling their customers that their systems are only suitable for use on > the IPv6 networks where DHCPv6 is available. I don’t think publishing a > BCP declaring such hosts non-conforming will change their minds. Those > vendors clearly believe DHCPv6 should be a requirement for their > customers despite IETF maintaining its optionality. Making it mandatory > would be taking sides with these vendors. RDNSS support is, one way or another, optional, too. It's a SHOULD on the client side, and it's not even a SHOULD on the router side. That's how we got to this sad state of affairs. > Likewise, if a vendor of host equipment chooses to implement RFC 6106 > and refuses to implement RFC 3315, they are telling their customers that > their systems are suitable for use everywhere except on networks where > hosts are required to implement DHCPv6 despite IETF maintaining that > DHCPv6 is purely optional. Those vendors think DHCPv6 should remain > optional just as current IETF standards and Best Current Practice > explain. Making it mandatory would be taking sides against these vendors. We're taking sides with the ops people, because while these two vendors have their fight, we need to rely on IPv4 for configuring DNS info. That's really a shame. 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 Feb 28 15:14: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 861D71297CF for ; Tue, 28 Feb 2017 15:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 jfgcyFhDc4hT for ; Tue, 28 Feb 2017 15:14:35 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id DC19D1297CA for ; Tue, 28 Feb 2017 15:14:35 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Feb 2017 23:14:35 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 5AD22D788B; Tue, 28 Feb 2017 15:14:35 -0800 (PST) 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=OGxRq4jwX3KEYxmBkFVwtosY0Y8=; b= DNr0M8NsleAoARR5K/U+foYw+3v0ZDRW4lwR/1GdivLtJ0tAs3fE8FEb9yU9PAd2 8e0jqUmVUt8ShS6sN+pJX474vM7fjDPKd18Xz+epy77t3GQim7wqtGS/cG9PscQs u/m1PS5/T+5hPT6zM9q2wZFYgmH2T/AGX60QAF3dn4c= 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=EhVmlkxB3BFGD/vcgEC44TK NDESRhn7SzAiJBL8ucm/xpiW7bIB5qZO1zP4U4aUyN7MbHgjvEBmUCOtp+XX/FKK R6zQZNHBm4uFuGFz0pLsqIx8qyOC4WSe7nQK3n8diW92La/ZmUu6Lae4cdwUcSHN d4GWCh00SRkN2bcrFFnk= 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 2F181D788E; Tue, 28 Feb 2017 15:14:35 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6193790C1354; Wed, 1 Mar 2017 00:14:32 +0100 (CET) From: otroan@employees.org Message-Id: <74EF0172-F021-4941-92EE-76D11C3F9401@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_55859C30-B4FA-4F6F-81E2-7AD17ADB1BA6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 1 Mar 2017 00:14:31 +0100 In-Reply-To: To: Brian E Carpenter References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Fernando Gont , IPv6 Operations , james woodyatt Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:14:39 -0000 --Apple-Mail=_55859C30-B4FA-4F6F-81E2-7AD17ADB1BA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > ... >> If your network has such a requirement, use RDNSS rather than SLAAC. >>=20 >> We're not mandating what you must *use*. Actually, we want to allow = you >> to make that choice. Right now, you can't. Because Google's Android >> refuses to implement stateless DHCPv6, and MS Windows and a number of >> router vendors refuse to implement RDNSS. >=20 > This is the point. We are supposed to care about interoperbility, and > this is a breakage in interoperability specification, which has led to > breakage in real-world interoperability. Our bad. No. That's way outside of IETF's role. An example. I've got an open source implementation I'm working on of an = IPv6 router. It does not support RDNSS. Would you think the IETF writing = one more non-protocol specification document telling me that I'm stupid, = change that? > There's another closely related breakage, which is the absence of > default router signalling in DHCPv6. That means that even if a site > must use DHCPv6 for configuring stuff that RAs cannot configure, they > must also use RAs for configuring stuff that DHCPv6 cannot configure. >=20 > Something like bad systems design. It's a failure of the IETF to have specified two ways of doing the same = thing. And now you are proposing that we should do even more of that? Ole --Apple-Mail=_55859C30-B4FA-4F6F-81E2-7AD17ADB1BA6 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 iQIcBAEBCgAGBQJYtgRYAAoJEL7aWKiYQt92IqYP/RJps09KwMY3FwGTqRtgOWSJ ssG//SBDswCQ0OZye5n6o1C9ivEDEhf1vKZInmoZpzQOe9g8fy5B6EVUvuz0YMjc /4TmQQrCuij8Vf7dLy7GM3sQqjLqpXSPoJgkm++EIiQ46p997YrDUdXYi6BBwOxG og3i4hOIrJAq8UZZgVn6r6R4+izi0oSEc549FUt0Aknf+5s5E69Iygy1xk9Zzcov PxDXynJLVsGhjdoGnR/KDYbfjsilKAJB8szWIvwpW1R3bN1x8k0DU038fMgfGdYq mBC9GwIcQhayVvx1dwYZgXZVRLYZ0HnFCCmfmsTBX6nGMpUGaHRz3ElXbwRRs/Aq 5xetjnoMcIzDcvfWlrS934t4RxNcF363MVqtEW+CIYv24vaJawy6OW1d+L//U8jl NurhycfTwNUvWH2ueTy0VP8Ic5jXZKZKlznFx4rk12fbZK2mdk2hftQKqVhaRJ38 2SFJ8YA4uFt/a8u0WRHo7Ilhm2lUg21xa+wPZrc3QQrPeWWPuyJxh3Hl766UIK1H LOjOx+aFmA9qPZG4uugmLmWYfGjt+B/LtERlkyMBeM92mt/oIKQrgIulHf/f/lUq Wn0BTL1rYWOae/0+m5G34OqSUHH/OnfsUIaBqoXiVcXVLf9bBwkr9JDxABLoFmWk lQIOv0wLYc92K+Hn1Mhz =x/eS -----END PGP SIGNATURE----- --Apple-Mail=_55859C30-B4FA-4F6F-81E2-7AD17ADB1BA6-- From nobody Tue Feb 28 15:25: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 3EF6E1297DE for ; Tue, 28 Feb 2017 15:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oNDDr_D3liqL for ; Tue, 28 Feb 2017 15:25:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A4C129435 for ; Tue, 28 Feb 2017 15:25:37 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 34AD480EFB; Wed, 1 Mar 2017 00:25:33 +0100 (CET) To: otroan@employees.org, Brian E Carpenter References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> <74EF0172-F021-4941-92EE-76D11C3F9401@employees.org> From: Fernando Gont Message-ID: <47207f61-504b-8053-b9ef-741a890eb005@si6networks.com> Date: Tue, 28 Feb 2017 20:19:51 -0300 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: <74EF0172-F021-4941-92EE-76D11C3F9401@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: james woodyatt , IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:25:38 -0000 On 02/28/2017 08:14 PM, otroan@employees.org wrote: >> There's another closely related breakage, which is the absence of >> default router signalling in DHCPv6. That means that even if a site >> must use DHCPv6 for configuring stuff that RAs cannot configure, they >> must also use RAs for configuring stuff that DHCPv6 cannot configure. >> >> Something like bad systems design. > > It's a failure of the IETF to have specified two ways of doing the same thing. And now you are proposing that we should do even more of that? If you accept that there was a failure, and there is a problem, then you should probably also accept that we should clean up the mess. 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 Feb 28 16:29: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 11E011297EE for ; Tue, 28 Feb 2017 16:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Eq8CNzO5Nm2 for ; Tue, 28 Feb 2017 16:29:00 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD881129435 for ; Tue, 28 Feb 2017 16:29:00 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 1so3570450pgz.2 for ; Tue, 28 Feb 2017 16:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jyAPXUv0+iM5ReSTcfmNNP4mJHw6X7KDrmt7tEQ+ZIM=; b=rK0cXP+rbu2Irvk7id4Ng6ZIEPYvg0ZX4f8yClEpMznHhLqCkC/x6GsjGx0K8Krw5Z 8MAPKAMbn8wi4HchL2escqJ2xZAckWptj+nhrUUEZoEB1JR9IuuuUs9j4gvB0IRlHwcF j7wleO1u0hHxDGSNh3bRjdVUPnI2Gipy2IeRqThRxc+qBjdD5Ur/pvGOVhFYAoR/2cg8 G6W8oMzBWC/4q+sOd39DbBndnDuyhItbHfc7pw9AYauZl4n7AoGdeEsvnkG/HmDYchn2 JLCDpG45zbO2nuxf2nQ92nFouBgEZO415iEXmGEwwxp94CYfQlCcctbfwnPkBFWd0VgG YJlw== 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=jyAPXUv0+iM5ReSTcfmNNP4mJHw6X7KDrmt7tEQ+ZIM=; b=nLL8ZmnTEd3ImqFXVWS2ySp6YBuHEVjx9dt8ah5c/y7nyT1mPxscI0QprGpEWkxG3u NrRRJxfxiQEG+k3EKPF+Ok6NGmqRY0W8arsUyUPyaAOi6T4vXv/DdbB5vGB9uy27rsPt YcfBToQd/dmLcowhsRW4Yztw7ta06IuHJlFoQE+nritQjrlYUQDqknFIjA+TjQZkSgVL aFTMtrdOhjLyOQSAhr1kU6UAp2SG2MY0EJIVxBM4BL0kIJIxrGHuo9+/twc1Y9Asz2Dz Q9l0SngiPBUV2pZgJei7x9zSMhl50d7k5Drao4XQV7ExgU2F2tH1OEi9HVqZwdIoIhbG jQ1w== X-Gm-Message-State: AMke39mZNTrdR6YmzJcMzH9THQ+rxmAs06QTzmFH6XsuDHFKDP3fuaPhoqkTwvJohXKd9Q== X-Received: by 10.99.171.5 with SMTP id p5mr5530028pgf.182.1488328140194; Tue, 28 Feb 2017 16:29:00 -0800 (PST) Received: from ?IPv6:2406:e007:794c:1:28cc:dc4c:9703:6781? ([2406:e007:794c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a2sm6318682pfc.72.2017.02.28.16.28.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 16:28:59 -0800 (PST) To: otroan@employees.org References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> <3e733fa0-744b-28d8-28d2-dbf3ace3c8b3@si6networks.com> <74EF0172-F021-4941-92EE-76D11C3F9401@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <49a10ca2-6d6c-4d92-fffb-902e20566d9d@gmail.com> Date: Wed, 1 Mar 2017 13:28:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <74EF0172-F021-4941-92EE-76D11C3F9401@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations , james woodyatt Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 00:29:02 -0000 On 01/03/2017 12:14, otroan@employees.org wrote: >> ... >>> If your network has such a requirement, use RDNSS rather than SLAAC. >>> >>> We're not mandating what you must *use*. Actually, we want to allow you >>> to make that choice. Right now, you can't. Because Google's Android >>> refuses to implement stateless DHCPv6, and MS Windows and a number of >>> router vendors refuse to implement RDNSS. >> >> This is the point. We are supposed to care about interoperbility, and >> this is a breakage in interoperability specification, which has led to >> breakage in real-world interoperability. Our bad. > > No. > That's way outside of IETF's role. > > An example. I've got an open source implementation I'm working on of an IPv6 router. It does not support RDNSS. Would you think the IETF writing one more non-protocol specification document telling me that I'm stupid, change that? > >> There's another closely related breakage, which is the absence of >> default router signalling in DHCPv6. That means that even if a site >> must use DHCPv6 for configuring stuff that RAs cannot configure, they >> must also use RAs for configuring stuff that DHCPv6 cannot configure. >> >> Something like bad systems design. > > It's a failure of the IETF to have specified two ways of doing the same thing. And now you are proposing that we should do even more of that? In the sense that two incomplete solutions are worse than two complete solutions, yes. I think the real goal is that a wide-enough set of functions should be covered by both solutions, and to my mind that should include both DNS servers and default routers. Brian From nobody Tue Feb 28 18:00: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 20E9D12946A for ; Tue, 28 Feb 2017 18:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 luYyl5p7B5-U for ; Tue, 28 Feb 2017 18:00:56 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BED129469 for ; Tue, 28 Feb 2017 18:00:56 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id q7so1833079uaf.2 for ; Tue, 28 Feb 2017 18:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8uP9f5cn+2yJScDK0/Q/p5w0Ruxlpf5HjXnCA+Eqw+I=; b=RpE2CZ2P9FJzKehJzMUIhCEU02GizFdt0YQWvkV1/XGMcixV3vpHXoOApMWRyfLiuH G9WQe45CR9ehTz+cGZRvQ8QYEZTuDHUZz36KceEM5g3Js0d6xZ5xuV11oQudaQwjV7oH S7/QliQT7T7UjlfkqvVeCA2UgJfpYt4xkMjx1c+o5b7s/ax1+OKETEmApK0/BpctoHMn RQeRU5CCs1kg7jEUwh7qZ8TGN8tsh22+ZQre7V+fCC78XZMVMhH8NEQP7u4ZCDcGAmha SYbVZQeKNLwgd/erMcos9GeeikxYkMiiZJrluGR9yeROWLzOl+Kz4KWnWw4fA0qEwnD4 loZA== 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=8uP9f5cn+2yJScDK0/Q/p5w0Ruxlpf5HjXnCA+Eqw+I=; b=IolPgnDoxEG8FMfRKLI26Tre4wlqC9w7Gb7dJDnOSTpMjyVma08wS3pRsrLQVNb1lD aIfOOyoHG8LG4pJkGYy356Sxpx+tYrdJe/jCV2IVRVIMWOlVpU2c4V2aH4aDIVaw1C26 3hBeA6Vb/moXhLPpLnwA9gF5vHQ+3lQnygOT1PTGdqlEfM0CU6bFt7+1VFTRF13v5yol SSbYdq0Va2WDcrSdv5KWVxeL1BEbNXxQTsXbUpYHmWeDHDW7VuIe7G3wftf/bX0zvznd 9IhfvOJBK3xTZI+2io0S91wj56Im6wYTE8wOonacrUhYN5x0cbX0Ya+q881a9ZYb8JNi ZCZg== X-Gm-Message-State: AMke39lt3qsIhsu1qc/Vem0W6qVSfQFXsEUx1QAKic/ko2ntNfH1ZERvmWxxjDTaOgBaSilA6DKpIE5u+odjNr07 X-Received: by 10.159.56.193 with SMTP id w1mr2836868uaf.72.1488333655444; Tue, 28 Feb 2017 18:00:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 28 Feb 2017 18:00:34 -0800 (PST) In-Reply-To: <20170228195303.GU2367@Space.Net> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> From: Lorenzo Colitti Date: Wed, 1 Mar 2017 11:00:34 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=f403045f4162d7ca9e0549a1ae1b Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 02:00:58 -0000 --f403045f4162d7ca9e0549a1ae1b Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 4:53 AM, Gert Doering wrote: > So, they cannot reasonably implement what should have been the default > for new deployments years ago, and need to add IPv4 purely because IETF > failed to very clearly mandate what router and host OS vendors need to > provide, so a network can run v6-only today... > Why do you say they "cannot" implement it? There is nothing stopping a network from supporting both stateless DHCPv6 and RDNSS. Many residential gateways do this today, and those often aren't high-margin implementations. Saying "hosts must implement both stateless DHCPv6 and RDNSS so that networks can choose to implement only one" is one way to solve this problem. Saying "networks should support both stateless DHCPv6 and RDNSS so that hosts can choose to implement only one" is another. --f403045f4162d7ca9e0549a1ae1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 4:53 AM, Gert Doering <gert@space.net> wrote= :
So, they cannot reasonably implement wh= at should have been the default
for new deployments years ago, and need to add IPv4 purely because IETF
failed to very clearly mandate what router and host OS vendors need to
provide, so a network can run v6-only today...

Why do you say they "cannot" implement it? There is nothi= ng stopping a network from supporting both stateless DHCPv6 and RDNSS. Many= residential gateways do this today, and those often aren't high-margin= implementations.

Saying "hosts must implemen= t both stateless DHCPv6 and RDNSS so that networks can choose to implement = only one" is one way to solve this problem. Saying "networks shou= ld support both stateless DHCPv6 and RDNSS so that hosts can choose to impl= ement only one" is another.
--f403045f4162d7ca9e0549a1ae1b-- From nobody Tue Feb 28 18:04: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 84474129434 for ; Tue, 28 Feb 2017 18:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7aI4BBDtMPJG for ; Tue, 28 Feb 2017 18:04:06 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FB71293DA for ; Tue, 28 Feb 2017 18:04:06 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 72so32752016uaf.3 for ; Tue, 28 Feb 2017 18:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3wrN9jN1f9xq/kqXr3N6LVjjIl2RQMTKMwoB5ZKbHbg=; b=Gf8DtnYmLbHTi/a3wKvzWRiAGWfgzyUaGXBacrU8/mQICAYYkBrB1mP8exCRllvqut Ho5necBSNiNrFIC4ixQdMdz7RX0SLrVA7UtrwTKamxqCo35qTwwGLuGO3hXfMbGQwQGj iXDGvDJA/iRJDIZddd3B9W6u2KLWHq+PusZVZFOkXP+jZxq3Wr7e0ouoW0nMrJZM+zEI PO28FAHX2D1gPlASh2LO1+xF451h6S+B9biLYvrE9Fm1uRt3rwBWnXocXsL3XdPaI+y7 xr3yPs6tzDXc15MKSCwo6SPwQCF5kmnPZohppymfOlSimjvxHVQ3EDO1NBqisSfGddjQ 1uKQ== 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=3wrN9jN1f9xq/kqXr3N6LVjjIl2RQMTKMwoB5ZKbHbg=; b=C7kkjn5V7WJmSoFUG6E4CV4RpowmWCvuQPBCbyRn4QSk08D5j5EUEsZRmwgtWCi/8E WEt6kpdj2+alNFo+5T0M02EulUbn+FcMcSuzz4SxAPx8f84Ua0jZcVh7U27N16rjyDH4 CAdTKnL6Ahf7Y9zoXmep1dT5Ji/zT+kaW/GqjcmBMofvTc7/Lq+bP+L491qQl6OcJ872 OqW/we3RHsB8hkMI8iZtNQsdPapj9yb7O1ecsW89PReavJlJgRlUbKvJbWwnmN+RK/5G 10KBcd8+mzAsXAqLAhGzmU8445UKrtb6CSsUnyZW8GsLHjlfBFTTKqJ68FGOmd0c4BB0 ThNA== X-Gm-Message-State: AMke39mBUIyh2yLLCq/S7w9wktgF0ki3tK8ci2hWMpsIIRNO4przLrVDuek7jAMlss2baqYCa8osxbcUPOZDn0PC X-Received: by 10.176.82.93 with SMTP id j29mr2907728uaa.57.1488333845273; Tue, 28 Feb 2017 18:04:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 28 Feb 2017 18:03:44 -0800 (PST) In-Reply-To: <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <2646FC7F-A008-4A5F-8D33-4607D306B8AE@google.com> From: Lorenzo Colitti Date: Wed, 1 Mar 2017 11:03:44 +0900 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=94eb2c1916a42850b00549a1baca Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 02:04:07 -0000 --94eb2c1916a42850b00549a1baca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 1, 2017 at 5:51 AM, james woodyatt wrote: > > This proposes a requirement for IPv6 host implementations that I have to > oppose. My reasoning follows: > > p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive > notifications that previously provided information has become invalid. It= =E2=80=99s > very important that hosts receive timely notifications when DNS server > addresses are not valid anymore, otherwise they must rely on heuristics f= or > detecting the difference between transient and persistent DNS server > unavailability. These heuristics come with significant cost to user > experience and should therefore be avoided. RDNSS provides this facility, > whereas Stateless DHCPv6 does not. > +1. It's possible to build non-heuristic solutions to this as well, (e.g., always send all queries to all DNS servers), but those cost in terms of complexity, bandwidth, and battery life. p2. On networks where all the routers are sending RA messages with O flag > cleared, I=E2=80=99d prefer that hosts weren=E2=80=99t constantly trying = to discover > undeployed DHCPv6 servers. > +1. If nothing else, it's expensive for battery-powered hosts to do this. --94eb2c1916a42850b00549a1baca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 5:51 AM, james woodyatt <jhw@google.com> wro= te:
= This proposes a requirement for IPv6 host implementations that I have to op= pose. My reasoning follows:

p1. Stateless DHCPv6 [= RFC 3315] lacks a mechanism for hosts to receive notifications that previou= sly provided information has become invalid. It=E2=80=99s very important th= at hosts receive timely notifications when DNS server addresses are not val= id anymore, otherwise they must rely on heuristics for detecting the differ= ence between transient and persistent DNS server unavailability. These heur= istics come with significant cost to user experience and should therefore b= e avoided. RDNSS provides this facility, whereas Stateless DHCPv6 does not.=

+1. It's possible to build= non-heuristic solutions to this as well, (e.g., always send all queries to= all DNS servers), but those cost in terms of complexity, bandwidth, and ba= ttery life.

p2. On networks where all the routers are se= nding RA messages with O flag cleared, I=E2=80=99d prefer that hosts weren= =E2=80=99t constantly trying to discover undeployed DHCPv6 servers.

+1. If nothing else, it's expensiv= e for battery-powered hosts to do this.
--94eb2c1916a42850b00549a1baca-- From nobody Tue Feb 28 20: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 E597C129467 for ; Tue, 28 Feb 2017 20:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HcEWnuyX7DXT for ; Tue, 28 Feb 2017 20:13:35 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45C7129442 for ; Tue, 28 Feb 2017 20:13:34 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 9D11D801A2; Wed, 1 Mar 2017 05:13:26 +0100 (CET) To: Lorenzo Colitti , Gert Doering References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.com> Date: Wed, 1 Mar 2017 01:07:56 -0300 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 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 04:13:37 -0000 On 02/28/2017 11:00 PM, Lorenzo Colitti wrote: > On Wed, Mar 1, 2017 at 4:53 AM, Gert Doering > wrote: > > So, they cannot reasonably implement what should have been the default > for new deployments years ago, and need to add IPv4 purely because IETF > failed to very clearly mandate what router and host OS vendors need to > provide, so a network can run v6-only today... > > Why do you say they "cannot" implement it? There is nothing stopping a > network from supporting both stateless DHCPv6 and RDNSS. You did check the MS IPv6-only article I posted, right? That's a very usual case: there's no RDNSS support in routers, and/or the clients don't support RDNSS and/or the clients do not support DHCPv6. > Saying "hosts must implement both stateless DHCPv6 and RDNSS so that > networks can choose to implement only one" is one way to solve this > problem. Saying "networks should support both stateless DHCPv6 and RDNSS > so that hosts can choose to implement only one" is another. Huh? You want your client to be able to connect to any network. If you have a client that cannot connect to a network because it fails to implement X, that sucks. Android connecting to an IPv6 network that employs stateless DHCPv6 is one of such cases. Besides, you do want to be able to provide rich config info as in IPv4.. whether that's web proxies, or anything else. 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 Feb 28 20:26: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 1113E129468 for ; Tue, 28 Feb 2017 20:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 jcXotvnB-JqQ for ; Tue, 28 Feb 2017 20:26:43 -0800 (PST) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 A545A129420 for ; Tue, 28 Feb 2017 20:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1488342402; 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=XFX+12J9RU3yk5iOFN9ervovcOqXx4Wxlg8JIVn5G1U=; b=An0nOT2Gca6kHkD0yrCD4Ey0Fmg8B3MvQqFBfkggCWh/fOjTFaRhUOBOoxo+n0Ke LheQzdmYEHtajSa81mj6kE6xCfIDKMG8XtcukFZSaKARVBw/dG90gGvbX4EUM/MX ncZ05An0JixoUluJHvTrsboGGnpZ/zR7TY+ChK4vjMhfXXIiL7ghwylaucbZ+ahR ZFjOqg/yulYVO13X0ltqu6876L5G+xH0x1iP9HtrdN09d3V/wOH4L+NDQjhb5ILd MH9zIWp3qTSIn8u46USkM45R4X8yB1rdGrRFvB16W6PEl1rBVYKvO0QhQU3b/9QY bs6rP1ZpCtfG1ybO4ySozQ==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id DE.25.09934.18D46B85; Tue, 28 Feb 2017 20:26:42 -0800 (PST) X-AuditID: 11ab0215-3c5ff700000026ce-18-58b64d817187 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay2.apple.com (Apple SCV relay) with SMTP id F4.1F.11444.08D46B85; Tue, 28 Feb 2017 20:26:40 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.90.184] (unknown [17.153.90.184]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OM400MOOCCFFU80@nwk-phonehomebzp-sz01.apple.com> for v6ops@ietf.org; Tue, 28 Feb 2017 20:26:40 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Date: Tue, 28 Feb 2017 20:26:39 -0800 References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.com> To: IPv6 Operations In-reply-to: <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.com> Message-id: X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDorNvkuy3C4NgfOYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro+fDP6aC34IV827YNDDO5eti5OSQEDCRmLfoO3sXIxeHkMA+ Roltn74wwSSaWh5AJY4xShxf+JQNJMErICjxY/I9li5GDg5mAXmJg+dlQcLMAloS3x+1skDU b2GSeLb2EdggYQFpia4Ld1lB6tmAig6sMYII10u0rNoNNoZFQFWi/aUFROsnVomPR16BrRIR UJGYcuY+G0gNp4CzxMFrTBAX2EhcXbqHDeJMWYlPz3+CnSkhMINNouHLMqYJjEKzkFw6C+HS WUguXcDIvIpRODcxM0c3M8/IUC+xoCAnVS85P3cTIyhUVzOJ7mCc/8rwEKMAB6MSD+9Ll20R QqyJZcWVuYcYpTlYlMR5U5SAQgLpiSWp2ampBalF8UWlOanFhxiZODilGhiFhBeXn/z2LuCs sGKRtGlGtfstfpuOwkOn5LZU8/p2Gb/N/2v2S/vEJc+jofUBs/bZensWWH7ffWhui6+YT77T z4uT1r+YoaFwP713UedW/jOdeeobnwWcd135/fOMzLVab5nXxSlpsfibP/61ll/v95T4dW51 vxWFHgYUz5wksHBLzIGjgruVWIozEg21mIuKEwFo3wl6NgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUiON3OQbfBd1uEweFLZhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRs+Hf0wFvwUr5t2waWCcy9fFyMkhIWAi0dTygB3CFpO4cG89 WxcjF4eQwDFGieMLn7KBJHgFBCV+TL7H0sXIwcEsIC9x8LwsSJhZQEvi+6NWFoj6LUwSz9Y+ YgJJCAtIS3RduMsKUs8GVHRgjRFEuF6iZdVusDEsAqoS7S8tIFo/sUp8PPIKbJWIgIrElDP3 2UBqOAWcJQ5eY4K4wEbi6tI9bBBnykp8ev6TfQKjwCwkx81COG4WkuMWMDKvYhQoSs1JrDTS SywoyEnVS87P3cQICriGQucdjMeWWR1iFOBgVOLhPdC9NUKINbGsuDL3EKMEB7OSCG+wwbYI Id6UxMqq1KL8+KLSnNTiQ4zJQOdPZJYSTc4HRkNeSbyhiYmBibGxmbGxuYk5acJK4rxWgVsi hATSE0tSs1NTC1KLYLYwcXBKNTCq3P+p86iqntd05Y05Jdyibgd+b/DYMtUz+eFLi6SGGu2p x5Off7WM33c1YKfAp0nvftiVv+n7LPbpPdfxBstTwo059q+CGwyPWE0O37e2ML1htdknLu+H r4W7fk/hvHWpWF592qSE5G/dh1LX/3r64cXUwP1XxS5HVAYV8K2SWmRXYC3idHyzEktxRqKh FnNRcSIA7WqDkHwCAAA= Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 04:26:45 -0000 In my opinion having two ways of doing the same thing is generally a bad idea. The fact that DNS configuration can be conveyed in both DHCPv6 and RA is unfortunate. Declaring both as a MUST implement will only make this situation worse. The IETF should either: 1) declare one option better and deprecate the other 2) stay out of this debate Because of this, I strongly oppose this document. David > On Feb 28, 2017, at 20:07, Fernando Gont wrote: > > On 02/28/2017 11:00 PM, Lorenzo Colitti wrote: >> On Wed, Mar 1, 2017 at 4:53 AM, Gert Doering > > wrote: >> >> So, they cannot reasonably implement what should have been the default >> for new deployments years ago, and need to add IPv4 purely because IETF >> failed to very clearly mandate what router and host OS vendors need to >> provide, so a network can run v6-only today... >> >> Why do you say they "cannot" implement it? There is nothing stopping a >> network from supporting both stateless DHCPv6 and RDNSS. > > You did check the MS IPv6-only article I posted, right? That's a very > usual case: there's no RDNSS support in routers, and/or the clients > don't support RDNSS and/or the clients do not support DHCPv6. > > > >> Saying "hosts must implement both stateless DHCPv6 and RDNSS so that >> networks can choose to implement only one" is one way to solve this >> problem. Saying "networks should support both stateless DHCPv6 and RDNSS >> so that hosts can choose to implement only one" is another. > > Huh? You want your client to be able to connect to any network. If you > have a client that cannot connect to a network because it fails to > implement X, that sucks. Android connecting to an IPv6 network that > employs stateless DHCPv6 is one of such cases. > > Besides, you do want to be able to provide rich config info as in IPv4.. > whether that's web proxies, or anything else. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Feb 28 20: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 5FC3B129432 for ; Tue, 28 Feb 2017 20:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bWuUEityqG9n for ; Tue, 28 Feb 2017 20:44:26 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA9312940F for ; Tue, 28 Feb 2017 20:44:26 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 63DA7803A7; Wed, 1 Mar 2017 05:44:20 +0100 (CET) To: David Schinazi , IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 1 Mar 2017 01:42:57 -0300 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=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 04:44:27 -0000 On 03/01/2017 01:26 AM, David Schinazi wrote: > In my opinion having two ways of doing the same thing is generally a bad idea. > The fact that DNS configuration can be conveyed in both DHCPv6 and RA is unfortunate. > Declaring both as a MUST implement will only make this situation worse. > The IETF should either: > 1) declare one option better and deprecate the other They are simply different. In the same way that SLAAC is different than DHCPv6. > 2) stay out of this debate > Because of this, I strongly oppose this document. Oh, so this is like "Oh, yeah, we screwed up... but we're not going to do anything about it". -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 28 20:54: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 6F54112948D for ; Tue, 28 Feb 2017 20:54:36 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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=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 mdnEVAkZnVQN for ; Tue, 28 Feb 2017 20:54:35 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 5537B129445 for ; Tue, 28 Feb 2017 20:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1488344075; 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=3qd0iIA9TNqmgKv1510kYFJnTPXcHn2J4rzuo84Yr00=; b=I7cpoPZQ9zqXGKJu65YE8UhyvmwCzVq//lriDVhVyu+WO9ZcfkHJC4Yh1lNnTks1 2rCi3ym7yGCk7U5negrCjosIqo3kKTC7VcjOErwAVeWzvE7MjVD2aaYNWevBLKBT qswV9XPBPLUehLQD0+KMmQI1mEZzSr8LbIvMkXeYVXe+iRYJC3KpG8kfN9Gsm+SU cjD+U4fUe/ls3kw7j2+TPAZTdHHcgJSlkL+WFZhavmvcYjBjPxDZIhpSrlGx/0yC NCZ+VljV1T3T5qYklt5IDynOcgUWnTa7SH0HhY9M+TTusM8GW8G0meQ4kcxre44m FpD57DCLHi3CQLxnT9c3NQ==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id DF.C9.24205.A0456B85; Tue, 28 Feb 2017 20:54:34 -0800 (PST) X-AuditID: 11973e11-5d5b79a000005e8d-09-58b6540a6ea8 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay8.apple.com (Apple SCV relay) with SMTP id 0A.73.23141.A0456B85; Tue, 28 Feb 2017 20:54:34 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.90.184] (unknown [17.153.90.184]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OM400MKJDMXFU90@nwk-phonehomebzp-sz01.apple.com> for v6ops@ietf.org; Tue, 28 Feb 2017 20:54:34 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Date: Tue, 28 Feb 2017 20:54:34 -0800 References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.com> To: IPv6 Operations In-reply-to: Message-id: X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCYpssVsi3C4PR3c4vTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/aZqYwFs1grppy7z9TAOI2li5GTQ0LAROLA3ZlMXYxcHEIC +xglrv2/zQiT2LPpOwtE4hijxJ6vi9hBErwCghI/Jt8DSnBwMAvISxw8LwsSZhbQkvj+qBWq fguTxJLJzUwgCWEBaYmuC3dZQerZgIoOrDGCCNdLtKzaDXYEi4CqxJ61y5lBbCGBe2wSa85k g9giAioSU87cZwOxOQWcJTranjOCjOEVsJHY/U8Z4kxZiU/Pf7KDrJUQ+MoqMeXsK/YJjEKz kFw6C+HSWUguXcDIvIpRKDcxM0c3M89IL7GgICdVLzk/dxMjKFSn2wnuYDy+yuoQowAHoxIP b0bn1ggh1sSy4srcQ4zSHCxK4rzzFbZFCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamA0M76d KXbioLHzkzylQBfvVu8n7/9ma3bfOGT17vRx6QTG18F3En/z3/n0qnjD4jt6S1nLo5hjGXaY zxItTrln5rBY5oNw3eIlMp0ad3+1SO2KWsvxktMoYseG32Eqrz7Y7q/j3sq7gyesMSNrZbJ+ 5NSSWZ0L5hw6fP3wzsy+LqODpdp77EyVWIozEg21mIuKEwG5jLUVNgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUiON3OQZcrZFuEwd+dqhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuwzUxkLZrFWTDl3n6mBcRpLFyMnh4SAicSeTd+hbDGJC/fW s3UxcnEICRxjlNjzdRE7SIJXQFDix+R7QEUcHMwC8hIHz8uChJkFtCS+P2plgajfwiSxZHIz E0hCWEBaouvCXVaQejagogNrjCDC9RItq3aD7WIRUJXYs3Y5M4gtJHCPTWLNmWwQW0RARWLK mftsIDangLNER9tzRpAxvAI2Erv/KUOcKSvx6flP9gmMArOQHDcL4bhZSI5bwMi8ilGgKDUn sdJCL7GgICdVLzk/dxMjKOQaCtN2MDYttzrEKMDBqMTDm9G5NUKINbGsuDL3EKMEB7OSCG+w wbYIId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rzWgVsihATSE0tSs1NTC1KLYLJMHJxSDYzXxHva 5W7si83+8LJudezXvUxcp+d/ZTvZ27E0dE6P/rTtRp9uMXzlS56cJ/bRwWPp9KbLofVA+1Qi Lz49cKc41F3D51v41jM3pk49sOB7YPj3O9wXOo0z5KZXLjVPvVuVnbU3ofSaOvt0973LV13J +PXpd9+XK4/X77ykKbBnU/idxt0MM04osRRnJBpqMRcVJwIAca9bGzUCAAA= Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 04:54:36 -0000 > On Feb 28, 2017, at 20:42, Fernando Gont wrote: > > Oh, so this is like "Oh, yeah, we screwed up... but we're not going to > do anything about it". More like "Oh, yeah, we screwed up... but we shouldn't make it worse" Not to mention the fact that making something a MUST implement will not make vendors implement it if they disagree. You'd be better off convincing said vendors, and starting by explaining the benefits of one approach over the other would be more useful than mandating both. I couldn't find anything in the document explaining how one option configures my DNS server address better than the other. David From nobody Tue Feb 28 21:10: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 26B14120726 for ; Tue, 28 Feb 2017 21:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 enDYeZ1LA8sL for ; Tue, 28 Feb 2017 21:10:26 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A13129420 for ; Tue, 28 Feb 2017 21:10:25 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 5511C807BF; Wed, 1 Mar 2017 06:10:21 +0100 (CET) To: David Schinazi , IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <8c53ae4d-50cb-89d3-90e3-4fcbaa376058@si6networks.com> Date: Wed, 1 Mar 2017 02:09:58 -0300 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=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 05:10:27 -0000 On 03/01/2017 01:54 AM, David Schinazi wrote: > >> On Feb 28, 2017, at 20:42, Fernando Gont wrote: >> >> Oh, so this is like "Oh, yeah, we screwed up... but we're not going to >> do anything about it". > > More like "Oh, yeah, we screwed up... but we shouldn't make it worse" COuld you please explain how this document would make that worse? > Not to mention the fact that making something a MUST implement > will not make vendors implement it if they disagree. You'd be better > off convincing said vendors, and starting by explaining the benefits > of one approach over the other would be more useful than mandating > both. I couldn't find anything in the document explaining how one > option configures my DNS server address better than the other. This document is not about picking a winner in this religious battle. Operators should evaluate what works better for them. What we want is for them to be able to make that choice, because nowadays, they simple can't. 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 Feb 28 21:29: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 D747D129442 for ; Tue, 28 Feb 2017 21:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 yc9jOOY5_vx8 for ; Tue, 28 Feb 2017 21:29:16 -0800 (PST) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 B7E2F120726 for ; Tue, 28 Feb 2017 21:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1488346155; 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=QnoqoZ9+iJ0wqSm9foPCRViz9UEAgMLTN9LMFmPurFo=; b=myt5d4IJKBKaHGhSGg3tQ1cSCPeME7Wj1+ZdJ6lBMzA+jgxKmN0py0ypwLV7N1VB Ee0QsMbIhAi+f54MI+3ijfgGCP6ZkcVMRTqeZC0m7bB3aqQOgC7bN7y91zOTIbR2 Ho+T56rv4VgymUzB9vDqqTwhj2X+R3WooXkJXcMcseGlrrdR5TfFleF1bBPbecEj LysOaBjJm372Q2l1toaEIB5/QQqAf7FPksuCkp9WQhX7255dmz0f7sc+050JihEU i7cTdLrhP/Z/Anh6g5EybTWSq6W/fjWStPMXzo4FEjaHqIji5C+YBMVh5KwDohLX M/ri9Di7FiVfJwaYi6T1VA==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 9C.A7.09934.52C56B85; Tue, 28 Feb 2017 21:29:11 -0800 (PST) X-AuditID: 11ab0215-3c5ff700000026ce-75-58b65c24d0c3 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay7.apple.com (Apple SCV relay) with SMTP id EB.C2.06316.42C56B85; Tue, 28 Feb 2017 21:29:08 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.90.184] (unknown [17.153.90.184]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OM400NP4F8J2U00@koseret.apple.com> for v6ops@ietf.org; Tue, 28 Feb 2017 21:29:08 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Date: Tue, 28 Feb 2017 21:29:08 -0800 References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.com> <8c53ae4d-50cb-89d3-90e3-4fcbaa376058@si6networks.com> To: IPv6 Operations In-reply-to: <8c53ae4d-50cb-89d3-90e3-4fcbaa376058@si6networks.com> Message-id: X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCYqqsdsy3CYOpTE4vTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49ad+8wFK9gqjh3Zy9bA2MbaxcjJISFgIjHlzRLGLkYuDiGB /YwSZ5+/ZYNJzJ1/mBUisYpR4mJrE1gHr4CgxI/J91i6GDk4mAXkJQ6elwUJMwtoSXx/1MoC UT+DSeLrrzawQcIC0hJdF+6ygtSzARUdWGMEEa6XaFm1mwXEZhFQlZj+fCvUEafYJT6evAfW KyKgIjHlzH02kF5OAWeJ61tsIU6wkdjb3QF1p6zEp+c/2UF6JQTeskpMOXWMdQKj0Cwkp85C OHUWklMXMDKvYhTOTczM0c3MMzLUSywoyEnVS87P3cQICtfVTKI7GOe/MjzEKMDBqMTDuzJ8 W4QQa2JZcWXuIUZpDhYlcd4UJaCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRnPlHXw32hax Ltqypmi+SOl5tUyJCM9Ni7itfrdNuzbjV+GcH4vvlR1fczznT/757HglI+68jVoTtxtcq0rr a1S9z3I37MDf2PKXB74slXNpK9usqv2TZ1amosLCPaec/kS5nX6iNNvCyslu480n/ett9k5l KeLNuc3MzGXurffj69SsiOSvr5VYijMSDbWYi4oTAStNQ4E4AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUiON1OXVclZluEQeNcMYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49ad+8wFK9gqjh3Zy9bA2MbaxcjJISFgIjF3/mEoW0ziwr31 bF2MXBxCAqsYJS62NoEleAUEJX5MvsfSxcjBwSwgL3HwvCxImFlAS+L7o1YWiPoZTBJff7Wx gSSEBaQlui7cZQWpZwMqOrDGCCJcL9GyajcLiM0ioCox/flWRojeU+wSH0/eA+sVEVCRmHLm PhtIL6eAs8T1LbYQJ9hI7O3uYIO4U1bi0/Of7BMYBWYhuW4WwnWzkFy3gJF5FaNAUWpOYqW5 XmJBQU6qXnJ+7iZGUNA1FKbuYGxcbnWIUYCDUYmH90D31ggh1sSy4srcQ4wSHMxKIrzBBtsi hHhTEiurUovy44tKc1KLDzFKc7AoifNaB26JEBJITyxJzU5NLUgtgskycXBKNTD2a3Nf02P+ mnurauvbhI0Wbs681rnlXkoyKX+PcR5rLng+p2P9axlf1abvPb1bmEV/y+sElQgWiagwHRRM /cP4IkBHy2qdp9rhpumLhV3lZgo4eHVt37KiSn0+W2bNl61ip08emBUok/2r0ieNf8cs83nL s30XB3ZYv7/ofELm/vsDjW3Rk5VYijMSDbWYi4oTAR9gf082AgAA Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 05:29:18 -0000 > On Feb 28, 2017, at 21:09, Fernando Gont wrote: > > COuld you please explain how this document would make that worse? By perpetuating coexistence of multiple solutions to the same problem. > This document is not about picking a winner in this religious battle. > Operators should evaluate what works better for them. > > What we want is for them to be able to make that choice, because > nowadays, they simple can't. It sounds like your document is designed to allow operators to pick what works best for them, by forcing mobile device manufacturers to implement both. Why don't device manufacturers get to pick which one is best for their users? Sounds like you're fighting another religious battle, and I don't think the IETF should pick a side. David From nobody Tue Feb 28 22:33: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 53B93128B44 for ; Tue, 28 Feb 2017 22:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 F4POWrZ9AHnu for ; Tue, 28 Feb 2017 22:33:24 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4EA120725 for ; Tue, 28 Feb 2017 22:33:23 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B4123A4; Wed, 1 Mar 2017 07:33:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1488350000; bh=Jn2xG8KtjaXJiDT5wq34Mnosgf5tTi4IJnSS7snrQdM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=tn3DdIDBFnsPFCHDpQZ/TG/V5GIffU4orE5AgyqzQQ0XoMj9ZVnOwTF0rRqgB3xC9 jFAhvgVMLM1/rFoIL+Ppy5SI8VvY1SPM0mJqjx0NzhXEZ8l3RpEJVMbzMOG2xMjHEA 2kQDufubTFm/mTkUmBqnAfTBk3CJlupscaTKwz+Q= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AED94A3; Wed, 1 Mar 2017 07:33:20 +0100 (CET) Date: Wed, 1 Mar 2017 07:33:20 +0100 (CET) From: Mikael Abrahamsson To: David Schinazi In-Reply-To: Message-ID: References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.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: Cc: IPv6 Operations Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 06:33:26 -0000 On Tue, 28 Feb 2017, David Schinazi wrote: > In my opinion having two ways of doing the same thing is generally a bad idea. > The fact that DNS configuration can be conveyed in both DHCPv6 and RA is unfortunate. https://tools.ietf.org/html/rfc7710 "Captive-Portal Identification Using DHCP or Router Advertisements (RAs)" I'd say generally here in the IETF, we commonly have more than 2 ways of doing the same thing, just look at routing protocols, tunneling protocols etc. Yes, having just one way is to be preferred, but it seems we rarely reach consensus on what this one thing is. Personally I think ND and DHCPv6 has different properties which gives them separate SWOT analysis bullet points, and it seems different organisations value this differently. Some like DHCP because it means the part of the organisation that touches routers won't have to get involved when something that has to do with host configuration needs to be changed, because this is now changed by the DHCP backend people. Others sees this as a problem, because they're working the other way around. What I like about having RA signal what's available on the link, is that we don't have DHCP clients asking questions without guidance, which is a good thing. See Sunset4. So people asking to get more functionality into DHCPv6, do they also see themselves running networks without RAs, thus requiring clients to forever ask DHCPv6 questions even if they get no answers? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Feb 28 23:01: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 2E52712941D for ; Tue, 28 Feb 2017 23:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SEcADml6bj7S for ; Tue, 28 Feb 2017 23:01:22 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35427129413 for ; Tue, 28 Feb 2017 23:01:22 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (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 9436A80155; Wed, 1 Mar 2017 08:01:19 +0100 (CET) To: David Schinazi , IPv6 Operations References: <148826826343.13815.15231542802790001626.idtracker@ietfa.amsl.com> <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> <7538ee3e-d9c8-bcf1-3908-41c0007bbc99@si6networks.com> <4cba7c1a-4006-84d2-9fb3-8f4b65382c90@si6networks.com> <20170228195303.GU2367@Space.Net> <17e7c5ca-7f23-585f-e2c7-5cf97b66adcb@si6networks.com> <8c53ae4d-50cb-89d3-90e3-4fcbaa376058@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <163ebf4b-f3bc-b52c-91c7-6c90ce14d93a@si6networks.com> Date: Wed, 1 Mar 2017 02:56:33 -0300 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=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 07:01:24 -0000 On 03/01/2017 02:29 AM, David Schinazi wrote: > >> On Feb 28, 2017, at 21:09, Fernando Gont wrote: >> >> COuld you please explain how this document would make that worse? > > By perpetuating coexistence of multiple solutions to the same problem. > >> This document is not about picking a winner in this religious battle. >> Operators should evaluate what works better for them. >> >> What we want is for them to be able to make that choice, because >> nowadays, they simple can't. > > It sounds like your document is designed to allow operators to pick > what works best for them, by forcing mobile device manufacturers > to implement both. Why don't device manufacturers get to pick > which one is best for their users? Because you don't operate networks. And because nobody appointed vendors to pick for users which networks they are supposed to be able to connect to. If anything, implement it, and provide a toggle so that your users can enable/disable features as they please. If your choice means that there are networks that I cannot connect to, then for me it represents a very lousy choice on your side. > Sounds like you're fighting another religious battle, and I don't > think the IETF should pick a side. I am not. I couldn't care less about what is eventually employed to get a DNS server address, as long as I get one. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492