From nobody Fri Nov 1 01:16:03 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1656F120121 for ; Fri, 1 Nov 2019 01:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJGS13s0VtWd for ; Fri, 1 Nov 2019 01:15:59 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1DD12010E for ; Fri, 1 Nov 2019 01:15:59 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 D4EE88690D; Fri, 1 Nov 2019 09:15:56 +0100 (CET) To: Ole Troan , Ted Lemon Cc: IPv6 Operations References: <0F0B6068-CA62-449B-B56E-78E9EF8D998E@fugue.com> <96344740-2F4B-4BCE-A881-EB1A5933AFA2@fugue.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <56466564-ce80-a5db-de3f-cc5da47e5cb5@si6networks.com> Date: Fri, 1 Nov 2019 01:21:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 08:16:01 -0000 On 30/10/19 11:07, Ole Troan wrote: > Ted, > >>> We check both, the handling of the IA_PD and the error message. >> >> And to be clear, you mean that if the CPE asks for a prefix delegation and doesn’t get the prefix it previously had, it deprecates it as described in L-14? When this deprecation happens, what ways are being tested for it to happen? >> >> E.g., is it the case that the client sends an IA PD containing an IA Prefix option, is the server returning the IA Prefix option containing the same prefix, with a status code encapsulated in it? What status code? Or is it returning an IA Prefix option with a different prefix? Or is it doing both? > > You are thinking about this wrong. > The simple implementation of uRPF/BCP38 is: on LAN ingress to do a lookup in the FIB of the SA, if the resulting adjacency/interface matches the ingress interface allow packet otherwise drop packet and send ICMP message. This behaviour is required regardless of renumbering or not. > The ISP is required to do this on their ingress interfaces too. You mean required as in "MUST"? If so, where? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 1 01:16:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8D7120824 for ; Fri, 1 Nov 2019 01:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iht5GCJVBFEa for ; Fri, 1 Nov 2019 01:16:05 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DF0120147 for ; Fri, 1 Nov 2019 01:16:05 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 441EF86957; Fri, 1 Nov 2019 09:16:01 +0100 (CET) To: Mark Smith , Ole Troan Cc: v6ops list References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> Date: Fri, 1 Nov 2019 01:53:05 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 08:16:10 -0000 On 30/10/19 20:38, Mark Smith wrote: > On Wed, 30 Oct 2019 at 22:02, Ole Troan wrote: >> > > >> In the case when a requesting router loses a prefix, it can of course signal that to the hosts as proposed in Fernando's draft. But that doesn't solve the general problem, and I'm skeptical to using addressing as a reachability signal. E.g. if the CPE's upstream link flaps, is that enough to trigger deprecation of the prefix? Of course it shouldn't. >> > > Exactly. Transient network faults are supposed to be survived - that's > why TCP makes quite a number of attempts at re-transmitting when > packet loss occurs, rather than just immediately terminating the > connection. > > When an ISP "flash renumbers" a customer what's really happening is > that the customer's network layer point of attachment to the network > is being changed - the customer is being abruptly disconnected, moved > and re-connected. Possibly that is easy to overlook because the > customers physical location and their physical link to the network > doesn't change. > > I think Ole observed that this is contrary to what the PD prefix's > Valid Lifetime said would be the case. The ISP supplied a PD Prefix > with a Valid Lifetime of X seconds, and then broke that promise by > abruptly changing addressing before X seconds. ISPs should be expected > to live up to their Valid Lifetime promises. "Hope" doesn't make networks run properly. In any case, as previously noted, there are multiple scenarios that may lead to this problem. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 1 01:16:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57199120818 for ; Fri, 1 Nov 2019 01:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 dZk9DkkuK_i5 for ; Fri, 1 Nov 2019 01:16:10 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93D1120860 for ; Fri, 1 Nov 2019 01:16:09 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 8168B8690D; Fri, 1 Nov 2019 09:16:06 +0100 (CET) To: Mark Smith Cc: Ted Lemon , v6ops list References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: Date: Fri, 1 Nov 2019 04:29:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 08:16:19 -0000 On 1/11/19 03:49, Mark Smith wrote: > > > On Fri, 1 Nov 2019, 14:31 Fernando Gont, > wrote: > > On 31/10/19 21:20, Mark Smith wrote: > > > > > > On Fri, 1 Nov 2019, 06:34 Ted Lemon, > > >> wrote: > > > >     On Oct 31, 2019, at 3:21 PM, Fernando Gont > > >     >> > wrote: > >>     On 27/10/19 09:02, Ted Lemon wrote: > >>>     Indeed, this would also not actually solve the problem.   At > present, > >>>     the ISPs are doing something that is out of spec and causes > problems. > >>>     If we “fix” this by accommodating what they do, does that > help, or > >>>     does it just encourage them to continue doing it? > >> > >>     Did happy eyeballs encourage broken IPv6 connectivity, or did it > >>     actually help IPv6 deployment? > > > >     Don’t get me wrong—I’m not saying we shouldn’t do things to > improve > >     the situation.   I am saying that we should be strategic about it. > > > >>>     What should be happening on the host with a prefix that’s > deprecated > >>>     is that TCP connections should be timing out.   This doesn’t > take > >>>     very long.   > >> > >>     ~9 minutes, IIRC. > > > >     Should be 90 seconds. > > > > > > You've got no more than 10 seconds unless you want end users to > actively > > try to do something to recover, which can include calling their ISP's > > helpdesk. > > I'd argue the opposite.. > > > > I wouldn't argue with research from 1968, referenced in an article from > 1993, by an expert in usability, cited in my slides. > > > Response Times: The 3 Important Limits > > https://www.nngroup.com/articles/response-times-3-important-limits/ What I meant is that I wouldn't expect you to deal with this at the transport layer, but at the app layer. Setting timers to small values at the transport layer is asking for all sort of failures. -- and not only that: you could have situations in which the transport-layer timers don't go off (say, you do get some data at the transport layer), but you don't get the app protocol-data-units that you can act upon. [....] > > It not being in control of the user is the point of knowing UX/HCI > factors so the good default response times can be chosen. > > TCP's default timeouts are way too large for a good end user experience. > I don't know what criteria were used to select them, but it certainly > wasn't human usability factors. TCP is not optimized for anything (although IIRC there are now "flavours" of TCP popping up). TCP simply aims at reliability, so that, unless there's an unrecoverable error, TCP does it best to make the data delivered to the remote TCP. The long user timeout means that transient network errors can be recovered. Similarly, TCP has an exponential back-off -- something that will likely not relate into nice response times. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 1 01:23:07 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E4912020A for ; Fri, 1 Nov 2019 01:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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=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 MAg_hrr7YrEM for ; Fri, 1 Nov 2019 01:23:03 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AA712012C for ; Fri, 1 Nov 2019 01:23:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7B90049; Fri, 1 Nov 2019 09:23:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1572596577; bh=KgNExSWwycSIu6jY4zq93HHw4JQwBczj2HZ9rg4shrU=; b=A m7zCOqplHjrnJd9TuW5Ud6lTBkx3Y47CnMYBTCH8p1lGje5dxbyARO62XsbNlhrL wECnCNQlu/EXJOZ70Ad6fJ8Hr3w1Pk9j5FMuu4hiMjWkw7F8wDrz30G5xufC8i8p 2CPRv2Dt63loPOjcysSz17IWGEu4MOcTfv9UVqZR+U= 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 xOKa3nYTAH5K; Fri, 1 Nov 2019 09:22:57 +0100 (CET) Received: from [IPv6:2c0f:fe40:3:3:58c8:a6f6:39:5294] (unknown [IPv6:2c0f:fe40:3:3:58c8:a6f6:39:5294]) (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 51A9D3C; Fri, 1 Nov 2019 09:22:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> Date: Fri, 1 Nov 2019 11:22:52 +0300 Cc: Mark Smith , Ole Troan , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 08:23:05 -0000 Hi, >> I think Ole observed that this is contrary to what the PD prefix's >> Valid Lifetime said would be the case. The ISP supplied a PD Prefix >> with a Valid Lifetime of X seconds, and then broke that promise by >> abruptly changing addressing before X seconds. ISPs should be = expected >> to live up to their Valid Lifetime promises. >=20 > "Hope" doesn't make networks run properly. This isn't "Hope", this is breaking promises, and that does break = networks. If you can't at least trust that promises are intended to be = kept then you have no network at all... > In any case, as previously noted, there are multiple scenarios that = may > lead to this problem. Sure, bad things can happen, and there are cases where despite the best = intentions you can't keep your promise. But that doesn't mean everybody = should go around making promises without even thinking about keeping = them=E2=80=A6 Cheers, Sander From nobody Fri Nov 1 01:51:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C381200C3 for ; Fri, 1 Nov 2019 01:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 8Yr1ZXBhEYcz for ; Fri, 1 Nov 2019 01:50:59 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B87120121 for ; Fri, 1 Nov 2019 01:50:59 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id y10so5273678qto.3 for ; Fri, 01 Nov 2019 01:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=f/GT7qxLNIYINgpvwopmx/FGOo+Kndpnr3g9CMUVGcg=; b=vL72j+T1Ke2Qnyn5WUK7rTdSy8ZfcoHM8o2MUjVijTM1QdBohCqxGY/+iPO4tKLexB vExGrr5UPOthznbVa0n+s212vU0BYFBOSAYinBt3KniT4pl3Gu4441Qb0oiShsfVArEG ur/0+CNfmyJvV1fMaoc7mgePweXxqF0gRu4qoOWuz5Wb5LAG05QbiCH5S/Kw+NIVYGIf fzc7eOBESaS6Z7DRZz/VslXLwNiKCADR2z03e6Dc5Bj6EIBaSSti13MXhNDuwT9B2YBP DPCtmwwguFUxhRXRWEkoyE3+Ft0PHgKgrhuJ8AV8hCONZHQE0U8B/2VOArdz3GRdq2/1 quEA== 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=f/GT7qxLNIYINgpvwopmx/FGOo+Kndpnr3g9CMUVGcg=; b=MWksNlVFv0KsLNJ5PLj0A/4aMWmAKGfcPSJC4lddEXbr1LVIz+Z2KmGiHLYNwYozU9 x+SC5sE9ZnJL5wKWbmNxQ+ptHeMvflPNwduBeIVpJEIvPNbFPjO67MEX03H5I3A1SA0T AzYz0Xq4n1En+Z6yH/9zeacaKCG4YYmmUlBmwl8kR9g+WH+giI7SpIsdGPYIHM3743gA WnIEbXq4s0G3WpuU/P17ryOZvFHe0PuhkxpIUJZrysCFYsa6IKTgK+Ac+dftIIj/iMah tkR+hjL7pFatWIS+XspcjbRYS2T3CGyqSgmcMqL+uiOLv3ApXz0vWYNVX4hoUYdFat7S 0RmQ== X-Gm-Message-State: APjAAAXbWwhOy/ADmXoSMq3OwEckus1oP3oAVogPPtimyQN4dqxfGkjo xDPi6K57QscCxCZ+BghU4O9j23XnA9gvhg== X-Google-Smtp-Source: APXvYqzwouNWiQju6gN0GaN1cJTj4Ar+p90yfUL08ymeaczi+10ev2PUOVmlDf3nz/5BmEJk+gJHvw== X-Received: by 2002:a05:6214:1323:: with SMTP id c3mr8826407qvv.243.1572598257917; Fri, 01 Nov 2019 01:50:57 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:bdc1:1d6d:228a:c9c1? ([2601:18b:300:36ee:bdc1:1d6d:228a:c9c1]) by smtp.gmail.com with ESMTPSA id f39sm3361940qtb.26.2019.11.01.01.50.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 01:50:57 -0700 (PDT) From: Ted Lemon Message-Id: <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_28FC60B6-5768-4DF3-9C6B-0F23DED14CA3" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Fri, 1 Nov 2019 04:50:55 -0400 In-Reply-To: <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com> Cc: v6ops list To: Fernando Gont References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 08:51:03 -0000 --Apple-Mail=_28FC60B6-5768-4DF3-9C6B-0F23DED14CA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 31, 2019, at 10:27 PM, Fernando Gont = wrote: >>>=20 >>> Did happy eyeballs encourage broken IPv6 connectivity, or did it >>> actually help IPv6 deployment? >>=20 >> Don=E2=80=99t get me wrong=E2=80=94I=E2=80=99m not saying we = shouldn=E2=80=99t do things to improve the >> situation. I am saying that we should be strategic about it. >=20 > For the home network case, the situation right now is that there are > deployments that break, and ISPs meaning to deploy IPv6 that can't do > stable prefixes. Certainly, that's a very bad strategy on our side. >=20 > That said, and as noted, the home network case is just *one* scenario > where this problem may be faced. And a subset of the mitigations for > this scenarios are useful for the general case. You mention later that if it takes more than ten seconds for the = connection to resume, the user will be on the phone to the ISP. It = sounds, then, like they already have an incentive to configure their = networks so that this doesn=E2=80=99t happen. So why aren=E2=80=99t = they doing that? What=E2=80=99s the obstacle? >>>> What should be happening on the host with a prefix that=E2=80=99s = deprecated >>>> is that TCP connections should be timing out. This doesn=E2=80=99t = take >>>> very long. =20 >>>=20 >>> ~9 minutes, IIRC. >>=20 >> Should be 90 seconds. >=20 > Nope. The default user timeout is 5 minutes as per RFC793. (The first > para of the second page of RFC5482 provides a summary wrt the > specification of the user timeout). Hm, okay. >>> That's not correct. Neither the Valid Lifetime nor the Preferred >>> Lifetime affect address selection. >>=20 >> Okay, there=E2=80=99s something to fix. Why would these not affect = source >> address selection? >=20 > For many reasons: one of them: two different routers might be using > different values for these timers, in an un-coordinated manner. And > there's not reason for which the smaller or larger lifetimes should > imply an address is preferred. >=20 > OTOH, you might thing about preferring "the last advertised prefix". = BUt > that would mean that src address would flap, which is bad for > trouble-shooting. On what actual network would this scenario occur, though, in a way that = would actually cause the problem you anticipate? I know you can set = this up in the lab. But in practice, I never have two competing = routers advertising different and incompatible lifetimes for the same = prefix on my home network. So if you want to break things in other ways = in order to be able to adapt to this situation, it should be likely. = When and where is it likely? As for previous comments about source address selection, I think that if = you have two prefixes that are otherwise equivalent (a tie), and one has = a preferred lifetime of zero, while the other has a preferred lifetime = of not-zero, it would be dysfunctional to choose the one with the = preferred lifetime of zero. What on earth is the purpose of preferred = and valid lifetimes if SAS isn=E2=80=99t taking them into account? >> What is =E2=80=9CFHS=E2=80=9D? >=20 > Sorry, for that: First Hop Security, Cisco's speak for RA-Guard, ND > inspeaction, and so on=E2=80=A6 Ah. Maybe we should call that NKB (network knows best). >>>> If you Really Really want to be able to have the routers send out = RAs >>>> that deprecate the default route, and, as Mark is saying here, to >>>> upgrade millions or perhaps billions of hosts, why not ask for >>>> something that=E2=80=99s a real improvement? >>>=20 >>> Every piece helps. >>=20 >> Right, but if the effort involved in two different options differs by >> epsilon, you should always choose the option that produces the better >> outcome, shouldn=E2=80=99t you? >=20 > Is there any of the proposed fixes that we shouldn't be doing, = already, > anyway? o CPE routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot events. We should definitely be doing this, but it might be worth pointing out = that a very simple fix for this problem would be to have the server = acknowledge the release but ignore it. The server is allowed to give = out the same prefix again even when it=E2=80=99s received a release, so = the release is not a =E2=80=9Cchange my prefix=E2=80=9D signal, and = perhaps we should explicitly advise that it not be treated that way. = This would be an easy tweak in a DHCP server, much easier than updating = a billion CPEs. o A CPE router sending RAs that advertise dynamically-learned prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on stable storage, the list of prefixes being advertised on each network segment. Okay. However, if an ISP makes the change I suggest above, this is no = longer necessary, although I think it=E2=80=99s still good advice. Your other proposed changes seem fine to me; my main focus here is = really on whether there are other things we could be doing that would = improve things even more. >>> What's the practical difference between that, an a network that = supports >>> RA-Guard? >>=20 >> On a network that supports RA guard, there probably is no difference, >> but RA guard on some networks, as we=E2=80=99ve discussed in the = past, will >> actually make the network not work. RA guard requires an active >> administrator. So the CPE case we=E2=80=99re talking about isn=E2=80=99= t relevant. >=20 > The point is: in a network where you do not employ RA-Guard, you are > already trusting the router. Actually, it's worse: you trust all local > systems. That=E2=80=99s why I=E2=80=99m suggesting that there might be a way to = allow us to trust less and verify more, rather than having an entity on = the wire that has no basis for knowing which devices are trustworthy and = which are not, making that decision for us (NKB). >>>> When another RA arrives, see if it was signed with the same key. = If >>>> so, it came from the same router, and can be trusted to update >>>> whatever information that router sent, including flash-deprecating = a >>>> prefix. If not, ignore it. >>>=20 >>> In the non-SEND trust model, you do trust the local router. Why did = you >>> trust the local router to configure your network, but not for >>> deprecating the prefix? >>=20 >> In the non-SEND trust model, you trust the local network. You >> /hope/ that the RA you get =E2=80=9Cfrom the router=E2=80=9D is = actually from the router. >=20 > Exactly: that's the point: you already trust the local network. What's > the rationale for trusting one of the RAs, but not the others? If I get an RA that=E2=80=99s not signed by the same key as a route in = my routing table that=E2=80=99s working, I don=E2=80=99t let it override = what is currently in my routing table and working. --Apple-Mail=_28FC60B6-5768-4DF3-9C6B-0F23DED14CA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 31, 2019, at 10:27 PM, Fernando Gont <fgont@si6networks.com> wrote:

Did happy eyeballs encourage broken IPv6 = connectivity, or did it
actually help IPv6 deployment?

Don=E2=80=99t get me = wrong=E2=80=94I=E2=80=99m not saying we shouldn=E2=80=99t do things to = improve the
situation.   I am saying that we should = be strategic about it.

For the = home network case, the situation right now is that there are
deployments that break, and ISPs meaning to deploy IPv6 that = can't do
stable prefixes. Certainly, that's a very bad = strategy on our side.

That said, and as = noted, the home network case is just *one* scenario
where = this problem may be faced. And a subset of the mitigations for
this scenarios are useful for the general case.

You = mention later that if it takes more than ten seconds for the connection = to resume, the user will be on the phone to the ISP.  It sounds, = then, like they already have an incentive to configure their networks so = that this doesn=E2=80=99t happen.   So why aren=E2=80=99t they = doing that?   What=E2=80=99s the obstacle?

What should be happening = on the host with a prefix that=E2=80=99s deprecated
is = that TCP connections should be timing out.   This doesn=E2=80=99= t take
very long.  

~9 minutes, IIRC.

Should be 90 seconds.

Nope. The default user timeout is 5 minutes as per RFC793. = (The first
para of the second page of RFC5482 provides a = summary wrt the
specification of the user timeout).

Hm, = okay.

That's not correct. = Neither the Valid Lifetime nor the Preferred
Lifetime = affect address selection.

Okay, = there=E2=80=99s something to fix.  Why would these not affect = source
address selection?

For many reasons: one of them: two different routers might be = using
different values for these timers, in an = un-coordinated manner. And
there's not reason for which = the smaller or larger lifetimes should
imply an address is = preferred.

OTOH, you might thing about = preferring "the last advertised prefix". BUt
that would = mean that src address would flap, which is bad for
trouble-shooting.

On what actual network would this scenario occur, though, in a way = that would actually cause the problem you anticipate?  I know you = can set this up in the lab.   But in practice, I never have two = competing routers advertising different and incompatible lifetimes for = the same prefix on my home network.  So if you want to break things = in other ways in order to be able to adapt to this situation, it should = be likely.  When and where is it likely?

As for previous comments about source = address selection, I think that if you have two prefixes that are = otherwise equivalent (a tie), and one has a preferred lifetime of zero, = while the other has a preferred lifetime of not-zero, it would be = dysfunctional to choose the one with the preferred lifetime of zero. =  What on earth is the purpose of preferred and valid lifetimes if = SAS isn=E2=80=99t taking them into account?

What is = =E2=80=9CFHS=E2=80=9D?

Sorry, = for that: First Hop Security, Cisco's speak for RA-Guard, ND
inspeaction, and so on=E2=80=A6
Ah.   Maybe we should call that NKB (network = knows best).

If you Really Really want to be able to have the routers send = out RAs
that deprecate the default route, and, as Mark is = saying here, to
upgrade millions or perhaps billions of = hosts, why not ask for
something that=E2=80=99s a real = improvement?

Every piece = helps.

Right, but if the = effort involved in two different options differs by
epsilon,= you should always choose the option that produces the better
outcome, shouldn=E2=80=99t you?

Is there any of the proposed fixes that we shouldn't be = doing, already,
anyway?

   o  CPE routers SHOULD NOT automatically send =
DHCPv6-PD RELEASE
      messages upon reboot events.

We should definitely be doing this, but = it might be worth pointing out that a very simple fix for this problem = would be to have the server acknowledge the release but ignore it. =  The server is allowed to give out the same prefix again even when = it=E2=80=99s received a release, so the release is not a =E2=80=9Cchange = my prefix=E2=80=9D signal, and perhaps we should explicitly advise that = it not be treated that way.   This would be an easy tweak in a DHCP = server, much easier than updating a billion CPEs.
   o  A CPE =
router sending RAs that advertise dynamically-learned
      prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on
      stable storage, the list of prefixes being advertised on each
      network segment.

Okay.   However, if an ISP makes the change I suggest = above, this is no longer necessary, although I think it=E2=80=99s still = good advice.

Your other proposed changes seem fine to me; my main focus = here is really on whether there are other things we could be doing that = would improve things even more.

What's the = practical difference between that, an a network that supports
RA-Guard?

On a = network that supports RA guard, there probably is no difference,
but RA guard on some networks, as we=E2=80=99ve discussed in = the past, will
actually make the network not work.   = RA guard requires an active
administrator.   So the = CPE case we=E2=80=99re talking about isn=E2=80=99t relevant.

The point is: in a network where = you do not employ RA-Guard, you are
already trusting the = router. Actually, it's worse: you trust all local
systems.

That=E2=80=99s why I=E2=80=99m suggesting that there = might be a way to allow us to trust less and verify more, rather than = having an entity on the wire that has no basis for knowing which devices = are trustworthy and which are not, making that decision for us = (NKB).

When another RA arrives, see if it was signed with the same = key.   If
so, it came from the same router, and = can be trusted to update
whatever information that router = sent, including flash-deprecating a
prefix.   If = not, ignore it.

In the = non-SEND trust model, you do trust the local router. Why did you
trust the local router to configure your network, but not = for
deprecating the prefix?

In the non-SEND trust model, you trust the local network. =   You
/hope/ that the RA you get =E2=80=9Cfro= m the router=E2=80=9D is actually from the router.

Exactly: that's the point: you = already trust the local network. What's
the rationale for = trusting one of the RAs, but not the others?

If I get an RA that=E2=80=99s not signed by the same key as a = route in my routing table that=E2=80=99s working, I don=E2=80=99t let it = override what is currently in my routing table and working.

= --Apple-Mail=_28FC60B6-5768-4DF3-9C6B-0F23DED14CA3-- From nobody Fri Nov 1 02:45:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2310120805 for ; Fri, 1 Nov 2019 02:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 GdP0UWyOQoms for ; Fri, 1 Nov 2019 02:45:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED4212023E for ; Fri, 1 Nov 2019 02:45:18 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 B922986A99; Fri, 1 Nov 2019 10:45:14 +0100 (CET) To: Sander Steffann Cc: Mark Smith , Ole Troan , v6ops list References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: Date: Fri, 1 Nov 2019 06:29:37 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 09:45:22 -0000 On 1/11/19 05:22, Sander Steffann wrote: > Hi, > >>> I think Ole observed that this is contrary to what the PD prefix's >>> Valid Lifetime said would be the case. The ISP supplied a PD Prefix >>> with a Valid Lifetime of X seconds, and then broke that promise by >>> abruptly changing addressing before X seconds. ISPs should be expected >>> to live up to their Valid Lifetime promises. >> >> "Hope" doesn't make networks run properly. > > This isn't "Hope", this is breaking promises, and that does break networks. If you can't at least trust that promises are intended to be kept then you have no network at all... You might hope the ISPs do stable prefixes, that CPEs record the leased prefixes on stable storage, and that CPE routers does not crash and reboot. However, 37% of surveyed ISPs (https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf) indicate they do dynamic prefixes, and thus are likely to be facing this problem (possibly being masqueraded by falling back to IPv4). You may want to declare ISPs clueless, start a crusade to switch to stable prefixes (unlikely success), claim that CPE vendors are cheap, etc. But at the end of the day, user experience will still suck. (I have had cases in which I have flash-renumbered my network by changing and reloading a RA daemon) > >> In any case, as previously noted, there are multiple scenarios that may >> lead to this problem. > > Sure, bad things can happen, and there are cases where despite the best intentions you can't keep your promise. But that doesn't mean everybody should go around making promises without even thinking about keeping them… I certainly can't speak for the 37% above. But a number of folks have already noted (some on-list, some off-list) that they are running networks on which this flash-renumbering events do occur. The home network/cpe case is a notable example, but others exists. And particularly the host-side mitigations help all of them. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 1 02:45:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37571120838 for ; Fri, 1 Nov 2019 02:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 sfZNT9nCyik1 for ; Fri, 1 Nov 2019 02:45:23 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B34312023E for ; Fri, 1 Nov 2019 02:45:23 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 887B486ACF; Fri, 1 Nov 2019 10:45:19 +0100 (CET) To: Ted Lemon Cc: v6ops list References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com> <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <7870ab3d-9570-4f79-df5b-3653ab3a6c54@si6networks.com> Date: Fri, 1 Nov 2019 06:45:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 09:45:31 -0000 On 1/11/19 05:50, Ted Lemon wrote: > On Oct 31, 2019, at 10:27 PM, Fernando Gont > wrote: >>>> >>>> Did happy eyeballs encourage broken IPv6 connectivity, or did it >>>> actually help IPv6 deployment? >>> >>> Don’t get me wrong—I’m not saying we shouldn’t do things to improve the >>> situation.   I am saying that we should be strategic about it. >> >> For the home network case, the situation right now is that there are >> deployments that break, and ISPs meaning to deploy IPv6 that can't do >> stable prefixes. Certainly, that's a very bad strategy on our side. >> >> That said, and as noted, the home network case is just *one* scenario >> where this problem may be faced. And a subset of the mitigations for >> this scenarios are useful for the general case. > > You mention later that if it takes more than ten seconds for the > connection to resume, the user will be on the phone to the ISP.  It > sounds, then, like they already have an incentive to configure their > networks so that this doesn’t happen. In the presence of Happy Eyeballs, the problem will be masqueraded. > So why aren’t they doing that?   What’s the obstacle? Are you referring to the CPE case, or to the rest? [....] > >>>> That's not correct. Neither the Valid Lifetime nor the Preferred >>>> Lifetime affect address selection. >>> >>> Okay, there’s something to fix.  Why would these not affect source >>> address selection? >> >> For many reasons: one of them: two different routers might be using >> different values for these timers, in an un-coordinated manner. And >> there's not reason for which the smaller or larger lifetimes should >> imply an address is preferred. >> >> OTOH, you might thing about preferring "the last advertised prefix". BUt >> that would mean that src address would flap, which is bad for >> trouble-shooting. > > On what /actual/ network would this scenario occur, though, in a way > that would actually cause the problem you anticipate?  I know you can > set this up in the lab.   But in practice, I never have two competing > routers advertising different and incompatible lifetimes for the same > prefix on my home network.  So if you want to break things in other ways > in order to be able to adapt to this situation, it should be likely. >  When and where is it likely? If you assume all routers employ the same values for the valid/preferred lifetimes, then what you propose is the equivalent to "prefer the last advertised prefix". In which case, in the presence of multiple RAs the src address of new sessions will deterministically flap. That doesn't seem nice from a troubleshooting perspective. > As for previous comments about source address selection, I think that if > you have two prefixes that are otherwise equivalent (a tie), and one has > a preferred lifetime of zero, while the other has a preferred lifetime > of not-zero, it would be dysfunctional to choose the one with the > preferred lifetime of zero.  What on earth is the purpose of preferred > and valid lifetimes if SAS isn’t taking them into account? The timers are only supposed to be of use if they go off. Given the default values the use (one month, and one week), they never go off. The valid lifetime would trigger garbage collection for stale prefixes. The preferred lifetime would keep a fresh and working address as the preferred address for new flows. -- if only they went of in a timelier manner. So, I'd rather ask the question: what on earth is the purpose of setting a timer that will never go off in a meaningful situation and period of time? >>>>> If you Really Really want to be able to have the routers send out RAs >>>>> that deprecate the default route, and, as Mark is saying here, to >>>>> upgrade millions or perhaps billions of hosts, why not ask for >>>>> something that’s a real improvement? >>>> >>>> Every piece helps. >>> >>> Right, but if the effort involved in two different options differs by >>> epsilon, you should always choose the option that produces the better >>> outcome, shouldn’t you? >> >> Is there any of the proposed fixes that we shouldn't be doing, already, >> anyway? > > o CPE routers SHOULD NOT automatically send DHCPv6-PD RELEASE > messages upon reboot events. > > > We should definitely be doing this, but it might be worth pointing out > that a very simple fix for this problem would be to have the server > acknowledge the release but ignore it. What if the user does want to release the prefix, e.g. for privacy reasons? >  The server is allowed to give > out the same prefix again even when it’s received a release, so the > release is not a “change my prefix” signal, and perhaps we should > explicitly advise that it not be treated that way.   This would be an > easy tweak in a DHCP server, much easier than updating a billion CPEs. > > o A CPE router sending RAs that advertise dynamically-learned > prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on > stable storage, the list of prefixes being advertised on each > network segment. > > > Okay.   However, if an ISP makes the change I suggest above, this is no > longer necessary, although I think it’s still good advice. > > Your other proposed changes seem fine to me; my main focus here is > really on whether there are other things we could be doing that would > improve things even more. I'm all for that. >>>> What's the practical difference between that, an a network that supports >>>> RA-Guard? >>> >>> On a network that supports RA guard, there probably is no difference, >>> but RA guard on some networks, as we’ve discussed in the past, will >>> actually make the network not work.   RA guard requires an active >>> administrator.   So the CPE case we’re talking about isn’t relevant. >> >> The point is: in a network where you do not employ RA-Guard, you are >> already trusting the router. Actually, it's worse: you trust all local >> systems. > > That’s why I’m suggesting that there might be a way to allow us to trust > less and verify more, rather than having an entity on the wire that has > no basis for knowing which devices are trustworthy and which are not, > making that decision for us (NKB). Not that I oppose to that. But I just note that there's no reason for ot trusting a router that advertises PIO,VL=0, because your trust model is that you do trust the router (if not your whole local network). > >>>>> When another RA arrives, see if it was signed with the same key.   If >>>>> so, it came from the same router, and can be trusted to update >>>>> whatever information that router sent, including flash-deprecating a >>>>> prefix.   If not, ignore it. >>>> >>>> In the non-SEND trust model, you do trust the local router. Why did you >>>> trust the local router to configure your network, but not for >>>> deprecating the prefix? >>> >>> In the non-SEND trust model, you trust the local network.   You >>> /hope/ that the RA you get “from the router” is actually from the router. >> >> Exactly: that's the point: you already trust the local network. What's >> the rationale for trusting one of the RAs, but not the others? > > If I get an RA that’s not signed by the same key as a route in my > routing table that’s working, I don’t let it override what is currently > in my routing table and working. But that's not the current deployed reality. IN current deployments, RAs are not signed. So why wuld you be skeptical to PIO, VL=0? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 1 03:12:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5DF12022E for ; Fri, 1 Nov 2019 03:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 EcvErwqmu6Dm for ; Fri, 1 Nov 2019 03:11:58 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C466A120220 for ; Fri, 1 Nov 2019 03:11:57 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id u22so12224654qtq.13 for ; Fri, 01 Nov 2019 03:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E+4xWjj1E9rFFsHAHe++oIhW5yAf04szckv9/YzvX7k=; b=JUnmVGzvgBys+kdNJq5zfxhjix8+4GvlqQlQGfhDP4IgqbKIgMsnXhMj8/UqiXSpbG MuDsdkllc2f95kkwII8sFuE5zwsOsrcF8iVVb+Mvfg1/yEcaTsdbdb6W8qZL7Zz58NB3 Zkh62rPIoAdV66v1e5voiPvUnWLUMZ6Vsr3LTEoFcSY8t+9GQrG9DqUPC5NNmosnSrkp VYMse+3YlKTnXwEXFtLs7NN/IDZ+nlnn3SnF7FKx0L8cxuv+gi2YNhHXGE5Jik1XJAk/ Bx6FN0qm/RmE9Ub5QlfeJkdL0KFeLusYoA/XNuA6ow/JMhG81TnwFj+caFkU4o1vhIY8 IG4A== 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=E+4xWjj1E9rFFsHAHe++oIhW5yAf04szckv9/YzvX7k=; b=JGsp1H2kuSLORmrX1I2x9ho0O1s4f5IEajcpKW/lw7/q68X1w4ljrh5UX9OKfNhdlH 8E62saOw6+43sSUMOwiv+wZjXnze/aLLYVas8gCbV5piGLAUXdmmH89wgERFtkfkJIZA 3wKFPr6ekJ9RMy7I5Li8oZbmZILSe25Zwc5T/TSEp3Nl/yFrwmfSP3N3a8yFOIWk76Hz WTuaQTe9a3uYUJLH5SmsmbKnBg874QArHa3ghFF540RlfG7i1pbe/QEJoYeo8oqx2rjj t15vGidKd2DGQhlzT6y2kOrD3WPowkB3xuHQZSDWi7dvPHTlRpr7tWTbZoUqdIKC69NP AN5g== X-Gm-Message-State: APjAAAV4GwR9pxR1IkRHH7FnnwShs3sXkPYzxdIRx4DeZB3++uHCvonk qii5Mv6VL1zN9m5dKTmeNdb2LOheZ06FvA== X-Google-Smtp-Source: APXvYqyYvpRY2JriHdS7Vemx365U3W/LGgtlY883lyBjZiYRCyTHdgkh32rrO5X51TXvdBUS/f4Bzw== X-Received: by 2002:a0c:a222:: with SMTP id f31mr8951265qva.192.1572603114559; Fri, 01 Nov 2019 03:11:54 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:bdc1:1d6d:228a:c9c1? ([2601:18b:300:36ee:bdc1:1d6d:228a:c9c1]) by smtp.gmail.com with ESMTPSA id d126sm3571515qkc.93.2019.11.01.03.11.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 03:11:53 -0700 (PDT) From: Ted Lemon Message-Id: <2A9E3CA6-EF42-4D76-8BE2-3BEC9E117AC2@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0B214466-6CE8-4D4C-8DFD-C53B1BE1BF97" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Fri, 1 Nov 2019 06:11:52 -0400 In-Reply-To: <7870ab3d-9570-4f79-df5b-3653ab3a6c54@si6networks.com> Cc: v6ops list To: Fernando Gont References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com> <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> <7870ab3d-9570-4f79-df5b-3653ab3a6c54@si6networks.com> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 10:11:59 -0000 --Apple-Mail=_0B214466-6CE8-4D4C-8DFD-C53B1BE1BF97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 5:45 AM, Fernando Gont wrote: >> So why aren=E2=80=99t they doing that? What=E2=80=99s the obstacle? >=20 > Are you referring to the CPE case, or to the rest? I=E2=80=99m specifically referring to the ISP case, although I think = referring to it as =E2=80=9Cthe CPE case=E2=80=9D is limiting your = options! :) > If you assume all routers employ the same values for the = valid/preferred > lifetimes, then what you propose is the equivalent to "prefer the last > advertised prefix". In which case, in the presence of multiple RAs the > src address of new sessions will deterministically flap. That doesn't > seem nice from a troubleshooting perspective. No, I=E2=80=99m saying that if you have two prefixes, one with a = preferred lifetime of zero, and another with a preferred lifetime that = is not zero, you should choose the second one. Can you explain in a = little more detail when this would cause a =E2=80=9Cdeterministic = flap=E2=80=9D? >> As for previous comments about source address selection, I think that = if >> you have two prefixes that are otherwise equivalent (a tie), and one = has >> a preferred lifetime of zero, while the other has a preferred = lifetime >> of not-zero, it would be dysfunctional to choose the one with the >> preferred lifetime of zero. What on earth is the purpose of = preferred >> and valid lifetimes if SAS isn=E2=80=99t taking them into account? >=20 > The timers are only supposed to be of use if they go off. Given the > default values the use (one month, and one week), they never go off. >=20 > The valid lifetime would trigger garbage collection for stale = prefixes. > The preferred lifetime would keep a fresh and working address as the > preferred address for new flows. -- if only they went of in a timelier > manner. >=20 > So, I'd rather ask the question: what on earth is the purpose of = setting > a timer that will never go off in a meaningful situation and period of = time? Possibly we are talking past each other. A prefix with a preferred = lifetime of zero always has a preferred lifetime of zero. There=E2=80=99= s no timer to go off. How the preferred lifetime got to be zero is of = course an important question, and there I think that what you are = getting at is important: a 30 day expiry time is way too long. What if the user does want to release the prefix, e.g. for privacy = reasons? > Not that I oppose to that. But I just note that there's no reason for = ot > trusting a router that advertises PIO,VL=3D0, because your trust model = is > that you do trust the router (if not your whole local network). >=20 >> If I get an RA that=E2=80=99s not signed by the same key as a route = in my >> routing table that=E2=80=99s working, I don=E2=80=99t let it override = what is currently >> in my routing table and working. >=20 > But that's not the current deployed reality. IN current deployments, = RAs > are not signed. So why wuld you be skeptical to PIO, VL=3D0? Right, we have a problem there. SEND didn=E2=80=99t solve it. I = don=E2=80=99t think RA Guard solves it for the home case. So, there is = work to do=E2=80=A6 :) --Apple-Mail=_0B214466-6CE8-4D4C-8DFD-C53B1BE1BF97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 5:45 AM, Fernando Gont <fgont@si6networks.com> wrote:
So why aren=E2=80=99t they doing = that?   What=E2=80=99s the obstacle?

Are you = referring to the CPE case, or to the = rest?

I=E2=80= =99m specifically referring to the ISP case, although I think referring = to it as =E2=80=9Cthe CPE case=E2=80=9D is limiting your options! = :)

If you = assume all routers employ the same values for the = valid/preferred
lifetimes, then what you propose is the = equivalent to "prefer the last
advertised prefix". In which case, in the = presence of multiple RAs the
src address of new sessions will = deterministically flap. That doesn't
seem nice from a = troubleshooting perspective.

No, I=E2=80=99m saying that if you have two prefixes, one = with a preferred lifetime of zero, and another with a preferred lifetime = that is not zero, you should choose the second one.   Can you = explain in a little more detail when this would cause a =E2=80=9Cdetermini= stic flap=E2=80=9D?

As for previous = comments about source address selection, I think that if
you= have two prefixes that are otherwise equivalent (a tie), and one has
a preferred lifetime of zero, while the other has a preferred = lifetime
of not-zero, it would be dysfunctional to choose = the one with the
preferred lifetime of zero.  What on = earth is the purpose of preferred
and valid lifetimes if = SAS isn=E2=80=99t taking them into account?
The timers = are only supposed to be of use if they go off. Given the
default = values the use (one month, and one week), they never go off.

The valid lifetime would trigger garbage = collection for stale prefixes.
The preferred lifetime would keep a fresh and = working address as the
preferred address for new flows. -- if only = they went of in a timelier
manner.

So, I'd rather ask the question: what on earth is the purpose = of setting
a timer that will never go off in a meaningful situation and = period of time?

Possibly we are talking past each other.   A prefix with = a preferred lifetime of zero always has a preferred lifetime of zero. =   There=E2=80=99s no timer to go off.   How the preferred = lifetime got to be zero is of course an important = question, and there I think that what you are getting at is important: a = 30 day expiry time is way too long.

What if = the user does want to release the prefix, e.g. for privacy = reasons?

Not that I oppose to that. But I just note = that there's no reason for ot
trusting a router that advertises PIO,VL=3D0, = because your trust model is
that you do trust the router (if not your = whole local network).

If I get an RA that=E2=80=99s not signed by = the same key as a route in my
routing table that=E2=80=99s = working, I don=E2=80=99t let it override what is currently
in my routing table and working.
But that's = not the current deployed reality. IN current deployments, RAs
are not = signed. So why wuld you be skeptical to PIO, = VL=3D0?

Right, = we have a problem there.   SEND didn=E2=80=99t solve it.   I = don=E2=80=99t think RA Guard solves it for the home case.   So, = there is work to do=E2=80=A6 :)

= --Apple-Mail=_0B214466-6CE8-4D4C-8DFD-C53B1BE1BF97-- From nobody Fri Nov 1 03:40:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D14120816 for ; Fri, 1 Nov 2019 03:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 Ki8QxMG8WxqD for ; Fri, 1 Nov 2019 03:40:09 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F99B12008A for ; Fri, 1 Nov 2019 03:40:09 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 1EBDA86ABF; Fri, 1 Nov 2019 11:40:06 +0100 (CET) To: Ted Lemon Cc: v6ops list References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com> <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <8b4ff434-c4e2-2f9d-02c6-59fc0c13797d@si6networks.com> Date: Fri, 1 Nov 2019 06:54:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 10:40:11 -0000 On 1/11/19 05:50, Ted Lemon wrote: > On Oct 31, 2019, at 10:27 PM, Fernando Gont > wrote: >>>> >>>> Did happy eyeballs encourage broken IPv6 connectivity, or did it >>>> actually help IPv6 deployment? >>> >>> Don’t get me wrong—I’m not saying we shouldn’t do things to improve the >>> situation.   I am saying that we should be strategic about it. >> >> For the home network case, the situation right now is that there are >> deployments that break, and ISPs meaning to deploy IPv6 that can't do >> stable prefixes. Certainly, that's a very bad strategy on our side. >> >> That said, and as noted, the home network case is just *one* scenario >> where this problem may be faced. And a subset of the mitigations for >> this scenarios are useful for the general case. > > You mention later that if it takes more than ten seconds for the > connection to resume, the user will be on the phone to the ISP. On this lat/long, *if* the failure is visible (likely not, thanks to Happy Eyeballs), people will normally just unplug and reconnect all boxes (e.g. CPE router). Normally, a call to the ISP will lead to the same procedure. (Then, in my own circle, *I* get the call. And based on past experiences, I wouldn't bother to try to escalate the issue at the ISP, and most likely disable IPv6 myself, keep my folks' networks running, and use my time for something else.) P.S.: On a related note, IPv4 masquerading IPv6 issues is the same reason why there have not been peaks of support calls complaining about the DNS configuration mess(android with no dhcpv6, windows with no rdnss). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 1 03:40:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643A4120847 for ; Fri, 1 Nov 2019 03:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 WxvU2qCTOzJI for ; Fri, 1 Nov 2019 03:40:13 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F87120821 for ; Fri, 1 Nov 2019 03:40:13 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 E0DC086ABF; Fri, 1 Nov 2019 11:40:10 +0100 (CET) To: Ted Lemon Cc: v6ops list References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com> <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> <7870ab3d-9570-4f79-df5b-3653ab3a6c54@si6networks.com> <2A9E3CA6-EF42-4D76-8BE2-3BEC9E117AC2@fugue.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <6d724f8b-a2ef-e531-bfd3-f44067398bd1@si6networks.com> Date: Fri, 1 Nov 2019 07:39:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2A9E3CA6-EF42-4D76-8BE2-3BEC9E117AC2@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 10:40:20 -0000 On 1/11/19 07:11, Ted Lemon wrote: > On Nov 1, 2019, at 5:45 AM, Fernando Gont > wrote: >>> So why aren’t they doing that?   What’s the obstacle? >> >> Are you referring to the CPE case, or to the rest? > > I’m specifically referring to the ISP case, although I think referring > to it as “the CPE case” is limiting your options! :) At least one ISP reported issues with their provisioning system. I will ask another, and come back to you. > >> If you assume all routers employ the same values for the valid/preferred >> lifetimes, then what you propose is the equivalent to "prefer the last >> advertised prefix". In which case, in the presence of multiple RAs the >> src address of new sessions will deterministically flap. That doesn't >> seem nice from a troubleshooting perspective. > > No, I’m saying that if you have two prefixes, one with a preferred > lifetime of zero, and another with a preferred lifetime that is not > zero, you should choose the second one.   Can you explain in a little > more detail when this would cause a “deterministic flap”? I misunderstoof you. What I was assuming that you were describing is this: * CPE no longer advertises OLDPREFIX * CPE now advertises NEWPREFIX * If hosts always prefer the prefix with the larger Preferred Lifetime (or the latest advertised Prefix), then you have "solved the problem" However, in a scenario where you have two routers, Router_A that advertises PREFIX_A, and Router_B that Advertises Prefix_B, then, upon receipt of an RA from Router_A, Prefix_A would become preferred. But then, when an RA from Router_B is received, Prefix_B will become preferred. Then, upon receipt of an RA from Router_A, Prefix_A will become preferred again. In the case you discribe, all is fine. However, the key is: what caused the Preferred Lifetime to become 0? (and RA from the CPE trying to deprecate a previous prefix?) >>> As for previous comments about source address selection, I think that if >>> you have two prefixes that are otherwise equivalent (a tie), and one has >>> a preferred lifetime of zero, while the other has a preferred lifetime >>> of not-zero, it would be dysfunctional to choose the one with the >>> preferred lifetime of zero.  What on earth is the purpose of preferred >>> and valid lifetimes if SAS isn’t taking them into account? >> >> The timers are only supposed to be of use if they go off. Given the >> default values the use (one month, and one week), they never go off. >> >> The valid lifetime would trigger garbage collection for stale prefixes. >> The preferred lifetime would keep a fresh and working address as the >> preferred address for new flows. -- if only they went of in a timelier >> manner. >> >> So, I'd rather ask the question: what on earth is the purpose of setting >> a timer that will never go off in a meaningful situation and period of >> time? > > Possibly we are talking past each other.   A prefix with a preferred > lifetime of zero always has a preferred lifetime of zero.   There’s no > timer to go off.   How the preferred lifetime /got/ to be zero is of > course an important question, and there I think that what you are > getting at is important: a 30 day expiry time is way too long. Yep, then we were talking past each other :-) > > What if the user does want to release the prefix, e.g. for privacy reasons? > >> Not that I oppose to that. But I just note that there's no reason for ot >> trusting a router that advertises PIO,VL=0, because your trust model is >> that you do trust the router (if not your whole local network). >> >>> If I get an RA that’s not signed by the same key as a route in my >>> routing table that’s working, I don’t let it override what is currently >>> in my routing table and working. >> >> But that's not the current deployed reality. IN current deployments, RAs >> are not signed. So why wuld you be skeptical to PIO, VL=0? > > Right, we have a problem there.   SEND didn’t solve it.   I don’t think > RA Guard solves it for the home case.   So, there is work to do… :) Improvements in this area would certainly be nice. However, my point is that it should be quite acceptable for one to update RFC4861 such that PIO, VL=0 be honored, since the trust model is that you do trust routers... and, in terms of DoS, there are already pletny of other vectors for an attacker to exploint. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 1 03:41:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454CB12008A for ; Fri, 1 Nov 2019 03:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 u6AiljIcAkxH for ; Fri, 1 Nov 2019 03:41:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 8274D120816 for ; Fri, 1 Nov 2019 03:41:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iQUNM-0000KTC; Fri, 1 Nov 2019 11:41:52 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> In-reply-to: Your message of "Fri, 1 Nov 2019 11:22:52 +0300 ." <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> Date: Fri, 01 Nov 2019 11:41:52 +0100 Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 10:41:56 -0000 > > "Hope" doesn't make networks run properly. > > This isn't "Hope", this is breaking promises, and that does break > networks. If you can't at least trust that promises are intended > to be kept then you have no network at all... Maybe somebody can do a text analysis and show which promise is broken. The typical case is a CPE rebooting, requesting a prefix using DHCPv6 and getting a different prefix from before. As far as I know, there is no text that requires a DHCPv6 server to return the previous lease if it is still valid. The next question would be, if the CPE would try to renew the old prefix and the DHCPv6 server declines. Is there any text the requires a DHCPv6 server to do that. Then the question is, if a CPE reboots can it continue to use the old lease? Typically, link attachment requires obtaining a new lease. But I don't know if that is specified anywhere. I do know that some routers do not install a forwarding entry if you don't get a new lease. I don't think we have any spec for that. From nobody Fri Nov 1 03:57:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF7D120089 for ; Fri, 1 Nov 2019 03:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 s9uHyC_l4Q1M for ; Fri, 1 Nov 2019 03:56:58 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919A812004E for ; Fri, 1 Nov 2019 03:56:58 -0700 (PDT) Received: from [192.168.10.190] (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 7BA3A4E11AD4; Fri, 1 Nov 2019 10:56:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Fri, 1 Nov 2019 11:56:55 +0100 Message-Id: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> References: Cc: v6ops@ietf.org In-Reply-To: To: Philip Homburg X-Mailer: iPhone Mail (17B5084a) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 10:57:00 -0000 Philip, > On 1 Nov 2019, at 11:42, Philip Homburg wrote= : >=20 > =EF=BB=BF >>=20 >>> "Hope" doesn't make networks run properly. >>=20 >> This isn't "Hope", this is breaking promises, and that does break >> networks. If you can't at least trust that promises are intended >> to be kept then you have no network at all... >=20 > Maybe somebody can do a text analysis and show which promise is broken. >=20 > The typical case is a CPE rebooting, requesting a prefix using DHCPv6 and > getting a different prefix from before. >=20 > As far as I know, there is no text that requires a DHCPv6 server to return= > the previous lease if it is still valid. As an author of rfc3633, let me tell what the intention of prefix delegation= is. Then you can choose to bring your lawyer to argue the finer points to j= ustify your use after. :-) PD was intended as a fax replacement. Which was the typical provisioning mec= hanism at the time. The intention was that prefixes delegated had a lifetime= equal to the length of the user=E2=80=99s contract with the ISP. Lifetimes in PD give you an expiry date. E.g a value of 864000 means that th= e delegating entity promises that you are delegated and control this prefix u= ntil November 11th. Unless extended.=20 There=E2=80=99s really little value in having both valid and preferred lifet= imes in PD.=20 The finer points of the DHCP machinery is really no excuse for this practice= . Ole > The next question would be, if the CPE would try to renew the old prefix a= nd > the DHCPv6 server declines. Is there any text the requires a DHCPv6 server= > to do that. >=20 > Then the question is, if a CPE reboots can it continue to use the old leas= e? > Typically, link attachment requires obtaining a new lease. But I don't kno= w > if that is specified anywhere.=20 >=20 > I do know that some routers do not install a forwarding entry if you don't= =20 > get a new lease. I don't think we have any spec for that. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Nov 1 04:05:59 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFDB120823 for ; Fri, 1 Nov 2019 04:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 ITUFReN-yKeb for ; Fri, 1 Nov 2019 04:05:55 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9362B12004E for ; Fri, 1 Nov 2019 04:05:55 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id x21so12374524qto.12 for ; Fri, 01 Nov 2019 04:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yLpKmLEaCuG1+20M7owIjQTeDdpYGmbe0IH4XY+npCA=; b=fbs+EDlF+qbwZLesQk8+lDvtuw4PC/Vxmb/0vrfC1BAIAsIK6vGzkT47k3lc1RLhl9 KSFmAC0GmMkr6uhtRYA4o/vAwZ/36z/nLOOySGRxmsFjeTmLypqd+x352uwtUP9aM0RR /bsTsF5YklRiKWEIeynIEoVjCU3RZsWRAeXGoamvPAm3S8V2UYY9JVWobuzDDddJl359 Kfr1nYKLv/Z8g4t4PsPEc6ERHr1+I0Qbp0wJWVfkNf6QSZ/H4EQ4qkxFa0ONUpCY014z eEH2M59vyAaHDPTMexcLGeG4le0LFnIlBGpQn7eioTIG1bTy1aI+7xe0P/aLIBu2ZCIv vbAQ== 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=yLpKmLEaCuG1+20M7owIjQTeDdpYGmbe0IH4XY+npCA=; b=JR6IUfxtaBwDMmItxpBLcYVlfw9kcuSkvDchdFdC4ZFx2cbW20F0dwYmZEAnJnn1hw JoD9THFkKEtEAUOwJVNTamNr9ZN9MXJCHVkZ006o8sDCJqXKJGlNQTc2AIuBJ4GsQarH AUa8OW9/eqHNnEkhQUF9rlEX/w/7Bp31WuZ+7vGFhCzjSBrkMZ2+iZFpykCCUZnlk5XA Qa8sP4fDNKMBoA9lpE/ngaN24hTwqmy+wyLuZxhITxce++imdrViIOtWe9MRIBO9PmfJ VFztwBKmKgqkS8DevqMrhY81KgKbVN4fgP6gghtbWLw3amZAp/NMCPqVe7SE09kdUxcB Wo1A== X-Gm-Message-State: APjAAAUDxR2NSQWu/6zpjn3hsUGDdEqG7C+SwZ7SfQbjHjnOVYtX+fiX LHT+2Mj8VGUkrcgyaEq6XomuGoBL/MZ6rA== X-Google-Smtp-Source: APXvYqwQr6NSzsU30AwfG7lXzgLL1UZGchSTRI1JL2NUg5JeLYnhmW5OKpMA+tEvNzeCPMfewTQ0Uw== X-Received: by 2002:ac8:18a9:: with SMTP id s38mr5269008qtj.355.1572606354560; Fri, 01 Nov 2019 04:05:54 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:bdc1:1d6d:228a:c9c1? ([2601:18b:300:36ee:bdc1:1d6d:228a:c9c1]) by smtp.gmail.com with ESMTPSA id y28sm3136183qky.25.2019.11.01.04.05.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 04:05:53 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_70CEC1D7-C785-4594-B44A-5D661E4D9CD7" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Fri, 1 Nov 2019 07:05:51 -0400 In-Reply-To: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> Cc: Philip Homburg , v6ops@ietf.org To: Ole Troan References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 11:05:58 -0000 --Apple-Mail=_70CEC1D7-C785-4594-B44A-5D661E4D9CD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 6:56 AM, Ole Troan wrote: > There=E2=80=99s really little value in having both valid and preferred = lifetimes in PD.=20 Ole, I think argument from authority isn=E2=80=99t very useful here. I = can imagine that you might think this, but=E2=80=A6 Suppose I want to renumber a customer. And I have one tool with which = to do this: DHCP. What is the correct behavior? There are options: 1: just stop renewing the old prefix, but continue to route it 2: provide two prefixes, one with a preferred lifetime of zero, the = other with a nonzero preferred lifetime; continue to route both until = the valid lifetime on the deprecated prefix expires, at which point stop = routing that prefix. 3: stop renewing the old prefix, and don=E2=80=99t route it. I think that (1) is valid, and is what we would expect, but there is a = problem: how does the infrastructure know that that prefix should = continue to be routed? It=E2=80=99s not seeing renewal traffic, and I = think that=E2=80=99s how it knows currently. Maybe it does DHCP = leasequery? If so, then does the DHCP server know the prefix is still = valid? I hope so. It would be bad if the DHCP server gave out that = prefix before it had expired. (2) seems valid, and I think is correct behavior, but there=E2=80=99s = been some theorizing on the DHC wg mailing list (and here, a bit) that = some CPE devices might not be expecting this behavior, and might choke = on it. (3) This is a flash renumbering scenario. Now, I think what you just said was that none of these scenarios are = valid, because the ISP should never renumber the customer. Is that = correct? --Apple-Mail=_70CEC1D7-C785-4594-B44A-5D661E4D9CD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 6:56 AM, Ole Troan <otroan@employees.org> wrote:
There=E2=80=99s really little value in having both valid and = preferred lifetimes in PD. 

Ole, I think argument from authority isn=E2=80=99t very = useful here.   I can imagine that you might think this, = but=E2=80=A6

Suppose I want to renumber a customer.   And I have one = tool with which to do this: DHCP.   What is the correct behavior? =   There are options:

1: just stop renewing the old prefix, but continue to route = it
2: provide two prefixes, one with a preferred = lifetime of zero, the other with a nonzero preferred lifetime; continue = to route both until the valid lifetime on the deprecated prefix expires, = at which point stop routing that prefix.
3: stop = renewing the old prefix, and don=E2=80=99t route it.

I think that (1) is = valid, and is what we would expect, but there is a problem: how does the = infrastructure know that that prefix should continue to be routed? =   It=E2=80=99s not seeing renewal traffic, and I think that=E2=80=99s= how it knows currently.   Maybe it does DHCP leasequery?   If = so, then does the DHCP server know the prefix is still valid?   I = hope so.   It would be bad if the DHCP server gave out that prefix = before it had expired.

(2) seems valid, and I think is correct behavior, but = there=E2=80=99s been some theorizing on the DHC wg mailing list (and = here, a bit) that some CPE devices might not be expecting this behavior, = and might choke on it.

(3) This is a flash renumbering scenario.

Now, I think what you = just said was that none of these scenarios are valid, because the ISP = should never renumber the customer.   Is that correct?

= --Apple-Mail=_70CEC1D7-C785-4594-B44A-5D661E4D9CD7-- From nobody Fri Nov 1 04:13:03 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681A9120103 for ; Fri, 1 Nov 2019 04:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 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_HELO_NONE=0.001, 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 gHCZRfqq3m3b for ; Fri, 1 Nov 2019 04:12:59 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5B31200E0 for ; Fri, 1 Nov 2019 04:12:59 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id u13so8072946ote.0 for ; Fri, 01 Nov 2019 04:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sZL/TaeYfq2bgliXG+Y6UeRNB0WpHJ+Evms4JfCbh6k=; b=DRI8rGnGAQs8FKy2UwkZ5ehRRTk/E93aUnK86xPwEdy6WuDScq+7n5VZxqtyyauLUD b6MpvRA/HpJ6Xs5KQHNdX6b5wmxvNlm+7odKk2DiZcDOfJUC17MGjNxuCF1/AikkWUcN RM45JyP+JqKwMMU0txH+NcKuXLLobwfybWTB6Ej3bnTBSYJn7NmqdseE/Nq8/xN8XxrP rznknnfhOp1g/gs1v2EU5BXc1YLfoYxjCuHAvIK0K4RwVFlk72PUJ13UhYWEMZ8cfHtb QSP0xeeB+ms6ki1Oukbo41R34UyRAB/kHQPtRGODQfHWB0osgEHAeOIuI3J9jug5QmAo p2LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sZL/TaeYfq2bgliXG+Y6UeRNB0WpHJ+Evms4JfCbh6k=; b=V1wi4NwzyGQhjyFAHD5ihZT69qXqRMRmSGP8K9uCDjzcZFZFus+twisBQCWxzKJo+G zn3BDmtgwiUFDdy5DcFwYy0sx5wYBS04ZcK4Npv24qZhgfzBqODWvFq/nQeX0aYAeRgE oqhxaSPwMofnoRmIH5+tpNbq7gdkWrgEx7INMP8188HnvQ5TeCcgQE6OO4GZ2dmck0FM kF4yFsZNUFdL/WBP7Oj+YJGwOwrRZeb2yTZuKJBw2CUtCG8UVTO86mwtze59YjhFfIOB DdaX7uX0mFfnxaXEWirv44MTk3pCEBhiB4oBfRNKfnG9cVNZEyeYoKZ05/9WxcFXdU58 in5A== X-Gm-Message-State: APjAAAUszoqVZ/E0+9yWS4UOBQZ1+ZPXJMFE7C1aKXKN9iicv/LLD5mk HmtGLjuwZRqGq6Ok0Y4yMNSnoSWz99v8vOhNWWindw== X-Google-Smtp-Source: APXvYqyZm/VCHOOfKfLIz7tIilerFFJKfEWHvD82e7vnW3/tLQ+PXzFQT6zc/Dygk7z1F5jWHdmxd+YriZiAsD64pR8= X-Received: by 2002:a9d:611c:: with SMTP id i28mr5814407otj.348.1572606778871; Fri, 01 Nov 2019 04:12:58 -0700 (PDT) MIME-Version: 1.0 References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> In-Reply-To: From: Mark Smith Date: Fri, 1 Nov 2019 22:12:48 +1100 Message-ID: To: Philip Homburg Cc: v6ops list Content-Type: multipart/alternative; boundary="0000000000006d14fc0596470c7d" Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 11:13:01 -0000 --0000000000006d14fc0596470c7d Content-Type: text/plain; charset="UTF-8" On Fri, 1 Nov 2019, 21:42 Philip Homburg, wrote: > > > "Hope" doesn't make networks run properly. > > > > This isn't "Hope", this is breaking promises, and that does break > > networks. If you can't at least trust that promises are intended > > to be kept then you have no network at all... > > Maybe somebody can do a text analysis and show which promise is broken. > > The typical case is a CPE rebooting, requesting a prefix using DHCPv6 and > getting a different prefix from before. > It shouldn't be. That's why clients have DHCP Unique Identifiers (DUIDs) that should be persistent across client restarts (or CPE reboots). >From RFC 8415 (the new RFC 3315) binding A binding (or client binding) is a group of server data records containing the information the server has about the addresses or delegated prefixes in an Identity Association (IA) or configuration information explicitly assigned to the client. Configuration information that has been returned to a client through a policy, such as the information returned to all clients on the same link, does not require a binding. A binding containing information about an IA is indexed by the tuple (where IA-type is the type of lease in the IA -- for example, temporary). A binding containing configuration information for a client is indexed by . See below for definitions of DUID, IA, and IAID. "The DUID is designed to be unique across all DHCP clients and servers, and stable for any specific client or server. That is, the DUID used by a client or server SHOULD NOT change over time if at all possible; for example, a device's DUID should not change as a result of a change in the device's network hardware or changes to virtual interfaces (e.g., Mrugalski, et al. Standards Track [Page 32] ------------------------------ RFC 8415 DHCP for IPv6 November 2018 logical PPP (over Ethernet) interfaces that may come and go in Customer Premises Equipment routers). The client may change its DUID as specified in [RFC7844 ]." > As far as I know, there is no text that requires a DHCPv6 server to return > the previous lease if it is still valid. > > The next question would be, if the CPE would try to renew the old prefix > and > the DHCPv6 server declines. Is there any text the requires a DHCPv6 server > to do that. > > Then the question is, if a CPE reboots can it continue to use the old > lease? > Typically, link attachment requires obtaining a new lease. But I don't know > if that is specified anywhere. > > I do know that some routers do not install a forwarding entry if you don't > get a new lease. I don't think we have any spec for that. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000006d14fc0596470c7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 1 Nov 2019, 21:42 Philip Homburg, <pch-v6ops-9@u-1.phicoh.com> wrote:=
> > "Hope" doesn&#= 39;t make networks run properly.
>
> This isn't "Hope", this is breaking promises, and that d= oes break
> networks. If you can't at least trust that promises are intended > to be kept then you have no network at all...

Maybe somebody can do a text analysis and show which promise is broken.

The typical case is a CPE rebooting, requesting a prefix using DHCPv6 and getting a different prefix from before.

It shouldn't be. That's why = clients have DHCP Unique Identifiers (DUIDs) that should be persistent acro= ss client restarts (or CPE reboots).

From RFC 8415 (the new RFC 3315)

binding                   A binding (or client binding) is a=
 group of
                             server data records containing the
                             information the server has about the
                             addresses or delegated prefixes in an
                             Identity Association (IA) or configuration
                             information explicitly assigned to the
                             client.  Configuration information that has
                             been returned to a client through a policy,
                             such as the information returned to all
                             clients on the same link, does not require
                             a binding.  A binding containing
                             information about an IA is indexed by the
                             tuple <DUID, IA-type, IAID> (where IA-ty=
pe
                             is the type of lease in the IA -- for
                             example, temporary).  A binding containing
                             configuration information for a client is
                             indexed by <DUID>.  See below for
                             definitions of DUID, IA, and IAID.
=


<= pre style=3D"font-size:12.6667px;margin-top:0px;margin-bottom:0px">"Th= e DUID is designed to be unique across all DHCP clients and servers, and stable for any specific client or server. That is, the DUID used by a client or server SHOULD NOT change over time if at all possible; for example, a device's DUID should not change as a result of a change i= n the device's network hardware or changes to virtual interfaces (e.g.= , Mrugalski, et al. Standar= ds Track [Page 32]
 
RFC 8415                  =
    DHCP for IPv6                November 2018


   logical PPP (over Ethernet) interfaces that may come and go in
   Customer Premises Equipment routers).  The client may change its DUID
   as specified in [RFC7844=
]."




As far as I know, there is no text that requires a DHCPv6 server to return<= br> the previous lease if it is still valid.

The next question would be, if the CPE would try to renew the old prefix an= d
the DHCPv6 server declines. Is there any text the requires a DHCPv6 server<= br> to do that.

Then the question is, if a CPE reboots can it continue to use the old lease= ?
Typically, link attachment requires obtaining a new lease. But I don't = know
if that is specified anywhere.

I do know that some routers do not install a forwarding entry if you don= 9;t
get a new lease. I don't think we have any spec for that.


_______________________________________________
v6ops mailing list
v6ops@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/v6ops
--0000000000006d14fc0596470c7d-- From nobody Fri Nov 1 04:16:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709451200E0 for ; Fri, 1 Nov 2019 04:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 pPZGeukJofXw for ; Fri, 1 Nov 2019 04:16:00 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D173A12002E for ; Fri, 1 Nov 2019 04:16:00 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:709f:2665:c927:f9f1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 0937D4E12585; Fri, 1 Nov 2019 11:16:00 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 459C82136216; Fri, 1 Nov 2019 12:15:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: Date: Fri, 1 Nov 2019 12:15:56 +0100 Cc: Philip Homburg , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> To: Ted Lemon X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 11:16:03 -0000 Ted, >> There=E2=80=99s really little value in having both valid and = preferred lifetimes in PD.=20 >=20 > Ole, I think argument from authority isn=E2=80=99t very useful here. = I can imagine that you might think this, but=E2=80=A6 >=20 > Suppose I want to renumber a customer. And I have one tool with = which to do this: DHCP. What is the correct behavior? There are = options: >=20 > 1: just stop renewing the old prefix, but continue to route it > 2: provide two prefixes, one with a preferred lifetime of zero, the = other with a nonzero preferred lifetime; continue to route both until = the valid lifetime on the deprecated prefix expires, at which point stop = routing that prefix. > 3: stop renewing the old prefix, and don=E2=80=99t route it. >=20 > I think that (1) is valid, and is what we would expect, but there is a = problem: how does the infrastructure know that that prefix should = continue to be routed? It=E2=80=99s not seeing renewal traffic, and I = think that=E2=80=99s how it knows currently. Maybe it does DHCP = leasequery? If so, then does the DHCP server know the prefix is still = valid? I hope so. It would be bad if the DHCP server gave out that = prefix before it had expired. >=20 > (2) seems valid, and I think is correct behavior, but there=E2=80=99s = been some theorizing on the DHC wg mailing list (and here, a bit) that = some CPE devices might not be expecting this behavior, and might choke = on it. >=20 > (3) This is a flash renumbering scenario. >=20 > Now, I think what you just said was that none of these scenarios are = valid, because the ISP should never renumber the customer. Is that = correct? >=20 Neither of your options have IETF consensus behind them. DHCP PD = supports renumbering, but it also says: "Many applications expect stable addresses. Even though this mechanism makes automatic renumbering easier, it is expected that prefixes have a long lifespan. During renumbering it is expected that the old and the new prefix co-exist for some time." RFC4192 is as far as I know the most complete graceful renumbering = description. To continue my example: (4) Continue to delegate prefix A with a lifetime expiring on November = 11. On November 4th start also delegating prefix B with a lifetime = expiring December 31st 2022. On November 11th, stop advertising prefix A. This is how IPv6 renumbering has been specified for 20 years... I = presume that was not news? Cheers, Ole From nobody Fri Nov 1 04:17:28 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E09120103 for ; Fri, 1 Nov 2019 04:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 gnIjM3q_inYf for ; Fri, 1 Nov 2019 04:17:26 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7348F12002E for ; Fri, 1 Nov 2019 04:17:26 -0700 (PDT) Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 265CA4E14095; Fri, 1 Nov 2019 11:17:26 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 7DC6821362E0; Fri, 1 Nov 2019 12:17:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: Date: Fri, 1 Nov 2019 12:17:24 +0100 Cc: Owen DeLong , Fernando Gont , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 11:17:27 -0000 Ted, >> RA Guard could be default configured on switches with particular = default =E2=80=9Cplug router in here=E2=80=9D (uplink) ports, = eliminating the need for an active administrator. This could be a useful = specification in the HomeNet documents, perhaps. >=20 > This would be disastrous. It pretty much makes permissionless = networking impossible in exchange for solving a security problem no-one = has. At the risk of straying off topic. There is no mechanism for = permissionless networking in IPv6. (which I think is a big gap) Cheers, Ole= From nobody Fri Nov 1 04:44:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DDD120828 for ; Fri, 1 Nov 2019 04:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 3oRdJ1B7o7Nn for ; Fri, 1 Nov 2019 04:44:13 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6428120822 for ; Fri, 1 Nov 2019 04:44:12 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 49B07E6079; Fri, 1 Nov 2019 12:44:09 +0100 (CET) Date: Fri, 01 Nov 2019 12:44:09 +0100 (CET) Message-Id: <20191101.124409.30333597.sthaug@nethelp.no> To: otroan@employees.org Cc: mellon@fugue.com, v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 11:44:15 -0000 >> Now, I think what you just said was that none of these scenarios are valid, because the ISP should never renumber the customer. Is that correct? >> > > Neither of your options have IETF consensus behind them. DHCP PD supports renumbering, but it also says: > > "Many applications expect stable addresses. Even though this > mechanism makes automatic renumbering easier, it is expected that > prefixes have a long lifespan. During renumbering it is expected > that the old and the new prefix co-exist for some time." > > RFC4192 is as far as I know the most complete graceful renumbering description. > > To continue my example: > > (4) Continue to delegate prefix A with a lifetime expiring on November 11. On November 4th start also delegating prefix B with a lifetime expiring December 31st 2022. > On November 11th, stop advertising prefix A. > > This is how IPv6 renumbering has been specified for 20 years... I presume that was not news? A comment from an operator perspective: - We don't "flash renumber" DHCP customers if we can avoid it. - Sometimes a DHCP customer needs to be moved to a new router or cluster of routers. This also implies that the customer will be renumbered. - We normally perform such moves as a planned activity, during nighttime, with alerts to customers beforehand. - We *don't* start delegating new prefixes in advance (and that would be somewhat difficult in any case since they "belong" to the router the customer will be moved to). We have no plans to change this. So - TL;DR: We don't do "flash renumbering" for fun, on the other hand we also don't strictly follow RFC 4192. Steinar Haug, AS2116 From nobody Fri Nov 1 05:21:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0337120255 for ; Fri, 1 Nov 2019 05:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 4At4z1KFrpuQ for ; Fri, 1 Nov 2019 05:20:57 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DA812010E for ; Fri, 1 Nov 2019 05:20:57 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id d13so10466824qko.3 for ; Fri, 01 Nov 2019 05:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=SQgBu58TJGxBVZhG0F+pme01TkHDOX0eqrhGQuXpLW4=; b=qXAPDplOhN6Fgxoe//M8zGx2koiEkUoIcE83aD4NFtcNSQqLzz+wfNeKXaU6jyZtu/ rXtuoZ4LqOnQjUYKgbg4OzmtkC/ikBwqPNuPXeRcwJs4xIfUG4/Y+UWA324N9wLXoZHK zgYJie02OVWuoNS8dLV6k7rF2maWpuYOwMMpCjAFx5DQmxiRXkL+TYPpBQ07R3wCq6ou CsdJ97SRk7Cw/tM85GV+xkIwuBl03HnQ6Xc0lZFnsD7K7EAAqeGAvhnb0+XnnfWIg+dQ rAMScIDlDejT/jTsNqe1ksrtWmczGkT2skaM6WdqsWvwFgKyZu7/iONREDwVqVncK39g lO/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=SQgBu58TJGxBVZhG0F+pme01TkHDOX0eqrhGQuXpLW4=; b=lMkTofFCWHrowSmCUYxvPsPZik/RMfxXDvsFyGDdyQVimA0ZDB7R0T+mtd60qPK0ci 5dCRLVHLd0ZozE3Lr60HS7STVeQRigOS1c5yBslvLX62hSqGBqwdGEfWBPtqqbFZZ44F AnsaRoHMyjVKjHnRfNWSNc07BdVSWqhnt15n1xgEgsQLwMXaxYR7qT4PwhieSeqFXEt0 aNPNXlj7meBieMuGql4NczwtLu01yIjEwp45hW0jvdY1/bp8+4v2aALn1N/+DXRwxIKJ fZ4FT1BHnhcODd9+evlKnjBb8JvwpZYICWJBNAChdrF2mXiJ+eiA3f3aCUHgL4AZ4Id5 d77w== X-Gm-Message-State: APjAAAUm5lJrrp+UYjKxlNLAVOiWurJTlNPH9ZCaH8BZ5ngcGUvszjWS jerMMVEpHh+LwSZ/6rhaD8hgT5N8l4vJqw== X-Google-Smtp-Source: APXvYqyuhBJDFDUOZoxJVyogdTV8RPPYTe74k7vKxuprlxloh+7DTCVD3SiIm38OuuN5ZmJQ4+3Iow== X-Received: by 2002:a37:782:: with SMTP id 124mr5317501qkh.142.1572610856023; Fri, 01 Nov 2019 05:20:56 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:186c:1ff3:ea8d:a057? ([2601:18b:300:36ee:186c:1ff3:ea8d:a057]) by smtp.gmail.com with ESMTPSA id 197sm3795717qkh.80.2019.11.01.05.20.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 05:20:55 -0700 (PDT) From: Ted Lemon Message-Id: <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F2DAAABD-CEC9-40FA-B064-1579160AC359" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 1 Nov 2019 08:20:53 -0400 In-Reply-To: <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> Cc: Philip Homburg , v6ops@ietf.org To: Ole Troan References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 12:20:59 -0000 --Apple-Mail=_F2DAAABD-CEC9-40FA-B064-1579160AC359 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 7:15 AM, Ole Troan wrote: > This is how IPv6 renumbering has been specified for 20 years... I = presume that was not news? There have been efforts in the IETF to document how renumbering can be = done in as minimally disruptive a way as possible (see e.g. Steinar=E2=80=99= s message). There are ISPs that believe that they are supposed to = renumber end user addressing regularly to prevent (or at least = complicate) prefix-based user tracking. And there are ISPs that, if = Fernando is to believed, and I think he is, do flash renumbering. RFC 4192 doesn=E2=80=99t specify timeframes. I think it=E2=80=99s a = good document, but it doesn=E2=80=99t actually prescribe any detailed = behavior. So if none of the options I suggested have IETF consensus, is the answer = to say =E2=80=9Cthen we just assume that people will do whatever they = want, and if they break things we=E2=80=99re okay with that?=E2=80=9D --Apple-Mail=_F2DAAABD-CEC9-40FA-B064-1579160AC359 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 7:15 AM, Ole Troan <otroan@employees.org> wrote:
This is how IPv6 renumbering has been specified for 20 = years... I presume that was not news?

There have been efforts in the IETF to = document how renumbering can be done in as minimally disruptive a way as = possible (see e.g. Steinar=E2=80=99s message).   There are ISPs = that believe that they are supposed to renumber end user addressing = regularly to prevent (or at least complicate) prefix-based user = tracking.  And there are ISPs that, if Fernando is to believed, and = I think he is, do flash renumbering.

RFC 4192 doesn=E2=80=99t specify = timeframes.   I think it=E2=80=99s a good document, but it = doesn=E2=80=99t actually prescribe any detailed behavior.

So if none of the = options I suggested have IETF consensus, is the answer to say =E2=80=9Cthe= n we just assume that people will do whatever they want, and if they = break things we=E2=80=99re okay with that?=E2=80=9D

= --Apple-Mail=_F2DAAABD-CEC9-40FA-B064-1579160AC359-- From nobody Fri Nov 1 05:22:23 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DF312010E for ; Fri, 1 Nov 2019 05:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 l1WMg0GhvcEA for ; Fri, 1 Nov 2019 05:22:21 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9B312007C for ; Fri, 1 Nov 2019 05:22:21 -0700 (PDT) Received: from astfgl.hanazo.no (77.16.221.94.tmi.telenormobil.no [77.16.221.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id C9EAF4E11A33; Fri, 1 Nov 2019 12:22:18 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 8D993213A60B; Fri, 1 Nov 2019 13:22:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> Date: Fri, 1 Nov 2019 13:22:09 +0100 Cc: Philip Homburg , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 12:22:23 -0000 Ted, >> This is how IPv6 renumbering has been specified for 20 years... I = presume that was not news? >=20 > There have been efforts in the IETF to document how renumbering can be = done in as minimally disruptive a way as possible (see e.g. Steinar=E2=80=99= s message). There are ISPs that believe that they are supposed to = renumber end user addressing regularly to prevent (or at least = complicate) prefix-based user tracking. And there are ISPs that, if = Fernando is to believed, and I think he is, do flash renumbering. >=20 > RFC 4192 doesn=E2=80=99t specify timeframes. I think it=E2=80=99s a = good document, but it doesn=E2=80=99t actually prescribe any detailed = behavior. >=20 > So if none of the options I suggested have IETF consensus, is the = answer to say =E2=80=9Cthen we just assume that people will do whatever = they want, and if they break things we=E2=80=99re okay with that? Can you please read my message one more time? Ole From nobody Fri Nov 1 05:22:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B021208B9 for ; Fri, 1 Nov 2019 05:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 R-Tj0Fo7mmnI for ; Fri, 1 Nov 2019 05:22:47 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C6B120883 for ; Fri, 1 Nov 2019 05:22:46 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id o11so7621373qtr.11 for ; Fri, 01 Nov 2019 05:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=X1hiMhhaaGXUvMuEYN0kcc5ny3WPDx7QTpsVgllkke8=; b=FHNEUj1pjaJmqtuYMI3HajoyDcIwM6H28Qz3Rxi9Wgm7UczSp3RVoLIbilSumGu/Kf 8lIWQcSaWS3ITDyIhmgSdHWe9H/grSnHwZuSBKRJN7K1llxjFh7tMmh18qG7xUA5t0xp EGSVgECtBl0uhUfBiLuDAu3FmnhLGI2Z133EYDgOtreEfglYV2JO4MK9GJUsUWAegmj4 Uy7dg62B7ZnRwj8OIvNz3TpACwv/+I7rX0F5zhkeVMRzE/vrY5XhbICtYBSHcqktITW2 fTvj73mp3dqrJ8qsfXvl935SlhfOmy+Z6pTv7W8KT/HLtujE4zgRKjCJDxqUTEEV8LnW I+JQ== 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=X1hiMhhaaGXUvMuEYN0kcc5ny3WPDx7QTpsVgllkke8=; b=eGYWuIMQC5acOnx4u2Rtar8/H60XeQVhQZ/Ay4c+8uM4ilis3YQBCqjpzwWneeEzPt j/Pa6Dp0QVFI26sS91nurQKecn8PNEsgCFrDUqWsQk2mXdrwAhK6lmrOCLE8i3jhb9AF C0sqG6oh0SuP6X7/HM+HfzcKBgIdwuPv8rhylhDSst5M06F2x6BN4D/3z/nbZW3Z2oMk Hb1zkvoeO24anLo692y3KPjCXdrnfuzystmZzlIlr5Kl5uCFUQMvmLGIGI3WtjoXdvDA wBcq+RZ51iKVv+EfGxQ0ms+IEt0pNLx79ronSsFQl3xmFFqc4JBVnuW48/l3HRRhQMBH b0jg== X-Gm-Message-State: APjAAAXZLIGnlefyrmlnnHmrCe3seJvA1j60qNLWpx9IeZoQx3nljvwV XBwj66V47OTROGbpq8ZJk5rP5HhJIWTpZg== X-Google-Smtp-Source: APXvYqxm0BiqsgynR4Or+1wpdNRLmvLF3XcwNBP/ZCZkTioItJjQawdjaXSIlr3KwPkttRwRcgCa5w== X-Received: by 2002:aed:2986:: with SMTP id o6mr10169333qtd.320.1572610965997; Fri, 01 Nov 2019 05:22:45 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:186c:1ff3:ea8d:a057? ([2601:18b:300:36ee:186c:1ff3:ea8d:a057]) by smtp.gmail.com with ESMTPSA id w15sm4263067qtk.43.2019.11.01.05.22.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 05:22:45 -0700 (PDT) From: Ted Lemon Message-Id: <166A84EB-3F53-43D2-86AD-C1233DA45399@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E00D315A-F18C-4D17-8112-747E2D98CAC0" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 1 Nov 2019 08:22:43 -0400 In-Reply-To: Cc: Owen DeLong , Fernando Gont , v6ops list To: Ole Troan References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 12:22:53 -0000 --Apple-Mail=_E00D315A-F18C-4D17-8112-747E2D98CAC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 7:17 AM, Ole Troan wrote: > At the risk of straying off topic. There is no mechanism for = permissionless networking in IPv6. > (which I think is a big gap) Do you mean permissionless advertising of routes to new networks? If = so, I agree. It can be made to sort of work for limited cases, but = there=E2=80=99s no standardized way to make end-to-end connectivity work = between all networks using the various bits of protocol and practice = that we have at present. --Apple-Mail=_E00D315A-F18C-4D17-8112-747E2D98CAC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 7:17 AM, Ole Troan <otroan@employees.org> wrote:
At the risk of straying off topic. There is no mechanism for = permissionless networking in IPv6.
(which I think is a big = gap)

Do = you mean permissionless advertising of routes to new networks?   If = so, I agree.   It can be made to sort of work for limited cases, = but there=E2=80=99s no standardized way to make end-to-end connectivity = work between all networks using the various bits of protocol and = practice that we have at present.

= --Apple-Mail=_E00D315A-F18C-4D17-8112-747E2D98CAC0-- From nobody Fri Nov 1 05:26:40 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84822120118 for ; Fri, 1 Nov 2019 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 eorEUoR0jc5N for ; Fri, 1 Nov 2019 05:26:36 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCFE12002E for ; Fri, 1 Nov 2019 05:26:36 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id o49so12693490qta.7 for ; Fri, 01 Nov 2019 05:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gPvWg0kQKFq6KNjwOVGDcRvcgqGkTpviqnoCco8VYo4=; b=jR4t10qYsPcty5oLFVPmZRrcilNgyRvC1jrJ+yUyMrT/PEWAj4FRp134zM7UnPNXnc iwpKJk2vGa0g73Mw4DRT9PN34CkZxjgi1bkSSvoKJTLxqW5XrGy/1pQ3+qwc+HJ5fFlJ 46HVhY9jr8i7/8pbXicwHrXEwYUIZNw16cf8UwvH88o3tmCE4sdRKXH6R6OUl1EiRW7U d1BwZ7qKVtfoANKTIitMzyg7S7oyEzSnzbDIOtSlEfoskmm0bCaOpDMmVX4lTSzNe+8Q sCsJTpNKuQYBTidIjdoG0jJv2qHFr65JRzZDfsLDuGge7/Q9uwiRyaHwbWuaxHGNtkN0 IT6Q== 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=gPvWg0kQKFq6KNjwOVGDcRvcgqGkTpviqnoCco8VYo4=; b=Qbm/yXypT2xygun8qj81oOIC8cPd9B0cKDe6mPnRtwKj2XU2dWzrgrWpQd7JgSCSXE YQs/Ri7BYfYBDq+PYv7nwqjfcz+RriH2uzD1y2pEhNct793HLUNoiO+XhmilnluWwAVz DSb00+A7pDcMlVjSocoVlgAQERgRPxPlhWPGkXENsgDkbXbkgFHYFCT8Kb8V99Ux2uwf EgXNq2cv+QqMXE9ggmK8lrezhJ7dtnTjzsX0yuG/oUknnzXcqDoQ9YwOqJZHYQ/Ojt/I davYnG9d/m5o8Dh+g+/RxhatueGCQVNeQ+YGsfG/PTrQfLlnvaDvh/OjLD8LlZ49QBBD JjCg== X-Gm-Message-State: APjAAAXff7kEeGcUDM0Vx3+z+4KMhjpSQY6xY5aRbXsPn9lM4tX7oON4 2//ZchcG/hZUxeEZ/PHACoBA8Kb3xwI04g== X-Google-Smtp-Source: APXvYqw4wVbuI8ETuBO+OHCCIV0WBEuve1GM55WldpV8SVPCsMcmw3AwuMaYgzeUHKra13ZQxqZvFQ== X-Received: by 2002:ac8:f35:: with SMTP id e50mr10595802qtk.39.1572611195637; Fri, 01 Nov 2019 05:26:35 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:186c:1ff3:ea8d:a057? ([2601:18b:300:36ee:186c:1ff3:ea8d:a057]) by smtp.gmail.com with ESMTPSA id i4sm2322987qtp.57.2019.11.01.05.26.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 05:26:35 -0700 (PDT) From: Ted Lemon Message-Id: <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0720C975-4470-4D2E-A4C7-6182628FF519" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 1 Nov 2019 08:26:33 -0400 In-Reply-To: <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> Cc: Philip Homburg , v6ops@ietf.org To: Ole Troan References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 12:26:38 -0000 --Apple-Mail=_0720C975-4470-4D2E-A4C7-6182628FF519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 8:22 AM, Ole Troan wrote: > Can you please read my message one more time? I=E2=80=99m not seeing whatever it is that you think I missed. It may = help to realize that =E2=80=9Clong time=E2=80=9D is a subjective term, = and that =E2=80=9Cwhat the IETF has specified=E2=80=9D is not always = =E2=80=9Cwhat people do in practice.=E2=80=9D But beyond that I think = I did read and comprehend what you said, so I=E2=80=99m don=E2=80=99t = know why you=E2=80=99re asking me to read it again. As a general rule, = rather than making a broad request like this, it may help to expose = whatever mental model produced the conclusion that I hadn=E2=80=99t = fully read or understood what you wrote. If I failed to understand it, = asking me to read it again isn=E2=80=99t likely to fix that. --Apple-Mail=_0720C975-4470-4D2E-A4C7-6182628FF519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 8:22 AM, Ole Troan <otroan@employees.org> wrote:
Can you please read my message one more time?

I=E2=80=99m not seeing whatever it is that you think I = missed.   It may help to realize that =E2=80=9Clong time=E2=80=9D = is a subjective term, and that =E2=80=9Cwhat the IETF has specified=E2=80=9D= is not always =E2=80=9Cwhat people do in practice.=E2=80=9D   But = beyond that I think I did read and comprehend what you said, so I=E2=80=99= m don=E2=80=99t know why you=E2=80=99re asking me to read it again. =  As a general rule, rather than making a broad request like this, = it may help to expose whatever mental model produced the conclusion that = I hadn=E2=80=99t fully read or understood what you wrote.   If I = failed to understand it, asking me to read it again isn=E2=80=99t likely = to fix that.

= --Apple-Mail=_0720C975-4470-4D2E-A4C7-6182628FF519-- From nobody Fri Nov 1 05:36:34 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFEF120046 for ; Fri, 1 Nov 2019 05:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 Wj4bDqTT9vtB for ; Fri, 1 Nov 2019 05:36:32 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29C312002E for ; Fri, 1 Nov 2019 05:36:31 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a02:2121:280:6edf:b992:4b01:a510:a476]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 15AA64E11A76; Fri, 1 Nov 2019 12:36:31 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 53F5B213AFEF; Fri, 1 Nov 2019 13:36:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> Date: Fri, 1 Nov 2019 13:36:27 +0100 Cc: Philip Homburg , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org> References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 12:36:33 -0000 Ted, >> Can you please read my message one more time? >=20 > I=E2=80=99m not seeing whatever it is that you think I missed. It = may help to realize that =E2=80=9Clong time=E2=80=9D is a subjective = term, and that =E2=80=9Cwhat the IETF has specified=E2=80=9D is not = always =E2=80=9Cwhat people do in practice.=E2=80=9D But beyond that I = think I did read and comprehend what you said, so I=E2=80=99m don=E2=80=99= t know why you=E2=80=99re asking me to read it again. As a general = rule, rather than making a broad request like this, it may help to = expose whatever mental model produced the conclusion that I hadn=E2=80=99t= fully read or understood what you wrote. If I failed to understand = it, asking me to read it again isn=E2=80=99t likely to fix that. You said: "So if none of the options I suggested have IETF consensus, is the = answer to say =E2=80=9Cthen we just assume that people will do whatever = they want, and if they break things we=E2=80=99re okay with that?=E2=80=9D= " In reply to: "(4) Continue to delegate prefix A with a lifetime expiring on = November 11. On November 4th start also delegating prefix B with a = lifetime expiring December 31st 2022. On November 11th, stop advertising prefix A." (4) is the definition of graceful renumbering. What makes you conclude = "then we just assume that people will do whatever they want"? (especially since your options 1-3 are exactly that, people do whatever = they want...) Ole= From nobody Fri Nov 1 05:57:39 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF8E1200FE for ; Fri, 1 Nov 2019 05:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 9lSkwbvcn5GT for ; Fri, 1 Nov 2019 05:57:35 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF8A12002E for ; Fri, 1 Nov 2019 05:57:35 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id y10so6008248qto.3 for ; Fri, 01 Nov 2019 05:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xuhs/UaZwKyCW+VjTUYISsFSUALF7+CIr9FZgI69aQ0=; b=ucRPAkhiV1ZWaQdw+HM/zVkJeV6QrlIfrU3XrpelTVQSQU5sszGq071UFhEMOOZ26u smn3pTPImihMUZm4JzSg9n7nkJtfV0mCOFncy1v/OlYJh/s182f+s68v3tXN+6cwP0iQ N5hdVdtM2jn7Qya5PrysqgiXs3aspg0t1Q2+k0kkWarda7T1vxoQ3uqj0swe+fkY3xj6 BsMakg3k24O66S6/w7PBasx0BKyxhw7J5GF03ewjgumPUmAOMfYn0Ozg/yQ52Nrmy+lm y7DNiObo3x97MIb6G4649rlwVxtMyLNNTw14XThs2RjovzoXbJcMg9+JQuPMw6/6TucQ Rh5Q== 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=xuhs/UaZwKyCW+VjTUYISsFSUALF7+CIr9FZgI69aQ0=; b=fKQB8+sA6tKm6uurTG5TiyHM6QayC34g9gd+A6TgF7dduVJfgGcHl6BnZgDBLsMXig wKw8iUezTOz6xFDAolmUW3nxkqwX/ZZz9PRfKKjpIbWPyG8D/t/e+punFnDFFJNEBHrF SeS+XlBFmgUcFB4COq1e8N5CIkgyix+pDuqQavHK9oQesFRjXhVaFJAP2IlNzXVvHc5G OUulIfhcmUq3J2xkTjKvi+pvxEisIdifklizY2BNfekmzDKUrtRO5+2QVGknT01R4vG5 pJMh8pDMSNRwNilM8R+xHGE5TvdIXkF7NL+cSx8CU+ew9DKCXzpwRQ0TR4LhMQ3qCJZp 5moQ== X-Gm-Message-State: APjAAAUEocdrq6FP9r7aaJN2W6ny8z1nvmmuTXaYq0/62YnqN68SFNTK Ag2iNfQe/tf7XObYciBRM0NdIHv4WhHXVA== X-Google-Smtp-Source: APXvYqxsBLRwizBxTTZQvF4wYVliEH4HRA6Bg6qdDOopC5S+AJu1FJKIzQ88YYLFN2DTXVjsEpbjtg== X-Received: by 2002:a05:6214:90f:: with SMTP id dj15mr8049648qvb.224.1572613053989; Fri, 01 Nov 2019 05:57:33 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:186c:1ff3:ea8d:a057? ([2601:18b:300:36ee:186c:1ff3:ea8d:a057]) by smtp.gmail.com with ESMTPSA id y186sm3365089qkd.71.2019.11.01.05.57.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 05:57:33 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_21870CED-FAD5-4958-91BB-4D2EE88BF974" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 1 Nov 2019 08:57:31 -0400 In-Reply-To: <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org> Cc: Philip Homburg , v6ops@ietf.org To: Ole Troan References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 12:57:38 -0000 --Apple-Mail=_21870CED-FAD5-4958-91BB-4D2EE88BF974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 8:36 AM, Ole Troan wrote: > (4) is the definition of graceful renumbering. What makes you conclude = "then we just assume that people will do whatever they want"? > (especially since your options 1-3 are exactly that, people do = whatever they want=E2=80=A6) Okay, I missed a step (or five). We have specified what a renumbering = process should ideally look like, without taking into account several = likely operational circumstances. We have not specified in sufficient = detail how renumbering works using DHCPv6 PD, e.g. in a home = environment. Consequently, providers do not have a viable way to follow = our recommendations for how to renumber, and hence just do whatever they = can think of, possibly without realizing that there might be a better = way to do it. Also, DHCP server vendors in particular do not implement = what we intended that they implement, because we never said explicitly = that they should do so, not specified what a CPE should expect in this = situation. Does that help? FWIW, I was asked to consult with an operator who shall remain nameless = about how to solve this problem, and the solution I came up with relied = on the recommendations from RFC 4192. and further relied on DHCPv6 = prefix delegation offering two prefixes, one valid and one preferred. = Unfortunately I don=E2=80=99t think this was ever implemented, but I = still think it=E2=80=99s the right thing to do; what I=E2=80=99m = realizing from this conversation is that not everybody saw this solution = as obvious. Which I think is a problem. --Apple-Mail=_21870CED-FAD5-4958-91BB-4D2EE88BF974 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 8:36 AM, Ole Troan <otroan@employees.org> wrote:
(4) is the definition of graceful renumbering. What makes you = conclude "then we just assume that people will do whatever they = want"?
(especially = since your options 1-3 are exactly that, people do whatever they = want=E2=80=A6)

Okay, I missed a step (or five).  We have = specified what a renumbering process should ideally look like, without = taking into account several likely operational circumstances.  We = have not specified in sufficient detail how renumbering works using = DHCPv6 PD, e.g. in a home environment.  Consequently, providers do = not have a viable way to follow our recommendations for how to renumber, = and hence just do whatever they can think of, possibly without realizing = that there might be a better way to do it.   Also, DHCP server = vendors in particular do not implement what we intended that they = implement, because we never said explicitly that they should do so, not = specified what a CPE should expect in this situation.

Does that help?

FWIW, I was asked to consult with an operator who = shall remain nameless about how to solve this problem, and the solution = I came up with relied on the recommendations from RFC 4192. and further = relied on DHCPv6 prefix delegation offering two prefixes, one valid and = one preferred.  Unfortunately I don=E2=80=99t think this was ever = implemented, but I still think it=E2=80=99s the right thing to do; what = I=E2=80=99m realizing from this conversation is that not everybody saw = this solution as obvious.   Which I think is a = problem.

= --Apple-Mail=_21870CED-FAD5-4958-91BB-4D2EE88BF974-- From nobody Fri Nov 1 06:10:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD29120125 for ; Fri, 1 Nov 2019 06:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=lvZRV0MR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DnkIEYKE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pacBHZg0ubk for ; Fri, 1 Nov 2019 06:10:00 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413BC1200F1 for ; Fri, 1 Nov 2019 06:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15064; q=dns/txt; s=iport; t=1572613800; x=1573823400; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vLkxED5mryQq4g5WUaaBC6UMG6XWdm8mBobPeKggGRk=; b=lvZRV0MRBsoFzS8ssuqHmOrwVdRk+EUi+HesXHFrswSZM9g7T1siu7xY Z1h5n8zdmkSwmdfKR0c8a/gg3w+v/b13CVerp+qBhYmhEEHwz9EPeuOKF dvIoxQ8UKXQajAdWTdWrezNZmNXAvtiXkKQiU0v54FymOLsdiF3IUoUbv g=; IronPort-PHdr: =?us-ascii?q?9a23=3ApNToBBI3+wtIq2m5otmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZubDknpBPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AABSLrxd/5xdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF9gRwvUAVsWCAECyoKhB6DRgOKdYJekxuEYYF?= =?us-ascii?q?CgRADVAkBAQEMAQEtAgEBhEACF4NkJDgTAgMLAQEEAQEBAgEFBG2FNwyFUQE?= =?us-ascii?q?BAQECARIRChMBATcBBAsCAQgOAwQBARYOBAMCAgIwFAkIAgQBDQUIEweDAYF?= =?us-ascii?q?5TQMOIAGnBAKBOIhgdYEygn4BAQWFFxiCFwmBNowRGIF/gRFGgh4uPoQALxg?= =?us-ascii?q?0CYJRMoIsj32FPJg9CoIklVCZZYRXhhODVplUAgQCBAUCDgEBBYFpIoFYcBW?= =?us-ascii?q?DJ1ARFIMGDBcVgzuKU3SBKIw2AYENAQE?= X-IronPort-AV: E=Sophos;i="5.68,255,1569283200"; d="scan'208,217";a="370396233" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 13:09:59 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1D9xEx014577 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 13:09:59 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 08:09:58 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 08:09:58 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 09:09:58 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RV6S3mSF7bRpTRdedv6ze1I1gjQm7FAdUnE5x05isJCurbx752FiiJbeMeKoX8Fho3Ho/P9z55QbEsio0GajqhB/NBKggj3gdZA/sYBkZb0l3jlrcXrqNVXkn/SRMgAcq8DYclzl1pwPIUpH91OvlZXdFeNswl1ymsSJqxz4n57R2zFGzPihBxLNncJNNMemf3/e+c/JnwFM9mLwlcNvkeaOOM/1H7fQnSe7yjo0O/g4lf+cpEdRHXVeHUqjZ6oCNtL7ahsWs5zorZJiX0LqY2+HjWZLjPgzlARIxr6Vn88hGxZo3Eh0lxfU78kETAatNLzZ/e8BtW8aKAWbeq626w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vLkxED5mryQq4g5WUaaBC6UMG6XWdm8mBobPeKggGRk=; b=edWsb0n9/8k+zu5IO+bL1uJhgwlykfqav0RC2kgz7zPVbeqlGB4xAGICG6ydVGuwtt689AtWs4BFcH+ihDItLE6mcJK8uVdoFQxbjZmh2hFlBIASvvqA+I8xFAuJldI6O5fOUGfm4pZ424foDE62rzyjPyTER0aGb2gJ6DwvDekJDa/nh+5sbFC/xRzifpHydN0uhRLM/sKOP+vWrWuJWp7I1oAWjTjTmuwB5DH8jRxhZinDEgHJ0R5DEpcfs6QULqtOEQSRW8FyCpf1P8sKJ5ZxZkXwRf+ueUwtMD2gepncNjqv5RlH6THpM5VpDArPJhPKGQ3l2YwzIsZeeCCR2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vLkxED5mryQq4g5WUaaBC6UMG6XWdm8mBobPeKggGRk=; b=DnkIEYKElzGPipzNCCzd5QBCo9GHwW9KCiDTilE2bT04z6jJ/JU/d9mmZuiAmpXkeHazvG0JIH7PtVQ2M5wYPddrWn2dgEfcAqUvUCLkMHNnMWGxTBQP/tKc6ZvDmmlYXmV1qq0DpRUiitbcOry77WyEQJk0rNgzmQ8VaiUyM8A= Received: from CY4PR1101MB2279.namprd11.prod.outlook.com (10.172.75.137) by CY4PR1101MB2310.namprd11.prod.outlook.com (10.172.77.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Fri, 1 Nov 2019 13:09:56 +0000 Received: from CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab]) by CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab%10]) with mapi id 15.20.2387.030; Fri, 1 Nov 2019 13:09:56 +0000 From: "Bernie Volz (volz)" To: Ted Lemon , Ole Troan CC: "v6ops@ietf.org" Thread-Topic: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) Thread-Index: AQHVj3tMtRKWxZ0q/E2E0DD0Qyz586d1wYiAgAA6nACAACb0iIAABBeAgAACf4CAAALRAIAAEiaAgAAAWoCAAAE7gIAAAsSAgAAF44CAAAICsA== Date: Fri, 1 Nov 2019 13:09:56 +0000 Message-ID: References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f115c5c-c230-4584-d937-08d75ecccae8 x-ms-traffictypediagnostic: CY4PR1101MB2310: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(346002)(396003)(366004)(189003)(199004)(55016002)(486006)(71200400001)(66446008)(71190400001)(6436002)(3846002)(64756008)(316002)(256004)(102836004)(6506007)(53546011)(110136005)(76116006)(14444005)(76176011)(7696005)(66556008)(66946007)(6116002)(790700001)(14454004)(7736002)(478600001)(86362001)(446003)(8936002)(52536014)(11346002)(26005)(66476007)(6246003)(236005)(25786009)(6306002)(54896002)(99286004)(9686003)(476003)(4326008)(2906002)(33656002)(74316002)(81156014)(81166006)(8676002)(66066001)(5660300002)(186003)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2310; H:CY4PR1101MB2279.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: S1ZGjOIS0iM32OL2GipRXu1KScad7lOVEkrE5ZyJgtJdqDxJWco/UdF+KKzbfG9JeUHuQziVjlLXwSSDaATEJ5aqZn8eVYJ96m5RB/8fF7XV1us7ZbgOOG4BNFdGKDWudRKGkoJyE2d/H8krrJtDAvY+SZa32/2ivosk4aOvIKUdIRThq0J8HhHWWrn23kjjXMW4/wt3eSQC1e8FC7sXP2dFjF4Y+PGD90mcUUpEE21YiLX7oJFotBD1DuZKIXgtgYipcDe5TryWgCjMlJ3bRqh1LJcm1fVhAfw1dv5l0hXF9qdismSRGVRcvslWeEiCcJZNeYXCfoumzdoC3KYKyPtO1UBa7/REl8tIgpQUK7d0V5LWPK0Rwcev2d57plqdlkXxgGZddpF7ILlDLUhad63+9olaYtfOAr1NFnEdb4MAaatnXaS6qqDQNe8fJ7nA x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR1101MB22791F44933650A4E34D333FCF620CY4PR1101MB2279_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6f115c5c-c230-4584-d937-08d75ecccae8 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 13:09:56.6091 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HcQl2rzdIv54PVg70FGsY4tpE7CLGLS5ak9BHZALJtG5J3cLnhuoZt4MsRwMDt6g X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2310 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:10:03 -0000 --_000_CY4PR1101MB22791F44933650A4E34D333FCF620CY4PR1101MB2279_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBBbHNvLCBESENQIHNlcnZlciB2ZW5kb3JzIGluIHBhcnRpY3VsYXIgZG8gbm90IGltcGxlbWVu dCB3aGF0IHdlIGludGVuZGVkIHRoYXQgdGhleSBpbXBsZW1lbnQsIGJlY2F1c2Ugd2UgbmV2ZXIg c2FpZCBleHBsaWNpdGx5IHRoYXQgdGhleSBzaG91bGQgZG8gc28sIG5vdCBzcGVjaWZpZWQgd2hh dCBhIENQRSBzaG91bGQgZXhwZWN0IGluIHRoaXMgc2l0dWF0aW9uLg0KDQpUaGF04oCZcyBub3Qg dHJ1ZS4gVGhlIHNlcnZlciBJIHdvcmsgb24gYWxsb3dzIHlvdSB0byBzcGVjaWZ5IGFuIGV4cGly YXRpb24gdGltZSBmb3IgYSBwcmVmaXgsIGFuZCB3ZSB3aWxsIGF1dG9tYXRpY2FsbHkgZGVjcmVh c2UgbGlmZXRpbWVzIHRvIGhvbm9yIHRoYXQgdGltZSBhbmQgYWxzbyBzdG9wIHVzaW5nIHRoZSBw cmVmaXggZm9yIG5ldyBsZWFzZXMuIFRoaXMgYWxsb3dzIHlvdSB0byBpbnRyb2R1Y2UgYSBuZXcg cHJlZml4IHRvIGJlIHVzZWQgZm9yIHByZWZpeCBkZWxlZ2F0aW9uIGZvciBncmFjZWZ1bCByZW51 bWJlcmluZy4gT25jZSB0aGUgZXhwaXJhdGlvbiB0aW1lIGhhcyBwYXNzZWQsIHlvdSBjYW4gcmVt b3ZlIHRoZSBvbGQgcHJlZml4IGFzIHRoZXJlIHNob3VsZCBubyBsb25nZXIgYmUgYW55IGFjdGl2 ZSBsZWFzZXMuIFdlIGludHJvZHVjZWQgdGhpcyB3aXRoIHRoZSBmaXJzdCByZWxlYXNlIHdpdGgg REhDUHY2IHN1cHBvcnQgYSBsb25nIHRpbWUgYWdvLg0KDQoNCiAgKiAgIEJlcm5pZQ0KDQpGcm9t OiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0K U2VudDogRnJpZGF5LCBOb3ZlbWJlciAxLCAyMDE5IDg6NTggQU0NClRvOiBPbGUgVHJvYW4gPG90 cm9hbkBlbXBsb3llZXMub3JnPg0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2 b3BzXSBBIGJyb2tlbiBwcm9taXNlIC0gIllvdSBzYWlkIFBEIFByZWZpeCBWYWxpZCBMaWZldGlt ZSBpcyBnb2luZyB0byBiZSBYIiAoUmU6IFNMQUFDIHJlbnVtOiBQcm9ibGVtIFN0YXRlbWVudCAm IE9wZXJhdGlvbmFsIHdvcmthcm91bmRzKQ0KDQpPbiBOb3YgMSwgMjAxOSwgYXQgODozNiBBTSwg T2xlIFRyb2FuIDxvdHJvYW5AZW1wbG95ZWVzLm9yZzxtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5v cmc+PiB3cm90ZToNCig0KSBpcyB0aGUgZGVmaW5pdGlvbiBvZiBncmFjZWZ1bCByZW51bWJlcmlu Zy4gV2hhdCBtYWtlcyB5b3UgY29uY2x1ZGUgInRoZW4gd2UganVzdCBhc3N1bWUgdGhhdCBwZW9w bGUgd2lsbCBkbyB3aGF0ZXZlciB0aGV5IHdhbnQiPw0KKGVzcGVjaWFsbHkgc2luY2UgeW91ciBv cHRpb25zIDEtMyBhcmUgZXhhY3RseSB0aGF0LCBwZW9wbGUgZG8gd2hhdGV2ZXIgdGhleSB3YW50 4oCmKQ0KDQpPa2F5LCBJIG1pc3NlZCBhIHN0ZXAgKG9yIGZpdmUpLiAgV2UgaGF2ZSBzcGVjaWZp ZWQgd2hhdCBhIHJlbnVtYmVyaW5nIHByb2Nlc3Mgc2hvdWxkIGlkZWFsbHkgbG9vayBsaWtlLCB3 aXRob3V0IHRha2luZyBpbnRvIGFjY291bnQgc2V2ZXJhbCBsaWtlbHkgb3BlcmF0aW9uYWwgY2ly Y3Vtc3RhbmNlcy4gIFdlIGhhdmUgbm90IHNwZWNpZmllZCBpbiBzdWZmaWNpZW50IGRldGFpbCBo b3cgcmVudW1iZXJpbmcgd29ya3MgdXNpbmcgREhDUHY2IFBELCBlLmcuIGluIGEgaG9tZSBlbnZp cm9ubWVudC4gIENvbnNlcXVlbnRseSwgcHJvdmlkZXJzIGRvIG5vdCBoYXZlIGEgdmlhYmxlIHdh eSB0byBmb2xsb3cgb3VyIHJlY29tbWVuZGF0aW9ucyBmb3IgaG93IHRvIHJlbnVtYmVyLCBhbmQg aGVuY2UganVzdCBkbyB3aGF0ZXZlciB0aGV5IGNhbiB0aGluayBvZiwgcG9zc2libHkgd2l0aG91 dCByZWFsaXppbmcgdGhhdCB0aGVyZSBtaWdodCBiZSBhIGJldHRlciB3YXkgdG8gZG8gaXQuICAg QWxzbywgREhDUCBzZXJ2ZXIgdmVuZG9ycyBpbiBwYXJ0aWN1bGFyIGRvIG5vdCBpbXBsZW1lbnQg d2hhdCB3ZSBpbnRlbmRlZCB0aGF0IHRoZXkgaW1wbGVtZW50LCBiZWNhdXNlIHdlIG5ldmVyIHNh aWQgZXhwbGljaXRseSB0aGF0IHRoZXkgc2hvdWxkIGRvIHNvLCBub3Qgc3BlY2lmaWVkIHdoYXQg YSBDUEUgc2hvdWxkIGV4cGVjdCBpbiB0aGlzIHNpdHVhdGlvbi4NCg0KRG9lcyB0aGF0IGhlbHA/ DQoNCkZXSVcsIEkgd2FzIGFza2VkIHRvIGNvbnN1bHQgd2l0aCBhbiBvcGVyYXRvciB3aG8gc2hh bGwgcmVtYWluIG5hbWVsZXNzIGFib3V0IGhvdyB0byBzb2x2ZSB0aGlzIHByb2JsZW0sIGFuZCB0 aGUgc29sdXRpb24gSSBjYW1lIHVwIHdpdGggcmVsaWVkIG9uIHRoZSByZWNvbW1lbmRhdGlvbnMg ZnJvbSBSRkMgNDE5Mi4gYW5kIGZ1cnRoZXIgcmVsaWVkIG9uIERIQ1B2NiBwcmVmaXggZGVsZWdh dGlvbiBvZmZlcmluZyB0d28gcHJlZml4ZXMsIG9uZSB2YWxpZCBhbmQgb25lIHByZWZlcnJlZC4g IFVuZm9ydHVuYXRlbHkgSSBkb27igJl0IHRoaW5rIHRoaXMgd2FzIGV2ZXIgaW1wbGVtZW50ZWQs IGJ1dCBJIHN0aWxsIHRoaW5rIGl04oCZcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG87IHdoYXQgSeKA mW0gcmVhbGl6aW5nIGZyb20gdGhpcyBjb252ZXJzYXRpb24gaXMgdGhhdCBub3QgZXZlcnlib2R5 IHNhdyB0aGlzIHNvbHV0aW9uIGFzIG9idmlvdXMuICAgV2hpY2ggSSB0aGluayBpcyBhIHByb2Js ZW0uDQoNCg== --_000_CY4PR1101MB22791F44933650A4E34D333FCF620CY4PR1101MB2279_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3Vs YXI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDY4NjcxNTIzOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODcwMjc4NjI4IC05MTAyODM2MDAg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoz Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyBBbHNvLCBESENQIHNlcnZlciB2ZW5kb3JzIGluIHBhcnRpY3Vs YXIgZG8gbm90IGltcGxlbWVudCB3aGF0IHdlIGludGVuZGVkIHRoYXQgdGhleSBpbXBsZW1lbnQs IGJlY2F1c2Ugd2UgbmV2ZXIgc2FpZCBleHBsaWNpdGx5IHRoYXQgdGhleSBzaG91bGQgZG8gc28s IG5vdCBzcGVjaWZpZWQgd2hhdCBhIENQRSBzaG91bGQgZXhwZWN0IGluIHRoaXMgc2l0dWF0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF04oCZcyBub3QgdHJ1ZS4gVGhlIHNlcnZlciBJ IHdvcmsgb24gYWxsb3dzIHlvdSB0byBzcGVjaWZ5IGFuIGV4cGlyYXRpb24gdGltZSBmb3IgYSBw cmVmaXgsIGFuZCB3ZSB3aWxsIGF1dG9tYXRpY2FsbHkgZGVjcmVhc2UgbGlmZXRpbWVzIHRvIGhv bm9yIHRoYXQgdGltZSBhbmQgYWxzbyBzdG9wIHVzaW5nIHRoZSBwcmVmaXggZm9yIG5ldyBsZWFz ZXMuIFRoaXMgYWxsb3dzIHlvdSB0byBpbnRyb2R1Y2UgYSBuZXcNCiBwcmVmaXggdG8gYmUgdXNl ZCBmb3IgcHJlZml4IGRlbGVnYXRpb24gZm9yIGdyYWNlZnVsIHJlbnVtYmVyaW5nLiBPbmNlIHRo ZSBleHBpcmF0aW9uIHRpbWUgaGFzIHBhc3NlZCwgeW91IGNhbiByZW1vdmUgdGhlIG9sZCBwcmVm aXggYXMgdGhlcmUgc2hvdWxkIG5vIGxvbmdlciBiZSBhbnkgYWN0aXZlIGxlYXNlcy4gV2UgaW50 cm9kdWNlZCB0aGlzIHdpdGggdGhlIGZpcnN0IHJlbGVhc2Ugd2l0aCBESENQdjYgc3VwcG9ydCBh IGxvbmcgdGltZSBhZ28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj5CZXJuaWU8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiB2Nm9wcyAm bHQ7djZvcHMtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NClRlZCBM ZW1vbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDEsIDIwMTkgODo1OCBBTTxi cj4NCjxiPlRvOjwvYj4gT2xlIFRyb2FuICZsdDtvdHJvYW5AZW1wbG95ZWVzLm9yZyZndDs8YnI+ DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZv cHNdIEEgYnJva2VuIHByb21pc2UgLSAmcXVvdDtZb3Ugc2FpZCBQRCBQcmVmaXggVmFsaWQgTGlm ZXRpbWUgaXMgZ29pbmcgdG8gYmUgWCZxdW90OyAoUmU6IFNMQUFDIHJlbnVtOiBQcm9ibGVtIFN0 YXRlbWVudCAmYW1wOyBPcGVyYXRpb25hbCB3b3JrYXJvdW5kcyk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAxLCAyMDE5LCBhdCA4OjM2IEFNLCBPbGUgVHJv YW4gJmx0OzxhIGhyZWY9Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyI+b3Ryb2FuQGVtcGxv eWVlcy5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj4oNCkgaXMgdGhlIGRlZmluaXRp b24gb2YgZ3JhY2VmdWwgcmVudW1iZXJpbmcuIFdoYXQgbWFrZXMgeW91IGNvbmNsdWRlICZxdW90 O3RoZW4gd2UganVzdCBhc3N1bWUgdGhhdCBwZW9wbGUgd2lsbCBkbyB3aGF0ZXZlciB0aGV5IHdh bnQmcXVvdDs/PGJyPg0KKGVzcGVjaWFsbHkgc2luY2UgeW91ciBvcHRpb25zIDEtMyBhcmUgZXhh Y3RseSB0aGF0LCBwZW9wbGUgZG8gd2hhdGV2ZXIgdGhleSB3YW504oCmKTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P a2F5LCBJIG1pc3NlZCBhIHN0ZXAgKG9yIGZpdmUpLiAmbmJzcDtXZSBoYXZlIHNwZWNpZmllZCB3 aGF0IGEgcmVudW1iZXJpbmcgcHJvY2VzcyBzaG91bGQgaWRlYWxseSBsb29rIGxpa2UsIHdpdGhv dXQgdGFraW5nIGludG8gYWNjb3VudCBzZXZlcmFsIGxpa2VseSBvcGVyYXRpb25hbCBjaXJjdW1z dGFuY2VzLiAmbmJzcDtXZSBoYXZlIG5vdCBzcGVjaWZpZWQgaW4gc3VmZmljaWVudCBkZXRhaWwg aG93IHJlbnVtYmVyaW5nIHdvcmtzDQogdXNpbmcgREhDUHY2IFBELCBlLmcuIGluIGEgaG9tZSBl bnZpcm9ubWVudC4gJm5ic3A7Q29uc2VxdWVudGx5LCBwcm92aWRlcnMgZG8gbm90IGhhdmUgYSB2 aWFibGUgd2F5IHRvIGZvbGxvdyBvdXIgcmVjb21tZW5kYXRpb25zIGZvciBob3cgdG8gcmVudW1i ZXIsIGFuZCBoZW5jZSBqdXN0IGRvIHdoYXRldmVyIHRoZXkgY2FuIHRoaW5rIG9mLCBwb3NzaWJs eSB3aXRob3V0IHJlYWxpemluZyB0aGF0IHRoZXJlIG1pZ2h0IGJlIGEgYmV0dGVyIHdheSB0byBk bw0KIGl0LiAmbmJzcDsgQWxzbywgREhDUCBzZXJ2ZXIgdmVuZG9ycyBpbiBwYXJ0aWN1bGFyIGRv IG5vdCBpbXBsZW1lbnQgd2hhdCB3ZSBpbnRlbmRlZCB0aGF0IHRoZXkgaW1wbGVtZW50LCBiZWNh dXNlIHdlIG5ldmVyIHNhaWQgZXhwbGljaXRseSB0aGF0IHRoZXkgc2hvdWxkIGRvIHNvLCBub3Qg c3BlY2lmaWVkIHdoYXQgYSBDUEUgc2hvdWxkIGV4cGVjdCBpbiB0aGlzIHNpdHVhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lcyB0 aGF0IGhlbHA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZXSVcsIEkgd2FzIGFza2VkIHRvIGNvbnN1bHQgd2l0aCBhbiBvcGVyYXRvciB3aG8g c2hhbGwgcmVtYWluIG5hbWVsZXNzIGFib3V0IGhvdyB0byBzb2x2ZSB0aGlzIHByb2JsZW0sIGFu ZCB0aGUgc29sdXRpb24gSSBjYW1lIHVwIHdpdGggcmVsaWVkIG9uIHRoZSByZWNvbW1lbmRhdGlv bnMgZnJvbSBSRkMgNDE5Mi4gYW5kIGZ1cnRoZXIgcmVsaWVkIG9uIERIQ1B2NiBwcmVmaXggZGVs ZWdhdGlvbiBvZmZlcmluZw0KIHR3byBwcmVmaXhlcywgb25lIHZhbGlkIGFuZCBvbmUgcHJlZmVy cmVkLiAmbmJzcDtVbmZvcnR1bmF0ZWx5IEkgZG9u4oCZdCB0aGluayB0aGlzIHdhcyBldmVyIGlt cGxlbWVudGVkLCBidXQgSSBzdGlsbCB0aGluayBpdOKAmXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRv OyB3aGF0IEnigJltIHJlYWxpemluZyBmcm9tIHRoaXMgY29udmVyc2F0aW9uIGlzIHRoYXQgbm90 IGV2ZXJ5Ym9keSBzYXcgdGhpcyBzb2x1dGlvbiBhcyBvYnZpb3VzLiAmbmJzcDsgV2hpY2ggSSB0 aGluayBpcw0KIGEgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_CY4PR1101MB22791F44933650A4E34D333FCF620CY4PR1101MB2279_-- From nobody Fri Nov 1 06:17:46 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8A11200F1 for ; Fri, 1 Nov 2019 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 uCpMOOIt-9aE for ; Fri, 1 Nov 2019 06:17:43 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2CC1200CE for ; Fri, 1 Nov 2019 06:17:43 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id c26so12865405qtj.10 for ; Fri, 01 Nov 2019 06:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/asZBcNHBSB0p0BcZwvetEjUf4ygB9vZny7Zbb6iDCs=; b=Hk1pPr14QPaqdDEtLl6R4+u0dKABCLlriYogQ49NKjDFcd8bSafTKGR00PRgOeHUL8 MKP8Lor7RfOiEKXEi0w8YwsJFVTVJYQkmI8BEf0iV25SD9stqp3UgGIriJid5IPcP0DM RLVdhZpnKRIPul3nfFm6wZ1fh+JGJk3d8bWcRbvNz7+joDGUjbZ/FlXk1IYL3Z/jmMb4 fKYZwuh4r8w0Kl8UFRmFLB8gsdpbQR+eYZ45EjcH4Cq8DNW8NTeJqAju1HCxEIb5m3m/ DvDgCW8wHOOUvhJPJn9aaSK46gAq+pyZI9pd3sKFOTKpDeZvkMn3JPsn3Di2m3VyZu2H D1zA== 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=/asZBcNHBSB0p0BcZwvetEjUf4ygB9vZny7Zbb6iDCs=; b=gq01XdBZAilTNoaURv4aVY27W0WClMxkHVa0PahlI9C5DAidwP99Qw9LUlKjsbyjSi x5V9LalO24SIZbR6LynpPgqm3uYOt5E6fH04vQuxRpbDrX0mU6oYft6kEeghl0FtYj7t yU3dfy2S93CMgMFD6kGr75p45wri2Fr9WaeLGQVVsyQ7YbEPX7kwwOBMWAG/vePguyHa O/hkITSbm81OsVhOQV8H5/HzP2if0OqLmRl9X+2+OEvl1km1V6LvshD+bQ24XGvvsi2w wmNaAG/I9Hw+AU7LimmxFPqQ1VG/lGQiQAjHSzUMUuFuO77YuMGgSIjU1M/iD0Sz5Xl9 yFAQ== X-Gm-Message-State: APjAAAUWhSkcx3qyGFuN+nMVGVOqD/D+9HvYXHTm+f3yEhKiXVdY12mj 0/P91KMddPdHgK12UfIBE4XwVw== X-Google-Smtp-Source: APXvYqzIcvzPWCdwgtjtcQzU0PCe0hwFKGMCnT2G06tIzY/cbN+uiuRel+Bh8PC2CkLK7QPGqrJcJw== X-Received: by 2002:ad4:4081:: with SMTP id l1mr9597801qvp.174.1572614262346; Fri, 01 Nov 2019 06:17:42 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:186c:1ff3:ea8d:a057? ([2601:18b:300:36ee:186c:1ff3:ea8d:a057]) by smtp.gmail.com with ESMTPSA id y10sm3856427qkb.55.2019.11.01.06.17.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 06:17:41 -0700 (PDT) From: Ted Lemon Message-Id: <806C343D-1C75-43A7-81F3-14DE03F327B1@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_349D38A4-A84C-4304-ABBE-D35F98B2DF1F" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 1 Nov 2019 09:17:40 -0400 In-Reply-To: Cc: Ole Troan , "v6ops@ietf.org" To: "Bernie Volz (volz)" References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:17:45 -0000 --Apple-Mail=_349D38A4-A84C-4304-ABBE-D35F98B2DF1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 9:09 AM, Bernie Volz (volz) wrote: > That=E2=80=99s not true. The server I work on allows you to specify an = expiration time for a prefix, and we will automatically decrease = lifetimes to honor that time and also stop using the prefix for new = leases. This allows you to introduce a new prefix to be used for prefix = delegation for graceful renumbering. Once the expiration time has = passed, you can remove the old prefix as there should no longer be any = active leases. We introduced this with the first release with DHCPv6 = support a long time ago. Does it send both prefixes to the CPE, or just the new one? --Apple-Mail=_349D38A4-A84C-4304-ABBE-D35F98B2DF1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 9:09 AM, Bernie Volz (volz) <volz@cisco.com> = wrote:
That=E2=80=99s = not true. The server I work on allows you to specify an expiration time = for a prefix, and we will automatically decrease lifetimes to honor that = time and also stop using the prefix for new leases. This allows you to = introduce a new prefix to be used for prefix delegation for graceful = renumbering. Once the expiration time has passed, you can remove the old = prefix as there should no longer be any active leases. We introduced = this with the first release with DHCPv6 support a long time = ago.

Does = it send both prefixes to the CPE, or just the new one?

= --Apple-Mail=_349D38A4-A84C-4304-ABBE-D35F98B2DF1F-- From nobody Fri Nov 1 06:27:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E14E120145 for ; Fri, 1 Nov 2019 06:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=XMyU8MLr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=D5Bs5K9w Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS86rrTqHzvr for ; Fri, 1 Nov 2019 06:27:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A3B1200CE for ; Fri, 1 Nov 2019 06:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11537; q=dns/txt; s=iport; t=1572614873; x=1573824473; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KFaOhWW9zPufbTciE65+8lIOeBBQt/9kaT0gzPDtn7Q=; b=XMyU8MLrstSbqZ4ADTv9Ujd/xv2NhlSQbY6LuXxfWJfbzWZ7NMEBMBq6 msC4sUHw8TA91PaZuYSjkE/mNAZHFbjLeT+YbVPmC3InhJmcvHeGA8MFO IcSxWyRR2vd/HDqSbA3DvT+eBX8VEM0reOchuVOhoRjg8AGErT61sqRBa E=; IronPort-PHdr: =?us-ascii?q?9a23=3AItMyKxOn/tZOtUr8vwsl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQF0r/PtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAABMMrxd/5tdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgX2BHC9QBWxYIAQLKgqEHoNGA4p1gjk?= =?us-ascii?q?lkxuEYYJSA1QJAQEBDAEBLQIBAYRAAheDZCQ4EwIDCwEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhVEBAQEBAxIRHQEBNwEPAgEIDgMDAQIkBAMCAgIwFAkIAgQOBSKDAAGBeU0?= =?us-ascii?q?DLgGnEAKBOIhgdYEygn4BAQWFFxiCFwmBNowRGIF/gTgME4IeLj6EKQY2FoJ?= =?us-ascii?q?aMoIsjQUGCIJqGoUigjuVFG4KgiSVNRQHmWWEV4YTnSoCBAIEBQIOAQEFgWk?= =?us-ascii?q?igVhwFWUBgkFQERSDBgwXFYM7ilN0gSiMNgEvXgEB?= X-IronPort-AV: E=Sophos;i="5.68,255,1569283200"; d="scan'208,217";a="660264482" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 13:27:52 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1DRqma024501 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 13:27:52 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 08:27:51 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 08:27:50 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 08:27:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Amrxa2E3wT8C7OX6p7z/ZBQTm5/LeA4w4E0lQfmlGSzOpFarDPy/AZqhp6fhAa5CBvSVFJFYdZNxPwVrdD2BGvOEsbpl1xnJ7IGfAapFkeAADmS4oRq33wXW1c2cdrs7rcsdnx0ZivxU9Ut6ZM6iOrOCh+eNm8IRAh5EAxwlZAnvSF8m2uHPe3Tsahdm4xFX3KVoCiPJ0yCxAcTQLNxzhtot39906HEjwzC6IpG4mStNUYTHwVUK8iSlgf46oNgDgtfhCZNQOKF/VRZiBNNWlM7Nk6F5vR+KZ0SASWi9gHUHlG09OoBekevZjBxNUzBmULkvbvJF/HPEZULRPx18Ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KFaOhWW9zPufbTciE65+8lIOeBBQt/9kaT0gzPDtn7Q=; b=HNvFqmdKEMc9t/iao3yRhXZjFtviaWuzM6v5fATKAJcGVsulWEMpJykjX81jyf9xkPNYylRmltO1Fz3AVy4BEPaxSbgU1DNcEyhp+8DgQZudzltTz6S2jnRrlgwxrx/J4b8BkqreYHOZN4ffowbtr7bjBn7uwDBoyzVSo/JNnVYTHL+IWqFSEvHPt4OqdizWJi8y7uZlchuGqNlW+jUWBoYSkVQuLFmK+jDFj7bNAC4fFJJVGheMzLKYoFcu5RgAGlomWFLLu/9z9LZXGjEfwEgjviWRoVTVzixOjj1JQHaZtDNhtkrmCXPHg2hNi5bmc+Tlh3SoQfq85KVwUNekfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KFaOhWW9zPufbTciE65+8lIOeBBQt/9kaT0gzPDtn7Q=; b=D5Bs5K9wJxHwCEKgiMT3Z9un1tEQ/cGubFHlJU+/SN9DQ/slhTbCZ+7LuoZSry+WxWpqIhBaoyoIuaKnSE5bpXASAFzI5XxXdckYINvUVOpYO/RRTz5FOAKrwSgjT5do/ww7/9FbHz7C0PvajuHIReZWJi06/ubNMKcXlreNchQ= Received: from CY4PR1101MB2279.namprd11.prod.outlook.com (10.172.75.137) by CY4PR1101MB2296.namprd11.prod.outlook.com (10.172.77.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.23; Fri, 1 Nov 2019 13:27:49 +0000 Received: from CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab]) by CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab%10]) with mapi id 15.20.2387.030; Fri, 1 Nov 2019 13:27:49 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: Ole Troan , "v6ops@ietf.org" Thread-Topic: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) Thread-Index: AQHVj3tMtRKWxZ0q/E2E0DD0Qyz586d1wYiAgAA6nACAACb0iIAABBeAgAACf4CAAALRAIAAEiaAgAAAWoCAAAE7gIAAAsSAgAAF44CAAAICsIAAA58A//+/xwA= Date: Fri, 1 Nov 2019 13:27:49 +0000 Message-ID: References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org> <806C343D-1C75-43A7-81F3-14DE03F327B1@fugue.com> In-Reply-To: <806C343D-1C75-43A7-81F3-14DE03F327B1@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d1e04ec-a97d-47ce-51e6-08d75ecf4a7f x-ms-traffictypediagnostic: CY4PR1101MB2296: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(39860400002)(366004)(136003)(199004)(189003)(76176011)(236005)(11346002)(54896002)(446003)(33656002)(476003)(14444005)(6916009)(2616005)(6486002)(53546011)(486006)(14454004)(6436002)(6506007)(6306002)(256004)(478600001)(99286004)(6512007)(36756003)(186003)(71190400001)(7736002)(229853002)(8936002)(6116002)(66066001)(71200400001)(2906002)(6246003)(91956017)(3846002)(26005)(8676002)(102836004)(81166006)(54906003)(81156014)(316002)(4326008)(66476007)(66946007)(64756008)(66446008)(5660300002)(76116006)(86362001)(58126008)(66556008)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2296; H:CY4PR1101MB2279.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2k61yi3eFHrp9T+291T14X7fZ5qHDCTJr9iLPuS+9UoYQXvX+EdZi2myf50Zhs2njcdYF+5hjGMBvBlKwfcEe57cTD7Vkl8W9Nzrj41dqw9txuTXqTYNqf3kaAdCAStrtY29e8/syV0Bkv4nfOUv3xSborVYS5dFPk6nFmpe9I9Kxnxudut/CDLd7KGeoCGpuG6uMj3wF3moJHatELcs+yVyeIdbL7cSMGTSN7+HcwJeWR1F9Ll1me8V1j2sEIF38n2dsK13YOwMjlfv1fmmeMfBjHOC4pk+oS6M0AboglKNDAq3rvK7tXBBNepsj1ygEHeOJcuRRivJ+R5nsW4GOpfyRdKTUL1wjNbDasgDZBbZujpM7pmkRyOA+zrFhvCwgG3SMBDyzdqWBcWyjK6jqX9yyAh8w5JV86hRBQ//h6AhxkXwub+aoa47tXqvhQD8 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_EB8656057EE4495995B3A3C55C847068ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9d1e04ec-a97d-47ce-51e6-08d75ecf4a7f X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 13:27:49.5354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YZl7Ok6s2JnJNeWQguOMtGUa8VjWzUv1hfCRKpVMzgqjnFQJq6mu3gcz55XgxUWi X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2296 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:27:55 -0000 --_000_EB8656057EE4495995B3A3C55C847068ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm90aCAodW50aWwgdGhlIG9sZCBoYXMgZXhwaXJlZCkuDQoNClRoZXJlIG1pZ2h0IGJlIGEgY29u ZGl0aW9uIHRoYXQgb24gYSBTb2xpY2l0IHdlIG1heSBub3Qgc2VuZCB0aGUgZXhwaXJpbmcgb25l IGFmdGVyIHRoZSBwcmVmZXJyZWQgbGlmZXRpbWUgaGFzIGVsYXBzZWQg4oCTIGJ1dCBpdCB3YXMg YSB3aGlsZSBhZ28gdGhhdCB0aGlzIHdhcyBpbXBsZW1lbnRlZCBhbmQgbmVlZCB0byBjaGVjayB0 aGUgZGV0YWlscy4gSWYgSSByZWNhbGwgY29ycmVjdGx5LCBJIHRoaW5rIHdhcyBkb25lIGJlY2F1 c2UgaW4gdGhlIGVhcmx5IGRheXMgb2YgREhDUHY2IHRoZXJlIHdlcmUgY2xpZW50cyB0aGF0IHdv dWxkIG5vdCBoYW5kbGUgbXVsdGlwbGUgSUFQUkVGSVhlcyBwcm9wZXJseSDigJMgZm9yIGV4YW1w bGUsIHRoZXkgd291bGQgb25seSB1c2UgdGhlIGZpcnN0IG9yIGZhaWwuIEFuZCwgaWYgZG9uZSwg dGhhdCBtaWdodCBoYW1wZXIgcmVtb3ZhbCBvZiB0aGUgb2xkIHByZWZpeCBpbiBkZXZpY2VzIGJl aGluZCB0aGUgQ1BFIGFzIHRoZSBDUEUgd291bGQgbm90IGxlYXJuIG9mIHRoaXMgcHJlZml4IG9u IGEgcG93ZXIgY3ljbGUuDQoNCg0KICAqICAgQmVybmllDQoNCkZyb206IFRlZCBMZW1vbiA8bWVs bG9uQGZ1Z3VlLmNvbT4NCkRhdGU6IEZyaWRheSwgTm92ZW1iZXIgMSwgMjAxOSBhdCA5OjE4IEFN DQpUbzogQmVybmllIFZvbHogPHZvbHpAY2lzY28uY29tPg0KQ2M6IE9sZSBUcm9hbiA8b3Ryb2Fu QGVtcGxveWVlcy5vcmc+LCAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbdjZvcHNdIEEgYnJva2VuIHByb21pc2UgLSAiWW91IHNhaWQgUEQgUHJlZml4IFZh bGlkIExpZmV0aW1lIGlzIGdvaW5nIHRvIGJlIFgiIChSZTogU0xBQUMgcmVudW06IFByb2JsZW0g U3RhdGVtZW50ICYgT3BlcmF0aW9uYWwgd29ya2Fyb3VuZHMpDQoNCk9uIE5vdiAxLCAyMDE5LCBh dCA5OjA5IEFNLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPG1haWx0bzp2b2x6 QGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhhdOKAmXMgbm90IHRydWUuIFRoZSBzZXJ2ZXIgSSB3b3Jr IG9uIGFsbG93cyB5b3UgdG8gc3BlY2lmeSBhbiBleHBpcmF0aW9uIHRpbWUgZm9yIGEgcHJlZml4 LCBhbmQgd2Ugd2lsbCBhdXRvbWF0aWNhbGx5IGRlY3JlYXNlIGxpZmV0aW1lcyB0byBob25vciB0 aGF0IHRpbWUgYW5kIGFsc28gc3RvcCB1c2luZyB0aGUgcHJlZml4IGZvciBuZXcgbGVhc2VzLiBU aGlzIGFsbG93cyB5b3UgdG8gaW50cm9kdWNlIGEgbmV3IHByZWZpeCB0byBiZSB1c2VkIGZvciBw cmVmaXggZGVsZWdhdGlvbiBmb3IgZ3JhY2VmdWwgcmVudW1iZXJpbmcuIE9uY2UgdGhlIGV4cGly YXRpb24gdGltZSBoYXMgcGFzc2VkLCB5b3UgY2FuIHJlbW92ZSB0aGUgb2xkIHByZWZpeCBhcyB0 aGVyZSBzaG91bGQgbm8gbG9uZ2VyIGJlIGFueSBhY3RpdmUgbGVhc2VzLiBXZSBpbnRyb2R1Y2Vk IHRoaXMgd2l0aCB0aGUgZmlyc3QgcmVsZWFzZSB3aXRoIERIQ1B2NiBzdXBwb3J0IGEgbG9uZyB0 aW1lIGFnby4NCg0KRG9lcyBpdCBzZW5kIGJvdGggcHJlZml4ZXMgdG8gdGhlIENQRSwgb3IganVz dCB0aGUgbmV3IG9uZT8NCg0K --_000_EB8656057EE4495995B3A3C55C847068ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5NTA2MzA3Nzg7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjUyMjY5MzY2IC0xMTU1MjEzNzI4 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Cb3RoICh1bnRpbCB0aGUgb2xkIGhhcyBleHBpcmVk KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgbWlnaHQgYmUgYSBjb25kaXRpb24gdGhh dCBvbiBhIFNvbGljaXQgd2UgbWF5IG5vdCBzZW5kIHRoZSBleHBpcmluZyBvbmUgYWZ0ZXIgdGhl IHByZWZlcnJlZCBsaWZldGltZSBoYXMgZWxhcHNlZCDigJMgYnV0IGl0IHdhcyBhIHdoaWxlIGFn byB0aGF0IHRoaXMgd2FzIGltcGxlbWVudGVkIGFuZCBuZWVkIHRvIGNoZWNrIHRoZSBkZXRhaWxz LiBJZiBJIHJlY2FsbCBjb3JyZWN0bHksIEkgdGhpbmsgd2FzDQogZG9uZSBiZWNhdXNlIGluIHRo ZSBlYXJseSBkYXlzIG9mIERIQ1B2NiB0aGVyZSB3ZXJlIGNsaWVudHMgdGhhdCB3b3VsZCBub3Qg aGFuZGxlIG11bHRpcGxlIElBUFJFRklYZXMgcHJvcGVybHkg4oCTIGZvciBleGFtcGxlLCB0aGV5 IHdvdWxkIG9ubHkgdXNlIHRoZSBmaXJzdCBvciBmYWlsLiBBbmQsIGlmIGRvbmUsIHRoYXQgbWln aHQgaGFtcGVyIHJlbW92YWwgb2YgdGhlIG9sZCBwcmVmaXggaW4gZGV2aWNlcyBiZWhpbmQgdGhl IENQRSBhcyB0aGUNCiBDUEUgd291bGQgbm90IGxlYXJuIG9mIHRoaXMgcHJlZml4IG9uIGEgcG93 ZXIgY3ljbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj5CZXJuaWU8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPlRlZCBMZW1vbiAmbHQ7bWVsbG9uQGZ1Z3VlLmNvbSZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+RnJpZGF5LCBOb3ZlbWJlciAxLCAyMDE5IGF0IDk6MTggQU08YnI+DQo8Yj5U bzogPC9iPkJlcm5pZSBWb2x6ICZsdDt2b2x6QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9i Pk9sZSBUcm9hbiAmbHQ7b3Ryb2FuQGVtcGxveWVlcy5vcmcmZ3Q7LCAmcXVvdDt2Nm9wc0BpZXRm Lm9yZyZxdW90OyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbdjZvcHNdIEEgYnJva2VuIHByb21pc2UgLSAmcXVvdDtZb3Ugc2FpZCBQRCBQcmVmaXggVmFs aWQgTGlmZXRpbWUgaXMgZ29pbmcgdG8gYmUgWCZxdW90OyAoUmU6IFNMQUFDIHJlbnVtOiBQcm9i bGVtIFN0YXRlbWVudCAmYW1wOyBPcGVyYXRpb25hbCB3b3JrYXJvdW5kcyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDEsIDIwMTks IGF0IDk6MDkgQU0sIEJlcm5pZSBWb2x6ICh2b2x6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZvbHpA Y2lzY28uY29tIj52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdOKAmXMgbm90IHRydWUu IFRoZSBzZXJ2ZXIgSSB3b3JrIG9uIGFsbG93cyB5b3UgdG8gc3BlY2lmeSBhbiBleHBpcmF0aW9u IHRpbWUgZm9yIGEgcHJlZml4LCBhbmQgd2Ugd2lsbCBhdXRvbWF0aWNhbGx5IGRlY3JlYXNlIGxp ZmV0aW1lcyB0byBob25vciB0aGF0IHRpbWUgYW5kIGFsc28gc3RvcCB1c2luZyB0aGUgcHJlZml4 IGZvciBuZXcgbGVhc2VzLiBUaGlzIGFsbG93cyB5b3UgdG8gaW50cm9kdWNlIGEgbmV3DQogcHJl Zml4IHRvIGJlIHVzZWQgZm9yIHByZWZpeCBkZWxlZ2F0aW9uIGZvciBncmFjZWZ1bCByZW51bWJl cmluZy4gT25jZSB0aGUgZXhwaXJhdGlvbiB0aW1lIGhhcyBwYXNzZWQsIHlvdSBjYW4gcmVtb3Zl IHRoZSBvbGQgcHJlZml4IGFzIHRoZXJlIHNob3VsZCBubyBsb25nZXIgYmUgYW55IGFjdGl2ZSBs ZWFzZXMuIFdlIGludHJvZHVjZWQgdGhpcyB3aXRoIHRoZSBmaXJzdCByZWxlYXNlIHdpdGggREhD UHY2IHN1cHBvcnQgYSBsb25nIHRpbWUgYWdvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgaXQgc2VuZCBib3RoIHByZWZp eGVzIHRvIHRoZSBDUEUsIG9yIGp1c3QgdGhlIG5ldyBvbmU/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EB8656057EE4495995B3A3C55C847068ciscocom_-- From nobody Fri Nov 1 06:33:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5412022A for ; Fri, 1 Nov 2019 06:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 rEeSs7HACQIu for ; Fri, 1 Nov 2019 06:32:59 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B664012013A for ; Fri, 1 Nov 2019 06:32:59 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id o11so7875715qtr.11 for ; Fri, 01 Nov 2019 06:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gSxU3RA37biRfSIXriVt+MX5VciAyPxUtovf1xh/h1U=; b=yHMxiZSiRJVkixEYxq0hA9DQljH/Tg43z1BvHgIyN4qS/Rk4Fc6v4m6h2AfmRJIJmw +aAtelFWCyW7gw1kVDszXkHsQ5Dw/bgZLoFaCSZi1+U2ghjMPUjdStmIp19Fc9/LEs4V MDPIjFPW+wvWodZiPyWPgxDsLWgiVZ2C5/ExTf99954WtQoLytQKExZBbzDAGQB8jXuT pzOyYJhwb6OAuEEVetB+cWFgFUl0DjxDOLic0Y+EdN8MH6bWhI0599Dcyhy+PKT3cyky MwbzrptJlwYYQb/w7rkq6j+/rEq1T0HDni0oeZRyDn23Vv1ql90KFhp7sEPENMJw+U+U Zwng== 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=gSxU3RA37biRfSIXriVt+MX5VciAyPxUtovf1xh/h1U=; b=hP+pFuFxBK++wyKaDQ29bkwRi1ZlzZ/i6/TaC88/50cnOTbNjpLtUV4YKfltAG9OCi 6VF0jsF133/LBCjZEPvENJugpP6p7bgbGYEz1fDge/QylKYe6HNwI5EczO5kkj+TA2Of cIWd6S2nWqNh/HqL9Dlo51HDXZfe1A+CjAOatvErpSimFy0AKaUrl/4L6NTtirqphzJs T1w1TNWk9dcVkv7TcvLNqn9UJk8RO9NnZL6nuU39bqOjYSoo/IDXRsFn7XfOchIXnZoz nUoZtI9EbKu9fjINfsSrYLpgwNnBg9COWxQS/3Cm0jqntFzL7Mn2sQSTSIFTip/ZzajV 85uA== X-Gm-Message-State: APjAAAXDPl9YKd7K3/8Qy+hV29SXZeGlifJMJbuBU5pmBywHC06j0r/Z OLPlKlQIyTsWOSPGoSXkvox/Nrpq/NYDlw== X-Google-Smtp-Source: APXvYqxTuQF4edf/cMJW+3CwAOI2eYnGVeVyalARuinOaZTv2k98AH5ZF9bJZnTKtCtTpJzM458vNw== X-Received: by 2002:ac8:36c4:: with SMTP id b4mr1155967qtc.149.1572615178531; Fri, 01 Nov 2019 06:32:58 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:186c:1ff3:ea8d:a057? ([2601:18b:300:36ee:186c:1ff3:ea8d:a057]) by smtp.gmail.com with ESMTPSA id w131sm4385724qka.85.2019.11.01.06.32.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 06:32:57 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BE4D0862-9F28-49F1-BE03-34EEF60F0E3E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 1 Nov 2019 09:32:55 -0400 In-Reply-To: Cc: Ole Troan , "v6ops@ietf.org" To: "Bernie Volz (volz)" References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org> <806C343D-1C75-43A7-81F3-14DE03F327B1@fugue.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:33:03 -0000 --Apple-Mail=_BE4D0862-9F28-49F1-BE03-34EEF60F0E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 9:27 AM, Bernie Volz (volz) wrote: > Both (until the old has expired). > =20 > There might be a condition that on a Solicit we may not send the = expiring one after the preferred lifetime has elapsed =E2=80=93 but it = was a while ago that this was implemented and need to check the details. = If I recall correctly, I think was done because in the early days of = DHCPv6 there were clients that would not handle multiple IAPREFIXes = properly =E2=80=93 for example, they would only use the first or fail. = And, if done, that might hamper removal of the old prefix in devices = behind the CPE as the CPE would not learn of this prefix on a power = cycle. Is it required that the CPE request both prefixes, or are they sent = regardless? Is the deprecated prefix sent with a preferred lifetime of = zero? I think this was the question we were discussing on the DHC = mailing list yesterday, and I thought you said that this would be new = behavior. What am I missing? --Apple-Mail=_BE4D0862-9F28-49F1-BE03-34EEF60F0E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 9:27 AM, Bernie Volz (volz) <volz@cisco.com> = wrote:
Both (until the old has expired).
 
There = might be a condition that on a Solicit we may not send the expiring one = after the preferred lifetime has elapsed =E2=80=93 but it was a while = ago that this was implemented and need to check the details. If I recall = correctly, I think was done because in the early days of DHCPv6 there = were clients that would not handle multiple IAPREFIXes properly =E2=80=93 = for example, they would only use the first or fail. And, if done, that = might hamper removal of the old prefix in devices behind the CPE as the = CPE would not learn of this prefix on a power = cycle.

Is = it required that the CPE request both prefixes, or are they sent = regardless?   Is the deprecated prefix sent with a preferred = lifetime of zero?   I think this was the question we were = discussing on the DHC mailing list yesterday, and I thought you said = that this would be new behavior.  What am I missing?

= --Apple-Mail=_BE4D0862-9F28-49F1-BE03-34EEF60F0E3E-- From nobody Fri Nov 1 06:39:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC64120142 for ; Fri, 1 Nov 2019 06:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=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 NAnJyj9Zgs-I for ; Fri, 1 Nov 2019 06:39:03 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0569712013A for ; Fri, 1 Nov 2019 06:39:03 -0700 (PDT) Received: from [IPv6:2a02:2121:280:6edf:11a4:ab34:580:9bbc] (unknown [IPv6:2a02:2121:280:6edf:11a4:ab34:580:9bbc]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 0FC774E11A42; Fri, 1 Nov 2019 13:39:01 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-2AE8114E-045A-46F4-BA13-EF3AF5F02C24 Content-Transfer-Encoding: 7bit From: Ole Troan Mime-Version: 1.0 (1.0) Date: Fri, 1 Nov 2019 14:38:58 +0100 Message-Id: References: Cc: Philip Homburg , v6ops@ietf.org In-Reply-To: To: Ted Lemon X-Mailer: iPhone Mail (17B5084a) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:39:04 -0000 --Apple-Mail-2AE8114E-045A-46F4-BA13-EF3AF5F02C24 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted, Ok. Thanks. I don=E2=80=99t think I have heard from anyone who thinks there=E2= =80=99s a gap with regards to pd and renumbering before. Or renumbering with= addresses for that matter. The main issue here seems that people want to do renumbering differently. Th= en we as a community have to figure out how harmful that is to the Internet.= Or what other changes would be required for that.=20 Cheers=20 Ole > On 1 Nov 2019, at 13:57, Ted Lemon wrote: >=20 > =EF=BB=BFOn Nov 1, 2019, at 8:36 AM, Ole Troan wrot= e: >> (4) is the definition of graceful renumbering. What makes you conclude "t= hen we just assume that people will do whatever they want"? >> (especially since your options 1-3 are exactly that, people do whatever t= hey want=E2=80=A6) >=20 > Okay, I missed a step (or five). We have specified what a renumbering pro= cess should ideally look like, without taking into account several likely op= erational circumstances. We have not specified in sufficient detail how ren= umbering works using DHCPv6 PD, e.g. in a home environment. Consequently, p= roviders do not have a viable way to follow our recommendations for how to r= enumber, and hence just do whatever they can think of, possibly without real= izing that there might be a better way to do it. Also, DHCP server vendors= in particular do not implement what we intended that they implement, becaus= e we never said explicitly that they should do so, not specified what a CPE s= hould expect in this situation. >=20 > Does that help? >=20 > FWIW, I was asked to consult with an operator who shall remain nameless ab= out how to solve this problem, and the solution I came up with relied on the= recommendations from RFC 4192. and further relied on DHCPv6 prefix delegati= on offering two prefixes, one valid and one preferred. Unfortunately I don=E2= =80=99t think this was ever implemented, but I still think it=E2=80=99s the r= ight thing to do; what I=E2=80=99m realizing from this conversation is that n= ot everybody saw this solution as obvious. Which I think is a problem. >=20 --Apple-Mail-2AE8114E-045A-46F4-BA13-EF3AF5F02C24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ted,

Ok. Thanks. I don=E2=80=99t think I have heard f= rom anyone who thinks there=E2=80=99s a gap with regards to pd and renumberi= ng before. Or renumbering with addresses for that matter.

The main issue here seems that people want to= do renumbering differently. Then we as a community have to figure out how h= armful that is to the Internet. Or what other changes would be required for t= hat. 

Cheers 
Ole

O= n 1 Nov 2019, at 13:57, Ted Lemon <mellon@fugue.com> wrote:

=EF=BB=BFOn Nov 1, 2= 019, at 8:36 AM, Ole Troan <otroan@employees.org> wrote:
(4) is the definition of graceful renumbering. W= hat makes you conclude "then we just assume that people will do whatever the= y want"?
(especially sinc= e your options 1-3 are exactly that, people do whatever they want=E2=80=A6)<= /span>

Okay, I missed a step (or five).  We have specified what a= renumbering process should ideally look like, without taking into account s= everal likely operational circumstances.  We have not specified in suff= icient detail how renumbering works using DHCPv6 PD, e.g. in a home environm= ent.  Consequently, providers do not have a viable way to follow our re= commendations for how to renumber, and hence just do whatever they can think= of, possibly without realizing that there might be a better way to do it. &= nbsp; Also, DHCP server vendors in particular do not implement what we inten= ded that they implement, because we never said explicitly that they should d= o so, not specified what a CPE should expect in this situation.
Does that help?

= FWIW, I was asked to consult with an operator who shall remain nameless abou= t how to solve this problem, and the solution I came up with relied on the r= ecommendations from RFC 4192. and further relied on DHCPv6 prefix delegation= offering two prefixes, one valid and one preferred.  Unfortunately I d= on=E2=80=99t think this was ever implemented, but I still think it=E2=80=99s= the right thing to do; what I=E2=80=99m realizing from this conversation is= that not everybody saw this solution as obvious.   Which I think is a p= roblem.

= --Apple-Mail-2AE8114E-045A-46F4-BA13-EF3AF5F02C24-- From nobody Fri Nov 1 06:41:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8C112013A for ; Fri, 1 Nov 2019 06:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 GCvv5em2AgZM for ; Fri, 1 Nov 2019 06:41:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D191200CE for ; Fri, 1 Nov 2019 06:41:47 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 C11DF868BE; Fri, 1 Nov 2019 14:41:44 +0100 (CET) To: Mark Smith , Philip Homburg Cc: v6ops list References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: Date: Fri, 1 Nov 2019 09:29:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:41:50 -0000 On 1/11/19 08:12, Mark Smith wrote: > > > On Fri, 1 Nov 2019, 21:42 Philip Homburg, > wrote: > > > > "Hope" doesn't make networks run properly. > > > > This isn't "Hope", this is breaking promises, and that does break > > networks. If you can't at least trust that promises are intended > > to be kept then you have no network at all... > > Maybe somebody can do a text analysis and show which promise is broken. > > The typical case is a CPE rebooting, requesting a prefix using > DHCPv6 and > getting a different prefix from before. > > > It shouldn't be. That's why clients have DHCP Unique Identifiers (DUIDs) > that should be persistent across client restarts (or CPE reboots). RFC7844 might lead to non-stable DUIDs. You might argue that that in some scenarios you wouldn't do this (non-portable CPEs), but in others (portable ones) you might. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 1 06:42:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFF9120850 for ; Fri, 1 Nov 2019 06:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 tKGsZjtRhbz6 for ; Fri, 1 Nov 2019 06:41:52 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347451200CE for ; Fri, 1 Nov 2019 06:41:52 -0700 (PDT) Received: from [192.168.1.36] (unknown [177.27.208.83]) (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 E5C9D868BE; Fri, 1 Nov 2019 14:41:49 +0100 (CET) To: IPv6 Operations From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <0ede0670-b815-6605-ec51-ee1b1cb3da1c@si6networks.com> Date: Fri, 1 Nov 2019 10:40:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Update on SLAAC renum I-Ds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:41:57 -0000 Folks, Based on the recent/ongoing discussion, I've done the following: * I have split all the CPE improvements into a stand-alone. So we now have the following I-Ds: + draft-gont-v6ops-slaac-renum: Problem statement and operational mitigations + draft-gont-v6ops-cpe-slaac-renum: Improvements to Customer Edge Routers. + draft-gont-6man-slaac-renum: Protocol update proposals (working on it right now) I believe the problem becomes more tractable/actionable this way, since we can agree, separately, on the problem statement, possible CPE improvements, and possible protocol updates/improvements. Some specific comments: + draft-gont-v6ops-slaac-renum: This version suggests a much longer VL, as suggested by Owen. And it also clarifies that the home network/cpe case is *one* of the possible flash-renumbering scenarios. + draft-gont-v6ops-cpe-slaac-renum: I still need to address some of the feedback received from Owen and Ted. Namely, evaluate to send A=0,L=0, instead of advertising 0 lifetimes, and go through other possible improvements for the CPE side. While there's certainly work to be done in these documents, I believe we are at a point where the group could make a decision on whether to pursue this effort. P.S.: Your feedback on the I-Ds will be welcome! 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 Fri Nov 1 06:44:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8826F12013A for ; Fri, 1 Nov 2019 06:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=MkldqpXK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ia5aCkNC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQZhZJkdD61U for ; Fri, 1 Nov 2019 06:44:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FDB4120130 for ; Fri, 1 Nov 2019 06:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13101; q=dns/txt; s=iport; t=1572615843; x=1573825443; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r1kTbm15Wj6WXayxDwFSlYLqx7X6Kauhol2OLxPg//o=; b=MkldqpXKN2jAE7jbpwPbhEyWk12ODqR3al37ovpp4/su23Q9vgbjrLBY AMQZhJyo6r6OHZHjtdnWj/F340ZN+QjyL+oVj0J9Q6XFfS9t0mEI7ROlt drHrxZamgYSmdlXD5464WLKpNNiwlQuiAhxRoC6DZgH+Nw4pAs6w6viwI g=; IronPort-PHdr: =?us-ascii?q?9a23=3AsT1ZrxwFZjjQoLLXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRGN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A+GsHbIQKUh?= =?us-ascii?q?YEjcsMmAl1HsmBG2XwLeXhaGoxG8ERHFI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAAAkNrxd/4sNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgWwBAQEBAQELAYEbL1AFbFggBAsqCoQ?= =?us-ascii?q?eg0YDinSCXpMbhGGCUgNUCQEBAQwBAS0CAQGEQAIXg2QkNwYOAgMLAQEEAQE?= =?us-ascii?q?BAgEFBG2FNwyFUQEBAQECARIRHQEBLAsBBAsCAQgOAwMBAiQEAwICAjAUCQg?= =?us-ascii?q?CBA4FGweDAAGBeU0DDiABpx8CgTiIYHWBMoJ+AQEFhRcYghcJgTYBjBAYgX+?= =?us-ascii?q?BOB+CFwcuPoQpBjYWgloygiyNBQYIgmoahSKCO5UUbgqCJJU1G5llhFeGE50?= =?us-ascii?q?qAgQCBAUCDgEBBYFoI4FYcBU7KgGCQVARFIMGDBcVgzuKU3SBKIw2AS9eAQE?= X-IronPort-AV: E=Sophos;i="5.68,255,1569283200"; d="scan'208,217";a="657939315" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 13:44:02 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1Di28N005560 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 13:44:02 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 08:44:01 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 08:44:01 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 08:44:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XlSngJrDIQQWQUMYt2ezu9VVe1jzOeEkRWmyY2mP7rflOFx2cdk3Kv2MZbiDuHBvUZZowNg4w7Gptj8PKIqXZzFJnhtZGA8xLhqB3FAF3YPU6KjCzmVblPXufgJu1RIBJRHcg/8X13pn9McwtaGIl7+oqELEAcE0SiimkrI1CsRidVxU04+v7nFn/FK9E+OkbtSMTr/c/qev+Wcz4HBWJJffxK5Qn/0ooHLR5wIzgue8ru5whtDmG94+URGVZ72i+gcI14n2ESCC7ydRj9NR+VcWby+BvhEkM7su8gUzwRByQ1wPorvgyvKJFsZW/FWmsyoNl37NPII5+lC79J0WDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r1kTbm15Wj6WXayxDwFSlYLqx7X6Kauhol2OLxPg//o=; b=TQb5gR4nL5Y4kYQuc0A9HpPaesNVhUAJuwAX3Pde0hNiuY1hdUtCrBEZj9wX4wxrkwSBnb+mWmZ7qUbRKzWGLHCFRQ0PH7p0tv6CDduHMnf8KzWkcloL1BZLL+U3JuIcnEYJYK52X7qdbg+wYOySzhrzvXM615qBAVuSGkFr1QJL51GEmXF92tsq0aoYI2X5FlSkmBZLhDfqPCmJFBZZMvVEt7DLCGfY1XYQ9pGGZ7NCtegHlRHv/VtQVxENrUlU7tDqU6U9z7O5VG4c5q9xkYnsPBAqmUGf17wJFlqROXNK8G8nyX7BLQqWkwefYsCKXPH8nxlNA5t3FIJHesvwGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r1kTbm15Wj6WXayxDwFSlYLqx7X6Kauhol2OLxPg//o=; b=Ia5aCkNC6S2SU5VzzBkQF8Kl+XTPT12ynpZ5hbeurE/0UuNbOGVNUbx8kJci7fbH0o4ccR7YTc3kqHfh8KNsB7mnx1GbK9g3Iuu8++r/a2BYWXJFfNk/ZRY0G4LJgw+oZx4DND5enhQrtiy1kk3L2qFXsZbKjPyfTZLplBtQxiQ= Received: from CY4PR1101MB2279.namprd11.prod.outlook.com (10.172.75.137) by CY4PR1101MB2085.namprd11.prod.outlook.com (10.174.52.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.20; Fri, 1 Nov 2019 13:43:59 +0000 Received: from CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab]) by CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab%10]) with mapi id 15.20.2387.030; Fri, 1 Nov 2019 13:43:59 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: Ole Troan , "v6ops@ietf.org" Thread-Topic: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) Thread-Index: AQHVj3tMtRKWxZ0q/E2E0DD0Qyz586d1wYiAgAA6nACAACb0iIAABBeAgAACf4CAAALRAIAAEiaAgAAAWoCAAAE7gIAAAsSAgAAF44CAAAICsIAAA58A//+/xwCAAER8gP//wAeA Date: Fri, 1 Nov 2019 13:43:59 +0000 Message-ID: References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org> <806C343D-1C75-43A7-81F3-14DE03F327B1@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8623b6c3-403d-4aa2-572f-08d75ed18c8e x-ms-traffictypediagnostic: CY4PR1101MB2085: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(396003)(376002)(136003)(189003)(199004)(54906003)(66476007)(54896002)(81156014)(6512007)(6506007)(76116006)(102836004)(76176011)(66066001)(66946007)(26005)(186003)(6246003)(229853002)(36756003)(5660300002)(8936002)(6116002)(236005)(4326008)(99286004)(6486002)(7736002)(64756008)(3846002)(66446008)(6436002)(66556008)(91956017)(86362001)(81166006)(58126008)(53546011)(6306002)(25786009)(256004)(446003)(33656002)(6916009)(2906002)(8676002)(71190400001)(2616005)(476003)(316002)(14444005)(14454004)(71200400001)(486006)(478600001)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2085; H:CY4PR1101MB2279.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eARBncrhP9rUE89ABB8guXzH0KObNcwAZnpz7LJSqpO7iEUSUqH/rLdbe6W16i0CUzL19cL04gvRKnMhAWeLyCiyVi0zxBTVetyVh2ZCAJY+vlPqocfq70LlTpW9GEV/f/LWHvi4MrPED1n3PucxO1XpHGWQ6R7ktzkUwZQP/4bNMDFVjovwxTSj6GqSXIx569JxmogbOAsGto18Pv2Z0E4QfavbGpjrmiVWcGyHRvkKAW8zmbt6ihHzpWwGb9G3aDH850I8gx8njDrjMuQQqFh2e8SymTlDZ4ZxE9xH7hc53jFI0MCU8Yqwm8JwOdhgdct+I46cnoTU2W4SCtYHlSe3xnRZmjrcH1upJ+QGtv6gDUKe2xln7gaBU+IjdVddRP4H/nQZrlpfB5+VWDCL9CtWc3BvGZdT0tRvhhIB5h9LzsvJ7S34RMbwWXhnIQyW x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_B1D7E74E1EF54A6489F8CF1CBD54963Eciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8623b6c3-403d-4aa2-572f-08d75ed18c8e X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 13:43:59.4409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: D3qRb9PDO9PSKW1SqHrU3h3LvIaKFF9b3wInKfZgct6+Co2dw3YAglX8nOHHXftx X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2085 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:44:06 -0000 --_000_B1D7E74E1EF54A6489F8CF1CBD54963Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBhbmQgSSB0aG91Z2h0IHlvdSBzYWlkIHRoYXQgdGhpcyB3b3VsZCBiZSBuZXcgYmVoYXZpb3Iu DQoNCkkgdGhpbmsgYXQgcHJlc2VudCB0aGUgZXhhY3QgYmVoYXZpb3IgaXMgbm90IHNwZWNpZmll ZCBpbiBSRkM4NDE1IGFuZCBpdCBpcyBsZWZ0IHVwIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBhcyB0 byBob3cgdGhleSBoYW5kbGUgdGhlc2Ugc2l0dWF0aW9ucy4NCg0KVGhlIHBvaW50IG9mIGRvY3Vt ZW50aW5nIHRoaXMgd2FzIHRvIGFzc3VyZSB0aGF0IHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVybnMg YWxsIG9mIHRoZSBwcmVmaXhlcyAoaW4gUmVwbHkgbWVzc2FnZXMpIGFzIGxvbmcgYXMgdGhlIGRl bGVnYXRlZCBwcmVmaXggaGFzIGEgbm9uLXplcm8gdmFsaWQgbGlmZXRpbWVzLiBUaGF0IHNob3Vs ZCBoZWxwIOKAnGZpeOKAnSB0aGUgb3BlcmF0aW9uYWwgaXNzdWVzIHdpdGggcmVudW1iZXJpbmcg YW5kIENQRSByZWJvb3RzIOKAkyBidXQgb2YgY291cnNlIG9ubHkgY292ZXJzIHRoZSBjYXNlIHdo ZXJlIHRoZSBzZXJ2ZXIgc3RpbGwgaGFzIGEgcmVjb3JkIG9mIHRoYXQgcHJlZml4IGRlbGVnYXRp b24gdGhhdCBpdCBpcyBhYmxlIHRvIGxvY2F0ZS4gVGh1cywgaXQgaXMgbm90IGEgY29tcGxldGUg c29sdXRpb24gdG8gdGhpcyBpc3N1ZSAodGhhdCBkb2VzIHJlcXVpcmUgdGhlIENQRSB0byBzdG9y ZSB0aGlzIGluZm9ybWF0aW9uKS4NCg0KDQogICogICBCZXJuaWUNCg0KRnJvbTogVGVkIExlbW9u IDxtZWxsb25AZnVndWUuY29tPg0KRGF0ZTogRnJpZGF5LCBOb3ZlbWJlciAxLCAyMDE5IGF0IDk6 MzMgQU0NClRvOiBCZXJuaWUgVm9seiA8dm9sekBjaXNjby5jb20+DQpDYzogT2xlIFRyb2FuIDxv dHJvYW5AZW1wbG95ZWVzLm9yZz4sICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFt2Nm9wc10gQSBicm9rZW4gcHJvbWlzZSAtICJZb3Ugc2FpZCBQRCBQcmVm aXggVmFsaWQgTGlmZXRpbWUgaXMgZ29pbmcgdG8gYmUgWCIgKFJlOiBTTEFBQyByZW51bTogUHJv YmxlbSBTdGF0ZW1lbnQgJiBPcGVyYXRpb25hbCB3b3JrYXJvdW5kcykNCg0KT24gTm92IDEsIDIw MTksIGF0IDk6MjcgQU0sIEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb208bWFpbHRv OnZvbHpAY2lzY28uY29tPj4gd3JvdGU6DQpCb3RoICh1bnRpbCB0aGUgb2xkIGhhcyBleHBpcmVk KS4NCg0KVGhlcmUgbWlnaHQgYmUgYSBjb25kaXRpb24gdGhhdCBvbiBhIFNvbGljaXQgd2UgbWF5 IG5vdCBzZW5kIHRoZSBleHBpcmluZyBvbmUgYWZ0ZXIgdGhlIHByZWZlcnJlZCBsaWZldGltZSBo YXMgZWxhcHNlZCDigJMgYnV0IGl0IHdhcyBhIHdoaWxlIGFnbyB0aGF0IHRoaXMgd2FzIGltcGxl bWVudGVkIGFuZCBuZWVkIHRvIGNoZWNrIHRoZSBkZXRhaWxzLiBJZiBJIHJlY2FsbCBjb3JyZWN0 bHksIEkgdGhpbmsgd2FzIGRvbmUgYmVjYXVzZSBpbiB0aGUgZWFybHkgZGF5cyBvZiBESENQdjYg dGhlcmUgd2VyZSBjbGllbnRzIHRoYXQgd291bGQgbm90IGhhbmRsZSBtdWx0aXBsZSBJQVBSRUZJ WGVzIHByb3Blcmx5IOKAkyBmb3IgZXhhbXBsZSwgdGhleSB3b3VsZCBvbmx5IHVzZSB0aGUgZmly c3Qgb3IgZmFpbC4gQW5kLCBpZiBkb25lLCB0aGF0IG1pZ2h0IGhhbXBlciByZW1vdmFsIG9mIHRo ZSBvbGQgcHJlZml4IGluIGRldmljZXMgYmVoaW5kIHRoZSBDUEUgYXMgdGhlIENQRSB3b3VsZCBu b3QgbGVhcm4gb2YgdGhpcyBwcmVmaXggb24gYSBwb3dlciBjeWNsZS4NCg0KSXMgaXQgcmVxdWly ZWQgdGhhdCB0aGUgQ1BFIHJlcXVlc3QgYm90aCBwcmVmaXhlcywgb3IgYXJlIHRoZXkgc2VudCBy ZWdhcmRsZXNzPyAgIElzIHRoZSBkZXByZWNhdGVkIHByZWZpeCBzZW50IHdpdGggYSBwcmVmZXJy ZWQgbGlmZXRpbWUgb2YgemVybz8gICBJIHRoaW5rIHRoaXMgd2FzIHRoZSBxdWVzdGlvbiB3ZSB3 ZXJlIGRpc2N1c3Npbmcgb24gdGhlIERIQyBtYWlsaW5nIGxpc3QgeWVzdGVyZGF5LCBhbmQgSSB0 aG91Z2h0IHlvdSBzYWlkIHRoYXQgdGhpcyB3b3VsZCBiZSBuZXcgYmVoYXZpb3IuICBXaGF0IGFt IEkgbWlzc2luZz8NCg0K --_000_B1D7E74E1EF54A6489F8CF1CBD54963Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTAzNTIzODUyOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzg4ODQ2MTQyIC02OTg4MzYyNjAg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IGFuZCBJIHRob3VnaHQgeW91 IHNhaWQgdGhhdCB0aGlzIHdvdWxkIGJlIG5ldyBiZWhhdmlvci4gJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdGhpbmsgYXQgcHJlc2VudCB0aGUgZXhhY3QgYmVoYXZpb3IgaXMgbm90 IHNwZWNpZmllZCBpbiBSRkM4NDE1IGFuZCBpdCBpcyBsZWZ0IHVwIHRvIHRoZSBpbXBsZW1lbnRh dGlvbiBhcyB0byBob3cgdGhleSBoYW5kbGUgdGhlc2Ugc2l0dWF0aW9ucy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHBvaW50IG9mIGRvY3VtZW50aW5nIHRoaXMgd2FzIHRvIGFzc3VyZSB0 aGF0IHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVybnMgYWxsIG9mIHRoZSBwcmVmaXhlcyAoaW4gUmVw bHkgbWVzc2FnZXMpIGFzIGxvbmcgYXMgdGhlIGRlbGVnYXRlZCBwcmVmaXggaGFzIGEgbm9uLXpl cm8gdmFsaWQgbGlmZXRpbWVzLiBUaGF0IHNob3VsZCBoZWxwIOKAnGZpeOKAnSB0aGUgb3BlcmF0 aW9uYWwgaXNzdWVzIHdpdGggcmVudW1iZXJpbmcNCiBhbmQgQ1BFIHJlYm9vdHMg4oCTIGJ1dCBv ZiBjb3Vyc2Ugb25seSBjb3ZlcnMgdGhlIGNhc2Ugd2hlcmUgdGhlIHNlcnZlciBzdGlsbCBoYXMg YSByZWNvcmQgb2YgdGhhdCBwcmVmaXggZGVsZWdhdGlvbiB0aGF0IGl0IGlzIGFibGUgdG8gbG9j YXRlLiBUaHVzLCBpdCBpcyBub3QgYSBjb21wbGV0ZSBzb2x1dGlvbiB0byB0aGlzIGlzc3VlICh0 aGF0IGRvZXMgcmVxdWlyZSB0aGUgQ1BFIHRvIHN0b3JlIHRoaXMgaW5mb3JtYXRpb24pLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+QmVybmllPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5UZWQgTGVtb24gJmx0O21lbGxvbkBmdWd1ZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZy aWRheSwgTm92ZW1iZXIgMSwgMjAxOSBhdCA5OjMzIEFNPGJyPg0KPGI+VG86IDwvYj5CZXJuaWUg Vm9seiAmbHQ7dm9sekBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5PbGUgVHJvYW4gJmx0 O290cm9hbkBlbXBsb3llZXMub3JnJmd0OywgJnF1b3Q7djZvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0 O3Y2b3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3Y2b3BzXSBBIGJy b2tlbiBwcm9taXNlIC0gJnF1b3Q7WW91IHNhaWQgUEQgUHJlZml4IFZhbGlkIExpZmV0aW1lIGlz IGdvaW5nIHRvIGJlIFgmcXVvdDsgKFJlOiBTTEFBQyByZW51bTogUHJvYmxlbSBTdGF0ZW1lbnQg JmFtcDsgT3BlcmF0aW9uYWwgd29ya2Fyb3VuZHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAxLCAyMDE5LCBhdCA5OjI3IEFNLCBC ZXJuaWUgVm9seiAodm9seikgJmx0OzxhIGhyZWY9Im1haWx0bzp2b2x6QGNpc2NvLmNvbSI+dm9s ekBjaXNjby5jb208L2E+Jmd0OyB3cm90ZToNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Cb3RoICh1bnRpbCB0aGUgb2xkIGhhcyBl eHBpcmVkKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlcmUgbWlnaHQgYmUgYSBjb25kaXRpb24gdGhhdCBvbiBhIFNvbGljaXQgd2UgbWF5 IG5vdCBzZW5kIHRoZSBleHBpcmluZyBvbmUgYWZ0ZXIgdGhlIHByZWZlcnJlZCBsaWZldGltZSBo YXMgZWxhcHNlZCDigJMgYnV0IGl0IHdhcyBhIHdoaWxlIGFnbyB0aGF0IHRoaXMgd2FzIGltcGxl bWVudGVkIGFuZCBuZWVkIHRvIGNoZWNrIHRoZSBkZXRhaWxzLiBJZiBJIHJlY2FsbCBjb3JyZWN0 bHksIEkgdGhpbmsgd2FzDQogZG9uZSBiZWNhdXNlIGluIHRoZSBlYXJseSBkYXlzIG9mIERIQ1B2 NiB0aGVyZSB3ZXJlIGNsaWVudHMgdGhhdCB3b3VsZCBub3QgaGFuZGxlIG11bHRpcGxlIElBUFJF RklYZXMgcHJvcGVybHkg4oCTIGZvciBleGFtcGxlLCB0aGV5IHdvdWxkIG9ubHkgdXNlIHRoZSBm aXJzdCBvciBmYWlsLiBBbmQsIGlmIGRvbmUsIHRoYXQgbWlnaHQgaGFtcGVyIHJlbW92YWwgb2Yg dGhlIG9sZCBwcmVmaXggaW4gZGV2aWNlcyBiZWhpbmQgdGhlIENQRSBhcyB0aGUNCiBDUEUgd291 bGQgbm90IGxlYXJuIG9mIHRoaXMgcHJlZml4IG9uIGEgcG93ZXIgY3ljbGUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JcyBpdCByZXF1aXJlZCB0aGF0IHRoZSBDUEUgcmVxdWVzdCBib3RoIHByZWZpeGVzLCBvciBh cmUgdGhleSBzZW50IHJlZ2FyZGxlc3M/ICZuYnNwOyBJcyB0aGUgZGVwcmVjYXRlZCBwcmVmaXgg c2VudCB3aXRoIGEgcHJlZmVycmVkIGxpZmV0aW1lIG9mIHplcm8/ICZuYnNwOyBJIHRoaW5rIHRo aXMgd2FzIHRoZSBxdWVzdGlvbiB3ZSB3ZXJlIGRpc2N1c3Npbmcgb24gdGhlIERIQyBtYWlsaW5n IGxpc3QgeWVzdGVyZGF5LCBhbmQNCiBJIHRob3VnaHQgeW91IHNhaWQgdGhhdCB0aGlzIHdvdWxk IGJlIG5ldyBiZWhhdmlvci4gJm5ic3A7V2hhdCBhbSBJIG1pc3Npbmc/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B1D7E74E1EF54A6489F8CF1CBD54963Eciscocom_-- From nobody Fri Nov 1 06:51:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7D6120120 for ; Fri, 1 Nov 2019 06:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 SbzbFJPerZwq for ; Fri, 1 Nov 2019 06:51:13 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A96F12006E for ; Fri, 1 Nov 2019 06:51:13 -0700 (PDT) Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id B5B574E11A76; Fri, 1 Nov 2019 13:51:12 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 3B848213BB8B; Fri, 1 Nov 2019 14:51:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: <166A84EB-3F53-43D2-86AD-C1233DA45399@fugue.com> Date: Fri, 1 Nov 2019 14:51:09 +0100 Cc: Owen DeLong , Fernando Gont , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <5E77C00A-B390-4CC5-B6F5-EB3B0177AA33@employees.org> References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <166A84EB-3F53-43D2-86AD-C1233DA45399@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:51:15 -0000 Hi Ted, >> At the risk of straying off topic. There is no mechanism for = permissionless networking in IPv6. >> (which I think is a big gap) >=20 > Do you mean permissionless advertising of routes to new networks? If = so, I agree. It can be made to sort of work for limited cases, but = there=E2=80=99s no standardized way to make end-to-end connectivity work = between all networks using the various bits of protocol and practice = that we have at present. I would define it as: "Permission-less extensions of the network with new links (and by = implications new routers) are not supported." NPT66/NAT66 is the only alternative (talking network layer here). If we have permission then: - normal managed network. Just add new router and run routing protocol. = Manually managed addressing - HNCP (automated addressing and routing) - hierarchical DHCP PD (only works in single rooted DAG) - proxy ND (RFC recommending against) Cheers, Ole= From nobody Fri Nov 1 07:22:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7524712010C for ; Fri, 1 Nov 2019 07:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qntgPB254Nsb for ; Fri, 1 Nov 2019 07:21:56 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D80F1200E7 for ; Fri, 1 Nov 2019 07:21:56 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id 21so7172749pfj.9 for ; Fri, 01 Nov 2019 07:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A+ViMIU2YoNBHYJf5YXqopm8nn5rZMcj90YEb+cFwSs=; b=T2FBpuhkLM8IvkqqllRAG90B8FqLUt+IOyibkh5NBOLhACkicauSfObMOGIJ3YbzKC aYTQxXLT7lFd9+BnZucNcnwwnzm0G3AsdIS3kcg0qg0U8TG3esESs6+6v3dKeJEBzDx3 gHiYqtg+Ur8DDk6v2wdFaKpK06L0R/addf1aT2Jo5b8mWgF8JEua/2gl+gQqh7+cFhcX 8ogcA1D1FgEslTiqEgfKKEOtGp6p9t3Awn9env609RyBw5JMP9J96+3bpk65j1HCqy+c dN05+vrORmO4KnKvbg6BhRQlsMt5XK/nTFC4R1qUl2DWJTaC7S1UfVdqWosh/sfjydGJ zZ2g== 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=A+ViMIU2YoNBHYJf5YXqopm8nn5rZMcj90YEb+cFwSs=; b=SphuALFPUGK9okW3H3lK7lgKoZo4y5s1vxsunPAI9UW/+5ML1yPQ7gfBFFrvK7jwJl OijeU6k/zBsZws4NfSPVepzwdqgiqZCy5tUL+jHc/3coFyh5cOGYBn7LT+0qiq+X1IkW VveHI5MNbV9dd1pHZg6zpDNAD2LhC7r2HHXaX38irfld33Wxk+9UIeonT7JTCyD9L/1v WltbqS2VGTIrtRF8dgeNvhGcc/s9SOHH+04RTPpXU4FFc6zdw4a4jVGWZd3acf8aXRxk LZDhwp7jOp6/4873xYUpyBJQlfvrPPRLinVxwSqW2but9HLLX83yTFBHUz7sWXWijh/w 6xvA== X-Gm-Message-State: APjAAAUv0CZ2y507359ZGu+uNrQwqXbskbCnyfbYSuYWDNLG+36VyGui K+KBBKoAPv1RJPPiFXV2snA= X-Google-Smtp-Source: APXvYqyqd0tPWScj0N3ujS2gTN516lHYOyuCC2ArY3kqIREX7AwVtuHwcucRSwDP0vqDvjARRBw5ZQ== X-Received: by 2002:a17:90a:268c:: with SMTP id m12mr11462pje.69.1572618115814; Fri, 01 Nov 2019 07:21:55 -0700 (PDT) Received: from 137.66.20.149.in-addr.arpa (137.66.20.149.in-addr.arpa. [149.20.66.137]) by smtp.gmail.com with ESMTPSA id v63sm6459919pfb.181.2019.11.01.07.21.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 07:21:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Fred Baker In-Reply-To: Date: Fri, 1 Nov 2019 10:21:53 -0400 Cc: Ted Lemon , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <9CBD28D9-2B13-4224-97FC-9560A41C6A3B@gmail.com> References: <0F0B6068-CA62-449B-B56E-78E9EF8D998E@fugue.com> <96344740-2F4B-4BCE-A881-EB1A5933AFA2@fugue.com> To: Ole Troan X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 14:21:59 -0000 > On Oct 30, 2019, at 10:07 AM, Ole Troan wrote: >=20 > Ted, >=20 >>> We check both, the handling of the IA_PD and the error message. >>=20 >> And to be clear, you mean that if the CPE asks for a prefix = delegation and doesn=E2=80=99t get the prefix it previously had, it = deprecates it as described in L-14? When this deprecation happens, what = ways are being tested for it to happen? >>=20 >> E.g., is it the case that the client sends an IA PD containing an IA = Prefix option, is the server returning the IA Prefix option containing = the same prefix, with a status code encapsulated in it? What status = code? Or is it returning an IA Prefix option with a different prefix? = Or is it doing both? >=20 > You are thinking about this wrong. > The simple implementation of uRPF/BCP38 is: on LAN ingress to do a = lookup in the FIB of the SA, On a customer-facing interface (e.g., someone you don't exchange BGP = with and is therefore the only source of the prefix), yes. In an ISP, = you want to be looking at the RIB, not the FIB; any BGP neighbor that is = advertising a prefix to you might send you a packet with a source = address in that prefix. > if the resulting adjacency/interface matches the ingress interface = allow packet otherwise drop packet and send ICMP message. This behaviour = is required regardless of renumbering or not. > The ISP is required to do this on their ingress interfaces too. >=20 > Cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Nov 1 08:39:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D57A1201EA for ; Fri, 1 Nov 2019 08:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JaNrrHZnFb1 for ; Fri, 1 Nov 2019 08:39:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BE38D12016E for ; Fri, 1 Nov 2019 08:38:54 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1FcggJ012761 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 08:38:43 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1FcggJ012761 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572622724; bh=dPJ1zmi++A38J+iRXJlXdYyMZOw2qSik0NAZ1vjyf8g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=NHDikv00DQVQiJO4Z9k/lm4G0gbuixEmPhMAhJAlWtutHAUGQZEw9llTQ3mGUUjiu ksX6wHG/8DHyjm1i2b/+5whTEV5UcVd4uO5FXfZstc63fySp84zBCuCpf7DINvTbUs b7qn7zOd5BSEP8Z6V2R6bbAZoAwRhq7BbLjZ+mbw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: Date: Fri, 1 Nov 2019 08:38:42 -0700 Cc: Ted Lemon , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <97D59666-DAF5-4EBC-8AD9-96B9F6128649@delong.com> References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 08:38:44 -0700 (PDT) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 15:39:04 -0000 > On Oct 31, 2019, at 8:02 PM, Fernando Gont = wrote: >=20 > On 31/10/19 16:38, Owen DeLong wrote: >>=20 >>=20 >>> On Oct 31, 2019, at 12:21 PM, Fernando Gont = wrote: >>>=20 >>> Hello, Ted, >>>=20 >>>=20 >>> On 27/10/19 09:02, Ted Lemon wrote: >>>> Indeed, this would also not actually solve the problem. At = present, >>>> the ISPs are doing something that is out of spec and causes = problems. >>>> If we =E2=80=9Cfix=E2=80=9D this by accommodating what they do, = does that help, or >>>> does it just encourage them to continue doing it? >>>=20 >>> Did happy eyeballs encourage broken IPv6 connectivity, or did it >>> actually help IPv6 deployment? >>=20 >> Considering these mutually exclusive is a false dichotomy. >>=20 >> It did both. >=20 > It's hard for me to believe that folks were breaking stuff on purpose. Perhaps =E2=80=9Cencouraging broken=E2=80=A6=E2=80=9D is too strong, but = certainly it =E2=80=9Creduced motivation to fix broken IPv6=E2=80=9D and = =E2=80=9Creduced visibility of broken IPv6=E2=80=9D. > In any case, I would assume and expect that helping IPv6 deployment = was > more of a priority at the time. IN fact, we wouldn't be talking about > "google seeing 25% of IPv6" if there wasn't a way to circumvent > brokenness, I'd assume. It absolutely was more of a priority and that=E2=80=99s why it was = implemented. However, we should recognize that it was not without = collateral damage. It may be that we accept that this idea, too, comes with certain = unintended consequences, but we should at least make a legitimate effort = to identify and consider them, mitigate them to the extent possible, and = then make a conscious deliberate decision to accept them (or not). > [...] >>=20 >>>> When another RA arrives, see if it was signed with the same key. = If >>>> so, it came from the same router, and can be trusted to update >>>> whatever information that router sent, including flash-deprecating = a >>>> prefix. If not, ignore it. >>>=20 >>> In the non-SEND trust model, you do trust the local router. Why did = you >>> trust the local router to configure your network, but not for >>> deprecating the prefix? >>=20 >> Trusting the local router to configure the network to add a = previously non-operational host to the network has a somewhat different = set of consequence for failure than trusting whatever on-link host = wishes to tell you to effectively shut down your currently operating = network connection. >=20 > We'll that's the SLAAC model. I think you are still missing the point here=E2=80=A6 The current SLAAC = model is trusting the router to configure the network. The consequences = when this model fails are that new hosts have difficulty (or failure) = joining the network. In most cases, it has pretty limited consequences = to existing hosts ability to continue to run. On the flip side, what is being proposed does create a possibility where = a single crafted packet can literally immediately disconnect every host = on the link from the network. The model is the same, but the consequences are significantly different, = so perhaps the greater consequences warrant considering a different = trust model. >=20 >=20 >=20 >> Especially when you consider that such an announcement can be sent to = the all nodes on link multicast address, effectively dropping them all = at once. >>=20 >> I agree it=E2=80=99s not a huge difference, but, it is a difference = and certainly the scope of the resulting problem can be much larger than = the case of individual host configuration. >=20 > Hosts trust a lot of other crap. e.g., feel free to advertising a Cur > Hop Limit of 1. Is that any different? Yes=E2=80=A6 A hop limit of 1 leads to errors that make the cause rather = obvious. Crafted RAs that send out PIOs deprecating all the actually valid = prefixes lead to error conditions that can be much harder to = identify/isolate. Owen From nobody Fri Nov 1 08:40:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5578512016E for ; Fri, 1 Nov 2019 08:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE_ZRE6q4y_Y for ; Fri, 1 Nov 2019 08:40:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BAE861200EB for ; Fri, 1 Nov 2019 08:40:50 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1Fdj4Y013066 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 08:39:46 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1Fdj4Y013066 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572622789; bh=8c8O5fqHAI9FnDsTen7u7bjKvobZSyZaXEJ8Xud1WSU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=2uUDBwwTJ7yG8UJSOvLjOJKXanx+kUW8GIe06Yx7ccdPXStESbC9qOE/GZIYl4XK/ 1umKZfXRCM/tp/irRmpxhuCZHSQ8C0axOCq0zYY0M5Tugg1YbkqPFeyKIGnqs+f3Sz nDLA4RGLumfOSPIfILoXbfv127TX/qT57UaGM2Wc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: <8f46bb68-1713-8c68-96b1-c46cf2003325@si6networks.com> Date: Fri, 1 Nov 2019 08:39:45 -0700 Cc: Ted Lemon , Philip Homburg , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <071E7287-74DD-44B9-9917-5231652F9E3D@delong.com> References: <8f46bb68-1713-8c68-96b1-c46cf2003325@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 08:39:49 -0700 (PDT) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 15:40:52 -0000 > On Oct 31, 2019, at 8:06 PM, Fernando Gont = wrote: >=20 > On 31/10/19 16:39, Owen DeLong wrote: >>=20 >>=20 >>> On Oct 31, 2019, at 12:25 PM, Fernando Gont = wrote: >>>=20 >>> On 27/10/19 10:54, Ted Lemon wrote: >>>> On Oct 27, 2019, at 9:41 AM, Philip Homburg = >>> > wrote: >>>>> The little bit missing is that the CPE should write prefixes >>>>> advertised using >>>>> SLAAC to persistent storage which allows the CPE to invalidate = stale >>>>> prefixes >>>>> after a reboot. >>>>=20 >>>> Actually I do not believe this is correct behavior. Let us assume >>>> prefix delegation. If we have prefix delegation, then when the = CPE >>>> comes back from a power cycle, it should reconfirm the prefix it = had >>>> previously; the assumption is that that prefix is still valid. = This can >>>> be handled in infrastructure=E2=80=94the ISP edge router should = know whether the >>>> prefix is still valid, because if it is it should be advertising a = route >>>> for it. If it is not still valid, then the CPE router should = attempt >>>> to renew it, which would go to the DHCP server (possibly both = messages >>>> would). >>>=20 >>> That assues the CPE has stored the previously-leased prefix on = stable >>> storage -- which does not need to be the case. Hence the related = text in >>> our I-D. >>=20 >> IMHO, the CPE requirements should be increased and the CPE should be = required >> to store the prefix and it=E2=80=99s expected valid and preferred = expiration times in persistent >> storage. I would like to see the text in the I-D updated accordingly. >=20 > It's already there (draft-gont-v6ops-slaac-renum-00): >=20 > 3.2.1. Signaling Stale Configuration Information >=20 > In order to phase-out stale configuration information: >=20 > o A CPE router sending RAs that advertise dynamically-learned > prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on > stable storage, the list of prefixes being advertised on each > network segment. Where is the mention of storing the expiration times? Did I miss it, or did you miss that part of my comment? Owen >=20 >=20 > Thanks! >=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 From nobody Fri Nov 1 08:49:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FC712091F for ; Fri, 1 Nov 2019 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWwtkTo-DOVq for ; Fri, 1 Nov 2019 08:49:14 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B9F6012095C for ; Fri, 1 Nov 2019 08:49:14 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1FmYBM015508 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 08:48:35 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1FmYBM015508 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572623316; bh=yMrGu5S79MTJcIyIhuXkK4/JHRsctZLlPheJPz5dAF4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=fsTVP3/WMx+j1bJx1WYqMAdNl/3vrUVNHeZYrRiwFrHGlUQobJ5imxuqGZ0x728sm otKxVfjZnL3YNQKSncOKY+qC4nAEGn7/x9GKGon6DnNikQtd6NFIx7BN6OmO7VoN6m F8m31Yg1D7QyRPJfKPySRI5fZhqAv50Oq2RuVm9U= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: Date: Fri, 1 Nov 2019 08:48:33 -0700 Cc: Mark Smith , Ted Lemon , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <34AF500F-388E-4F59-B4B2-7B98B6057303@delong.com> References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 08:48:36 -0700 (PDT) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 15:49:21 -0000 > On Oct 31, 2019, at 8:18 PM, Fernando Gont = wrote: >=20 > On 31/10/19 21:20, Mark Smith wrote: >>=20 >>=20 >> On Fri, 1 Nov 2019, 06:34 Ted Lemon, > > wrote: >>=20 >> On Oct 31, 2019, at 3:21 PM, Fernando Gont > > wrote: >>> On 27/10/19 09:02, Ted Lemon wrote: >>>> Indeed, this would also not actually solve the problem. At = present, >>>> the ISPs are doing something that is out of spec and causes = problems. >>>> If we =E2=80=9Cfix=E2=80=9D this by accommodating what they do, = does that help, or >>>> does it just encourage them to continue doing it? >>>=20 >>> Did happy eyeballs encourage broken IPv6 connectivity, or did it >>> actually help IPv6 deployment? >>=20 >> Don=E2=80=99t get me wrong=E2=80=94I=E2=80=99m not saying we = shouldn=E2=80=99t do things to improve >> the situation. I am saying that we should be strategic about it. >>=20 >>>> What should be happening on the host with a prefix that=E2=80=99s = deprecated >>>> is that TCP connections should be timing out. This doesn=E2=80=99= t take >>>> very long. =20 >>>=20 >>> ~9 minutes, IIRC. >>=20 >> Should be 90 seconds. >>=20 >>=20 >> You've got no more than 10 seconds unless you want end users to = actively >> try to do something to recover, which can include calling their ISP's >> helpdesk. >=20 > I'd argue the opposite. But, anyway, for the most part the user = timeout > is not under the control of the user. It depends on which user time out you are referring to=E2=80=A6 The TCP stack user timeout is not under user control. The time between when the user clicks on a URL and the when the user = starts hitting the refresh button in the browser with a frequency that = increases in proportion to said user=E2=80=99s frustration level is entirely under = the user=E2=80=99s control. Which of these timers is more significant is left as an execrcise to the = reader. Owen >=20 >=20 > --=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Nov 1 09:16:30 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5FA1209E0 for ; Fri, 1 Nov 2019 09:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 header.b=fko/3yOG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DoX7O5or Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i244uCdWwsuN for ; Fri, 1 Nov 2019 09:16:23 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379A41209B3 for ; Fri, 1 Nov 2019 09:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5482; q=dns/txt; s=iport; t=1572624971; x=1573834571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xdy9biID5XlkNN7g0SOLqD6U6sJ8FjLc9VZlEk3Z838=; b=fko/3yOGMop/4mn8HIH6H5IgPd7sLo3qo9imI3RXlB8sMbLgWFAAET2P 9x8GUBpurRwy7uirhHgmIQTLGpxA7SejP07Ie5SwY9aNzLleqfjOKeKeM wbP6lEkG8nfaozeEOD8gHyoJlH+sStba+7Rsmm7wnD8v0SOBpjVZJ17a+ w=; IronPort-PHdr: =?us-ascii?q?9a23=3AXSJaKxPUIPXq2S8F0OUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQF0r/PtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAACYWbxd/5JdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFpBQEBAQELAYFKJCwFbFggBAsqCoQeg0YDhFq?= =?us-ascii?q?GGoJef5Z9gS6BJANUCQEBAQwBARgLCgIBAYRAAheDZCQ0CQ4CAwsBAQQBAQE?= =?us-ascii?q?CAQUEbYU3DIVRAQEBAQIBAQEQEREMAQEsCwEECwIBCBgCAiMDAgICJQsUARA?= =?us-ascii?q?CBAENBSKDAAGCRgMOIAEOpz8CgTiIYHWBMoJ+AQEFgTQBg18YghcDBoEOKAG?= =?us-ascii?q?MEBiBf4ERJx+CFzU+gmIBAYFFBgIUFxWCZDKCLI0LCYJph3eWAgqCJIwviQY?= =?us-ascii?q?bmWWEV4YTg1aZVAIEAgQFAg4BAQWBUjmBWHAVOyoBgkFQERSDBgwXg1CFFIU?= =?us-ascii?q?/dIEoiwaBMAEvXgEB?= X-IronPort-AV: E=Sophos;i="5.68,256,1569283200"; d="scan'208";a="363273850" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 16:16:10 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1GGArp013258 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 16:16:10 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 11:16:09 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 11:16:08 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 11:16:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Df1/JomIZ3Ap0DLiJjqXJc5KKccKdvDsbtJo7k2hw7Lr1xuF3kJEZ0/VPsU7s4+YVSRnkvRRkoZ3dE5QZ94d1ac7SNvb24e30RC3bWrdwCl1doJlRgiHqMZF2LMZE5tAtZisn3m2R008QC5+78Z39eB4LEY2DCDCGmW9PGsWAnM1s+sP3eH4F6eqSGDRhw6KEu1BYfIflfnQnVjpqaeeV7MOtSa8UGSCIHLa9F5sih+NGdGeGY++Kx7pogve3TAokRRD3uFizjFyFlmDQZGvOytQ1xnGL2/f1ISuFNjreBsD1qDx3soSMBS93tGGwUy02jm2mAPCKtJYzm5iqnbqRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xdy9biID5XlkNN7g0SOLqD6U6sJ8FjLc9VZlEk3Z838=; b=DAzghC+khKjo9zBRwo+ZwSNV00JVz1FzKzSnLmt0jqO/HmlLaIJLibCXbShS3i/3bREAUC3C4tMxhrPe8JGDtJqGA3cum0iB51THzpCiV4ZRaNtrHPtu95zK2dXdHABZ0iaNUOcPy68a/jO28zzSgBhKO/pdNoLIJ3FOqAYschAobwluIcIgn9O5udqqW7OPRVYHrR0gnxEZvonOopuhaSBExU3ADrZEeu1agvyieB/bnt76cvY3evlTwkTEINE/79u8v2IxArEZUae59Da2e4pVCDNmmvwZ6E0Ef4hnR27Nqy54/gHT0c1/inD6xnFERW9zbeOeVHukFHC5/35KVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xdy9biID5XlkNN7g0SOLqD6U6sJ8FjLc9VZlEk3Z838=; b=DoX7O5orgCEfYuegLE8jAG1nYzsAwgWSSM65xxnok/ETq7tzrIeNI4QDi44oAEYlRsFwKX2PoxWBcdtnlYYqZjsrSNYOCGBhI/Fc57vPrQaSQgTiSbMpqo55KGgXipjz8tauCuuaAN1zXcM7VgB5PN0Ltfe4pdlcSuqrvldHcXI= Received: from CY4PR1101MB2279.namprd11.prod.outlook.com (10.172.75.137) by CY4PR1101MB2181.namprd11.prod.outlook.com (10.174.52.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.17; Fri, 1 Nov 2019 16:16:07 +0000 Received: from CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab]) by CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab%10]) with mapi id 15.20.2387.030; Fri, 1 Nov 2019 16:16:07 +0000 From: "Bernie Volz (volz)" To: Owen DeLong , Fernando Gont CC: "v6ops@ietf.org" Thread-Topic: [v6ops] SLAAC renum: Problem Statement & Operational workarounds Thread-Index: AQHVibwc6PRwlsH+ZUmOeFzp+XKiI6dt8FJugAA0sICAAERiAIAACLmAgAATKlOAAANjAIAGpb+AgAAD94CAAHz9AIAA0laA///HGgA= Date: Fri, 1 Nov 2019 16:16:07 +0000 Message-ID: References: <8f46bb68-1713-8c68-96b1-c46cf2003325@si6networks.com> <071E7287-74DD-44B9-9917-5231652F9E3D@delong.com> In-Reply-To: <071E7287-74DD-44B9-9917-5231652F9E3D@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3aefa0e9-7c45-4c7b-6a25-08d75ee6cd78 x-ms-traffictypediagnostic: CY4PR1101MB2181: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(396003)(376002)(346002)(189003)(199004)(53546011)(2906002)(476003)(36756003)(86362001)(14444005)(256004)(316002)(110136005)(99286004)(6246003)(91956017)(5024004)(486006)(11346002)(76116006)(2616005)(6306002)(6512007)(4326008)(66946007)(186003)(58126008)(66574012)(6116002)(446003)(229853002)(14454004)(26005)(66556008)(6436002)(8936002)(102836004)(8676002)(81156014)(64756008)(76176011)(966005)(6506007)(66446008)(71190400001)(25786009)(5660300002)(33656002)(66066001)(3846002)(6486002)(7736002)(478600001)(71200400001)(66476007)(305945005)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2181; H:CY4PR1101MB2279.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o7ERC7OdYJH3t/VVPqZDIHS7gvlj4OPNEwopx/x3eHGsbY5E67Y/8lJomabSZ+ZMYztqv0O0NHQ4XtqH33X+8TPHgWqhBw3c9iGXW+msSTtHmDo3RxaTwzTpAfWx38vhp4ggoyxDFg7hJAfqLC6yDzsG6/6ehEutGUCqcbMBi9umIVLFA/U/ftGPVo/MCD2ZshS/8TbPWnfln2IictOj9x5ZR0CwKmGKXqDuIQzKYT7Y1L5SfljINC1TPmAYhU/1/c2pnmLAGEMfk6TYcPZ7LG973OV+kiPJdedv8q2K2MAqBbBww8XMYRtnDWa7FmfAArCeV07UgmwOQ2gQWF+kPEDGA6Yd0WVXoncPnIlfCvubgG+20GAGFtyXiK+znvhQ+1eH868woBfmCqWGq3CvmxQi/6td/D88PhVHmptcIniLWMsNl0qzvI265SokLqutI+htVCkRWwsYE8bYUtVhmjFDO6KeV+R1TKqFhkHe9bQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0FE9AF9B2A711A47885130020FA6449D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3aefa0e9-7c45-4c7b-6a25-08d75ee6cd78 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 16:16:07.7435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RX3k6Z5hrjpCSY1DfDZDuCS2urLwj56sjllW0lUQ2BLslj9i8oNonLIYf140Vmm4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2181 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:16:29 -0000 PiAgICBXaGVyZSBpcyB0aGUgbWVudGlvbiBvZiBzdG9yaW5nIHRoZSBleHBpcmF0aW9uIHRpbWVz Pw0KDQpBbHNvLCBiYXNlZCBvbiBSRkM4NDE1IHRoaXMgbWVhbnMgdGhhdCB0aGUgY2xpZW50IHNo b3VsZCB1c2UgYSBESENQdjYgUmViaW5kIHdoZW4gaXQgcG93ZXJzIGJhY2sgb24gYXMgbm93IGl0 IGhhcyB0aGUgaW5mb3JtYXRpb24gdG8gYXNrIHdoZXRoZXIgaXQgaXMgc3RpbGwgdmFsaWQgKGFz c3VtaW5nIGl0IGhhc24ndCBleHBpcmVkKT8NCg0KU2VlIFNlY3Rpb24gMTguMi4xOCBvZiBSRkM4 NDE1Og0KDQogICBXaGVuZXZlciBhIGNsaWVudCBtYXkgaGF2ZSBtb3ZlZCB0byBhIG5ldyBsaW5r LCB0aGUNCiAgIHByZWZpeGVzL2FkZHJlc3NlcyBhc3NpZ25lZCB0byB0aGUgaW50ZXJmYWNlcyBv biB0aGF0IGxpbmsgbWF5IG5vDQogICBsb25nZXIgYmUgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaW5r IHRvIHdoaWNoIHRoZSBjbGllbnQgaXMgYXR0YWNoZWQuDQogICBFeGFtcGxlcyBvZiB0aW1lcyB3 aGVuIGEgY2xpZW50IG1heSBoYXZlIG1vdmVkIHRvIGEgbmV3IGxpbmsgaW5jbHVkZQ0KICAgdGhl IGZvbGxvd2luZzoNCg0KICAgLSAgVGhlIGNsaWVudCByZWJvb3RzIChhbmQgaGFzIHN0YWJsZSBz dG9yYWdlIGFuZCBwZXJzaXN0ZW50IERIQ1ANCiAgICAgIHN0YXRlKS4NCg0KICAgLSAgVGhlIGNs aWVudCBpcyByZWNvbm5lY3RlZCB0byBhIGxpbmsgb24gd2hpY2ggaXQgaGFzIG9idGFpbmVkDQog ICAgICBsZWFzZXMuDQoNCiAgIC0gIFRoZSBjbGllbnQgcmV0dXJucyBmcm9tIHNsZWVwIG1vZGUu DQoNCiAgIC0gIFRoZSBjbGllbnQgY2hhbmdlcyBhY2Nlc3MgcG9pbnRzIChlLmcuLCBpZiB1c2lu ZyBXaS1GaQ0KICAgICAgdGVjaG5vbG9neSkuDQouLi4NCg0KICAgSWYgdGhlIGNsaWVudCBoYXMg YW55IHZhbGlkIGRlbGVnYXRlZCBwcmVmaXhlcyBvYnRhaW5lZCBmcm9tIHRoZSBESENQDQogICBz ZXJ2ZXIsIHRoZSBjbGllbnQgTVVTVCBpbml0aWF0ZSBhIFJlYmluZC9SZXBseSBtZXNzYWdlIGV4 Y2hhbmdlIGFzDQouLi4NCg0KDQotIEJlcm5pZQ0KDQrvu79PbiAxMS8xLzE5LCAxMTo0MSBBTSwg InY2b3BzIG9uIGJlaGFsZiBvZiBPd2VuIERlTG9uZyIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIG93ZW5AZGVsb25nLmNvbT4gd3JvdGU6DQoNCiAgICANCiAgICANCiAgICA+ IE9uIE9jdCAzMSwgMjAxOSwgYXQgODowNiBQTSwgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0 d29ya3MuY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gT24gMzEvMTAvMTkgMTY6MzksIE93ZW4g RGVMb25nIHdyb3RlOg0KICAgID4+IA0KICAgID4+IA0KICAgID4+PiBPbiBPY3QgMzEsIDIwMTks IGF0IDEyOjI1IFBNLCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+IHdyb3Rl Og0KICAgID4+PiANCiAgICA+Pj4gT24gMjcvMTAvMTkgMTA6NTQsIFRlZCBMZW1vbiB3cm90ZToN CiAgICA+Pj4+IE9uIE9jdCAyNywgMjAxOSwgYXQgOTo0MSBBTSwgUGhpbGlwIEhvbWJ1cmcgPHBj aC12Nm9wcy05QHUtMS5waGljb2guY29tDQogICAgPj4+PiA8bWFpbHRvOnBjaC12Nm9wcy05QHUt MS5waGljb2guY29tPj4gd3JvdGU6DQogICAgPj4+Pj4gVGhlIGxpdHRsZSBiaXQgbWlzc2luZyBp cyB0aGF0IHRoZSBDUEUgc2hvdWxkIHdyaXRlIHByZWZpeGVzDQogICAgPj4+Pj4gYWR2ZXJ0aXNl ZCB1c2luZw0KICAgID4+Pj4+IFNMQUFDIHRvIHBlcnNpc3RlbnQgc3RvcmFnZSB3aGljaCBhbGxv d3MgdGhlIENQRSB0byBpbnZhbGlkYXRlIHN0YWxlDQogICAgPj4+Pj4gcHJlZml4ZXMNCiAgICA+ Pj4+PiBhZnRlciBhIHJlYm9vdC4NCiAgICA+Pj4+IA0KICAgID4+Pj4gQWN0dWFsbHkgSSBkbyBu b3QgYmVsaWV2ZSB0aGlzIGlzIGNvcnJlY3QgYmVoYXZpb3IuICAgTGV0IHVzIGFzc3VtZQ0KICAg ID4+Pj4gcHJlZml4IGRlbGVnYXRpb24uICAgSWYgd2UgaGF2ZSBwcmVmaXggZGVsZWdhdGlvbiwg dGhlbiB3aGVuIHRoZSBDUEUNCiAgICA+Pj4+IGNvbWVzIGJhY2sgZnJvbSBhIHBvd2VyIGN5Y2xl LCBpdCBzaG91bGQgcmVjb25maXJtIHRoZSBwcmVmaXggaXQgaGFkDQogICAgPj4+PiBwcmV2aW91 c2x5OyB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoYXQgcHJlZml4IGlzIHN0aWxsIHZhbGlkLiAg VGhpcyBjYW4NCiAgICA+Pj4+IGJlIGhhbmRsZWQgaW4gaW5mcmFzdHJ1Y3R1cmXigJR0aGUgSVNQ IGVkZ2Ugcm91dGVyIHNob3VsZCBrbm93IHdoZXRoZXIgdGhlDQogICAgPj4+PiBwcmVmaXggaXMg c3RpbGwgdmFsaWQsIGJlY2F1c2UgaWYgaXQgaXMgaXQgc2hvdWxkIGJlIGFkdmVydGlzaW5nIGEg cm91dGUNCiAgICA+Pj4+IGZvciBpdC4gICBJZiBpdCBpcyBub3Qgc3RpbGwgdmFsaWQsIHRoZW4g dGhlIENQRSByb3V0ZXIgc2hvdWxkIGF0dGVtcHQNCiAgICA+Pj4+IHRvIHJlbmV3IGl0LCB3aGlj aCB3b3VsZCBnbyB0byB0aGUgREhDUCBzZXJ2ZXIgKHBvc3NpYmx5IGJvdGggbWVzc2FnZXMNCiAg ICA+Pj4+IHdvdWxkKS4NCiAgICA+Pj4gDQogICAgPj4+IFRoYXQgYXNzdWVzIHRoZSBDUEUgaGFz IHN0b3JlZCB0aGUgcHJldmlvdXNseS1sZWFzZWQgcHJlZml4IG9uIHN0YWJsZQ0KICAgID4+PiBz dG9yYWdlIC0tIHdoaWNoIGRvZXMgbm90IG5lZWQgdG8gYmUgdGhlIGNhc2UuIEhlbmNlIHRoZSBy ZWxhdGVkIHRleHQgaW4NCiAgICA+Pj4gb3VyIEktRC4NCiAgICA+PiANCiAgICA+PiBJTUhPLCB0 aGUgQ1BFIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgaW5jcmVhc2VkIGFuZCB0aGUgQ1BFIHNob3Vs ZCBiZSByZXF1aXJlZA0KICAgID4+IHRvIHN0b3JlIHRoZSBwcmVmaXggYW5kIGl04oCZcyBleHBl Y3RlZCB2YWxpZCBhbmQgcHJlZmVycmVkIGV4cGlyYXRpb24gdGltZXMgaW4gcGVyc2lzdGVudA0K ICAgID4+IHN0b3JhZ2UuIEkgd291bGQgbGlrZSB0byBzZWUgdGhlIHRleHQgaW4gdGhlIEktRCB1 cGRhdGVkIGFjY29yZGluZ2x5Lg0KICAgID4gDQogICAgPiBJdCdzIGFscmVhZHkgdGhlcmUgKGRy YWZ0LWdvbnQtdjZvcHMtc2xhYWMtcmVudW0tMDApOg0KICAgID4gDQogICAgPiAzLjIuMS4gIFNp Z25hbGluZyBTdGFsZSBDb25maWd1cmF0aW9uIEluZm9ybWF0aW9uDQogICAgPiANCiAgICA+ICAg SW4gb3JkZXIgdG8gcGhhc2Utb3V0IHN0YWxlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb246DQog ICAgPiANCiAgICA+ICAgbyAgQSBDUEUgcm91dGVyIHNlbmRpbmcgUkFzIHRoYXQgYWR2ZXJ0aXNl IGR5bmFtaWNhbGx5LWxlYXJuZWQNCiAgICA+ICAgICAgcHJlZml4ZXMgKGUuZy4gdmlhIERIQ1B2 Ni1QRCkgb24gYW4gaW50ZXJmYWNlIE1VU1QgcmVjb3JkLCBvbg0KICAgID4gICAgICBzdGFibGUg c3RvcmFnZSwgdGhlIGxpc3Qgb2YgcHJlZml4ZXMgYmVpbmcgYWR2ZXJ0aXNlZCBvbiBlYWNoDQog ICAgPiAgICAgIG5ldHdvcmsgc2VnbWVudC4NCiAgICANCiAgICBXaGVyZSBpcyB0aGUgbWVudGlv biBvZiBzdG9yaW5nIHRoZSBleHBpcmF0aW9uIHRpbWVzPw0KICAgIA0KICAgIERpZCBJIG1pc3Mg aXQsIG9yIGRpZCB5b3UgbWlzcyB0aGF0IHBhcnQgb2YgbXkgY29tbWVudD8NCiAgICANCiAgICBP d2VuDQogICAgDQogICAgPiANCiAgICA+IA0KICAgID4gVGhhbmtzIQ0KICAgID4gDQogICAgPiBD aGVlcnMsDQogICAgPiAtLSANCiAgICA+IEZlcm5hbmRvIEdvbnQNCiAgICA+IFNJNiBOZXR3b3Jr cw0KICAgID4gZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb20NCiAgICA+IFBHUCBGaW5nZXJw cmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAwRDU1IDFENEUgNzQ5Mg0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZv cHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQogICAgDQoNCg== From nobody Fri Nov 1 09:17:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34AC120954 for ; Fri, 1 Nov 2019 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x14hgcy44fw4 for ; Fri, 1 Nov 2019 09:17:49 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7021D1208FA for ; Fri, 1 Nov 2019 09:17:49 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1FR3Vn010266 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 08:27:08 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1FR3Vn010266 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572622029; bh=75Qq72Z5x1NxQtKCwDmiFxUG1N8myUYj0FtMakDilps=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=x5imAAGxBpZ425agjal/JnVUIkXATk8cBxdsKDqAKCHJ7uyKCvHH9/1CWbtcw7L/h ePj2onC1XUQUqpMaigHis8eVmK7EIHelThYTX8Swx7Mycql/1wLBN/g55TqoAes3NM pdk8oiFKEDqEZBqUBj4M1HptN2a0UFwr0+ZIxQD0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: <95cbe3d9-191e-c6e1-cb42-305686ef1e42@si6networks.com> Date: Fri, 1 Nov 2019 08:27:02 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <51E4F723-C5DF-4FB1-A72D-6A66B9CBF0F6@delong.com> References: <7C913CC2-938F-449C-9750-85C36EC05E38@delong.com> <48c864c7-589d-23cf-417e-6f4ec012a76a@si6networks.com> <7C142F1F-04C6-48A2-A65A-7CADD3691ECF@delong.com> <8dbfb1b6-5efa-019f-313b-e8045ee277ee@si6networks.com> <95cbe3d9-191e-c6e1-cb42-305686ef1e42@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 08:27:09 -0700 (PDT) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:17:51 -0000 > On Oct 31, 2019, at 7:04 PM, Fernando Gont = wrote: >=20 > Hello, Owen, >=20 > On 31/10/19 16:27, Owen DeLong wrote: > [....] >>>>=20 >>>> I=E2=80=99m not sure what I could do to elaborate. The addition of = a specific >>>> call-out that >>>> even if the current behavior of =E2=89=A42 hours =3D 2 hours is to = be preserved, >>>> there should >>>> be a special case for =E2=80=9C0 seconds=E2=80=9D which causes the = prefix to be immediately >>>> deprecated with extreme prejudice. >>>>=20 >>>> Hosts should be required to treat an RA containing a prefix with a = 0 second >>>> valid lifetime as an invalid prefix and immediately deprecate it = from >>>> the interface >>>> if it is in use. >>>=20 >>> OK, so you do agree with the proposed change? (in >>> draft-gont-6man-slaac-renum, not in *this* document) >>=20 >> =46rom the context of my thinking at the time of writing the original = reply, >> =E2=80=9Cthis document=E2=80=9D referred to = draft-gont-6man-slaac-renum. Apolgies >> for my lack of clarity as you have apparently interpreted it = differently. >=20 > Ok. BUt, double-checking: DO you agree with the proposed behaviour? I agree that a host receiving an RA with a PIO containing a 0s preferred = lifetime should immediately deprecate the prefix from the interface and send an = appropriate exception to any open sockets bound to that prefix. While this can be a significant DoS vector, any environment where that = is a concern already has a number of other significant DoS vectors from = malicious RAs anyway. >=20 >=20 >=20 >=20 > [....] >>>>>=20 >>>>> Even with the default RA frequency, if you were to unprefer a = prefix >>>>> upon, say, second RA that doesn't advertise it, and say, remove = the >>>>> prefix after many other RAs are received, that would be a *big* >>>>> improvement to what we have now. >>>>=20 >>>> I don=E2=80=99t like this idea because I can think of some = scenarios where you >>>> may receive multiple RAs from router A not containing the prefix in = the >>>> same time frame that router B has not sent an additional RA = containing >>>> the prefix, but it will do so in its next RA. >>>=20 >>> Maybe it wasn't clear in the I-D, but the basic idea is: >>> If you receive multiple RAs from router A that do not advertise the >>> prefix, then you disassociate such prefix with router A. If nobody = else >>> is advertising the prefix, you'd deprecate it. If other routers are >>> advertising it, this would not change the status quo of the prefix = wrt >>> such other routers. >>=20 >> That=E2=80=99s definitely not how I interpreted the I-D and I would = strongly encourage >> you to review and update the I-D for clarity in this area. I=E2=80=99m = actually still not >> 100% convinced that this is correct behavior. It also places = additional burdens >> on hosts to track all routers associated with a given prefix rather = than merely >> tracking candidate default gateways, RIO data, and one set of prefix = timers >> utilizing the most recently received timer refreshes. >=20 > Thanks for the feedback! I will definitely clarify the text. FWIW, in > the context of RFC8028, you already need to keep prefixes associated > with routers=E2=80=A6. I=E2=80=99ll have to reread. Owen >=20 >=20 >>=20 >>>> There is no requirement for all routers on the same link to provide = the >>>> same set of PIOs, nor are they required to use the same = advertisement >>>> timers. >>>=20 >>> Agreed. Please see above. >>=20 >> With the above clarification, I think it can be done and is less = likely to break >> things. However, it does place a significant additional tracking = burden on the >> host which I=E2=80=99m not entirely convinced is a desirable = situation. Especially in the >> case of a resource-constrained host which is using SLAAC to avoid the = overhead >> of DHCP. >=20 > In the context of RFC8028, you don't have much of an option -- = otherwise > you run the risk of being egress filtered. >=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 From nobody Fri Nov 1 09:22:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92C21209FE for ; Fri, 1 Nov 2019 09:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbsAjuqsqzdh for ; Fri, 1 Nov 2019 09:22:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8511209EE for ; Fri, 1 Nov 2019 09:22:02 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1GLxwW025605 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 09:22:00 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1GLxwW025605 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572625321; bh=YPPfy0PFwleLtUFFrhhyhuVCj/I9ehRl4mO9AL8Sps8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=IsNAvMbbG9YPuWocZIFMisEzD8JipeUWMkCfRSiJBjmgU1DWRGROmd5NYONWi7BMz P0uMom6LK/YlKayahp77em5IJrnNIsc1cRF90fPZGYE2BX/i+OC4kynk1pcUPRFZfh YOfWDo3t4Zf/oxyMsZrrAEk3s+EO2gQn/YkXH/NQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: Date: Fri, 1 Nov 2019 09:21:59 -0700 Cc: Sander Steffann , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 09:22:01 -0700 (PDT) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:22:05 -0000 > On Nov 1, 2019, at 2:29 AM, Fernando Gont = wrote: >=20 > On 1/11/19 05:22, Sander Steffann wrote: >> Hi, >>=20 >>>> I think Ole observed that this is contrary to what the PD prefix's >>>> Valid Lifetime said would be the case. The ISP supplied a PD Prefix >>>> with a Valid Lifetime of X seconds, and then broke that promise by >>>> abruptly changing addressing before X seconds. ISPs should be = expected >>>> to live up to their Valid Lifetime promises. >>>=20 >>> "Hope" doesn't make networks run properly. >>=20 >> This isn't "Hope", this is breaking promises, and that does break = networks. If you can't at least trust that promises are intended to be = kept then you have no network at all... >=20 > You might hope the ISPs do stable prefixes, that CPEs record the = leased > prefixes on stable storage, and that CPE routers does not crash and = reboot. >=20 > However, 37% of surveyed ISPs > = (https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/86= 6/bcop-ipv6-prefix-v9.pdf) > indicate they do dynamic prefixes, and thus are likely to be facing = this > problem (possibly being masqueraded by falling back to IPv4). >=20 > You may want to declare ISPs clueless, start a crusade to switch to > stable prefixes (unlikely success), claim that CPE vendors are cheap, = etc. >=20 > But at the end of the day, user experience will still suck. >=20 > (I have had cases in which I have flash-renumbered my network by > changing and reloading a RA daemon) Dynamic prefixes do not necessarily imply flash renumbering and broken = promises as Sander calls it. He=E2=80=99s right that even in the case of dynamic prefixes, the ISP = _SHOULD_ delegate or at least preserve the operability of the prefix for = the duration promised in the lease, even across reboot of the delegated = router, etc. However, you=E2=80=99re also right that vendors and ISPs don=E2=80=99t = always do what they should and these proposals can help mitigate the = damage when that happens. If there are problematic tradeoffs associated with these measures, they = should be considered, but taking an absolutist approach of =E2=80=9Cthis = shouldn=E2=80=99t happen, so we shouldn=E2=80=99t make efforts to handle = this case=E2=80=9D isn=E2=80=99t useful IMHO. >>> In any case, as previously noted, there are multiple scenarios that = may >>> lead to this problem. >>=20 >> Sure, bad things can happen, and there are cases where despite the = best intentions you can't keep your promise. But that doesn't mean = everybody should go around making promises without even thinking about = keeping them=E2=80=A6 >=20 > I certainly can't speak for the 37% above. But a number of folks have > already noted (some on-list, some off-list) that they are running > networks on which this flash-renumbering events do occur. >=20 > The home network/cpe case is a notable example, but others exists. And > particularly the host-side mitigations help all of them. I=E2=80=99d argue that the CPE side mitigations are the low hanging = fruit here. I think it will be far faster and easier to update CPE = firmware and that the changes proposed to CPE are, in fact, in most = cases simpler than the host changes. Owen From nobody Fri Nov 1 09:33:39 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D00A120A0F for ; Fri, 1 Nov 2019 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqf3CoM97E3o for ; Fri, 1 Nov 2019 09:33:35 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B88F1209FE for ; Fri, 1 Nov 2019 09:33:27 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1GX5uH028651 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 09:33:07 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1GX5uH028651 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572625989; bh=KLOFXCWjWOeYFYbYf/QbY86wRBP3FVIuilWB/bb4IVw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ZK8stWlqbUMRTUC6klbwE6XgPEIsz+WEasf0J2sruVgLw/pK1Q8c2joU/OC41nyAO dCiBu5+WZDLuVOZLTGQTSHil27FYge1CmVULAr+sBqC+mfcnmG6gz0v1p20yKfSgg6 UAWJmmb2O/z3jPjv6YDvbSRPnyZgijUXWEJ+JpeE= From: Owen DeLong Message-Id: <5F1D8D50-7CE8-4142-82AC-44E5E07E762E@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9259C8F5-BA20-43A0-90C8-89588A33B12A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Fri, 1 Nov 2019 09:33:03 -0700 In-Reply-To: <2A9E3CA6-EF42-4D76-8BE2-3BEC9E117AC2@fugue.com> Cc: Fernando Gont , v6ops list To: Ted Lemon References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com> <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> <7870ab3d-9570-4f79-df5b-3653ab3a6c54@si6networks.com> <2A9E3CA6-EF42-4D76-8BE2-3BEC9E117AC2@fugue.com> X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 09:33:09 -0700 (PDT) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:33:38 -0000 --Apple-Mail=_9259C8F5-BA20-43A0-90C8-89588A33B12A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 1, 2019, at 3:11 AM, Ted Lemon wrote: >=20 > On Nov 1, 2019, at 5:45 AM, Fernando Gont > wrote: >>> So why aren=E2=80=99t they doing that? What=E2=80=99s the = obstacle? >>=20 >> Are you referring to the CPE case, or to the rest? >=20 > I=E2=80=99m specifically referring to the ISP case, although I think = referring to it as =E2=80=9Cthe CPE case=E2=80=9D is limiting your = options! :) >=20 >> If you assume all routers employ the same values for the = valid/preferred >> lifetimes, then what you propose is the equivalent to "prefer the = last >> advertised prefix". In which case, in the presence of multiple RAs = the >> src address of new sessions will deterministically flap. That doesn't >> seem nice from a troubleshooting perspective. >=20 > No, I=E2=80=99m saying that if you have two prefixes, one with a = preferred lifetime of zero, and another with a preferred lifetime that = is not zero, you should choose the second one. Can you explain in a = little more detail when this would cause a =E2=80=9Cdeterministic = flap=E2=80=9D? What we=E2=80=99re talking about is the case where you have two routers = advertising the same PIO with the same VL. Let=E2=80=99s assume you are = using a VL=3D3600 in your PIOs on both routers and that the routers = started up 1800 seconds apart. At T=3D0, you get RA from router A with prefix 2001:db8:4000:5000::/64 = PL=3D3600 You start a bunch of flows using that address. At T=3D1800, you get RA from router B with prefix = 2001:db8:b000:c000::/64 PL=3D3600. Your record for 2001:db8:4000:5000::/64 has PL=3D1800 remaining. Therefore, you now start (under your proposal) using = 2001:db8:b000:c000::/64 as your source prefix for all new flows. At T=3D3600, you get RA from router A refreshing prefix = 2001:db8:4000:5000::/64 PL=3D3600 which resets the PL timer for that prefix to 3600 while the PL timer for = =E2=80=A6:b000:c000::/64 has now counted down to 1800. Under your proposal, we flap back to = 2001:db8:4000:5000::/64. Lather, rinse, repeat this change in source address every 1800 seconds. Obviously, real world scenarios will be more complicated and the = randomness of RA refresh will come into play making it slightly less = deterministic as to when these flaps occur. >=20 >>> As for previous comments about source address selection, I think = that if >>> you have two prefixes that are otherwise equivalent (a tie), and one = has >>> a preferred lifetime of zero, while the other has a preferred = lifetime >>> of not-zero, it would be dysfunctional to choose the one with the >>> preferred lifetime of zero. What on earth is the purpose of = preferred >>> and valid lifetimes if SAS isn=E2=80=99t taking them into account? >>=20 >> The timers are only supposed to be of use if they go off. Given the >> default values the use (one month, and one week), they never go off. >>=20 >> The valid lifetime would trigger garbage collection for stale = prefixes. >> The preferred lifetime would keep a fresh and working address as the >> preferred address for new flows. -- if only they went of in a = timelier >> manner. >>=20 >> So, I'd rather ask the question: what on earth is the purpose of = setting >> a timer that will never go off in a meaningful situation and period = of time? >=20 > Possibly we are talking past each other. A prefix with a preferred = lifetime of zero always has a preferred lifetime of zero. There=E2=80=99= s no timer to go off. How the preferred lifetime got to be zero is of = course an important question, and there I think that what you are = getting at is important: a 30 day expiry time is way too long. >=20 > What if the user does want to release the prefix, e.g. for privacy = reasons? >=20 >> Not that I oppose to that. But I just note that there's no reason for = ot >> trusting a router that advertises PIO,VL=3D0, because your trust = model is >> that you do trust the router (if not your whole local network). >>=20 >>> If I get an RA that=E2=80=99s not signed by the same key as a route = in my >>> routing table that=E2=80=99s working, I don=E2=80=99t let it = override what is currently >>> in my routing table and working. >>=20 >> But that's not the current deployed reality. IN current deployments, = RAs >> are not signed. So why wuld you be skeptical to PIO, VL=3D0? >=20 > Right, we have a problem there. SEND didn=E2=80=99t solve it. I = don=E2=80=99t think RA Guard solves it for the home case. So, there is = work to do=E2=80=A6 :) Why can=E2=80=99t RA Guard solve it for the home case? Owen --Apple-Mail=_9259C8F5-BA20-43A0-90C8-89588A33B12A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 1, 2019, at 3:11 AM, Ted Lemon <mellon@fugue.com> = wrote:

On Nov 1, 2019, at = 5:45 AM, Fernando Gont <fgont@si6networks.com> wrote:
So why aren=E2=80=99t they doing = that?   What=E2=80=99s the obstacle?

Are you = referring to the CPE case, or to the = rest?

I=E2=80= =99m specifically referring to the ISP case, although I think referring = to it as =E2=80=9Cthe CPE case=E2=80=9D is limiting your options! = :)

If you assume all routers employ = the same values for the valid/preferred
lifetimes, then what you propose is the equivalent to "prefer = the last
advertised prefix". In which = case, in the presence of multiple RAs the
src address of new sessions will deterministically flap. That = doesn't
seem nice from a troubleshooting = perspective.

No, = I=E2=80=99m saying that if you have two prefixes, one with a preferred = lifetime of zero, and another with a preferred lifetime that is not = zero, you should choose the second one.   Can you explain in a = little more detail when this would cause a =E2=80=9Cdeterministic = flap=E2=80=9D?

What we=E2=80=99re talking about is the case where you = have two routers advertising the same PIO with the same VL. Let=E2=80=99s = assume you are using a VL=3D3600 in your PIOs on both routers and that = the routers started up 1800 seconds apart.

At T=3D0, you get RA from router A with prefix = 2001:db8:4000:5000::/64 PL=3D3600
You start a bunch of flows = using that address.
At T=3D1800, you get RA from router B with = prefix 2001:db8:b000:c000::/64 PL=3D3600.
Your record for = 2001:db8:4000:5000::/64 has PL=3D1800 remaining.
Therefore, = you now start (under your proposal) using 2001:db8:b000:c000::/64 as = your source
prefix for all new flows.
At T=3D3600, = you get RA from router A refreshing prefix 2001:db8:4000:5000::/64 = PL=3D3600
which resets the PL timer for that prefix to 3600 = while the PL timer for =E2=80=A6:b000:c000::/64
has now = counted down to 1800. Under your proposal, we flap back to = 2001:db8:4000:5000::/64.

Lather, = rinse, repeat this change in source address every 1800 = seconds.

Obviously, real world = scenarios will be more complicated and the randomness of RA refresh will = come into play making it slightly less deterministic as to when these = flaps occur.


As for previous comments about source address = selection, I think that if
you have two prefixes that are = otherwise equivalent (a tie), and one has
a preferred = lifetime of zero, while the other has a preferred lifetime
of not-zero, it would be dysfunctional to choose the one with = the
preferred lifetime of zero.  What on earth is the = purpose of preferred
and valid lifetimes if SAS isn=E2=80=99= t taking them into account?

The timers are only supposed to be of use if = they go off. Given the
default values the = use (one month, and one week), they never go off.

The valid lifetime would trigger = garbage collection for stale prefixes.
The preferred lifetime would keep a fresh and working address = as the
preferred address for new flows. = -- if only they went of in a timelier
manner.

So, I'd rather = ask the question: what on earth is the purpose of setting
a timer that will never go off in a = meaningful situation and period of time?

Possibly we are talking past each = other.   A prefix with a preferred lifetime of zero always has a = preferred lifetime of zero.   There=E2=80=99s no timer to go off. =   How the preferred lifetime got to be zero is of = course an important question, and there I think that what you are = getting at is important: a 30 day expiry time is way too long.

What if the user does want to release the prefix, e.g. for = privacy reasons?

Not that I oppose to that. But I just note = that there's no reason for ot
trusting a router = that advertises PIO,VL=3D0, because your trust model is
that you do trust the router (if not your = whole local network).

If I get = an RA that=E2=80=99s not signed by the same key as a route in my
routing table that=E2=80=99s working, I don=E2=80=99t let it = override what is currently
in my routing table and = working.

But that's not the = current deployed reality. IN current deployments, RAs
are not signed. So why wuld you be skeptical = to PIO, VL=3D0?

Right, we have a problem there.   SEND didn=E2=80=99t = solve it.   I don=E2=80=99t think RA Guard solves it for the home = case.   So, there is work to do=E2=80=A6 = :)

Why can=E2=80=99= t RA Guard solve it for the home case?

Owen

= --Apple-Mail=_9259C8F5-BA20-43A0-90C8-89588A33B12A-- From nobody Fri Nov 1 09:43:34 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EE01209CC for ; Fri, 1 Nov 2019 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bmDjD25KxIg for ; Fri, 1 Nov 2019 09:43:30 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 656C1120019 for ; Fri, 1 Nov 2019 09:43:30 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1GgMnb030639 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 09:42:26 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1GgMnb030639 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572626547; bh=ShBpDuvYFu8ZNqakDQ+pS+jr6Dx+ZgHHJ2fguO77HTg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=upeAO/5BB1Uq4oIMLrk+BPlexJ/KxbAPTQ2SKWdwAlpSdFO+bJBrCK13o5Qbx5LHD RDqvRW9prCuL5l9KSJ5ZZbR9TrZ0DjPbLMouWCpldYLFH8niU0qnmD9J2YZJLsxSKM 3JfWpTwKdEm5zjwAjgScjEDsJ1L38ry46IxzdiyI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: <20191101.124409.30333597.sthaug@nethelp.no> Date: Fri, 1 Nov 2019 09:42:22 -0700 Cc: otroan@employees.org, v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 09:42:27 -0700 (PDT) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:43:32 -0000 > So - TL;DR: We don't do "flash renumbering" for fun, on the other > hand we also don't strictly follow RFC 4192. Put another way, from the customer perspective=E2=80=A6 =E2=80=9CWe don=E2=80=99t do flash renumbering for fun, but we do value = our convenience above the impact this has on our customers and therefore when we find it convenient, we do flash renumber customers as needed.=E2=80=9D I=E2=80=99m not even saying this is necessarily an invalid approach. We = all know (or at least should know) that the margins in this industry don=E2=80=99t = support the cost involved in doing things differently, but, it does make a good case for why we should be looking at ways to mitigate this issue because in the real world, ISPs really do break DHCP lease promises on a regular basis. Owen >=20 > Steinar Haug, AS2116 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Nov 1 09:47:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9324B120122 for ; Fri, 1 Nov 2019 09:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 01H7CScsQwhc for ; Fri, 1 Nov 2019 09:47:49 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B266120019 for ; Fri, 1 Nov 2019 09:47:49 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id x21so13627372qto.12 for ; Fri, 01 Nov 2019 09:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vhW1NiCSshmuUmCP3eESwdo580DuZaAZNg+1o4T8Pgo=; b=k0kwOap9dlrIWck1nFBljacEUyyWG27Fha7Wce738xMCCWtmKa4GuXVXqX5qPljJoJ fz4xjxiuhaodeztUPM1ZQJa4/qj4eymG3Jmvfh0dRmfi0FcvvIpsfERHfORgECvWRJDe ocHw7BREKlZ0zjqbpKSNzd6+EL5pWSI53iJkGC5ZoznvxGecz8QbwVxTJAAFQtOE0aCh FTSdjLWrCAN4CzOjDObACZTYYUcB1WmwOD339B8IOWZgZVZM4Jv89BJHB0At8v7H6Klf OZJ0rUjeeVwfktlK4AnvDdiLLeZM91efYHFJhdtrSbneGEYjdFEkA1o8Fnu+F9KpA2ij 1GTg== 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=vhW1NiCSshmuUmCP3eESwdo580DuZaAZNg+1o4T8Pgo=; b=ALTzxPLRZbK183JNnpKJ07szNRBYl+nFiVWFKSdr3OJMXV93gauz/auB3C311B5+6K rLTvBb3/zEVcaXuxf35Gck8Mu90Px4NFfMgumELb6V1Nc22d4J2Mbx8e9HansHGSoRB4 tsvm87gIKj8FDW2QQKTZPlZub/Z05ac0NXfItVH9HGXlUpDuvV7bK5s9KnzETLv8x/uk NoV9s8eXYd2cN4s8vnshEVqswwl3BMq6JMv9XEZe2fO+Re/tNGD6NkqSoe5Sr3JC1rC5 n1+xC+8WZX6Vp9R5W57SM8cPsdCbjY4NADl9xxrUfczSf7ZVDQGgiZ0lJW+i+FH2MNED iA0A== X-Gm-Message-State: APjAAAU5IL6asCp/osyuVoYB5ivZSDCRlfyXysC7/v3Otsi0kSnq0NA9 TlqWASXExbq8TuZra0P3UvadC483ncocLg== X-Google-Smtp-Source: APXvYqzyiFgLIzJz4WvfNVRSYK8glq2OlgmW4WsgU5yRZ3L3P3V/s8OAauBGHeQ7bJZWwfWSbJOcng== X-Received: by 2002:ac8:e42:: with SMTP id j2mr217466qti.131.1572626868349; Fri, 01 Nov 2019 09:47:48 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:cef:776b:2643:f7b7? ([2601:18b:300:36ee:cef:776b:2643:f7b7]) by smtp.gmail.com with ESMTPSA id a28sm3698730qkn.126.2019.11.01.09.47.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 09:47:47 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D86FCE74-3695-404B-82ED-F43703272D9E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 1 Nov 2019 12:47:45 -0400 In-Reply-To: Cc: sthaug@nethelp.no, v6ops@ietf.org To: Owen DeLong References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:47:52 -0000 --Apple-Mail=_D86FCE74-3695-404B-82ED-F43703272D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 12:42 PM, Owen DeLong wrote: > I=E2=80=99m not even saying this is necessarily an invalid approach. = We all know > (or at least should know) that the margins in this industry don=E2=80=99= t support > the cost involved in doing things differently, I don=E2=80=99t think that=E2=80=99s the issue. I think the issue is = that =E2=80=9Cno flash renumbering=E2=80=9D is a nice-to-have, not a = must, because the layers above layer two can adapt when layer two = breaks. We=E2=80=99ve done a lot of efforts to try to fix this problem = at layer two, and none of them have succeeded. This is not to say that making layer two as solid as possible = shouldn=E2=80=99t be a goal; just that it is merely one of the tools we = have for making the network reliable, not the /only/ tool. --Apple-Mail=_D86FCE74-3695-404B-82ED-F43703272D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 12:42 PM, Owen DeLong <owen@delong.com> = wrote:
I=E2=80=99m = not even saying this is necessarily an invalid approach. We all = know
(or at least = should know) that the margins in this industry don=E2=80=99t = support
the cost = involved in doing things differently,

I don=E2=80=99t think that=E2=80=99s the = issue.   I think the issue is that =E2=80=9Cno flash renumbering=E2=80= =9D is a nice-to-have, not a must, because the layers above layer two = can adapt when layer two breaks.   We=E2=80=99ve done a lot of = efforts to try to fix this problem at layer two, and none of them have = succeeded.

This = is not to say that making layer two as solid as possible shouldn=E2=80=99t= be a goal; just that it is merely one of the tools we have for making = the network reliable, not the /only/ tool.

= --Apple-Mail=_D86FCE74-3695-404B-82ED-F43703272D9E-- From nobody Fri Nov 1 11:06:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E78120F87 for ; Fri, 1 Nov 2019 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tcNb2Li-q57 for ; Fri, 1 Nov 2019 11:06:44 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5977C120F6B for ; Fri, 1 Nov 2019 11:06:44 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id h2so758586qto.1 for ; Fri, 01 Nov 2019 11:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=Cg1SuMD7KCSA9nFtzGNmmHo7N8JAypKI0azk0dHu6Nk=; b=gkikDuvrVA5e1FXGuAWnGCte7Er7/ZYIfhFmxVci4w20Uaww9+u05awVQqmc4KGinI Mkcczi3wSK1GkYBAZ1yd245ZpD7EC9dD2LzWX4wcqNzgOYK595KlAj3N1oz8KUhOfBcs yhfi0nmMwh6TiigHTHgR/rxgnzShem6QXKXO+hJ7hyAi7faMp1Z62yeky8K0WQ8ZDLcE 2PnGdZLUZBkuTZ1akSagjwrQJuvN4Vk+1F9To+mVNtuQqV6BpfgjvmKYNZg8i8UMgRSu MwGG8OTkmxtolbROOhiiRJWNlaI/Bxc5v0dH9R4pqw2gxXndG+AriqVelbvH/el/kKBZ HKNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=Cg1SuMD7KCSA9nFtzGNmmHo7N8JAypKI0azk0dHu6Nk=; b=LaNZ8YlgjZXmMtMEd5heNxKsjfWUY66Tn3UV6w/eeMlUmacwX0pG87lAluU6r2OtX7 eSuB25NpKGFRPi2P9gYlU8QpP5grruLLD3WmYqBTNF1zvm1lCQutWVWYdBoQItMK3PEx +8wC3CyTejokVbf4+aiOpDWZBe+H3OhfTcZVpmqmKW7g23tj3md2/Hx4mduPFwwtfmdM 8ozlX1WImZodK74txeefl8b1IK+qGRcA6gZo83UQ+MGC1fJmddMijbZecxKGcN5l9p6L LuJObITaxsrtpXDH0NaT/pH54RpaMj4gr3pclCscspSHVhZksh2IH15D0n+0/5+BI3yb 9Usw== X-Gm-Message-State: APjAAAXKKyJdzXoA4xyixtyVZn9ckuREq8QRMH5WUssvpzoB+svS4tNj mQF509HfsCTLQ2DZbb37pGWGIIFLXOg= X-Google-Smtp-Source: APXvYqxdOwEmHfOVcVGAf/BSdoNp8+O91teI8xfWa4B/JdrDiZ11exzC9MHJKAMYeC+1A4vNKHmGUw== X-Received: by 2002:ac8:4a0d:: with SMTP id x13mr670842qtq.164.1572631603021; Fri, 01 Nov 2019 11:06:43 -0700 (PDT) Received: from ?IPv6:2620:f:8000:210:2142:621f:4c88:b238? ([2620:f:8000:210:2142:621f:4c88:b238]) by smtp.gmail.com with ESMTPSA id w69sm5078839qkb.26.2019.11.01.11.06.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 11:06:42 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_EE3B130A-B8D6-42DA-9F50-6FBA89E70994" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: References: <157263136295.32004.4925459918112981336.idtracker@ietfa.amsl.com> To: IPv6 Operations Date: Fri, 1 Nov 2019 14:06:41 -0400 X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [v6ops] Fwd: [106all] IETF 106 Standard Registration and Internet Draft Deadline Approaching: Monday, November 4, 2019 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 18:06:51 -0000 --Apple-Mail=_EE3B130A-B8D6-42DA-9F50-6FBA89E70994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In case anyone didn't see this... > Begin forwarded message: >=20 > From: IETF Secretariat > Subject: [106all] IETF 106 Standard Registration and Internet Draft = Deadline Approaching: Monday, November 4, 2019 > Date: November 1, 2019 at 2:02:42 PM EDT > To: "IETF Announcement List" > Cc: recentattendees@ietf.org, ietf@ietf.org, 106all@ietf.org > Reply-To: agenda@ietf.org >=20 > IETF 106 > Singapore > November 16-22, 2019 > Hosted By: Nokia >=20 > Standard Registration Deadline >=20 > REMINDER: The standard deadline for registration is Monday, = November 4th. > Be sure to register and pay before the deadline passes! > Register online at: https://ietf.org/how/meetings/register/ >=20 > NOTE: If you have started the registration process but not = completed > payment, your registration record will be deleted at UTC 23:59 = on > Monday, November 4th. After November 4th at UTC 23:59 you will = be required to > re-enter your data and the registration fee will be $1,000 USD. > =09 > Internet Draft Deadline: >=20 > Internet Draft submission cut-off (for all drafts, including = -00) > is Monday, November 4th by UTC 23:59. Please feel free to > upload drafts using the upload submissions tool found below: > https://datatracker.ietf.org/submit/ >=20 > If you have any questions or need assistance, please do not hesitate = to=20 > contact: ietf-registrar@ietf.org >=20 > --=20 > 106all mailing list > 106all@ietf.org > https://www.ietf.org/mailman/listinfo/106all --Apple-Mail=_EE3B130A-B8D6-42DA-9F50-6FBA89E70994 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In = case anyone didn't see this...

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>
Subject: = [106all] IETF 106 = Standard Registration and Internet Draft Deadline Approaching: Monday, = November 4, 2019
Date: November 1, 2019 at 2:02:42 PM EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: recentattendees@ietf.org, ietf@ietf.org, 106all@ietf.org
Reply-To: = agenda@ietf.org

IETF 106
Singapore
November = 16-22, 2019
Hosted By: Nokia

Standard Registration Deadline

=       REMINDER: The standard deadline for = registration is Monday, November 4th.
=       Be sure to register and pay before = the deadline passes!
=       Register online at: https://ietf.org/how/meetings/register/

      NOTE: If you have = started the registration process but not completed
=       payment, your registration record = will be deleted at UTC 23:59 on
=       Monday, November 4th. After November = 4th at UTC 23:59 you will be required to
=       re-enter your data and the = registration fee will be $1,000 USD.

Internet Draft Deadline:

Internet = Draft submission cut-off (for all drafts, including -00)
= is Monday, November 4th by UTC 23:59. Please feel free to
= upload drafts using the upload submissions tool found below:
= https://datatracker.ietf.org/submit/

If you have any questions or need assistance, please do not = hesitate to
contact: ietf-registrar@ietf.org

-- =
106all mailing list
106all@ietf.org
https://www.ietf.org/mailman/listinfo/106all

= --Apple-Mail=_EE3B130A-B8D6-42DA-9F50-6FBA89E70994-- From nobody Fri Nov 1 11:15:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5596D120F5E for ; Fri, 1 Nov 2019 11:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_WrxHIoqh1a for ; Fri, 1 Nov 2019 11:14:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 99AE4120F20 for ; Fri, 1 Nov 2019 11:14:48 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1IEX4Y019328 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 11:14:34 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1IEX4Y019328 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572632076; bh=6Aik4EGAChy2NnGoFi4zgmeeyBsd6B6jpQqisMEJUBA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OmTYNaw7Fr9uNngcdib8cor4tjKzBqUa5bqdzVoAOJssUUvGcy60i8YtZsKvoMItD 7vbU/VqHknXdnHjK2Ypgw46VktoqqXcIYuojrocYekjCeG2fYVNBqkHFU+WWP15U8i C6wV0rT6qnQCNBdlkZur8iaBs3JQ9ENUYFerhsqw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: Date: Fri, 1 Nov 2019 11:14:32 -0700 Cc: Fernando Gont , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <020501A3-CF94-474A-8763-1DC9E111B865@delong.com> References: <8f46bb68-1713-8c68-96b1-c46cf2003325@si6networks.com> <071E7287-74DD-44B9-9917-5231652F9E3D@delong.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 11:14:36 -0700 (PDT) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 18:14:57 -0000 Rebind isn=E2=80=99t the same as remembering. Consider the situation where a cable provider rehouse the customer to an = entirely different CMTS which may utilize an entirely different DHCP = server. A rebind is not going to get useful timer data in response. Owen > On Nov 1, 2019, at 9:16 AM, Bernie Volz (volz) wrote: >=20 >> Where is the mention of storing the expiration times? >=20 > Also, based on RFC8415 this means that the client should use a DHCPv6 = Rebind when it powers back on as now it has the information to ask = whether it is still valid (assuming it hasn't expired)? >=20 > See Section 18.2.18 of RFC8415: >=20 > Whenever a client may have moved to a new link, the > prefixes/addresses assigned to the interfaces on that link may no > longer be appropriate for the link to which the client is attached. > Examples of times when a client may have moved to a new link include > the following: >=20 > - The client reboots (and has stable storage and persistent DHCP > state). >=20 > - The client is reconnected to a link on which it has obtained > leases. >=20 > - The client returns from sleep mode. >=20 > - The client changes access points (e.g., if using Wi-Fi > technology). > ... >=20 > If the client has any valid delegated prefixes obtained from the = DHCP > server, the client MUST initiate a Rebind/Reply message exchange as > ... >=20 >=20 > - Bernie >=20 > =EF=BB=BFOn 11/1/19, 11:41 AM, "v6ops on behalf of Owen DeLong" = wrote: >=20 >=20 >=20 >> On Oct 31, 2019, at 8:06 PM, Fernando Gont = wrote: >>=20 >> On 31/10/19 16:39, Owen DeLong wrote: >>>=20 >>>=20 >>>> On Oct 31, 2019, at 12:25 PM, Fernando Gont = wrote: >>>>=20 >>>> On 27/10/19 10:54, Ted Lemon wrote: >>>>> On Oct 27, 2019, at 9:41 AM, Philip Homburg = >>>> > wrote: >>>>>> The little bit missing is that the CPE should write prefixes >>>>>> advertised using >>>>>> SLAAC to persistent storage which allows the CPE to invalidate = stale >>>>>> prefixes >>>>>> after a reboot. >>>>>=20 >>>>> Actually I do not believe this is correct behavior. Let us = assume >>>>> prefix delegation. If we have prefix delegation, then when the = CPE >>>>> comes back from a power cycle, it should reconfirm the prefix it = had >>>>> previously; the assumption is that that prefix is still valid. = This can >>>>> be handled in infrastructure=E2=80=94the ISP edge router should = know whether the >>>>> prefix is still valid, because if it is it should be advertising a = route >>>>> for it. If it is not still valid, then the CPE router should = attempt >>>>> to renew it, which would go to the DHCP server (possibly both = messages >>>>> would). >>>>=20 >>>> That assues the CPE has stored the previously-leased prefix on = stable >>>> storage -- which does not need to be the case. Hence the related = text in >>>> our I-D. >>>=20 >>> IMHO, the CPE requirements should be increased and the CPE should be = required >>> to store the prefix and it=E2=80=99s expected valid and preferred = expiration times in persistent >>> storage. I would like to see the text in the I-D updated = accordingly. >>=20 >> It's already there (draft-gont-v6ops-slaac-renum-00): >>=20 >> 3.2.1. Signaling Stale Configuration Information >>=20 >> In order to phase-out stale configuration information: >>=20 >> o A CPE router sending RAs that advertise dynamically-learned >> prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on >> stable storage, the list of prefixes being advertised on each >> network segment. >=20 > Where is the mention of storing the expiration times? >=20 > Did I miss it, or did you miss that part of my comment? >=20 > Owen >=20 >>=20 >>=20 >> Thanks! >>=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 From nobody Fri Nov 1 11:19:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1A71209BA for ; Fri, 1 Nov 2019 11:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 0XuPaA9LX1ZZ for ; Fri, 1 Nov 2019 11:19:53 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26912006F for ; Fri, 1 Nov 2019 11:19:53 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A69A4E6079; Fri, 1 Nov 2019 19:19:51 +0100 (CET) Date: Fri, 01 Nov 2019 19:19:51 +0100 (CET) Message-Id: <20191101.191951.54041693.sthaug@nethelp.no> To: owen@delong.com Cc: otroan@employees.org, v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: References: <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 18:19:56 -0000 >> So - TL;DR: We don't do "flash renumbering" for fun, on the other >> hand we also don't strictly follow RFC 4192. > > Put another way, from the customer perspective$B!D(B > > $B!H(BWe don$B!G(Bt do flash renumbering for fun, but we do value our convenience > above the impact this has on our customers and therefore when we find it > convenient, we do flash renumber customers as needed.$B!I(B Not sure if you understood my example: 1. DHCP customer needs to be moved to a different router. 2. Because customer will be moved to a different router, customer *will* be down for some time. 3. Moving the customer is done as a planned activity, at night, with alert to the customer several days in advance, in order to minimize customer inconvenience. Also, not directly related to the above: Business customers can also choose static addresses. If such a customer needs to be moved to a new router, addresses are also moved. I fail to see how this can be described as "we value our convenience above the impact this has on our customers". But I'll stop here. Steinar Haug, AS2116 From nobody Fri Nov 1 11:24:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1652E12101D for ; Fri, 1 Nov 2019 11:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0JSs4QKjvVr for ; Fri, 1 Nov 2019 11:24:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC1C120D23 for ; Fri, 1 Nov 2019 11:24:05 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1INs3k021638 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 11:23:55 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1INs3k021638 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572632635; bh=qXMNDAvi5rxulbcdcJyAD7QdKDAQSxPiT0XRKD27rR8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=VcnMnIJ5+vYWEyqfq+uLX8uFt2e45pQ3/wrleqcD1osD+O3bjwPPnUr9+tC68cGOC juby47ZNxG+rCPxaHmqq6nGuKRAsi7lBMyjEVBkzjq0PKT6GPA3NME7P9yvLS5e/3U tDwoB75BZCxYHM/S5C/t09NArN7dEPhr+RDglbt8= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4DE57380-0433-4E2C-9E4C-996763CE69D7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Fri, 1 Nov 2019 11:23:54 -0700 In-Reply-To: Cc: sthaug@nethelp.no, v6ops@ietf.org To: Ted Lemon References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 11:23:55 -0700 (PDT) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 18:24:16 -0000 --Apple-Mail=_4DE57380-0433-4E2C-9E4C-996763CE69D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 1, 2019, at 9:47 AM, Ted Lemon wrote: >=20 > On Nov 1, 2019, at 12:42 PM, Owen DeLong > wrote: >> I=E2=80=99m not even saying this is necessarily an invalid approach. = We all know >> (or at least should know) that the margins in this industry don=E2=80=99= t support >> the cost involved in doing things differently, >=20 > I don=E2=80=99t think that=E2=80=99s the issue. I think the issue is = that =E2=80=9Cno flash renumbering=E2=80=9D is a nice-to-have, not a = must, because the layers above layer two can adapt when layer two = breaks. We=E2=80=99ve done a lot of efforts to try to fix this problem = at layer two, and none of them have succeeded. Flash renumbering is NOT a layer 2 issue, it=E2=80=99s a layer 3 issue. > This is not to say that making layer two as solid as possible = shouldn=E2=80=99t be a goal; just that it is merely one of the tools we = have for making the network reliable, not the /only/ tool. Yeah, but we=E2=80=99re really talking more about layer 3 than layer 2 = here. Owen --Apple-Mail=_4DE57380-0433-4E2C-9E4C-996763CE69D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 1, 2019, at 9:47 AM, Ted Lemon <mellon@fugue.com> = wrote:

On Nov 1, 2019, at = 12:42 PM, Owen DeLong <owen@delong.com> wrote:
I=E2=80=99m not even saying this is necessarily an invalid = approach. We all know
(or at least should know) that the margins in this industry = don=E2=80=99t support
the cost involved in doing things = differently,

I don=E2=80=99t think that=E2=80=99s the issue.   I = think the issue is that =E2=80=9Cno flash renumbering=E2=80=9D is a = nice-to-have, not a must, because the layers above layer two can adapt = when layer two breaks.   We=E2=80=99ve done a lot of efforts to try = to fix this problem at layer two, and none of them have = succeeded.

Flash = renumbering is NOT a layer 2 issue, it=E2=80=99s a layer 3 = issue.

This = is not to say that making layer two as solid as possible shouldn=E2=80=99t= be a goal; just that it is merely one of the tools we have for making = the network reliable, not the /only/ = tool.

Yeah, but = we=E2=80=99re really talking more about layer 3 than layer 2 = here.

Owen

= --Apple-Mail=_4DE57380-0433-4E2C-9E4C-996763CE69D7-- From nobody Fri Nov 1 11:33:18 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE551210F8 for ; Fri, 1 Nov 2019 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 05FLWQcXb5EA for ; Fri, 1 Nov 2019 11:33:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 90755121144 for ; Fri, 1 Nov 2019 11:33:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iQbjJ-0000FNC; Fri, 1 Nov 2019 19:33:01 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> In-reply-to: Your message of "Fri, 1 Nov 2019 11:23:54 -0700 ." Date: Fri, 01 Nov 2019 19:32:58 +0100 Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 18:33:16 -0000 > This is not to say that making layer two as solid as possible > shouldn't be a goal; just that it is merely one of the tools we > have for making the network reliable, not the /only/ tool. > > Yeah, but we're really talking more about layer 3 than layer 2 > here. Conceptual it should not be hard for MPTCP to deal with this issue. In practice, we may have a bit of deployment problem. But the bigger question would be, if MPTCP would iterate over all possible sources addresses in a happy-eyeball fashion, is that something we want? We already have the issue that HE masks brokenness. If we promote that as a default mode in transport protocols, we may invite quite a big mess. From nobody Fri Nov 1 11:59:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4671200B6 for ; Fri, 1 Nov 2019 11:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI2rkmLO4f8z for ; Fri, 1 Nov 2019 11:59:54 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BBCBA120073 for ; Fri, 1 Nov 2019 11:59:40 -0700 (PDT) Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1Iwa0H028064 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 11:58:37 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1Iwa0H028064 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572634718; bh=ijhGIFM9cXcjoO6bauv6VJ7kqsarLFoT0G9/BM8/lZo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=R17web3DdKVBTJ4a5HbHl+xGd6GvTfLe9BdgmqDbS/uw0tyBNCE2fOnEqTMzaBwx6 ZbI+5G236+BaH6Pts7pjTo058dlfcRL3ztw8wsnptCIpCsw0MGzX2myP3jSgynx+t7 ib7FG4b/TU8Zx7mZyaFQnGflegEsG6IJVdxVmOY8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: <20191101.191951.54041693.sthaug@nethelp.no> Date: Fri, 1 Nov 2019 11:58:35 -0700 Cc: otroan@employees.org, v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6302CC3A-A26E-42B4-A455-D031ACC9D047@delong.com> References: <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> <20191101.191951.54041693.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 11:58:38 -0700 (PDT) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 18:59:56 -0000 > On Nov 1, 2019, at 11:19 AM, sthaug@nethelp.no wrote: >=20 >>> So - TL;DR: We don't do "flash renumbering" for fun, on the other >>> hand we also don't strictly follow RFC 4192. >>=20 >> Put another way, from the customer perspective=E2=80=A6 >>=20 >> =E2=80=9CWe don=E2=80=99t do flash renumbering for fun, but we do = value our convenience >> above the impact this has on our customers and therefore when we find = it >> convenient, we do flash renumber customers as needed.=E2=80=9D >=20 > Not sure if you understood my example: >=20 > 1. DHCP customer needs to be moved to a different router. > 2. Because customer will be moved to a different router, customer > *will* be down for some time. > 3. Moving the customer is done as a planned activity, at night, with > alert to the customer several days in advance, in order to minimize > customer inconvenience. Well, consider this optional (but less convenient) approach: Customers moving to other routers are generally groups of customers. = (e.g. CMTS splits, etc.) In such a case, creating a new prefix for that class of customers and = advertising it to them several days in advance as well as shortening the = preferred and valid lifetimes on the old prefix at that same time could = be done. The new prefix would then move with the customers. This is inconvenient, but achievable. If you then wanted to migrate the = customers to the prefix associated with the new router instead of making = the transition prefix permanent, you could use short preferred and valid = lifetimes on the transition prefix and start expiring it once the move = was completed and the new permanent prefix had been advertised to them. > Also, not directly related to the above: Business customers can also > choose static addresses. If such a customer needs to be moved to a > new router, addresses are also moved. Sure. > I fail to see how this can be described as "we value our convenience > above the impact this has on our customers". But I'll stop here. See above. Owen From nobody Fri Nov 1 12:39:49 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4651209A5 for ; Fri, 1 Nov 2019 12:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 wnBMbaeFs-kk for ; Fri, 1 Nov 2019 12:39:45 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCC8120843 for ; Fri, 1 Nov 2019 12:39:45 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id h2so1149163qto.1 for ; Fri, 01 Nov 2019 12:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XVZjtFNc6HM1YAX4VRFIL6ny5nBi9pMY/F09yaGOdug=; b=AsToR71/ggUafjoNv3gTr26tnk7Hmt0jMuJXYz4S0GL7HPGt0GUrAkDbtb6YrBWXqy F7SH4A3lJ9g2Zlx73lnNjW9G4+kWekeSmKoa7uOsknuGrPQOW/Me+/7N8ye4R9crsacS Q59i40/ADK1EXcTi1O0lXUfsw57tV3Lrn4ECwk4hiT7zlLz8d4pZ5sIp1HMnjsEi9fwX EYc3dfdZhL1t9xKiyNlmXye5b60v59oYsZVonI3P+I6Y08yCoVDlXedt88ba29haYiku dFfOvlHgl1AlFf61/SYyO3yWgNe9j00stg46SvgEBUvgGCE6gZQTbEVH93cDBgu5yt4O jSww== 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=XVZjtFNc6HM1YAX4VRFIL6ny5nBi9pMY/F09yaGOdug=; b=BMNDG+m0ZTNQQwqbitqNpcwdvzj5ow5y5HnDVB8b8aOohRWQPgdAzk/0zzc4IzsmLb XY112Q+Y8hDDI+PKBj2O6QjSKjeva7DLE3wTcJnkcn/8diqoTgqWg3lRYI4ReL82nDiB aCHrD/QWhWxmMx/SOyewxW5JVnqxIYPwQBWf9orRW3aM5KVp7PGppHJkacBvT0mdCp5V +KvYOzD+Af8r00jwyJFMfDKNcd3BM8kWDPB7cSCIcGv62Q0d322uLddwDRgSiHv6217P bAJGkwSO2x2KLwHpDToKpSEYaVaWmAcCFSQYFwxM2jR/g7T8uv5g2t3rbLFH6XC0hipX HSEg== X-Gm-Message-State: APjAAAWkk3uVBEJ2kUEqFhTnicFSZkrVkAYbR4u8tHTgFlU3ZngFQRQ9 Ue+I6NLR/Vp7VpAJS3WJwDvAuD5Lu9taOQ== X-Google-Smtp-Source: APXvYqxxhWw0INv7SHDD9qqHg5Dwu1Ixw/XjLafsxOGAIi8U04+vh/XfHhOVEqM1PuIVvOL7HgWpdw== X-Received: by 2002:ac8:2432:: with SMTP id c47mr1136879qtc.74.1572637184205; Fri, 01 Nov 2019 12:39:44 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:cef:776b:2643:f7b7? ([2601:18b:300:36ee:cef:776b:2643:f7b7]) by smtp.gmail.com with ESMTPSA id h185sm4757851qkc.7.2019.11.01.12.39.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 12:39:43 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_765FFF18-2197-4ED7-9E23-8632BCD2D48E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 1 Nov 2019 15:39:42 -0400 In-Reply-To: Cc: sthaug@nethelp.no, v6ops@ietf.org To: Owen DeLong References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 19:39:48 -0000 --Apple-Mail=_765FFF18-2197-4ED7-9E23-8632BCD2D48E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 1, 2019, at 2:23 PM, Owen DeLong wrote: >> I don=E2=80=99t think that=E2=80=99s the issue. I think the issue = is that =E2=80=9Cno flash renumbering=E2=80=9D is a nice-to-have, not a = must, because the layers above layer two can adapt when layer two = breaks. We=E2=80=99ve done a lot of efforts to try to fix this problem = at layer two, and none of them have succeeded. >=20 > Flash renumbering is NOT a layer 2 issue, it=E2=80=99s a layer 3 = issue. >=20 >> This is not to say that making layer two as solid as possible = shouldn=E2=80=99t be a goal; just that it is merely one of the tools we = have for making the network reliable, not the /only/ tool. >=20 > Yeah, but we=E2=80=99re really talking more about layer 3 than layer 2 = here. Sorry, I was referring to layer 3. I think I was still thinking about = RA Guard for some reason, and that=E2=80=99s an L2 thing. --Apple-Mail=_765FFF18-2197-4ED7-9E23-8632BCD2D48E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 1, 2019, at 2:23 PM, Owen DeLong <owen@delong.com> = wrote:
I don=E2=80=99t think that=E2=80=99s = the issue.   I think the issue is that =E2=80=9Cno flash = renumbering=E2=80=9D is a nice-to-have, not a must, because the layers = above layer two can adapt when layer two breaks.   We=E2=80=99ve = done a lot of efforts to try to fix this problem at layer two, and none = of them have succeeded.

Flash = renumbering is NOT a layer 2 issue, it=E2=80=99s a layer 3 = issue.

This is not to say that making layer = two as solid as possible shouldn=E2=80=99t be a goal; just that it is = merely one of the tools we have for making the network reliable, not the = /only/ tool.

Yeah, but we=E2=80=99re really talking more about layer 3 = than layer 2 here.

Sorry, I was referring to layer 3.   I think = I was still thinking about RA Guard for some reason, and that=E2=80=99s = an L2 thing.

= --Apple-Mail=_765FFF18-2197-4ED7-9E23-8632BCD2D48E-- From nobody Fri Nov 1 13:46:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C765120013 for ; Fri, 1 Nov 2019 13:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 header.b=AJwewRPM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NT3Noa/C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNoXy-RpR3Mh for ; Fri, 1 Nov 2019 13:45:58 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A04212000F for ; Fri, 1 Nov 2019 13:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7402; q=dns/txt; s=iport; t=1572641082; x=1573850682; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=w44YPXcdDSuTRBwRmUjRH3yW4ItvWGJSWtnZP2JT28U=; b=AJwewRPM/7MI2UWjKwtZh/pseMdsVRdY2cSIySIeH6osb5Iz8sVu0myK xa3tZ1BkBFFPsSs+0W3Kt96aDFqZtIvvPukRUKbloJVxnzUbhm/cAORui kLN9TtCTcYQ+RvAK+qpixc+5DFo1/zF57Q4LJqxozCyyXqRbAYATyC2op M=; IronPort-PHdr: =?us-ascii?q?9a23=3AIqPq+B3/9kg4rx1fsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdCCDV/TJ//xZCt8F8NHBxdo?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAADWl7xd/4ENJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFsAgEBAQELAYFKJAUnBWxYIAQLKgqEHoNGA4p?= =?us-ascii?q?1gl5/ln2CUgNUCQEBAQwBARgLCgIBAYRAAheDZCQ3Bg4CAwsBAQQBAQECAQU?= =?us-ascii?q?EbYU3DIVRAQEBAQIBAQEQEREMAQEsCwEEBwQCAQgRBAEBAQICIwMCAgIlCxQ?= =?us-ascii?q?BCAgCBA4FCBqDAYJGAw4gAQ6oBgKBOIhgdYEygn4BAQWBNAGDYxiCFwMGgQ4?= =?us-ascii?q?oAYwQGIF/gRFGghc1PoJiAQECAYFCBgIWFRWCZDKCLI0LCYJph3eWAgqCJIc?= =?us-ascii?q?RhR6JIZllhFeGE4wEkSYCBAIEBQIOAQEFgWgjgVhwFTuCbFARFIMGDBeBBAE?= =?us-ascii?q?CgkmFFIU/dAEBgSaLBoEwAS9eAQE?= X-IronPort-AV: E=Sophos;i="5.68,256,1569283200"; d="scan'208";a="363419201" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 20:44:41 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1KifDb008634 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 20:44:41 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 15:44:40 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 16:44:40 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 15:44:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VZ9VFtmFSgM5jJ7viwTo6R1bJa38Kch6OxAKW+4LFfJ5CLtTqXR+OObl+fruTWKjwDGQSVxU4S40grWE6A5IuHPyAUfWj2ymCA/SwocAp+fgDCQtNCwg6QWOwyvKthhMtOYPMQn17qv5GAQp121zQ37fvmBpKISyMgTwJ2dW5UBVNbhUqCnX3B2UGhZz6j5Yo/kKtcFKzMURVIn7uYIJ/9bEcpnHIHaDp0Fy11T6MqryG9kkrzzbQ4t1YkktdOnWL3zQCcMQ6SA7iJfpOqe6UENqZop6KeF/FrozWKFPoSIvDPCRtltV4CvkJgxikWvY6M6ht3zySZJkGfU4n1NIPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w44YPXcdDSuTRBwRmUjRH3yW4ItvWGJSWtnZP2JT28U=; b=OLtKUom8IPXjTPxYTyn933PpsDFAEBQ3f+HKDbDWNMAXrJ/5ksYzUq+8K8mY75Sw1REF1JNaGuth1zzK2Omq4/qAEjvdgY3tPgcpV2hGegSjxIMNuVuFutp34Ogx40cWyqh3FQex5iwO5a2IusryWF65bFvk4pKX5OQHq2WVVQi4FcZRigtGV5UBOC7M3p0lYzyf5TA9vhQY+HyqC1ACaJxT8SoaYqni/OImag8bk/uv4aJVxKihiBbJ8NK/roEXTKzFmOvCbm4Asx2qh68zId/DY9E8KJMFdbt5YM/Z283YD41kXUfxDB2XWOuhjEnKDK2yGBRF7kEOOjAtoqUDxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w44YPXcdDSuTRBwRmUjRH3yW4ItvWGJSWtnZP2JT28U=; b=NT3Noa/C9DjjNDVfBrDj7d1R0FCVCWoWngOVupxI/EuT1VmmSpy1BMY+iOAtYMWg/Sb9A1N3CEIL7UC2mXFEfy/pWsSfScX+yCDQQQrvoJyh1Ol7qps/Polfy6UzpQuw4cazdw6AbdBqbgqduTn/gV6Cy9P2J40cQX/yAwURvCo= Received: from CY4PR1101MB2279.namprd11.prod.outlook.com (10.172.75.137) by CY4PR1101MB2328.namprd11.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Fri, 1 Nov 2019 20:44:38 +0000 Received: from CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab]) by CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab%10]) with mapi id 15.20.2387.030; Fri, 1 Nov 2019 20:44:38 +0000 From: "Bernie Volz (volz)" To: Owen DeLong CC: Fernando Gont , "v6ops@ietf.org" Thread-Topic: [v6ops] SLAAC renum: Problem Statement & Operational workarounds Thread-Index: AQHVibwc6PRwlsH+ZUmOeFzp+XKiI6dt8FJugAA0sICAAERiAIAACLmAgAATKlOAAANjAIAGpb+AgAAD94CAAHz9AIAA0laA///HGgCAAGQlAIAAKLqw Date: Fri, 1 Nov 2019 20:44:37 +0000 Message-ID: References: <8f46bb68-1713-8c68-96b1-c46cf2003325@si6networks.com> <071E7287-74DD-44B9-9917-5231652F9E3D@delong.com> <020501A3-CF94-474A-8763-1DC9E111B865@delong.com> In-Reply-To: <020501A3-CF94-474A-8763-1DC9E111B865@delong.com> 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=volz@cisco.com; x-originating-ip: [173.38.117.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54ac4ef0-3a57-46dc-ae6a-08d75f0c4ffc x-ms-traffictypediagnostic: CY4PR1101MB2328: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(376002)(366004)(189003)(13464003)(199004)(6436002)(2906002)(66574012)(66446008)(5660300002)(14454004)(71200400001)(25786009)(66556008)(6116002)(86362001)(64756008)(71190400001)(6916009)(3846002)(6246003)(26005)(7696005)(4326008)(66476007)(102836004)(33656002)(76176011)(316002)(446003)(256004)(6306002)(7736002)(11346002)(186003)(74316002)(53546011)(476003)(305945005)(6506007)(229853002)(55016002)(9686003)(478600001)(966005)(5024004)(76116006)(54906003)(81156014)(8676002)(486006)(66066001)(8936002)(66946007)(52536014)(14444005)(99286004)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2328; H:CY4PR1101MB2279.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lhpYVnQ9VO6k4V179LGT7fcWHb5KoTq2i4ShTx8Nyh2fDFd8OFDIJHLqy9xzBSXHoV7E5Kdo/Bmgf1dcZ97j4x82ziGNx7SG2OtZ1Pn5oFBERFzr97lk4HhhUVFLsLYpOf+zyvc4oUEpKdsn5T0q9q/q7Zm2UZjf66hXUYz+acoDe8OQQ51lXE3S1murRBLdAga6p36I+3MRcMar4N5H0bYRDCjYbujdvhU02BUzwJRyIy/fnCqWTAvc4mczvsIQxqNtaCbbjI6tMvd6Wns7c79j5geJJKV4H52Ai9zNEu9qSuyP9tp+a7QyBRGZdleUwIt1DOJtzdVbQHUk7njdJiGebw/azoyFeDIkzgcpQ3uI8qVpE6QnLzNqwspZG9PKgbIeAZB9xiHtKVxAEW5s9tgskqrl70ylLqXgieSaZJTvJAvgQ5l0yuTy1hWanWZDHKeq3+u2S4DAUST2ExkoAHkPYJ0aOyl+Me0wJkDAqlE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 54ac4ef0-3a57-46dc-ae6a-08d75f0c4ffc X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 20:44:38.0471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: A3Nb9593EwdQtPqhusig93WA8QdTWKqKa+BEgUVKMA8Mc1Vrnfkk8A4/ZpEy7zVt X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2328 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 20:46:04 -0000 T3dlbiAuLiB0aGlzIGlzIElGIHRoZSBkZXZpY2UgcmVtZW1iZXJzIChpLmUuLCB3cml0ZXMgdGhl IGluZm9ybWF0aW9uIHRvIHBlcnNpc3RlbnQgc3RvcmFnZSkuDQoNCj4gQSByZWJpbmQgaXMgbm90 IGdvaW5nIHRvIGdldCB1c2VmdWwgdGltZXIgZGF0YSBpbiByZXNwb25zZS4NCg0KWWVzLCBpdCBz aG91bGQuIFRoaXMgaXMgYmVjYXVzZSB0aGUgQ1BFIHdpbGwgaW5jbHVkZSBpdHMgZXhpc3Rpbmcg KHJlbWVtYmVyZWQpIHByZWZpeGVzIGluIHRoZSBSZWJpbmQgYW5kIHRoZSBzZXJ2ZXIgdGhhdCBy ZWNlaXZlcyB0aGlzIGNhbiBpbW1lZGlhdGVseSByZXNwb25kIHdpdGggbGlmZXRpbWVzIG9mIDAg aWYgdGhlIFBEcyBhcmUgbm8gbG9uZ2VyIHZhbGlkIGZvciB3aGVyZSB0aGUgQ1BFIGlzICJub3ci IGNvbm5lY3RlZC4gV2hpY2ggaXMgZXhhY3RseSB3aGF0IHlvdSB3YW50ZWQgdGhlIGRldmljZSB0 byBrbm93Lg0KDQpIZXJlJ3MgdGV4dCBmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM4NDE1I3NlY3Rpb24tMTguMy41Og0KDQogICBJZiB0aGUgc2VydmVyIGZpbmRzIHRoYXQgdGhl IGNsaWVudCBlbnRyeSBmb3IgdGhlIElBIGFuZCBhbnkgb2YgdGhlDQogICBhZGRyZXNzZXMgb3Ig ZGVsZWdhdGVkIHByZWZpeGVzIGFyZSBubyBsb25nZXIgYXBwcm9wcmlhdGUgZm9yIHRoZQ0KICAg bGluayB0byB3aGljaCB0aGUgY2xpZW50J3MgaW50ZXJmYWNlIGlzIGF0dGFjaGVkIGFjY29yZGlu ZyB0byB0aGUNCiAgIHNlcnZlcidzIGV4cGxpY2l0IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24s IHRoZSBzZXJ2ZXIgcmV0dXJucyB0aG9zZQ0KICAgYWRkcmVzc2VzIG9yIGRlbGVnYXRlZCBwcmVm aXhlcyB0byB0aGUgY2xpZW50IHdpdGggbGlmZXRpbWVzIG9mIDAuDQoNCi0gQmVybmllDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcu Y29tPiANClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMSwgMjAxOSAyOjE1IFBNDQpUbzogQmVybmll IFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4NCkNjOiBGZXJuYW5kbyBHb250IDxmZ29udEBz aTZuZXR3b3Jrcy5jb20+OyB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gU0xB QUMgcmVudW06IFByb2JsZW0gU3RhdGVtZW50ICYgT3BlcmF0aW9uYWwgd29ya2Fyb3VuZHMNCg0K UmViaW5kIGlzbuKAmXQgdGhlIHNhbWUgYXMgcmVtZW1iZXJpbmcuDQoNCkNvbnNpZGVyIHRoZSBz aXR1YXRpb24gd2hlcmUgYSBjYWJsZSBwcm92aWRlciByZWhvdXNlIHRoZSBjdXN0b21lciB0byBh biBlbnRpcmVseSBkaWZmZXJlbnQgQ01UUyB3aGljaCBtYXkgdXRpbGl6ZSBhbiBlbnRpcmVseSBk aWZmZXJlbnQgREhDUCBzZXJ2ZXIuIEEgcmViaW5kIGlzIG5vdCBnb2luZyB0byBnZXQgdXNlZnVs IHRpbWVyIGRhdGEgaW4gcmVzcG9uc2UuDQoNCk93ZW4NCg0KDQo+IE9uIE5vdiAxLCAyMDE5LCBh dCA5OjE2IEFNLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPiB3cm90ZToNCj4g DQo+PiAgIFdoZXJlIGlzIHRoZSBtZW50aW9uIG9mIHN0b3JpbmcgdGhlIGV4cGlyYXRpb24gdGlt ZXM/DQo+IA0KPiBBbHNvLCBiYXNlZCBvbiBSRkM4NDE1IHRoaXMgbWVhbnMgdGhhdCB0aGUgY2xp ZW50IHNob3VsZCB1c2UgYSBESENQdjYgUmViaW5kIHdoZW4gaXQgcG93ZXJzIGJhY2sgb24gYXMg bm93IGl0IGhhcyB0aGUgaW5mb3JtYXRpb24gdG8gYXNrIHdoZXRoZXIgaXQgaXMgc3RpbGwgdmFs aWQgKGFzc3VtaW5nIGl0IGhhc24ndCBleHBpcmVkKT8NCj4gDQo+IFNlZSBTZWN0aW9uIDE4LjIu MTggb2YgUkZDODQxNToNCj4gDQo+ICAgV2hlbmV2ZXIgYSBjbGllbnQgbWF5IGhhdmUgbW92ZWQg dG8gYSBuZXcgbGluaywgdGhlDQo+ICAgcHJlZml4ZXMvYWRkcmVzc2VzIGFzc2lnbmVkIHRvIHRo ZSBpbnRlcmZhY2VzIG9uIHRoYXQgbGluayBtYXkgbm8NCj4gICBsb25nZXIgYmUgYXBwcm9wcmlh dGUgZm9yIHRoZSBsaW5rIHRvIHdoaWNoIHRoZSBjbGllbnQgaXMgYXR0YWNoZWQuDQo+ICAgRXhh bXBsZXMgb2YgdGltZXMgd2hlbiBhIGNsaWVudCBtYXkgaGF2ZSBtb3ZlZCB0byBhIG5ldyBsaW5r IGluY2x1ZGUNCj4gICB0aGUgZm9sbG93aW5nOg0KPiANCj4gICAtICBUaGUgY2xpZW50IHJlYm9v dHMgKGFuZCBoYXMgc3RhYmxlIHN0b3JhZ2UgYW5kIHBlcnNpc3RlbnQgREhDUA0KPiAgICAgIHN0 YXRlKS4NCj4gDQo+ICAgLSAgVGhlIGNsaWVudCBpcyByZWNvbm5lY3RlZCB0byBhIGxpbmsgb24g d2hpY2ggaXQgaGFzIG9idGFpbmVkDQo+ICAgICAgbGVhc2VzLg0KPiANCj4gICAtICBUaGUgY2xp ZW50IHJldHVybnMgZnJvbSBzbGVlcCBtb2RlLg0KPiANCj4gICAtICBUaGUgY2xpZW50IGNoYW5n ZXMgYWNjZXNzIHBvaW50cyAoZS5nLiwgaWYgdXNpbmcgV2ktRmkNCj4gICAgICB0ZWNobm9sb2d5 KS4NCj4gLi4uDQo+IA0KPiAgIElmIHRoZSBjbGllbnQgaGFzIGFueSB2YWxpZCBkZWxlZ2F0ZWQg cHJlZml4ZXMgb2J0YWluZWQgZnJvbSB0aGUgREhDUA0KPiAgIHNlcnZlciwgdGhlIGNsaWVudCBN VVNUIGluaXRpYXRlIGEgUmViaW5kL1JlcGx5IG1lc3NhZ2UgZXhjaGFuZ2UgYXMgDQo+IC4uLg0K PiANCj4gDQo+IC0gQmVybmllDQo+IA0KPiDvu79PbiAxMS8xLzE5LCAxMTo0MSBBTSwgInY2b3Bz IG9uIGJlaGFsZiBvZiBPd2VuIERlTG9uZyIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIG93ZW5AZGVsb25nLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gDQo+PiBPbiBPY3QgMzEs IDIwMTksIGF0IDg6MDYgUE0sIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4g d3JvdGU6DQo+PiANCj4+IE9uIDMxLzEwLzE5IDE2OjM5LCBPd2VuIERlTG9uZyB3cm90ZToNCj4+ PiANCj4+PiANCj4+Pj4gT24gT2N0IDMxLCAyMDE5LCBhdCAxMjoyNSBQTSwgRmVybmFuZG8gR29u dCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IE9uIDI3LzEwLzE5 IDEwOjU0LCBUZWQgTGVtb24gd3JvdGU6DQo+Pj4+PiBPbiBPY3QgMjcsIDIwMTksIGF0IDk6NDEg QU0sIFBoaWxpcCBIb21idXJnIA0KPj4+Pj4gPHBjaC12Nm9wcy05QHUtMS5waGljb2guY29tIDxt YWlsdG86cGNoLXY2b3BzLTlAdS0xLnBoaWNvaC5jb20+PiB3cm90ZToNCj4+Pj4+PiBUaGUgbGl0 dGxlIGJpdCBtaXNzaW5nIGlzIHRoYXQgdGhlIENQRSBzaG91bGQgd3JpdGUgcHJlZml4ZXMgDQo+ Pj4+Pj4gYWR2ZXJ0aXNlZCB1c2luZyBTTEFBQyB0byBwZXJzaXN0ZW50IHN0b3JhZ2Ugd2hpY2gg YWxsb3dzIHRoZSBDUEUgDQo+Pj4+Pj4gdG8gaW52YWxpZGF0ZSBzdGFsZSBwcmVmaXhlcyBhZnRl ciBhIHJlYm9vdC4NCj4+Pj4+IA0KPj4+Pj4gQWN0dWFsbHkgSSBkbyBub3QgYmVsaWV2ZSB0aGlz IGlzIGNvcnJlY3QgYmVoYXZpb3IuICAgTGV0IHVzIGFzc3VtZQ0KPj4+Pj4gcHJlZml4IGRlbGVn YXRpb24uICAgSWYgd2UgaGF2ZSBwcmVmaXggZGVsZWdhdGlvbiwgdGhlbiB3aGVuIHRoZSBDUEUN Cj4+Pj4+IGNvbWVzIGJhY2sgZnJvbSBhIHBvd2VyIGN5Y2xlLCBpdCBzaG91bGQgcmVjb25maXJt IHRoZSBwcmVmaXggaXQgDQo+Pj4+PiBoYWQgcHJldmlvdXNseTsgdGhlIGFzc3VtcHRpb24gaXMg dGhhdCB0aGF0IHByZWZpeCBpcyBzdGlsbCB2YWxpZC4gIA0KPj4+Pj4gVGhpcyBjYW4gYmUgaGFu ZGxlZCBpbiBpbmZyYXN0cnVjdHVyZeKAlHRoZSBJU1AgZWRnZSByb3V0ZXIgc2hvdWxkIA0KPj4+ Pj4ga25vdyB3aGV0aGVyIHRoZSBwcmVmaXggaXMgc3RpbGwgdmFsaWQsIGJlY2F1c2UgaWYgaXQg aXMgaXQgc2hvdWxkIGJlIGFkdmVydGlzaW5nIGEgcm91dGUNCj4+Pj4+IGZvciBpdC4gICBJZiBp dCBpcyBub3Qgc3RpbGwgdmFsaWQsIHRoZW4gdGhlIENQRSByb3V0ZXIgc2hvdWxkIGF0dGVtcHQN Cj4+Pj4+IHRvIHJlbmV3IGl0LCB3aGljaCB3b3VsZCBnbyB0byB0aGUgREhDUCBzZXJ2ZXIgKHBv c3NpYmx5IGJvdGggDQo+Pj4+PiBtZXNzYWdlcyB3b3VsZCkuDQo+Pj4+IA0KPj4+PiBUaGF0IGFz c3VlcyB0aGUgQ1BFIGhhcyBzdG9yZWQgdGhlIHByZXZpb3VzbHktbGVhc2VkIHByZWZpeCBvbiAN Cj4+Pj4gc3RhYmxlIHN0b3JhZ2UgLS0gd2hpY2ggZG9lcyBub3QgbmVlZCB0byBiZSB0aGUgY2Fz ZS4gSGVuY2UgdGhlIA0KPj4+PiByZWxhdGVkIHRleHQgaW4gb3VyIEktRC4NCj4+PiANCj4+PiBJ TUhPLCB0aGUgQ1BFIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgaW5jcmVhc2VkIGFuZCB0aGUgQ1BF IHNob3VsZCBiZSANCj4+PiByZXF1aXJlZCB0byBzdG9yZSB0aGUgcHJlZml4IGFuZCBpdOKAmXMg ZXhwZWN0ZWQgdmFsaWQgYW5kIHByZWZlcnJlZCANCj4+PiBleHBpcmF0aW9uIHRpbWVzIGluIHBl cnNpc3RlbnQgc3RvcmFnZS4gSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgdGV4dCBpbiB0aGUgSS1E IHVwZGF0ZWQgYWNjb3JkaW5nbHkuDQo+PiANCj4+IEl0J3MgYWxyZWFkeSB0aGVyZSAoZHJhZnQt Z29udC12Nm9wcy1zbGFhYy1yZW51bS0wMCk6DQo+PiANCj4+IDMuMi4xLiAgU2lnbmFsaW5nIFN0 YWxlIENvbmZpZ3VyYXRpb24gSW5mb3JtYXRpb24NCj4+IA0KPj4gIEluIG9yZGVyIHRvIHBoYXNl LW91dCBzdGFsZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uOg0KPj4gDQo+PiAgbyAgQSBDUEUg cm91dGVyIHNlbmRpbmcgUkFzIHRoYXQgYWR2ZXJ0aXNlIGR5bmFtaWNhbGx5LWxlYXJuZWQNCj4+ ICAgICBwcmVmaXhlcyAoZS5nLiB2aWEgREhDUHY2LVBEKSBvbiBhbiBpbnRlcmZhY2UgTVVTVCBy ZWNvcmQsIG9uDQo+PiAgICAgc3RhYmxlIHN0b3JhZ2UsIHRoZSBsaXN0IG9mIHByZWZpeGVzIGJl aW5nIGFkdmVydGlzZWQgb24gZWFjaA0KPj4gICAgIG5ldHdvcmsgc2VnbWVudC4NCj4gDQo+ICAg IFdoZXJlIGlzIHRoZSBtZW50aW9uIG9mIHN0b3JpbmcgdGhlIGV4cGlyYXRpb24gdGltZXM/DQo+ IA0KPiAgICBEaWQgSSBtaXNzIGl0LCBvciBkaWQgeW91IG1pc3MgdGhhdCBwYXJ0IG9mIG15IGNv bW1lbnQ/DQo+IA0KPiAgICBPd2VuDQo+IA0KPj4gDQo+PiANCj4+IFRoYW5rcyENCj4+IA0KPj4g Q2hlZXJzLA0KPj4gLS0NCj4+IEZlcm5hbmRvIEdvbnQNCj4+IFNJNiBOZXR3b3Jrcw0KPj4gZS1t YWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb20NCj4+IFBHUCBGaW5nZXJwcmludDogNjY2NiAzMUM2 IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAwRDU1IDFENEUgNzQ5Mg0KPj4gDQo+PiANCj4+IA0K PiANCj4gICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+ICAgIHY2b3BzQGlldGYub3JnDQo+ICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gDQo+IA0KDQo= From nobody Sun Nov 3 11:43:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD6C1200C1 for ; Sun, 3 Nov 2019 11:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 cjkyskryl7RL for ; Sun, 3 Nov 2019 11:43:01 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1BE120086 for ; Sun, 3 Nov 2019 11:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1572810177; x=1573414977; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=aSDUFk5CoOXmxUqZdoKWUER7/39Oo6lgr0 FiMyZ0vvQ=; b=inAZ6AK3YRXcvwv1vyAXQMZfYSWm/ZglxJsgBqdd6GntIDzsCT 6qry8nCZ32MFkV518ZbCTHjg2ezyLqj622pRANCmWuga8TGk1pb5MgkEbio2gPhb HVV/JE6cehlnwst2NUi8/JibOl20jc+t3iIrmcwTm4pfw8k2cI5WqlUWM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 03 Nov 2019 20:42:57 +0100 X-Spam-Processed: mail.consulintel.es, Sun, 03 Nov 2019 20:42:55 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006451769.msg for ; Sun, 03 Nov 2019 20:42:55 +0100 X-MDRemoteIP: 2001:470:1f09:495:550f:425e:d72f:461e X-MDHelo: [10.10.10.130] X-MDArrival-Date: Sun, 03 Nov 2019 20:42:55 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=121079e0a6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.f.191014 Date: Sun, 03 Nov 2019 20:42:51 +0100 From: JORDI PALET MARTINEZ To: Erik Nygren , "v6ops@ietf.org list" Message-ID: Thread-Topic: draft-palet-v6ops-464xlat-opt-cdn-caches concerns, including a potential major security vulnerability References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3655658571_151474369" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches concerns, including a potential major security vulnerability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 19:43:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3655658571_151474369 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Erik, =20 First of all, thanks a lot for your detailed comments, and sorry to come ba= ck so late, but last months have been really crazy non-stop =E2=80=A6 =20 See below, in-line. =20 =20 El 12/8/19 16:30, "Erik Nygren" escribi=C3=B3: =20 Some comments on draft-palet-v6ops-464xlat-opt-cdn-caches from the perspect= ives of having a $dayjob at a CDN.... This comes down to three general concerns, plus a major security concern: =20 Will this do more harm than good? (ie, creating brokenness which motivates= content to switch back to IPv4-only) =20 =C3=A8 If we are able to resolve the issues, which is the goal, then sho= uld be more =E2=80=9Cgood=E2=80=9D and no harm at all. =20 Stateless EAMT just won't work due to the typical rate of changes of A/AAAA= pairings in the DNS =20 =C3=A8 I expect the changes in the A/AAAA to follow DNS TTLs, right? Oth= erwise, the cached information at the DNS proxy, or even hosts, will be als= o break =E2=80=9Cregular=E2=80=9D usage, even if this optimization is not i= n place. =20 The IPv4:IPv6 associations may not be adequately 1:1 and client behavior ma= y be hard to antic=C3=ADpate =20 =C3=A8 I=E2=80=99m not sure you=E2=80=99re reading the last version of t= he document (draft-palet-v6ops-464xlat-opt-cdn-caches-03). In that version,= we anticipated that the EAMT must be extended with the FQDN, so we can cor= rectly match the IPv4 and IPv6 address only if it belongs to the same FQDN. =20 4) Poisoning risks/vulnerability (a major security consideration, which ma= y make the DNS approach not viable) =20 =C3=A8 How different is that from a regular DNS cache poisoning? I don= =E2=80=99t see the difference. =20 TL;DR is that the security issue (an attacker being able to poison the EAMT= cache, which can also happen non-maliciously as well) may mean the DNS-based approach is far= too dangerous to deploy. =20 =20 For #1 (the risk/concern factor)... =20 I worry really worry that while the DNS association option is a clever hack= , that it will turn out to be highly fragile and problematic in reality. I= t only takes some corner-cases that are missed or one bad implementation fo= r it to do much more harm than good. (I wrote this even before I realized = the security issue listed below.) =20 One of the biggest challenges I'm already seeing on getting video content d= ual-stacked in some parts of the world is consumer electronics with poor IP= v6 implementations interacting badly with buggy CPE/ISP/home-router configu= rations. Even if IPv6 is generally faster (and may be more available if a = good happy eyeballs implementation is used), it only takes a relatively sma= ll number of subscribers with some Smart TV + ISP configuration that breaks= in the face of dual-stack content to cause a content provider to get enoug= h calls to switch the content back to IPv4-only. I've seen this happen in = at least both the Nordics and East Asia. I worry that this optimization fe= ature could introduce an entirely new class of problems like this if poorly= implemented. If the only recourse content providers have is to switch the= ir content back to being IPv4-only (as that *may* make the difference betwe= en content appearing broken to IPv4 users and between it appearing to be wo= rking), then this could hinder IPv6 usage much more than it helps. =20 I don=E2=80=99t see this being a problem for a simple reason. This will req= uire a CPE firmware update. If I=E2=80=99m the ISP updating the firmware, I= will make sure before the upgrade, that it works. Otherwise this optimizat= ion will not be in place. If the upgrade is done by the customer, by their = own, this kind of problems happen with any buggy update, not just with this= optimization, and of course, in that case it is the customer the one that = know that after I did the upgrade, I broken something =E2=80=A6 =20 One approach that might help this would be to have hostname "allowed" lists= , allowing a ISPs to turn this on for select content. That could still be = problematic if the "allowed" list of hostnames overlaps on the same IPs as = other content. It might at least provide for a way for ISPs to use this fea= ture with their own STB+content combinations, such as for their own "walled= garden" use-cases where they control both the IPv4-only devices and the co= ntent being delivered. (Getting robust IPv6 support onto the devices would= obviate the need for this, however.) Another possibility might be some op= t-in mechanism? (eg, if an additional DNS record is looked up that indicat= es that this translation is supported?) =20 We have something similar also in the latest version of the document, so ag= ain I=E2=80=99m not sure you=E2=80=99re reading the last one. =20 For #2 (the stateless/stateful factor)... =20 The A/AAAA IPs returned in DNS can be very dynamic. For example, many CDNs= have DNS TTLs in the 20 second to 300 second range. At least for Akamai, = the assignments for which addresses are returned for A and AAAA lookups are= done independently. As such, frequent churn in associations should be exp= ected. =20 If the churn only impact new TCP connections then this part might work some= (much?) of the time (minus other caveats below). =20 Is not this the same impact that will happen today if the TTLs fall in the = middle of an existing TCP connection? Again, I don=E2=80=99t see a differen= ce versus the problem created by low DNS TTLs (without the optimization). =20 However if the translation is stateless then this is going to be breaking T= CP connections all the time and will make this solution unusable. It sounds like the current EAM Table (EAMT) lookups are stateless? =20 Same as above. The EAMT entries will expire at the same time as the DNS TTL= s, so I don=E2=80=99t see a difference. =20 This means that each time an association is removed or changed that it will= break all of the long-lived connections using that association. That seem= s likely to result in lots of timeouts and rebuffering (ie, as streams wil= l start playing and then will fail when the association changes or disappea= rs and the connection breaks). =20 Mmmm =E2=80=A6 do you mean that the EAMT instead of expiring based on TTL n= eeds to check if there is a live TCP and, in that case, keep it for the tim= e that TCP connection still exists. Not sure if that=E2=80=99s so easy to i= mplement. My reading is that the EAMT mission is to create =E2=80=9Cstate= =E2=80=9D. NAT46 is stateless if there is a /64 for the translation; it is = a stateful NAT44+stateless NAT46 if there is not such specific prefix. When= we add the EAMT we have state (this A must be translated to this specific = AAAA), but we may need to better define how to handle it. =20 However, if there is no optimization and the DNS TTLs expires in the middle= of a TCP connection and the CDN has changed the A or AAAA, the problem is = the same. =20 I think a requirement for this solution to work would be for the EAMT table= lookups to result in stateful NAT entries on the home router. (ie, the = lookups are just used to create stateful NAT entries for the 4-tuple for th= e duration of that session/connection.)=20 =20 I think I got that =E2=80=A6 =20 =20 For #3 (IPv4:IPv6 associations may not be adequately 1:1 and client behavio= r may be hard to anticipate) This issue has a longer subset of concerns/issues. The doc seems to touch = on a bunch of them, but I worry if there are lots of lurking corner-cases, = each one of which could cause problems. Without a good way to fix or disab= le bad implementations, each one could be a major problem: =20 Again, same question, as I=E2=80=99m not sure you have read the last versio= n (it was submitted very few days before your email, you may have downloade= d a previous version to provide the inputs in this email). The way we are h= andling is disallowing the optimization if a 1:1 is not the case. =20 * Not all clients are good at obeying DNS TTLs. Some are really bad. (eg,= Java will sometimes just do a single DNS lookup and use it for the duratio= n of the process lifetime. Many major browsers also will use a connection = for the duration of its lifetime even if the TTL has changed. In the best-= case (with stateful translation) this just results in more IPv4 due to less= cache entries. In a bad case (without stateful translation) it could mean= that connections are pretty much guaranteed to break when they pass their = TTLs and the EAMT entries time out but the clients keep using them. =20 * The aliasing issue (where the IPv4:IPv6 associations between hostnames ar= e far from 1:1) is real and will result in brokenness. The doc has a bunch= of heuristics that help. but given how clients often don't obey TTLs there= may not be enough information available to detect and fix enough of these = cases. It seems like there are lots of possibilities for timing and race c= onditions for cache entries. As an example, I know of one case where IPv4= is shared by lots of hostnames and SNI is used to determine which TLS cert= ificate to hand out, but on the IPv6 side the address determines which TLS = certificate to return. This or similar may be fairly common as IPv4 is muc= h more address-constrained. The result is that a bad association will retu= rn in clints seeing the wrong certificate. There are lots of similar but m= ore subtler corner-cases here. =20 * Related to the previous, it will be tricky to figure out how to handle a = set of IPv4 addresses from A records and sets of IPv6 addresses from AAAA r= ecords. It will be important to make sure to have some permutations of the= association to avoid hotspotting. =20 * The aliasing issue may result in effectively dual-stacking some IPv4-only= content which would also be a serious problem. (This is related to #4 bel= ow as well.) =20 I think all those cases get resolved because then the optimization is disab= led. =20 For #4 (major security risk / vulnerability): =20 It seems like a malicious actor can cause one client (eg, a browser visitin= g web sites) to create lots of bad associations by returning A/AAAA associa= tions unrelated to them. If done for IPv4-only content and in a consistent= manner, this seems like it can be used to hijack this content. This vulne= rability may be a death-nail for this DNS approach, at least without a host= name allowlist. =20 =20 * Take an IPv4-only site "www.example.com" which returns an IPv4 address "1= 92.0.2.2" (with a fairly short DNS TTL) * Malicious attacker tricks a client in the same network to resolve "hostil= e.example.net" (eg, as a single-pixel ad) which has {"2001:db8::2:2","192.0= .2.2"} but with long DNS TTLs. The attacker doesn't need to have any relat= ionship to the IPv4 address to perform this attack. * Now clients (even dual-stack clients) trying to visit "192.0.2.2" will ha= ve their traffic sent to the attacker-controlled IPv6 address ("2001:db8::2= :2"), which could be a middlebox for surveillance, or something to try and = phish the user, or even a DDoS target. =20 As we are disabling optimization when the same IPv4 address points to diffe= rent names, I don=E2=80=99t think this is a problem. =20 This also potentially is a problem when the same IPv4 address has a mixture= of dual-stack and IPv4-only hostnames pointing to it. Using DNS to remove EAMT entries might help a little here (eg, if IPv4-only= hostnames with NODATA are found for AAAA lookups), but given that this is = also a security vulnerability and given other issues (eg, widely differing = DNS client behaviors and TTLs) it seems highly likely that this is very exp= loitable. =20 Best regards, Erik =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3655658571_151474369 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Erik,

 

First of all, thanks a = lot for your detailed comments, and sorry to come back so late, but last mo= nths have been really crazy non-stop =E2=80=A6

 

See below, in-line.

 

=  

El 12/8/19 16:30, "Erik Nygren" <erik+ietf@nygren.org> escribi=C3=B3:

&= nbsp;

Some comments on draf= t-palet-v6ops-464xlat-opt-cdn-caches from the perspectives of having a $day= job at a CDN....

This comes down to three general concerns, plus a major security concern:=

 

  1. = Will this do m= ore harm than good?  (ie, creating brokenness which motivates content to switch back to IP= v4-only)

 

=C3=A8    <= span lang=3DEN-US style=3D'font-size:12.0pt'>If we are able to resolve the = issues, which is the goal, then should be more =E2=80=9Cgood=E2=80=9D and n= o harm at all.

 

  1. Stateless EAMT just won't work due to the= typical rate of changes of A/AAAA pairings in the DNS

 

= =C3=A8    I expect the changes in the A/AAAA to follow D= NS TTLs, right? Otherwise, the cached information at the DNS proxy, or even= hosts, will be also break =E2=80=9Cregular=E2=80=9D usage, even if this op= timization is not in place.

 

=
  1. The IPv4:IPv6 associations may not be ade= quately 1:1 and client behavior may be hard to antic=C3=ADpate

 

=C3=A8    I=E2=80=99m not sure you=E2=80=99re re= ading the last version of the document (draft-palet-v6ops-464xlat-opt-cdn-c= aches-03). In that version, we anticipated that the EAMT must be extended w= ith the FQDN, so we can correctly match the IPv4 and IPv6 address only if i= t belongs to the same FQDN.

 

=

4) Poisoning risks/vulnerability  (a major= security consideration, which may make the DNS approach not viable)

 

=C3=A8   = ; How different is that from a regular DNS cache poisoning? I don=E2=80= =99t see the difference.

 

TL;DR is that the security issue (an attacker= being able to poison the EAMT cache, which can

=

also happen non-maliciously as well) may mean t= he DNS-based approach is far too dangerous to deploy.

=

 

<= div>

 

=

For #1  (the risk/concern facto= r)...

 

I worry really worry that while the DNS association option is a clever = hack, that it will turn out to be highly fragile and problematic in reality= .  It only takes some corner-cases that are missed or one bad implemen= tation for it to do much more harm than good.  (I wrote this even befo= re I realized the security issue listed below.)

=

 

One of the biggest challenges I'm already seeing on getting = video content dual-stacked in some parts of the world is consumer electroni= cs with poor IPv6 implementations interacting badly with buggy CPE/ISP/home= -router configurations.  Even if IPv6 is generally faster (and may be = more available if a good happy eyeballs implementation is used), it only ta= kes a relatively small number of subscribers with some Smart TV + ISP confi= guration that breaks in the face of dual-stack content to cause a content provider to get enough calls to switch the conte= nt back to IPv4-only.  I've seen this happen in at least both the Nord= ics and East Asia.  I worry that this optimization feature could intro= duce an entirely new class of problems like this if poorly implemented.&nbs= p; If the only recourse content providers have is to switch their content b= ack to being IPv4-only (as that *may* make the difference between content a= ppearing broken to IPv4 users and between it appearing to be working), then= this could hinder IPv6 usage much more than it helps.

 

I don=E2=80=99t = see this being a problem for a simple reason. This will require a CPE firmw= are update. If I=E2=80=99m the ISP updating the firmware, I will make sure = before the upgrade, that it works. Otherwise this optimization will not be = in place. If the upgrade is done by the customer, by their own, this kind o= f problems happen with any buggy update, not just with this optimization, a= nd of course, in that case it is the customer the one that know that after = I did the upgrade, I broken something =E2=80=A6

 

= One approach that might hel= p this would be to have hostname "allowed" lists, allowing a ISPs= to turn this on for select content.  That could still be problematic = if the "allowed" list of hostnames overlaps on the same IPs as ot= her content. It might at least provide for a way for ISPs to use this featu= re with their own STB+content combinations, such as for their own "wal= led garden" use-cases where they control both the IPv4-only devices an= d the content being delivered.  (Getting robust IPv6 support onto the = devices would obviate the need for this, however.)  Another possibilit= y might be some opt-in mechanism?  (eg, if an additional DNS record is= looked up that indicates that this translation is supported?)

 = ;

We have something similar also in the latest version of the document, so= again I=E2=80=99m not sure you=E2=80=99re reading the last one.=

 

For #2  (the stateless/stateful factor)...

 

The A/AA= AA IPs returned in DNS can be very dynamic.  For example, many CDNs ha= ve DNS TTLs in the 20 second to 300 second range.  At least for Akamai= , the assignments for which addresses are returned for A and AAAA lookups a= re done independently.  As such, frequent churn in associations should= be expected.

&= nbsp;

If the churn only i= mpact new TCP connections then this part might work some (much?) of the tim= e (minus other caveats below).

 

Is not this the same imp= act that will happen today if the TTLs fall in the middle of an existing TC= P connection? Again, I don=E2=80=99t see a difference versus the problem cr= eated by low DNS TTLs (without the optimization).

 

However if the translation is statel= ess then this is going to be breaking TCP connections all the time and will= make this solution unusable.

It sounds like the current EAM Table (= EAMT) lookups are stateless?

 

Same as above. The = EAMT entries will expire at the same time as the DNS TTLs, so I don=E2=80= =99t see a difference.

 

=

This means that each time= an association is removed or changed that it will break all of the long-li= ved connections using that association.  That seems likely to result i= n lots of timeouts and rebuffering  (ie, as streams will start playing= and then will fail when the association changes or disappears and the conn= ection breaks).

 

Mmmm =E2=80=A6 do you mean that = the EAMT instead of expiring based on TTL needs to check if there is a live= TCP and, in that case, keep it for the time that TCP connection still exis= ts. Not sure if that=E2=80=99s so easy to implement. My reading is that the= EAMT mission is to create =E2=80=9Cstate=E2=80=9D. NAT46 is stateless if t= here is a /64 for the translation; it is a stateful NAT44+stateless NAT46 i= f there is not such specific prefix. When we add the EAMT we have state (th= is A must be translated to this specific AAAA), but we may need to better d= efine how to handle it.

 

However, if ther= e is no optimization and the DNS TTLs expires in the middle of a TCP connec= tion and the CDN has changed the A or AAAA, the problem is the same.

 

I think a requirement for this solution t= o work would be for the EAMT table lookups to result in stateful NAT entrie= s on the home router.    (ie, the lookups are just used to c= reate stateful NAT entries for the 4-tuple for the duration of that session= /connection.)

 

I think I got that =E2=80=A6=

 

 

For #3 (IPv4:IPv6 asso= ciations may not be adequately 1:1 and client behavior may be hard to antic= ipate)

This issue ha= s a longer subset of concerns/issues.  The doc seems to touch on a bun= ch of them, but I worry if there are lots of lurking corner-cases, each one= of which could cause problems.  Without a good way to fix or disable = bad implementations, each one could be a major problem:

&nbs= p;

Again, same question, as I=E2=80=99m not sure you have read the = last version (it was submitted very few days before your email, you may hav= e downloaded a previous version to provide the inputs in this email). The w= ay we are handling is disallowing the optimization if a 1:1 is not the case= .

 

* Not all clients are good at obeying DNS TTLs.  Some are really bad= .  (eg, Java will sometimes just do a single DNS lookup and use it for= the duration of the process lifetime.  Many major browsers also will = use a connection for the duration of its lifetime even if the TTL has chang= ed.  In the best-case (with stateful translation) this just results in= more IPv4 due to less cache entries.  In a bad case (without stateful= translation) it could mean that connections are pretty much guaranteed to = break when they pass their TTLs and the EAMT entries time out but the clien= ts keep using them.

 

* The aliasing issue (where the IPv4:IPv6 associations be= tween hostnames are far from 1:1) is real and will result in brokenness.&nb= sp; The doc has a bunch of heuristics that help. but given how clients ofte= n don't obey TTLs there may not be enough information available to detect a= nd fix enough of these cases.  It seems like there are lots of possibi= lities for timing and race conditions for cache entries.   As an = example, I know of one case where IPv4 is shared by lots of hostnames and S= NI is used to determine which TLS certificate to hand out, but on the IPv6 = side the address determines which TLS certificate to return.  This or = similar may be fairly common as IPv4 is much more address-constrained. = ; The result is that a bad association will return in clints seeing the wro= ng certificate.  There are lots of similar but more subtler corner-cas= es here.

 =

* Related to the previou= s, it will be tricky to figure out how to handle= a set of IPv4 addresses from A records and sets of IPv6 addresses f= rom AAAA records.  It will be important to make sure to have some perm= utations of the association to avoid hotspotting.

 

* The aliasing issue may result in effectively dual-stacki= ng some IPv4-only content which would also be a serious problem.  (Thi= s is related to #4 below as well.)

 

I think all those cases get resolved be= cause then the optimization is disabled.

 

For #4 (major security risk / vulnerability):

 

It seems like a malicious act= or can cause one client (eg, a browser visiting web sites) to create lots o= f bad associations by returning A/AAAA associations unrelated to them. = ; If done for IPv4-only content and in a consistent manner, this seems like= it can be used to hijack this content.  This vulnerability may be a d= eath-nail for this DNS approach, at least without a hostname allowlist.&nbs= p;

 

* Take an IPv4-only site &quo= t;www.example.com" which return= s an IPv4 address "192.0.2.2" (with a fairly short DNS TTL)<= /o:p>

* Malicious attacker tric= ks a client in the same network to resolve "hostile.example.net" (eg, as a single-pixel ad) which= has {"2001:db8::2:2","192.0.2.2"} but with long DNS TT= Ls.  The attacker doesn't need to have any relationship to the IPv4 ad= dress to perform this attack.

* Now clients (even dual-stack clients) trying to visit "192= .0.2.2" will have their traffic sent to the attacker-controlled IPv6 a= ddress ("2001:db8::2:2"), which could be a middlebox for surveill= ance, or something to try and phish the user, or even a DDoS target.

 

As we are disabling optimization when the same IPv4 a= ddress points to different names, I don=E2=80=99t think this is a problem.<= o:p>

 

This also potentially is a problem when the same= IPv4 address has a mixture of dual-stack and IPv4-only hostnames pointing = to it.

Using DNS to remove EAMT entries might help a little h= ere (eg, if IPv4-only hostnames with NODATA are found for AAAA lookups), bu= t given that this is also a security vulnerability and given other issues (= eg, widely differing DNS client behaviors and TTLs) it seems highly likely = that this is very exploitable.

 

B= est regards, Erik

 

 


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

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3655658571_151474369-- From nobody Sun Nov 3 13:31:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52285120845 for ; Sun, 3 Nov 2019 13:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 f6p-KJGsa_Kg for ; Sun, 3 Nov 2019 13:31:33 -0800 (PST) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467F5120853 for ; Sun, 3 Nov 2019 13:31:33 -0800 (PST) Received: by mail-wr1-f42.google.com with SMTP id a11so14865014wra.6 for ; Sun, 03 Nov 2019 13:31:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PcQXyvBt0eek8WzQp4t8fHgWQaSk2IjVzfe6xiuMpK4=; b=U9j6DjMC141pALVNMk7pzEStEflvaMtCRtdKVjENGeqN1Ktr+JIoMdwukHAt5C2eWL FfbN+b1XlPa8SCllVrDQfTl2kL4zEC4rXMVC/xn6zckxaHY/hXOVf/Fv/P2eM8MoQtQX 89H+I65mXli7HdhRZVceRZMac/LA6uzxJSJsXaRKbhrS7VIS2ziwwnzQ+1AQiz1L5M7E Zo9CDd1sEXAH7ZXIxN25wl7d+w2DdXbPYeBDAXVKY6HUYs85DsNbPmwV2NLqrX4HkApR zGfhaj7HgnEil193qoLjABhbVg3RDOiewU6wure70NFdJWPTq4rTSQ4ASoMoASM/Pyoe ricQ== X-Gm-Message-State: APjAAAUhkqGp2F6kvg+Ym5u/4n+VkUzGWKTYFUPNp+k7RvuFPj+8S7S+ gBoMe09qR6wdn0TtynDoE5NUtoE1zbq0IEl4rq8Qp3qJ X-Google-Smtp-Source: APXvYqzMQTi9JPEjT1SPe/7Vo45ohnzgyO+p8Exx5tZx5DJ1Mcq9CED3ej+npnWFpfwq8ezkJ+pUkeNq40Xj46uoRSg= X-Received: by 2002:adf:b608:: with SMTP id f8mr15591530wre.99.1572816691384; Sun, 03 Nov 2019 13:31:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Nygren Date: Sun, 3 Nov 2019 16:31:20 -0500 Message-ID: To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000002fd6cb059677ec9d" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches concerns, including a potential major security vulnerability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 21:31:43 -0000 --0000000000002fd6cb059677ec9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To summarize, I think the biggest problem is around this: > Mmmm =E2=80=A6 do you mean that the EAMT instead of expiring based on TTL= needs to check if there is a live TCP and, in that case, keep it for the time that TCP > connection still exists. Not sure if that=E2=80=99s so easy to implement.= My reading is that the EAMT mission is to create =E2=80=9Cstate=E2=80=9D. NAT4= 6 is stateless if there is a /64 for > the translation; it is a stateful NAT44+stateless NAT46 if there is not such specific prefix. When we add the EAMT we have state (this A must be translated > to this specific AAAA), but we may need to better define how to handle it= . > However, if there is no optimization and the DNS TTLs expires in the middle of a TCP connection and the CDN has changed the A o The problem is that most CDNs have TTLs in the ~10s to 300s range. Most clients don't actually follow DNS TTLs. Those short TTLS are primarily meant to get new resolutions to switch quickly and to handle large recursive resolvers (with hundreds of thousands of clients behind them). But individual clients will often keep those connections open for longer. For example, I believe Chrome and iOS/OSwill also keep connections open for an hour or more even with a short TTL. What this means is that if there's no state here then connections will constantly get broken. This is especially a problem for progressive streaming video and audio, a common scenario for exactly the use-case this is targeted at with legacy IPv4-only set-top boxes. They may start streaming an audio or video file progressively and rendering it over a single TCP connection that may last for an hour or three (eg, the length of the move or an ongoing radio station stream). If the DNS TTL is 20s, or even 300s, then the TCP connection will keep getting reset unless there's state on the CPE gateway. Erik On Sun, Nov 3, 2019 at 2:43 PM JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi Erik, > > > > First of all, thanks a lot for your detailed comments, and sorry to come > back so late, but last months have been really crazy non-stop =E2=80=A6 > > > > See below, in-line. > > > > > > El 12/8/19 16:30, "Erik Nygren" escribi=C3=B3: > > > > Some comments on draft-palet-v6ops-464xlat-opt-cdn-caches from the > perspectives of having a $dayjob at a CDN.... > > This comes down to three general concerns, plus a major security concern: > > > > 1. Will this do more harm than good? (ie, creating brokenness which > motivates content to switch back to IPv4-only) > > > > =C3=A8 If we are able to resolve the issues, which is the goal, then s= hould > be more =E2=80=9Cgood=E2=80=9D and no harm at all. > > > > 1. Stateless EAMT just won't work due to the typical rate of changes > of A/AAAA pairings in the DNS > > > > =C3=A8 I expect the changes in the A/AAAA to follow DNS TTLs, right? > Otherwise, the cached information at the DNS proxy, or even hosts, will b= e > also break =E2=80=9Cregular=E2=80=9D usage, even if this optimization is = not in place. > > > > 1. The IPv4:IPv6 associations may not be adequately 1:1 and client > behavior may be hard to antic=C3=ADpate > > > > =C3=A8 I=E2=80=99m not sure you=E2=80=99re reading the last version of= the document > (draft-palet-v6ops-464xlat-opt-cdn-caches-03). In that version, we > anticipated that the EAMT must be extended with the FQDN, so we can > correctly match the IPv4 and IPv6 address only if it belongs to the same > FQDN. > > > > 4) Poisoning risks/vulnerability (a major security consideration, which > may make the DNS approach not viable) > > > > =C3=A8 How different is that from a regular DNS cache poisoning? I don= =E2=80=99t > see the difference. > > > > TL;DR is that the security issue (an attacker being able to poison the > EAMT cache, which can > > also happen non-maliciously as well) may mean the DNS-based approach is > far too dangerous to deploy. > > > > > > For #1 (the risk/concern factor)... > > > > I worry really worry that while the DNS association option is a clever > hack, that it will turn out to be highly fragile and problematic in > reality. It only takes some corner-cases that are missed or one bad > implementation for it to do much more harm than good. (I wrote this even > before I realized the security issue listed below.) > > > > One of the biggest challenges I'm already seeing on getting video content > dual-stacked in some parts of the world is consumer electronics with poor > IPv6 implementations interacting badly with buggy CPE/ISP/home-router > configurations. Even if IPv6 is generally faster (and may be more > available if a good happy eyeballs implementation is used), it only takes= a > relatively small number of subscribers with some Smart TV + ISP > configuration that breaks in the face of dual-stack content to cause a > content provider to get enough calls to switch the content back to > IPv4-only. I've seen this happen in at least both the Nordics and East > Asia. I worry that this optimization feature could introduce an entirely > new class of problems like this if poorly implemented. If the only > recourse content providers have is to switch their content back to being > IPv4-only (as that *may* make the difference between content appearing > broken to IPv4 users and between it appearing to be working), then this > could hinder IPv6 usage much more than it helps. > > > > I don=E2=80=99t see this being a problem for a simple reason. This will r= equire a > CPE firmware update. If I=E2=80=99m the ISP updating the firmware, I will= make sure > before the upgrade, that it works. Otherwise this optimization will not b= e > in place. If the upgrade is done by the customer, by their own, this kind > of problems happen with any buggy update, not just with this optimization= , > and of course, in that case it is the customer the one that know that aft= er > I did the upgrade, I broken something =E2=80=A6 > > > > One approach that might help this would be to have hostname "allowed" > lists, allowing a ISPs to turn this on for select content. That could > still be problematic if the "allowed" list of hostnames overlaps on the > same IPs as other content. It might at least provide for a way for ISPs t= o > use this feature with their own STB+content combinations, such as for the= ir > own "walled garden" use-cases where they control both the IPv4-only devic= es > and the content being delivered. (Getting robust IPv6 support onto the > devices would obviate the need for this, however.) Another possibility > might be some opt-in mechanism? (eg, if an additional DNS record is look= ed > up that indicates that this translation is supported?) > > > > We have something similar also in the latest version of the document, so > again I=E2=80=99m not sure you=E2=80=99re reading the last one. > > > > For #2 (the stateless/stateful factor)... > > > > The A/AAAA IPs returned in DNS can be very dynamic. For example, many > CDNs have DNS TTLs in the 20 second to 300 second range. At least for > Akamai, the assignments for which addresses are returned for A and AAAA > lookups are done independently. As such, frequent churn in associations > should be expected. > > > > If the churn only impact new TCP connections then this part might work > some (much?) of the time (minus other caveats below). > > > > Is not this the same impact that will happen today if the TTLs fall in th= e > middle of an existing TCP connection? Again, I don=E2=80=99t see a differ= ence > versus the problem created by low DNS TTLs (without the optimization). > > > > However if the translation is stateless then this is going to be breaking > TCP connections all the time and will make this solution unusable. > > It sounds like the current EAM Table (EAMT) lookups are stateless? > > > > Same as above. The EAMT entries will expire at the same time as the DNS > TTLs, so I don=E2=80=99t see a difference. > > > > This means that each time an association is removed or changed that it > will break all of the long-lived connections using that association. Tha= t > seems likely to result in lots of timeouts and rebuffering (ie, as strea= ms > will start playing and then will fail when the association changes or > disappears and the connection breaks). > > > > Mmmm =E2=80=A6 do you mean that the EAMT instead of expiring based on TTL= needs to > check if there is a live TCP and, in that case, keep it for the time that > TCP connection still exists. Not sure if that=E2=80=99s so easy to implem= ent. My > reading is that the EAMT mission is to create =E2=80=9Cstate=E2=80=9D. NA= T46 is stateless > if there is a /64 for the translation; it is a stateful NAT44+stateless > NAT46 if there is not such specific prefix. When we add the EAMT we have > state (this A must be translated to this specific AAAA), but we may need = to > better define how to handle it. > > > > However, if there is no optimization and the DNS TTLs expires in the > middle of a TCP connection and the CDN has changed the A or AAAA, the > problem is the same. > > > > I think a requirement for this solution to work would be for the EAMT > table lookups to result in stateful NAT entries on the home router. (i= e, > the lookups are just used to create stateful NAT entries for the 4-tuple > for the duration of that session/connection.) > > > > I think I got that =E2=80=A6 > > > > > > For #3 (IPv4:IPv6 associations may not be adequately 1:1 and client > behavior may be hard to anticipate) > > This issue has a longer subset of concerns/issues. The doc seems to touc= h > on a bunch of them, but I worry if there are lots of lurking corner-cases= , > each one of which could cause problems. Without a good way to fix or > disable bad implementations, each one could be a major problem: > > > > Again, same question, as I=E2=80=99m not sure you have read the last vers= ion (it > was submitted very few days before your email, you may have downloaded a > previous version to provide the inputs in this email). The way we are > handling is disallowing the optimization if a 1:1 is not the case. > > > > * Not all clients are good at obeying DNS TTLs. Some are really bad. > (eg, Java will sometimes just do a single DNS lookup and use it for the > duration of the process lifetime. Many major browsers also will use a > connection for the duration of its lifetime even if the TTL has changed. > In the best-case (with stateful translation) this just results in more IP= v4 > due to less cache entries. In a bad case (without stateful translation) = it > could mean that connections are pretty much guaranteed to break when they > pass their TTLs and the EAMT entries time out but the clients keep using > them. > > > > * The aliasing issue (where the IPv4:IPv6 associations between hostnames > are far from 1:1) is real and will result in brokenness. The doc has a > bunch of heuristics that help. but given how clients often don't obey TTL= s > there may not be enough information available to detect and fix enough of > these cases. It seems like there are lots of possibilities for timing an= d > race conditions for cache entries. As an example, I know of one case > where IPv4 is shared by lots of hostnames and SNI is used to determine > which TLS certificate to hand out, but on the IPv6 side the address > determines which TLS certificate to return. This or similar may be fairl= y > common as IPv4 is much more address-constrained. The result is that a ba= d > association will return in clints seeing the wrong certificate. There ar= e > lots of similar but more subtler corner-cases here. > > > > * Related to the previous, it will be tricky to figure out how to handle > a set of IPv4 addresses from A records and sets of IPv6 addresses from > AAAA records. It will be important to make sure to have some permutation= s > of the association to avoid hotspotting. > > > > * The aliasing issue may result in effectively dual-stacking some > IPv4-only content which would also be a serious problem. (This is relate= d > to #4 below as well.) > > > > I think all those cases get resolved because then the optimization is > disabled. > > > > For #4 (major security risk / vulnerability): > > > > It seems like a malicious actor can cause one client (eg, a browser > visiting web sites) to create lots of bad associations by returning A/AAA= A > associations unrelated to them. If done for IPv4-only content and in a > consistent manner, this seems like it can be used to hijack this content. > This vulnerability may be a death-nail for this DNS approach, at least > without a hostname allowlist. > > > > * Take an IPv4-only site "www.example.com" which returns an IPv4 address > "192.0.2.2" (with a fairly short DNS TTL) > > * Malicious attacker tricks a client in the same network to resolve " > hostile.example.net" (eg, as a single-pixel ad) which has > {"2001:db8::2:2","192.0.2.2"} but with long DNS TTLs. The attacker doesn= 't > need to have any relationship to the IPv4 address to perform this attack. > > * Now clients (even dual-stack clients) trying to visit "192.0.2.2" will > have their traffic sent to the attacker-controlled IPv6 address > ("2001:db8::2:2"), which could be a middlebox for surveillance, or > something to try and phish the user, or even a DDoS target. > > > > As we are disabling optimization when the same IPv4 address points to > different names, I don=E2=80=99t think this is a problem. > > > > This also potentially is a problem when the same IPv4 address has a > mixture of dual-stack and IPv4-only hostnames pointing to it. > > Using DNS to remove EAMT entries might help a little here (eg, if > IPv4-only hostnames with NODATA are found for AAAA lookups), but given th= at > this is also a security vulnerability and given other issues (eg, widely > differing DNS client behaviors and TTLs) it seems highly likely that this > is very exploitable. > > > > Best regards, Erik > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > --0000000000002fd6cb059677ec9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To summarize, I think the biggest problem is around this:
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">

> Mmmm =E2=80=A6 do you mean that the EAMT instead of expiring based on TTL needs= to=20 check if there is a live TCP and, in that case, keep it for the time=20 that TCP

> connection still exists. Not sure if that=E2=80=99s = so easy to=20 implement. My reading is that the EAMT mission is to create =E2=80=9Cstate= =E2=80=9D.=20 NAT46 is stateless if there is a /64 for

> the translation; it = is a=20 stateful NAT44+stateless NAT46 if there is not such specific prefix.=20 When we add the EAMT we have state (this A must be translated

> to t= his=20 specific AAAA), but we may need to better define how to handle it.

>= However, if there is no optimization and the DNS TTLs expires in the middl= e of a TCP connection and the CDN has changed the A o


The prob= lem is that most CDNs have TTLs in the ~10s to 300s range.=C2=A0 Most clien= ts don't actually follow DNS TTLs.

Those short TTLS are primari= ly meant to get new resolutions to switch quickly and to handle large

r= ecursive resolvers (with hundreds of thousands of clients behind them).=C2= =A0 But individual clients

will often keep those connections open for l= onger.

For example, I believe Chrome and iOS/OSwill also keep connectio= ns open for an hour or more

even with a short TTL.=C2=A0 What this mean= s is that if there's no state here then connections will

constantly= get broken.


This is especially a problem for progressive stre= aming video and audio, a common

scenario for exactly the use-case this = is targeted at with legacy IPv4-only set-top boxes.

They may start stre= aming an audio or video file progressively and rendering it over

=

a sing= le TCP connection that may last for an hour or three (eg, the length of the= move

or an ongoing radio station stream).=C2=A0 If the DNS TTL is 20s= , or even 300s, then

the TCP connection will keep getting reset un= less there's state on the CPE gateway.


=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Erik












On Sun, Nov 3, 2019 at 2:= 43 PM JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

Hi Erik,

=C2=A0<= /p>

Fir= st of all, thanks a lot for your detailed comments, and sorry to come back = so late, but last months have been really crazy non-stop =E2=80=A6

=C2=A0

See below, in-line.

=C2=A0

=C2=A0

El 12/8/19 16:30, "Erik Nygren" <erik+ietf@nygren.org>= ; escribi=C3=B3:

=C2=A0

Some comments on draft-palet-v6ops-464xlat-opt-= cdn-caches from the perspectives of having a $dayjob at a CDN....=

This come= s down to three general concerns, plus a major security concern:<= /u>

=C2=A0

  1. Will this do more harm than good?=C2=A0 (ie, creating brokenness whi= ch motivates content to switch back to IPv4-only)
    2. =

=C2=A0

<= span style=3D"font-size:12pt;font-family:Wingdings" lang=3D"EN-US">= =C3=A8=C2=A0=C2=A0=C2= =A0 If we are able to resolve the issues, which is the goal, then should be = more =E2=80=9Cgood=E2=80=9D and no harm at all.

= =C2=A0

  1. Stateless EAMT just won't work due to the typica= l rate of changes of A/AAAA pairings in the DNS

    2. =C2=A0

    =C3=A8=C2= =A0=C2=A0=C2=A0 I expect the changes in the A/AAAA to follow DNS TTLs, right= ? Otherwise, the cached information at the DNS proxy, or even hosts, will b= e also break =E2=80=9Cregular=E2=80=9D usage, even if this optimization is = not in place.

    =C2=A0

=
  1. = Th= e IPv4:IPv6 associations may not be adequately 1:1 and client behavior may = be hard to antic=C3=ADpate

=C2=A0

=C3=A8=C2=A0=C2=A0=C2=A0 = I=E2=80= =99m not sure you=E2=80=99re reading the last version of the document (draf= t-palet-v6ops-464xlat-opt-cdn-caches-03). In that version, we anticipated t= hat the EAMT must be extended with the FQDN, so we can correctly match the = IPv4 and IPv6 address only if it belongs to the same FQDN.

=C2=A0

4) Poisoning risks/vulnerability=C2=A0 (a major security consideration,= which may make the DNS approach not viable)

=

=C2=A0

=C3=A8=C2=A0=C2=A0=C2=A0 How different is that from a regular DNS= cache poisoning? I don=E2=80=99t see the difference.<= /p>

= =C2=A0

TL;DR is that the security issue (an attacker being able to poison the = EAMT cache, which can

also happen non-maliciously as well) may mean the DNS-base= d approach is far too dangerous to deploy.

=C2=A0

=

=C2= =A0

For #1=C2= =A0 (the risk/concern factor)...

<= p class=3D"MsoNormal" style=3D"margin-left:35.4pt">=C2=A0

=

I worry really worry tha= t while the DNS association option is a clever hack, that it will turn out = to be highly fragile and problematic in reality.=C2=A0 It only takes some c= orner-cases that are missed or one bad implementation for it to do much mor= e harm than good.=C2=A0 (I wrote this even before I realized the security i= ssue listed below.)

=C2=A0

One of the biggest challenges I'm already seeing on ge= tting video content dual-stacked in some parts of the world is consumer ele= ctronics with poor IPv6 implementations interacting badly with buggy CPE/IS= P/home-router configurations.=C2=A0 Even if IPv6 is generally faster (and m= ay be more available if a good happy eyeballs implementation is used), it o= nly takes a relatively small number of subscribers with some Smart TV + ISP= configuration that breaks in the face of dual-stack content to cause a con= tent provider to get enough calls to switch the content back to IPv4-only.= =C2=A0 I've seen this happen in at least both the Nordics and East Asia= .=C2=A0 I worry that this optimization feature could introduce an entirely = new class of problems like this if poorly implemented.=C2=A0 If the only re= course content providers have is to switch their content back to being IPv4= -only (as that *may* make the difference between content appearing broken t= o IPv4 users and between it appearing to be working), then this could hinde= r IPv6 usage much more than it helps.

=C2=A0

I don=E2=80=99t s= ee this being a problem for a simple reason. This will require a CPE firmwa= re update. If I=E2=80=99m the ISP updating the firmware, I will make sure b= efore the upgrade, that it works. Otherwise this optimization will not be i= n place. If the upgrade is done by the customer, by their own, this kind of= problems happen with any buggy update, not just with this optimization, an= d of course, in that case it is the customer the one that know that after I= did the upgrade, I broken something =E2=80=A6

=C2= =A0

One appr= oach that might help this would be to have hostname "allowed" lis= ts, allowing a ISPs to turn this on for select content.=C2=A0 That could st= ill be problematic if the "allowed" list of hostnames overlaps on= the same IPs as other content. It might at least provide for a way for ISP= s to use this feature with their own STB+content combinations, such as for = their own "walled garden" use-cases where they control both the I= Pv4-only devices and the content being delivered.=C2=A0 (Getting robust IPv= 6 support onto the devices would obviate the need for this, however.)=C2=A0= Another possibility might be some opt-in mechanism?=C2=A0 (eg, if an addit= ional DNS record is looked up that indicates that this translation is suppo= rted?)

=C2=A0

We have something similar also in the lates= t version of the document, so again I=E2=80=99m not sure you=E2=80=99re rea= ding the last one.

=C2=A0

For #2=C2= =A0 (the stateless/stateful factor)...

=

=C2= =A0

The A/AAAA= IPs returned in DNS can be very dynamic.=C2=A0 For example, many CDNs have= DNS TTLs in the 20 second to 300 second range.=C2=A0 At least for Akamai, = the assignments for which addresses are returned for A and AAAA lookups are= done independently.=C2=A0 As such, frequent churn in associations should b= e expected.

=C2=A0

If the churn only impact new TCP connections then this part might = work some (much?) of the time (minus other caveats below).

=C2=A0=

Is not this the same impact that will happen today if the TTLs = fall in the middle of an existing TCP connection? Again, I don=E2=80=99t se= e a difference versus the problem created by low DNS TTLs (without the opti= mization).

=C2=A0

However if the translation is stateless then= this is going to be breaking TCP connections all the time and will make th= is solution unusable.

It sounds like the current EAM Table (EAM= T) lookups are stateless?=

=C2=A0

Same as above. The EAMT entries will expire at th= e same time as the DNS TTLs, so I don=E2=80=99t see a difference.=

=C2=A0

This = means that each time an association is removed or changed that it will brea= k all of the long-lived connections using that association.=C2=A0 That seem= s likely to result in lots of timeouts and rebuffering=C2=A0 (ie, as stream= s will start playing and then will fail when the association changes or dis= appears and the connection breaks).

=C2=A0

Mmmm= =E2=80=A6 do you mean that the EAMT instead of expiring based on TTL needs= to check if there is a live TCP and, in that case, keep it for the time th= at TCP connection still exists. Not sure if that=E2=80=99s so easy to imple= ment. My reading is that the EAMT mission is to create =E2=80=9Cstate=E2=80= =9D. NAT46 is stateless if there is a /64 for the translation; it is a stat= eful NAT44+stateless NAT46 if there is not such specific prefix. When we ad= d the EAMT we have state (this A must be translated to this specific AAAA),= but we may need to better define how to handle it.

=C2=A0

However, if there is no optimization and the DNS TTLs e= xpires in the middle of a TCP connection and the CDN has changed the A or A= AAA, the problem is the same.

=C2= =A0

I think a requirement for = this solution to work would be for the EAMT table lookups to result in stat= eful NAT entries on the home router.=C2=A0=C2=A0=C2=A0 (ie, the lookups are= just used to create stateful NAT entries for the 4-tuple for the duration = of that session/connection.)

=C2=A0

I think I = got that =E2=80=A6

=C2=A0<= /u>

=C2=A0

For #3 (IPv4:IPv6 associations may not be ade= quately 1:1 and client behavior may be hard to anticipate)

This issue has a long= er subset of concerns/issues.=C2=A0 The doc seems to touch on a bunch of th= em, but I worry if there are lots of lurking corner-cases, each one of whic= h could cause problems.=C2=A0 Without a good way to fix or disable bad impl= ementations, each one could be a major problem:

=C2=A0

<= p class=3D"MsoNormal">Again, = same question, as I=E2=80=99m not sure you have read the last version (it w= as submitted very few days before your email, you may have downloaded a pre= vious version to provide the inputs in this email). The way we are handling= is disallowing the optimization if a 1:1 is not the case.

=C2=A0

* Not all clients are good at obeying DNS TTLs.=C2=A0 Some are really b= ad.=C2=A0 (eg, Java will sometimes just do a single DNS lookup and use it f= or the duration of the process lifetime.=C2=A0 Many major browsers also wil= l use a connection for the duration of its lifetime even if the TTL has cha= nged.=C2=A0 In the best-case (with stateful translation) this just results = in more IPv4 due to less cache entries.=C2=A0 In a bad case (without statef= ul translation) it could mean that connections are pretty much guaranteed t= o break when they pass their TTLs and the EAMT entries time out but the cli= ents keep using them.

=C2=A0

=

* The aliasing issue (where the IPv= 4:IPv6 associations between hostnames are far from 1:1) is real and will re= sult in brokenness.=C2=A0 The doc has a bunch of heuristics that help. but = given how clients often don't obey TTLs there may not be enough informa= tion available to detect and fix enough of these cases.=C2=A0 It seems like= there are lots of possibilities for timing and race conditions for cache e= ntries.=C2=A0=C2=A0 As an example, I know of one case where IPv4 is shared = by lots of hostnames and SNI is used to determine which TLS certificate to = hand out, but on the IPv6 side the address determines which TLS certificate= to return.=C2=A0 This or similar may be fairly common as IPv4 is much more= address-constrained.=C2=A0 The result is that a bad association will retur= n in clints seeing the wrong certificate.=C2=A0 There are lots of similar b= ut more subtler corner-cases here.

=C2=A0

* Related to the previous, it will be trick= y to figure out how to handle a set of IPv4 addresses from A records and sets of IPv6 = addresses from AAAA records.=C2=A0 It will be important to make sure to hav= e some permutations of the association to avoid hotspotting.<= /span>

=C2=A0

= * The aliasing is= sue may result in effectively dual-stacking some IPv4-only content which wo= uld also be a serious problem.=C2=A0 (This is related to #4 below as well.)=

<= /u>=C2=A0

I think all those cases get resolved because then the = optimization is disabled.

=C2=A0

For #4 (major security risk / vulnera= bility):

=C2=A0

It seems like a malicious actor can cause one client (eg, a browser = visiting web sites) to create lots of bad associations by returning A/AAAA = associations unrelated to them.=C2=A0 If done for IPv4-only content and in = a consistent manner, this seems like it can be used to hijack this content.= =C2=A0 This vulnerability may be a death-nail for this DNS approach, at lea= st without a hostname allowlist.=C2=A0

=

=C2=A0

* Take an IPv4-only site "www.example.com" whi= ch returns an IPv4 address "192.0.2.2" (with a fairly short DNS T= TL)

*= Malicious attacker tricks a client in the same network to resolve "hostile.example.net<= /a>" (eg, as a single-pixel ad) which has {"2001:db8::2:2",&= quot;192.0.2.2"} but with long DNS TTLs.=C2=A0 The attacker doesn'= t need to have any relationship to the IPv4 address to perform this attack.=

* No= w clients (even dual-stack clients) trying to visit "192.0.2.2" w= ill have their traffic sent to the attacker-controlled IPv6 address ("= 2001:db8::2:2"), which could be a middlebox for surveillance, or somet= hing to try and phish the user, or even a DDoS target.=

=C2=A0

As we are disabling optimization when the same IPv4 address= points to different names, I don=E2=80=99t think this is a problem.=

=C2=A0

This= also potentially is a problem when the same IPv4 address has a mixture of = dual-stack and IPv4-only hostnames pointing to it.<= /u>

Using DNS to remove EAMT entries might h= elp a little here (eg, if IPv4-only hostnames with NODATA are found for AAA= A lookups), but given that this is also a security vulnerability and given = other issues (eg, widely differing DNS client behaviors and TTLs) it seems = highly likely that this is very exploitable.

=C2=A0

Best regards, Erik=

=C2=A0

=C2=A0


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

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--0000000000002fd6cb059677ec9d-- From nobody Mon Nov 4 00:27:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D01209D4 for ; Mon, 4 Nov 2019 00:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 PLrQIbQsN9U6 for ; Mon, 4 Nov 2019 00:27:43 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC14F120984 for ; Mon, 4 Nov 2019 00:27:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA48RfS8021532 for ; Mon, 4 Nov 2019 09:27:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6C73520342B for ; Mon, 4 Nov 2019 09:27:41 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 67B83203415 for ; Mon, 4 Nov 2019 09:27:41 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA48RfAA018568 for ; Mon, 4 Nov 2019 09:27:41 +0100 To: v6ops@ietf.org References: <85b1ef40-f107-0ece-3e71-377f4d22dd46@si6networks.com> <9dfd5e47-c593-4145-b530-74fb0f4155ed@www.fastmail.com> <6ABAC3D7-30EA-4ECD-8B5F-A04309C208CE@delong.com> <55508c99-42b7-5c22-5c56-306a41b51bf3@gmail.com> <804cba98-1f87-4fb8-abad-df0d80d25945@www.fastmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 4 Nov 2019 09:27:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <804cba98-1f87-4fb8-abad-df0d80d25945@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 08:27:50 -0000 Le 31/10/2019 à 20:15, Radu-Adrian Feurdean a écrit : > > > On Thu, Oct 31, 2019, at 15:16, Owen DeLong wrote: >> >> >>> On Oct 31, 2019, at 3:02 AM, Alexandre Petrescu >>> wrote: >>> >>> >> >>> Le 31/10/2019 à 04:05, Owen DeLong a écrit : >>>> 8 /64s is a /61. >>> Right, I guess 8 /64s is a /61 because 2^3 is 8, and 3+61 is 64. >> >>> >> Well, a /60 would include not only ce10..ce17, but also ce18, >> ce19, ce1a, ce1b, ce1c, ce1d, ce1e, and ce1f. > > They DO provision a /60 per customer, they just keep half of it for > their own use. The separate STB box was known to make use of it at > some moment on the past. It may still be the case... probably... I just found that the GUI on Android(!) lists 16 0xce10 to 0xce1f /64 prefixes whereas the GUI on the web lists just the first 8. There might be an inconsistency at Free about this. So I get a /60. Alex > >> 256 /64s is a /56. You should be getting 65,536 /64s (a /48) and if >> I were you, I would complain to any ISP that gave me less.I > > Legacy of their past 64rd deployment. > From nobody Mon Nov 4 00:30:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2E6120999 for ; Mon, 4 Nov 2019 00:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 tIVj_T6pYAHf for ; Mon, 4 Nov 2019 00:30:02 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894FB12006D for ; Mon, 4 Nov 2019 00:30:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA48TrWN006781; Mon, 4 Nov 2019 09:29:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 27C64200B4F; Mon, 4 Nov 2019 09:29:53 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 198D22033F3; Mon, 4 Nov 2019 09:29:53 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA48TrAc020446; Mon, 4 Nov 2019 09:29:53 +0100 To: Owen DeLong Cc: v6ops@ietf.org References: <85b1ef40-f107-0ece-3e71-377f4d22dd46@si6networks.com> <9dfd5e47-c593-4145-b530-74fb0f4155ed@www.fastmail.com> <6ABAC3D7-30EA-4ECD-8B5F-A04309C208CE@delong.com> <55508c99-42b7-5c22-5c56-306a41b51bf3@gmail.com> From: Alexandre Petrescu Message-ID: <7778d7f2-0c5b-2d22-24a2-e319b6d26c4a@gmail.com> Date: Mon, 4 Nov 2019 09:29:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 08:30:10 -0000 Le 31/10/2019 à 15:16, Owen DeLong a écrit : [...] > > I’m not familiar with your particular router or its GUI, so I can’t > explain why it displays what it does. I think I understand you. These GUIs are not only difficult to explain to others but also difficult to manipulate. The best is to replace manual filling of prefixes in GUI fields with automated prefix delegation. Alex > > It may simply be limited to 8 subnets that it can handle. It may be > something else. > > I doubt that it has anything to do with your neighbor as your > neighbor would get their own separate PD. They might have the > opposing /61 (ce18..ce1f), but in that case they would still also > have 8 subnets in that case. >> >> Yet in the hextet notation, I get ce10, ce11 ... ce17 (see an >> annotated figure of GUI below). They are 8 /64s. I dont see ce18, >> neither ce19 in the GUI. Might it be that my neighbor gets ce18 >> and ce19, but it would mean s/he cant get more than 2 /64s. Might >> it be that free hides ce18 and ce19 for something else inside my >> home that they dont tell me what. Might it be they expect me to >> ask them for more addresses later. >> >> Whether I get a /61 or a /60 at home is still a valid question for >> me. >> >>> 16 /64s is a /60. 256 /64s is a /56. You should be getting 65,536 >>> /64s (a /48) and if I were you, I would complain to any ISP that >>> gave me less.I >> >> I keep the /48 request in mind for my next interaction with their >> service, because I have many things to ask. >> >> I suppose they will ask me, in return, if I already spent the 2^61 >> addresses they already gave me. >> > This is IPv4think. In the IPv6 world, the intent is to provide large > blocks to avoid future need to renumber and routing table > pollution. > > Owen > >> Alex >> >> >> >> PS: >> >> For information, see below an annotated copy of the GUI listing the >> form of the 8 prefixes I see in GUI on CPE. >> >> One may notice things to complain about: the use of ff:fe in the >> LL, the way they call it 'Prefix Delegation' without using >> DHCPv6-PD and the optional firewall IPv6 activation (off by default >> - they dream :-) >> >> You may understand why I say I have many things to ask them. >> >> >> >> >> >> >>> Owen >>> >>>> On Oct 30, 2019, at 9:29 AM, Alexandre >>>> Petrescu wrote: >>>> >>>> >>>> >>>> Le 30/10/2019 à 15:27, Radu-Adrian Feurdean a écrit : >>>>> On Thu, Oct 24, 2019, at 11:20, Alexandre Petrescu wrote: >>>>>> In particular, the home networks scenario is very >>>>>> appropriate. First, I must say that the home network that I >>>>>> use uses a fixed /56 allocated by my ISP. In this, the >>>>>> prefix never changes, and it is not obtained by DHCPv6-PD - >>>>>> it is guaranteed by contract signed by hand. Such a case >>>>>> could be mentioned, as not being a problem described in >>>>>> this draft. >>>>> If you are talking about residential service (not >>>>> business/enterprise-class), I would like to know who your >>>>> service provider is. >>>> (my correction: I am not at all good at bit fiddling, sorry. >>>> What I get at home is a /60, I think, not a /56. Because the >>>> CPE GUI proposes me to split it into 8 /64s). >>>> >>>> YEs, it is at home, probably you mean it is residential. The >>>> payment is a flat 35eur/month. No special QoS commitments from >>>> them, other than a 'noise level' of 55dbm due to the length of >>>> the line. >>>> >>>> The service provider is Free. ('Free' is its name; it was the >>>> first callable at gratuitous phone numbers when all others >>>> requested a payment in exchange; later they were the first to >>>> offer flat rates when the others were per-connection time; >>>> because of that it called itself so). >>>> >>>>>> I must say that this kind of software (request a prefix >>>>>> with DHCPv6-PD, form sub-prefixes, and put them in RAs on >>>>>> the other interfaces) does not exist as open source or some >>>>>> other available package. >>>>> Dibbler-client does that by default. Once the delegated >>>>> prefix (shorter than /64) is obtained, a /64 from that prefix >>>>> is assigned to each interface. With proper radvd.conf >>>>> configuration (prefix ::/64), RAs will be sent for those >>>>> prefixes. >>>> I did not know. The difficulty I talked about is to maintain >>>> what's in that radvd.conf in sync with what is dhcpd.conf. >>>> Maybe some software packages already do it. >>>> >>>> Also, because you talk about deriving /64s out of /56: I am not >>>> sure there is a standard way to do it. Maybe dibbler does it, >>>> but I doubt it is the best way. >>>> >>>>> A lot (?? most ??) of CPEs implementing DHCPv6-PD client do >>>>> this in some form or another. Some do this automatically >>>>> (take prefixes and assign them to interfaces), other need >>>>> manual configuration (n-th prefix go to interface ZZZ). >>>> It's good to know. >>>> >>>> But again, I doubt these CPEs derive prefixes in the manner >>>> that _I_ want it. >>>> >>>> For example, I want the /60 to be derived into one /64 and a >>>> single other set of /64s. I dont want the /60 to be derived >>>> into 8 /64s. >>>> >>>> I do that to help aggregation and speed up the forwarding >>>> process. >>>> >>>> Other times I might want to derive that /60 differently. >>>> >>>> I dont think there is a standard way to do it. >>>> >>>>>> Because of that, I am surprised that you call it 'the most >>>>>> common deployment scenario'. Is this a scenario that is >>>>>> _expected_ to be 'common'? >>>>> "Expected enough" to warrant a device to be disqualified as >>>>> "CPE that supports IPv6" if it doesn't work this way. In an >>>>> ISP environment. >>>> Well. >>>> >>>> A CPE that supports IPv6 should run DHCPv6. A CLient and a >>>> Server? Both? Just one? >>>> >>>> How does CPE propagate the prefixes learned with its CLient to >>>> its Server? >>>> >>>>>> I would like to request addition of two other scenarios: - >>>>>> an IoT scenario, in which an IoR Router connects several >>>>>> sensors to the Internet. For example, an IoT Router is >>>>>> deployed in a box at a traffic lights. The IoT device is >>>>>> the Traffic Lights Controller connected on Ethernet to the >>>>>> IoT Router. The IoT Router is connected on 4G. - a >>>>>> vehicular networks scenario: the On-Board Unit is deployed >>>>>> in a car. This OBU has a 4G interface and an Ethernet >>>>>> interface. There are several computers in the car that need >>>>>> IPv6 addresses. >>>>> Like : you have a mobile phone on a network doing >>>>> IPv6+NAT64, >>>> My CPE is not doing NAT64, I think. >>>> >>>> I dont want NAT64. >>>> >>>>> you pout it in tethering/mobile-hotspot mode, and connect >>>>> several other devices (usually laptops) to that hotspot - >>>>> they all get IPv6 addresses (in the same single /64 that the >>>>> phone obtained via SLAAC or something else). It is clear that >>>>> getting a /56 (even a /60 or /62 would do it) via DHCPv6-PD >>>>> would be a nicer solution, but when your mobile device runs >>>>> android.... >>>> Well. Android is good in many places and for many goals. >>>> >>>> I agree that tethering/mobile-hotspot mode is a good solution >>>> in certain circumstances, like sharing one's smartphone >>>> connection to tablets nearby. >>>> >>>> However, tethering in IPv6 ('64share' RFC) has some drawbacks: >>>> (1) it does not support more than the WiFi tethered to the >>>> cellular (doesnt support an additional subnet like Ethernet) >>>> and (2) the incoming interface must be cellular (cant be >>>> another wifi). >>>> >>>> In a car, one has a WiFi hotspot but also lots of Ethernets and >>>> CANs. It's not possible to use 64share to accomodate all that. >>>> >>>> Hence, there DHCPv6-PD is not just a nicer solution - it is a >>>> requirement. >>>> >>>> Other than cars, even at home, one may want a DHCPv6-PD Server >>>> on the CPE for similar reasons. >>>> >>>> If one wants to run tethering on a device at home that has no >>>> cellular connection (e.g. a WiFi<->USB, or a USB<->Ethernet >>>> device) to extend to other devices then one cant use tethering >>>> ('64share'), must use DHCPv6-PD. >>>> >>>> Alex >>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 4 00:34:59 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDDD1208C6 for ; Mon, 4 Nov 2019 00:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 NkdsQaC54sNR for ; Mon, 4 Nov 2019 00:34:51 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802BF120850 for ; Mon, 4 Nov 2019 00:34:51 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA48YkbC024950; Mon, 4 Nov 2019 09:34:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C8C492034C1; Mon, 4 Nov 2019 09:34:46 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BD67A203495; Mon, 4 Nov 2019 09:34:46 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA48Yk8E024832; Mon, 4 Nov 2019 09:34:46 +0100 To: v6ops@ietf.org References: <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <166A84EB-3F53-43D2-86AD-C1233DA45399@fugue.com> <5E77C00A-B390-4CC5-B6F5-EB3B0177AA33@employees.org> Cc: Gyan Mishra , "Mudric, Dusan (Dusan)" , Naveen Kottapalli From: Alexandre Petrescu Message-ID: <65ad969c-ac48-e059-f471-58fba3c20510@gmail.com> Date: Mon, 4 Nov 2019 09:34:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <5E77C00A-B390-4CC5-B6F5-EB3B0177AA33@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 08:34:57 -0000 Le 01/11/2019 à 14:51, Ole Troan a écrit : > Hi Ted, > >>> At the risk of straying off topic. There is no mechanism for permissionless networking in IPv6. >>> (which I think is a big gap) >> >> Do you mean permissionless advertising of routes to new networks? If so, I agree. It can be made to sort of work for limited cases, but there’s no standardized way to make end-to-end connectivity work between all networks using the various bits of protocol and practice that we have at present. > > I would define it as: > "Permission-less extensions of the network with new links (and by implications new routers) are not supported." This is a problem statement. It must be put in a draft. There is a related problem statement about the IID being 64bit length, and the SLAAC on Ethernet running only on that. They could be associated. Alex > > NPT66/NAT66 is the only alternative (talking network layer here). > > If we have permission then: > - normal managed network. Just add new router and run routing protocol. Manually managed addressing > - HNCP (automated addressing and routing) > - hierarchical DHCP PD (only works in single rooted DAG) > - proxy ND (RFC recommending against) > > Cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 4 00:39:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575A31200E3 for ; Mon, 4 Nov 2019 00:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYjn8YpBltZK for ; Mon, 4 Nov 2019 00:39:10 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4211200B9 for ; Mon, 4 Nov 2019 00:39:10 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA48c5k0015874 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Nov 2019 00:38:05 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA48c5k0015874 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572856685; bh=HvxFw4tyN5/rlJdpqgBxalhsHtXsUXj8uYFFoHIzGWA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=lrDL+0Wmz9aXnFiAWGes8aBO2aEboGNso+WzFFrRsKCc6+TX3IChMQropSYEIxMYw LHMDWG+ufEVBCtUOy2byy3ERVWwIYWAjOxtvIu9Gxp+dLqDesNmQ0o073a4HwNw0i3 4EQftxyOPGOji0BpR5WpAvm53BoAf4O13appDNxM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <7778d7f2-0c5b-2d22-24a2-e319b6d26c4a@gmail.com> Date: Mon, 4 Nov 2019 00:38:04 -0800 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <63167CDD-2843-4C1C-BCDE-172095A5618B@delong.com> References: <85b1ef40-f107-0ece-3e71-377f4d22dd46@si6networks.com> <9dfd5e47-c593-4145-b530-74fb0f4155ed@www.fastmail.com> <6ABAC3D7-30EA-4ECD-8B5F-A04309C208CE@delong.com> <55508c99-42b7-5c22-5c56-306a41b51bf3@gmail.com> <7778d7f2-0c5b-2d22-24a2-e319b6d26c4a@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 04 Nov 2019 00:38:05 -0800 (PST) Archived-At: Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 08:39:13 -0000 > On Nov 4, 2019, at 00:29 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 31/10/2019 =C3=A0 15:16, Owen DeLong a =C3=A9crit : > [...] >> I=E2=80=99m not familiar with your particular router or its GUI, so I = can=E2=80=99t explain why it displays what it does. >=20 > I think I understand you. These GUIs are not only difficult to = explain > to others but also difficult to manipulate. >=20 > The best is to replace manual filling of prefixes in GUI fields with > automated prefix delegation. Or get a router with a good CLI such as a Juniper SRX series. Owen >=20 > Alex >=20 >> It may simply be limited to 8 subnets that it can handle. It may be = something else. >> I doubt that it has anything to do with your neighbor as your >> neighbor would get their own separate PD. They might have the >> opposing /61 (ce18..ce1f), but in that case they would still also >> have 8 subnets in that case. >>> Yet in the hextet notation, I get ce10, ce11 ... ce17 (see an = annotated figure of GUI below). They are 8 /64s. I dont see ce18, >>> neither ce19 in the GUI. Might it be that my neighbor gets ce18 >>> and ce19, but it would mean s/he cant get more than 2 /64s. Might >>> it be that free hides ce18 and ce19 for something else inside my >>> home that they dont tell me what. Might it be they expect me to >>> ask them for more addresses later. >>> Whether I get a /61 or a /60 at home is still a valid question for >>> me. >>>> 16 /64s is a /60. 256 /64s is a /56. You should be getting 65,536 >>>> /64s (a /48) and if I were you, I would complain to any ISP that >>>> gave me less.I >>> I keep the /48 request in mind for my next interaction with their = service, because I have many things to ask. >>> I suppose they will ask me, in return, if I already spent the 2^61 >>> addresses they already gave me. >> This is IPv4think. In the IPv6 world, the intent is to provide large >> blocks to avoid future need to renumber and routing table >> pollution. >> Owen >>> Alex >>> PS: >>> For information, see below an annotated copy of the GUI listing the >>> form of the 8 prefixes I see in GUI on CPE. >>> One may notice things to complain about: the use of ff:fe in the >>> LL, the way they call it 'Prefix Delegation' without using >>> DHCPv6-PD and the optional firewall IPv6 activation (off by default >>> - they dream :-) >>> You may understand why I say I have many things to ask them. >>> >>>> Owen >>>>> On Oct 30, 2019, at 9:29 AM, Alexandre >>>>> Petrescu wrote: >>>>> Le 30/10/2019 =C3=A0 15:27, Radu-Adrian Feurdean a =C3=A9crit : >>>>>> On Thu, Oct 24, 2019, at 11:20, Alexandre Petrescu wrote: >>>>>>> In particular, the home networks scenario is very >>>>>>> appropriate. First, I must say that the home network that I >>>>>>> use uses a fixed /56 allocated by my ISP. In this, the >>>>>>> prefix never changes, and it is not obtained by DHCPv6-PD - >>>>>>> it is guaranteed by contract signed by hand. Such a case >>>>>>> could be mentioned, as not being a problem described in >>>>>>> this draft. >>>>>> If you are talking about residential service (not >>>>>> business/enterprise-class), I would like to know who your >>>>>> service provider is. >>>>> (my correction: I am not at all good at bit fiddling, sorry. >>>>> What I get at home is a /60, I think, not a /56. Because the >>>>> CPE GUI proposes me to split it into 8 /64s). >>>>> YEs, it is at home, probably you mean it is residential. The >>>>> payment is a flat 35eur/month. No special QoS commitments from >>>>> them, other than a 'noise level' of 55dbm due to the length of >>>>> the line. >>>>> The service provider is Free. ('Free' is its name; it was the >>>>> first callable at gratuitous phone numbers when all others >>>>> requested a payment in exchange; later they were the first to >>>>> offer flat rates when the others were per-connection time; >>>>> because of that it called itself so). >>>>>>> I must say that this kind of software (request a prefix >>>>>>> with DHCPv6-PD, form sub-prefixes, and put them in RAs on >>>>>>> the other interfaces) does not exist as open source or some >>>>>>> other available package. >>>>>> Dibbler-client does that by default. Once the delegated >>>>>> prefix (shorter than /64) is obtained, a /64 from that prefix >>>>>> is assigned to each interface. With proper radvd.conf >>>>>> configuration (prefix ::/64), RAs will be sent for those >>>>>> prefixes. >>>>> I did not know. The difficulty I talked about is to maintain >>>>> what's in that radvd.conf in sync with what is dhcpd.conf. >>>>> Maybe some software packages already do it. >>>>> Also, because you talk about deriving /64s out of /56: I am not >>>>> sure there is a standard way to do it. Maybe dibbler does it, >>>>> but I doubt it is the best way. >>>>>> A lot (?? most ??) of CPEs implementing DHCPv6-PD client do >>>>>> this in some form or another. Some do this automatically >>>>>> (take prefixes and assign them to interfaces), other need >>>>>> manual configuration (n-th prefix go to interface ZZZ). >>>>> It's good to know. >>>>> But again, I doubt these CPEs derive prefixes in the manner >>>>> that _I_ want it. >>>>> For example, I want the /60 to be derived into one /64 and a >>>>> single other set of /64s. I dont want the /60 to be derived >>>>> into 8 /64s. >>>>> I do that to help aggregation and speed up the forwarding >>>>> process. >>>>> Other times I might want to derive that /60 differently. >>>>> I dont think there is a standard way to do it. >>>>>>> Because of that, I am surprised that you call it 'the most >>>>>>> common deployment scenario'. Is this a scenario that is >>>>>>> _expected_ to be 'common'? >>>>>> "Expected enough" to warrant a device to be disqualified as >>>>>> "CPE that supports IPv6" if it doesn't work this way. In an >>>>>> ISP environment. >>>>> Well. >>>>> A CPE that supports IPv6 should run DHCPv6. A CLient and a >>>>> Server? Both? Just one? >>>>> How does CPE propagate the prefixes learned with its CLient to >>>>> its Server? >>>>>>> I would like to request addition of two other scenarios: - >>>>>>> an IoT scenario, in which an IoR Router connects several >>>>>>> sensors to the Internet. For example, an IoT Router is >>>>>>> deployed in a box at a traffic lights. The IoT device is >>>>>>> the Traffic Lights Controller connected on Ethernet to the >>>>>>> IoT Router. The IoT Router is connected on 4G. - a >>>>>>> vehicular networks scenario: the On-Board Unit is deployed >>>>>>> in a car. This OBU has a 4G interface and an Ethernet >>>>>>> interface. There are several computers in the car that need >>>>>>> IPv6 addresses. >>>>>> Like : you have a mobile phone on a network doing >>>>>> IPv6+NAT64, >>>>> My CPE is not doing NAT64, I think. >>>>> I dont want NAT64. >>>>>> you pout it in tethering/mobile-hotspot mode, and connect >>>>>> several other devices (usually laptops) to that hotspot - >>>>>> they all get IPv6 addresses (in the same single /64 that the >>>>>> phone obtained via SLAAC or something else). It is clear that >>>>>> getting a /56 (even a /60 or /62 would do it) via DHCPv6-PD >>>>>> would be a nicer solution, but when your mobile device runs >>>>>> android.... >>>>> Well. Android is good in many places and for many goals. >>>>> I agree that tethering/mobile-hotspot mode is a good solution >>>>> in certain circumstances, like sharing one's smartphone >>>>> connection to tablets nearby. >>>>> However, tethering in IPv6 ('64share' RFC) has some drawbacks: >>>>> (1) it does not support more than the WiFi tethered to the >>>>> cellular (doesnt support an additional subnet like Ethernet) >>>>> and (2) the incoming interface must be cellular (cant be >>>>> another wifi). >>>>> In a car, one has a WiFi hotspot but also lots of Ethernets and >>>>> CANs. It's not possible to use 64share to accomodate all that. >>>>> Hence, there DHCPv6-PD is not just a nicer solution - it is a >>>>> requirement. >>>>> Other than cars, even at home, one may want a DHCPv6-PD Server >>>>> on the CPE for similar reasons. >>>>> If one wants to run tethering on a device at home that has no >>>>> cellular connection (e.g. a WiFi<->USB, or a USB<->Ethernet >>>>> device) to extend to other devices then one cant use tethering >>>>> ('64share'), must use DHCPv6-PD. >>>>> Alex >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Nov 4 11:35:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517421201DB for ; Mon, 4 Nov 2019 11:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 JfViFUaJ2uig for ; Mon, 4 Nov 2019 11:35:49 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A103A120144 for ; Mon, 4 Nov 2019 11:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1572896145; x=1573500945; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=Nwn/6Je5 s08AsUm8ZBFv9n4GHqyVcffBNTNL+z8VXzs=; b=qRwLxyXIhZluYRd/4iScBmye qSgPaWUtlJ0lswfiz+RwzIrimmmSz06Zg5nVUxy261hqYppUNOKGHpR4LnthFnoK N+bJL5OJ9U4nBFCv7RjlyoY9T0zVBK4GcWzluMNKeBHtIF9u0Enffb5GA97PU9Fz w8rSVB1LMT9uI1IjHBk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 04 Nov 2019 20:35:45 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 04 Nov 2019 20:35:44 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006453082.msg for ; Mon, 04 Nov 2019 20:35:44 +0100 X-MDRemoteIP: 2001:470:1f09:495:c0af:e9d8:5cdf:47e7 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Mon, 04 Nov 2019 20:35:44 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1211ca5699=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.f.191014 Date: Mon, 04 Nov 2019 20:35:42 +0100 From: JORDI PALET MARTINEZ To: Mark Smith , v6ops list Message-ID: Thread-Topic: [v6ops] Some comments on 'IPv6 Point-to-Point Links' / draft-palet-v6ops-p2p-links-03 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] Some comments on 'IPv6 Point-to-Point Links' / draft-palet-v6ops-p2p-links-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 19:35:54 -0000 Hi Mark, First of all thanks a lot for this detailed review and all the text provide= d, and excuse the late answer (extremely overbooked the last months). I'm still working in a review of the document (while involved in other docu= ments to review as well), but I'm almost done with this one and will publis= h a new version before the cut-off. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 15/10/19 2:17, "v6ops en nombre de Mark Smith" escribi=C3=B3: Hi Jordi, =20 I started this review a while ago, intending to get it finished before = now. =20 It isn't finished yet, however with IETF 106 coming, there's enough below to work on. =20 Regards, Mark. =20 -- Hi Jordi, =20 Some comments on the above ID. =20 * 3.2. Rationale for using /127 =20 It may be worth mentioning that the effectiveness of this relies on both ends of the link being configured with addresses from within the /127, and that if that doesn't occur due to human error through omission, nothing in IPv6 will detect and notify of that situation. If the link is successfully carrying traffic, then people can assume the link's configuration is correct and complete. =20 This is because although in IPv6 (and IPv4) we think about assigning a prefix to a link, in reality and practice, what we actually do is configure addresses from within a prefix to interfaces attached to a link. There is nothing in IPv6 that demands that all interfaces attached to a link have addresses from all of the prefixes assigned to the link, and it is a valid IPv6 configuration if all link interfaces don't have addresses from all link prefixes. =20 The only IPv6 prefix that requires all interfaces on a link to have addresses from within it is the Link-Local prefix. =20 A scenario I imagine is where two people are bringing up a Internet transit link between a service provider and a small enterprise. The small enterprise router has a default route towards the service provider. The service provider configures their link end with their /127, however the small enterprise overlooks it, because it isn't a routine task for them. As Internet access will work, it may appear that the link has been correctly configured with /127s at both ends. However, the ping-problem now exists with a "/127 link" due to the default route. =20 This might sound a bit contrived, however the point is that humans are involved and can make errors, and to be assured that the /127 prefix mitigates the problem it is supposed to, human operators must check that both addresses are configured on the link, because IPv6 won't, and the link carrying transit traffic isn't a positive confirmation of /127 configuration correctness. =20 So in this section it may be worth adding some text like: =20 "If using a /127 prefix, configuration of each of the addresses within the /127 prefix, at each respective end of the link, must be actively validated by the network operator. A missing /127 address from one end of the link, with a local route pointing out that end of the link that covers the missing /127 address, such as a default route, causes a "ping-pong" scenario to exist for the missing /127 address. The link could still be successfully carrying transit traffic, and IPv6 will not report any errors, because IPv6 doesn't require or nor check to ensure all interfaces attached to a link has addresses from all prefixes assigned to the link, excepting the Link-Local prefix per [RFC 4291]." =20 =20 =20 * Lack of full RFC 4861 ND implementation on point-to-point links =20 The fundamental root cause of the ping-pong problem is some IPv6 implementations not performing full Neighbor Discovery (NS/NA) on addresses that the prefix says could exist on the link. =20 IPv6 implementations are assuming that all addresses within the prefix must exist at the other end of the point-to-point link, and send the traffic straight onto the link. If the address doesn't exist, and there is a covering route back in the other direction, the ping-pong problem occurs. =20 Full Neighbor Discovery is doing more than just resolving the link-layer address of an IPv6 address. Neighbor Discovery is also determining if the address exists. Even if a point-to-point link doesn't have link-layer addresses to resolve, ND determining if an address exists on the link is very beneficial because it will prevent the ping-pong problem occurring entirely regardless of the IPv6 prefix length being used on the link. =20 So in my above SP and small enterprise example, the service provider router would try to ND NS for the missing far end /127, and if it doesn't successfully discover it's existence, then the SP router won't put packets onto the point-to-point link that would end up being ping-ponged. =20 (I think this should be covered somewhere in this draft, but not necessarily directly after 3.2 above. Just convenient to put it here to use the SP / small enterprise example to demonstrate how performing full ND prevents ping-pong entirely.) =20 =20 * 4. Numbering Choices =20 I don't think we should be referring to links as "numbered" or "unnumbered". If "numbers" are IPv6 addresses, all links are numbered, because RFC 4291 requires that all interfaces attached to a link have at least a Link-Local "number" or address from the Link-Local prefix. =20 The principle of least surprise means that we need to be factual in our terminology and descriptions. I could imagine somebody who doesn't know IPv6 that well being surprised to discover their "unnumbered" link has numbers on it. They may even briefly panic because they think somebody breached their router security. =20 An completely accurate and a most least surprising term for a link with interfaces that only has Link-Local Addresses is a "Link-Local Addresses Only" link, or "Link-Local Only" link. "Link-Local Only" is the also the abbreviated title of RFC 7404 "Using Only Link-Local Addressing inside an IPv6 Network", so using that term in this ID is consistent. =20 * 4.1. GUA (Global Unicast Addresses) =20 nit: extra "and" I think. =20 "It provides full functionality for both <>and<> end-points of the point-to-point link= s and consequently, facilitates troubleshooting." =20 probably should be: =20 "It provides full functionality for both end-points of the point-to-point links and consequently, facilitates troubleshooting." =20 =20 * 4.2. ULA (Unique Local Addresses) =20 "This approach may cause numerous problems and therefore is strongly discouraged." =20 I'd suggest adding in "when carrying Internet traffic". It wouldn't cause any issues with PMTUD links carrying ULA traffic within the local ULA domain/ /48 prefix. =20 i.e. =20 "This approach may cause numerous problems when carrying Internet traffic and therefore is strongly discouraged." =20 I think it would be worth referring to RFC 6752, "Issues with Private IP Addressing in the Internet", as it also services as more in depth discussion on this general issue, although from a private IPv4 addressing perspective. =20 So something like: =20 "ULAs are IPv6 private addresses, not intended to be used as source or destination addresses across the Internet. This issue also exists in IPv4 when using RFC 1918 addresses on links carrying IPv4 Internet traffic. [RFC 6752] discusses this issue for IPv4, with much of the discussion applying similarly to IPv6 and ULAs." =20 =20 =20 "However, this approach is valid if, following Section 2.2 of [RFC4443], and despite using ULA for the point-to-point link, the router is configured with at least one GUA and the source of the ICMPv6 messages are always a GUA." =20 I'd suggest referencing the IPv6 Default Address Selection RFC, as that is what will pick the GUA source address for a GUA destined ICMPv6 message. =20 e.g. =20 "However, this approach is valid if, following Section 2.2 of [RFC4443], and despite using ULA for the point-to-point link, the router is configured with at least one GUA and the source of the ICMPv6 messages are always a GUA, per the IPv6 Default Address Selection algorithm [RFC6724]." =20 =20 * 4.3. Unnumbered =20 Per-above, replace "unnumbered" with "Link-Local Only" or similar and adjust the text to suit. =20 =20 "While this might work for routers, it does not work for devices that can't request a prefix delegation over DHCPv6 and are therefore left without any usable GUA to allow traffic forwarding." =20 I'm a little confused by this. Is this describing a router can't do DHCPv6-PD and therefore would have only link-local addresses? =20 Is the comment about not having a usable GUA preventing traffic forwarding really referring to the route not having an address that can be used for ICMPv6 messages that need to be sent across more than one link? =20 If my understanding is correct, I think it might be better to say it that way, i.e. "The router will need to have a suitable routeable address, such as an appropriate GUA or ULA address, to use as a source for ICMPv6 messages." =20 =20 It's probably a bit of pedantry, however I expect a router with only link-local addresses will forward packets regardless, however if it needed to send an ICMPv6 message it would have no choice but to choose a link-local source address due to IPv6 Default Address Selection. I think they would be sent, however they should then be being dropped by the next router towards the destination. =20 I can't think of much use for it, however I think it might be a valid configuration. IPv6 hosts are expected to deal with ICMPv6 packets being lost, so this would just be a perverse case of ICMPv6 packet loss. If the hosts either don't ever trigger PMTUD, or use RFC 4821 "Packetization Layer Path MTU Discovery" then a pure link-local only router setup might even work without issue. =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.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Nov 4 12:47:18 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5918F12082A for ; Mon, 4 Nov 2019 12:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 USfvKVOPtVb0 for ; Mon, 4 Nov 2019 12:47:11 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5DD120838 for ; Mon, 4 Nov 2019 12:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1572900428; x=1573505228; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=cVGYFFVc +Hjh+lS5TT+eLBWZ8SKu/IBSyCFRxak/RNg=; b=rde0MNiyAPGkAoXSwkEaR37n kv3GKd5XxuuKqahrzTEko2V8c16xeeJHlsmr4oVrgFZivHCDFMai+SxOJBwJjkjr G1ATX/D/vfFu9eBmiaqrDoxI45yt4mAh8T+h6SpKLzJpLaCsKNurKxWjL1EfO34w jV0bV5DLDAKkDoTIVPM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 04 Nov 2019 21:47:08 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 04 Nov 2019 21:47:08 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006453159.msg for ; Mon, 04 Nov 2019 21:47:07 +0100 X-MDRemoteIP: 2001:470:1f09:495:f902:e228:ff96:f700 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Mon, 04 Nov 2019 21:47:07 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1211ca5699=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.f.191014 Date: Mon, 04 Nov 2019 21:47:04 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: New Version Notification for draft-palet-v6ops-p2p-links-04.txt References: <157289812094.13956.11176452142768798328.idtracker@ietfa.amsl.com> In-Reply-To: <157289812094.13956.11176452142768798328.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-p2p-links-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 20:47:17 -0000 Hi all, I've updated this document. https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-links/ As usual, inputs welcome! Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 4/11/19 21:08, "internet-drafts@ietf.org" escribi=C3=B3: =20 A new version of I-D, draft-palet-v6ops-p2p-links-04.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-p2p-links Revision: 04 Title: IPv6 Point-to-Point Links Document date: 2019-11-04 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= p2p-links-04.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-= links/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-p2p-links= -04 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -p2p-links Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-p= 2p-links-04 =20 Abstract: This document describes different alternatives for configuring IPv6 point-to-point links, considering the prefix size, numbering choices and prefix pool to be used. =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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Nov 4 14:34:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FB512009C for ; Mon, 4 Nov 2019 14:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 3ccR1ajm9Cvd for ; Mon, 4 Nov 2019 14:34:44 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0B8120106 for ; Mon, 4 Nov 2019 14:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1572906881; x=1573511681; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=gQ7/jVJU NRErzB5hgK77NFFGYeOAGtjITGKCoWPuCHI=; b=AwM52JHt9/UzXu2utNQETW7x 3yJDY/tCzK6VMqjOTtQdPBDOpdRI8SJyBbkh+YP7Mk5/L0T01dmJ1QiI5vJZzlfK b3dJtoOcdbRf7hACMVQEU/YxhG1ztgNTRwspDOVy2rHxQhrkET2YEKmnN51COQ4K ESm0lv4IV7eNouzwwQk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 04 Nov 2019 23:34:41 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 04 Nov 2019 23:34:41 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006453283.msg for ; Mon, 04 Nov 2019 23:34:40 +0100 X-MDRemoteIP: 2001:470:1f09:495:f902:e228:ff96:f700 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Mon, 04 Nov 2019 23:34:40 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1211ca5699=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.f.191014 Date: Mon, 04 Nov 2019 23:34:36 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <77945270-20D9-45DD-93E9-F4629214B1FF@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-04.txt References: <157290626919.13912.6379607055029472665.idtracker@ietfa.amsl.com> In-Reply-To: <157290626919.13912.6379607055029472665.idtracker@ietfa.amsl.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-464xlat-opt-cdn-caches-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 22:34:47 -0000 Hi all, I just published a new version of this document, following the inputs from = Erik. Thanks for that! https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches Basically, what we do now is to make sure that the EAMT is used only to cre= ate a stateful NAT, which avoids breaking apps that have long-lived TCP con= nections, even if there is a DNS update. This is described in section 4.2.4, that has been updated accordingly. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 4/11/19 23:24, "internet-drafts@ietf.org" escribi=C3=B3: =20 A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-04.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-464xlat-opt-cdn-caches Revision: 04 Title: 464XLAT Optimization Document date: 2019-11-04 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= 464xlat-opt-cdn-caches-04.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-464x= lat-opt-cdn-caches/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-464xlat-o= pt-cdn-caches-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -464xlat-opt-cdn-caches Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-4= 64xlat-opt-cdn-caches-04 =20 Abstract: This document proposes possible solutions to avoid certain drawbacks of IP/ICMP Translation Algorithm (SIIT) when the destinations are available with IPv6. When SIIT is used as a NAT46 and IPv4-only devices or applications initiate traffic flows to dual-stack CDNs (Content Delivery Networks), Caches or other network resources (in the operator network or Internet), those flows will be translated back to IPv4 by a NAT64. This is the case for 464XLAT and MAP-T. =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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Nov 5 10:47:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4A1120142 for ; Tue, 5 Nov 2019 10:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 NBHLTzf-gBnt for ; Tue, 5 Nov 2019 10:47:49 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DAE7120116 for ; Tue, 5 Nov 2019 10:47:49 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id o11so25643665qtr.11 for ; Tue, 05 Nov 2019 10:47:49 -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=OF9DHVBgwIV7beWOB0vnv257RufsW92SJ7Fv1+8eP5w=; b=Qc3jYTuUaBfGzliLzhyIL98GstfViO2s7VZweCAbCPIpTPlX8yUxKtNTlvywl7le9N OJe1tabRQHwmGbAynDaUefhMgh78Gj7+Z4jahMTRYlkSm3ngEGyAkr55229wVnEAEnOj P8mSrl1zbWg6R5fMU1JzNlT3QNYiKVjHWqxkFPfXyYTVcBV02n2oURB+qoUFaQaV2rT/ E7g9qK9wuqCoW/l7TSHsr1cUn0MjXBJDoKPaSBhA0N4GabHzSrpWgz+xeeBbd6A7LCWR DSl4MLEEY5QYOvC/uUiptPTY+kzh+F5IlK0wDZRt/WdGikZXc5Xm1BtUVMNE6bql9y+T /RJQ== 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=OF9DHVBgwIV7beWOB0vnv257RufsW92SJ7Fv1+8eP5w=; b=lW7CGrhfPPSYNm/+cYJpLtBDB+KKqEIzIblDuZrJgig0zNFNtYXpapBRtr3Wt/g+Qf u9Hq7+tPxf7m+Gn688UGzuRfNcuQlM2rMVTN1bYI+OlGMEeObRMjM0wrX3SmTsCaz+uh PExYUimJIK6jp50YIuofk4IBl3rmnMGWV+itfmOCcWE5qh+zY9ZUyqlviHQQ3Weu9m18 7BzCc7fZMHiLFPf+uQMFQm7GA8TI1rsDtFTIjgAiD/1RaWv/wUqUwmIcjAtLtdNh2be0 sET+BkMbW/QJYhe+RCx/VcKa5UwiO2xu69lVkPf9F0f11MdCTKZ2/LRRvr9Uhh7Qxn60 3p4A== X-Gm-Message-State: APjAAAXVmLfaFPXW672A5/Q2RXnSus2tf2Hpz+YZeRMfjKHDRaU6HeG/ e6L6pU3V6FFtxnbyz7HsRUMR7Kj0UZ0= X-Google-Smtp-Source: APXvYqzVyFSww1osXtfJYssUMoBn/JCltX7qXgZaiQuhLks/krYzJbf+5dj+X4RuB0PqvQ8xbzPkhA== X-Received: by 2002:aed:3f33:: with SMTP id p48mr18858691qtf.191.1572979668422; Tue, 05 Nov 2019 10:47:48 -0800 (PST) Received: from ?IPv6:2620:f:8000:210:2900:1e31:230a:8117? ([2620:f:8000:210:2900:1e31:230a:8117]) by smtp.gmail.com with ESMTPSA id v16sm12249526qth.51.2019.11.05.10.47.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 10:47:47 -0800 (PST) From: Fred Baker Content-Type: multipart/mixed; boundary="Apple-Mail=_FCDF9C6B-6315-4544-8C0E-B437CA51E7F7" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: <895EAAE8-E24D-429C-8C1D-552B3331BE11@gmail.com> Date: Tue, 5 Nov 2019 13:47:46 -0500 To: IPv6 Operations X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [v6ops] V6ops status as of this morning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 18:47:52 -0000 --Apple-Mail=_FCDF9C6B-6315-4544-8C0E-B437CA51E7F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii With the closing of the Internet Draft repository at 23:59 UTC = yesterday, the draft status in v6ops looks like the attached. I shared = this in July, and some folks found it useful, so I'm sharing it again = for IETF 106. --Apple-Mail=_FCDF9C6B-6315-4544-8C0E-B437CA51E7F7 Content-Disposition: attachment; filename=raw-agenda-data-v6ops.html Content-Type: text/html; x-unix-mode=0644; name="raw-agenda-data-v6ops.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis

This document describes the drafts associated with this group. It describes their current state as seen by the RFC Editor, IESG/AD, and the working or research group. For working group drafts and individual submissions, it also indicates whether the draft has been updated since the previous IETF meeting. Drafts that are new or have been updated are "current"; other drafts are "old".

On each draft, there are three or four links:

  • the relevant datatracker link,
  • a pointer to the HTML version of the draft in the tools directory,
  • a pointer to the email archived on IETF mailing lists related to the draft, and
  • a pointer to RFCDIFF against the previous version, if there was one.

RFC Editor: RFC-EDITOR

WG: Candidate for WG Adoption

WG: Updated WG Document

Individual Submission: Unupdated

Individual Submission: Updated

The charter for this group is at https://datatracker.ietf.org/group/v6ops/about/

Tue Nov 5 11:39:20 2019

--Apple-Mail=_FCDF9C6B-6315-4544-8C0E-B437CA51E7F7-- From nobody Thu Nov 7 11:21:59 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC61C120964 for ; Thu, 7 Nov 2019 11:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 J0Kh_ykluxsq for ; Thu, 7 Nov 2019 11:21:55 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C94120963 for ; Thu, 7 Nov 2019 11:21:55 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 A8D1E869AF; Thu, 7 Nov 2019 20:21:52 +0100 (CET) To: Fred Baker , IPv6 Operations References: <895EAAE8-E24D-429C-8C1D-552B3331BE11@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: Date: Thu, 7 Nov 2019 16:21:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <895EAAE8-E24D-429C-8C1D-552B3331BE11@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] V6ops status as of this morning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 19:21:58 -0000 Fred, On 5/11/19 15:47, Fred Baker wrote: > With the closing of the Internet Draft repository at 23:59 UTC > yesterday, the draft status in v6ops looks like the attached. I > shared this in July, and some folks found it useful, so I'm sharing > it again for IETF 106. What would be the next step for v6ops to be polled for adoption of: * draft-gont-v6ops-slaac-renum * draft-gont-v6ops-cpe-slaac-renum ? While there are certainly details to be worked out, based on the recent discussion (and earlier discussion this year), as a co-author I believe both docs are in shape for v6ops to decide whether the group wants to work on this or not. Thoughts? 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 Fri Nov 8 04:38:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3371D120118 for ; Fri, 8 Nov 2019 04:38:53 -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_HELO_NONE=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 M3qKz_yV6Qf0 for ; Fri, 8 Nov 2019 04:38:50 -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 BBB5912007C for ; Fri, 8 Nov 2019 04:38:50 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 457A3869BB; Fri, 8 Nov 2019 13:38:47 +0100 (CET) To: Sander Steffann Cc: Mark Smith , Ole Troan , v6ops list References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> Date: Fri, 8 Nov 2019 09:30:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 12:38:53 -0000 On 1/11/19 05:22, Sander Steffann wrote: > Hi, > >>> I think Ole observed that this is contrary to what the PD >>> prefix's Valid Lifetime said would be the case. The ISP supplied >>> a PD Prefix with a Valid Lifetime of X seconds, and then broke >>> that promise by abruptly changing addressing before X seconds. >>> ISPs should be expected to live up to their Valid Lifetime >>> promises. >> >> "Hope" doesn't make networks run properly. > > This isn't "Hope", this is breaking promises, and that does break > networks. If you can't at least trust that promises are intended to > be kept then you have no network at all... They are intended to be kept, but at times s* happens e.g., CPE routers don't crash and reboot on purpose. >> In any case, as previously noted, there are multiple scenarios >> that may lead to this problem. > > Sure, bad things can happen, and there are cases where despite the > best intentions you can't keep your promise. But that doesn't mean > everybody should go around making promises without even thinking > about keeping them… Could you please point to anything that we are proposing that shouldn't be there anyway? 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 Fri Nov 8 04:47:26 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A251200C5 for ; Fri, 8 Nov 2019 04:47: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_HELO_NONE=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 tr5YL57Ulrbv for ; Fri, 8 Nov 2019 04:47:23 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780E4120086 for ; Fri, 8 Nov 2019 04:47:23 -0800 (PST) Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 5C6054E11B11; Fri, 8 Nov 2019 12:47:21 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id 69C4521FBF7B; Fri, 8 Nov 2019 13:47:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> Date: Fri, 8 Nov 2019 13:47:18 +0100 Cc: Sander Steffann , Mark Smith , v6ops list Content-Transfer-Encoding: 7bit Message-Id: References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 12:47:25 -0000 >>>> I think Ole observed that this is contrary to what the PD >>>> prefix's Valid Lifetime said would be the case. The ISP supplied >>>> a PD Prefix with a Valid Lifetime of X seconds, and then broke >>>> that promise by abruptly changing addressing before X seconds. >>>> ISPs should be expected to live up to their Valid Lifetime >>>> promises. >>> >>> "Hope" doesn't make networks run properly. >> >> This isn't "Hope", this is breaking promises, and that does break >> networks. If you can't at least trust that promises are intended to >> be kept then you have no network at all... > > They are intended to be kept, but at times s* happens e.g., CPE routers > don't crash and reboot on purpose. This comment worries me. That a CE reboots is _not_ the problem, nor does it cause the problem. Cheers, Ole From nobody Fri Nov 8 04:56:07 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F19120096 for ; Fri, 8 Nov 2019 04:56:06 -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_HELO_NONE=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 RUDgET-fzbQt for ; Fri, 8 Nov 2019 04:56:04 -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 9DB1A12006F for ; Fri, 8 Nov 2019 04:56:04 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 011B5869DD; Fri, 8 Nov 2019 13:56:01 +0100 (CET) To: Ole Troan Cc: v6ops list References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> Date: Fri, 8 Nov 2019 09:55:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 12:56:06 -0000 On 8/11/19 09:47, Ole Troan wrote: >>>>> I think Ole observed that this is contrary to what the PD >>>>> prefix's Valid Lifetime said would be the case. The ISP supplied >>>>> a PD Prefix with a Valid Lifetime of X seconds, and then broke >>>>> that promise by abruptly changing addressing before X seconds. >>>>> ISPs should be expected to live up to their Valid Lifetime >>>>> promises. >>>> >>>> "Hope" doesn't make networks run properly. >>> >>> This isn't "Hope", this is breaking promises, and that does break >>> networks. If you can't at least trust that promises are intended to >>> be kept then you have no network at all... >> >> They are intended to be kept, but at times s* happens e.g., CPE routers >> don't crash and reboot on purpose. > > This comment worries me. > That a CE reboots is _not_ the problem, nor does it cause the problem. Well, if the CPE did keep state, there would be no problem. (is there a formal requirement for prefixes to be stable across crash & reboots?). (just as a reminder, this is just one scenario. there have been at least three operators that have noted that their setups experience renumbering scenarios for other reasons... and slaac could certainly do much better in those) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 8 05:09:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2865E120127 for ; Fri, 8 Nov 2019 05:09: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, SPF_HELO_NONE=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 AY4BDlJarVAM for ; Fri, 8 Nov 2019 05:09:35 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12E3120125 for ; Fri, 8 Nov 2019 05:09:34 -0800 (PST) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:f164:391d:aabb:2971]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id C6BFF4E11B44; Fri, 8 Nov 2019 13:09:32 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id AC4B621FD130; Fri, 8 Nov 2019 14:09:29 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> Date: Fri, 8 Nov 2019 14:09:29 +0100 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 13:09:36 -0000 >>>>>> I think Ole observed that this is contrary to what the PD=20 >>>>>> prefix's Valid Lifetime said would be the case. The ISP supplied=20= >>>>>> a PD Prefix with a Valid Lifetime of X seconds, and then broke=20 >>>>>> that promise by abruptly changing addressing before X seconds.=20 >>>>>> ISPs should be expected to live up to their Valid Lifetime=20 >>>>>> promises. >>>>>=20 >>>>> "Hope" doesn't make networks run properly. >>>>=20 >>>> This isn't "Hope", this is breaking promises, and that does break=20= >>>> networks. If you can't at least trust that promises are intended to=20= >>>> be kept then you have no network at all... >>>=20 >>> They are intended to be kept, but at times s* happens e.g., CPE = routers >>> don't crash and reboot on purpose. >>=20 >> This comment worries me. >> That a CE reboots is _not_ the problem, nor does it cause the = problem. >=20 > Well, if the CPE did keep state, there would be no problem. (is there = a > formal requirement for prefixes to be stable across crash & reboots?). CPE is not required to keep state. In PD the DR is in control, and should continue to delegate the same = prefix as previously delegated. If the RR includes prefixes in the request, those are purely there as = hints for prefixes it would prefer. > (just as a reminder, this is just one scenario. there have been at = least > three operators that have noted that their setups experience = renumbering > scenarios for other reasons... and slaac could certainly do much = better > in those) You have to be clear what the root cause of a problem is. The DHCP PD protocol is designed to carry leases over CPE reboots. If an SP uses the opportunity caused by a reboot to flash renumber, then = say so. Ole From nobody Fri Nov 8 05:15:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D8612008C for ; Fri, 8 Nov 2019 05:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 bBOoKmCFAse2 for ; Fri, 8 Nov 2019 05:15:45 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC9212006F for ; Fri, 8 Nov 2019 05:15:44 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA8DFgMQ001371 for ; Fri, 8 Nov 2019 14:15:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DE76B2059B2 for ; Fri, 8 Nov 2019 14:15:42 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D46C02016B7 for ; Fri, 8 Nov 2019 14:15:42 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA8DFgKn013247 for ; Fri, 8 Nov 2019 14:15:42 +0100 To: v6ops@ietf.org References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> From: Alexandre Petrescu Message-ID: <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> Date: Fri, 8 Nov 2019 14:15:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 13:15:47 -0000 Le 08/11/2019 à 13:55, Fernando Gont a écrit : > On 8/11/19 09:47, Ole Troan wrote: >>>>>> I think Ole observed that this is contrary to what the PD >>>>>> prefix's Valid Lifetime said would be the case. The ISP >>>>>> supplied a PD Prefix with a Valid Lifetime of X seconds, >>>>>> and then broke that promise by abruptly changing addressing >>>>>> before X seconds. ISPs should be expected to live up to >>>>>> their Valid Lifetime promises. >>>>> >>>>> "Hope" doesn't make networks run properly. >>>> >>>> This isn't "Hope", this is breaking promises, and that does >>>> break networks. If you can't at least trust that promises are >>>> intended to be kept then you have no network at all... >>> >>> They are intended to be kept, but at times s* happens e.g., CPE >>> routers don't crash and reboot on purpose. >> >> This comment worries me. That a CE reboots is _not_ the problem, >> nor does it cause the problem. > > Well, if the CPE did keep state, there would be no problem. (is there > a formal requirement for prefixes to be stable across crash & > reboots?). Probably there is no formal requirement for prefixes to be stable across crashes and reboots[*], but there is a behaviour of the client to send CONFIRM after reboot or wake-up from sleep, as described in the RFC DHCPv6. That is how my home network work with DHCPv6 for addresses: the Windows client reboots and sends CONFIRM to DHCPv6 server on CPE, who agrees with it in turn. So the same address is being used by the Client after reboot. I suspect it should work the same way when PD is implemented. Alex [*]: as for formal requirements for prefix stability: - there are commitments from certain cellular operator to maintain a stable IPv4 address for a cellular User Equipment; - there are cellular operators open to at least try to provide stable IPv6 addresses to smartphone users by using DHCPv6. - there are are commitments (some times unwritten, but visible in their design of use of static IPv6 addresses per intermediary equipment) from some ADSL ISPs to provide stable IPv4 and IPv6 addresses to home networks; > > (just as a reminder, this is just one scenario. there have been at > least three operators that have noted that their setups experience > renumbering scenarios for other reasons... and slaac could certainly > do much better in those) > > Thanks, > From nobody Fri Nov 8 06:20:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070FF120024 for ; Fri, 8 Nov 2019 06:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 ANqCfhrUrDgW for ; Fri, 8 Nov 2019 06:20:13 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 81752120105 for ; Fri, 8 Nov 2019 06:20:13 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iT57S-0000IGC; Fri, 8 Nov 2019 15:20:10 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> In-reply-to: Your message of "Fri, 8 Nov 2019 14:15:42 +0100 ." <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> Date: Fri, 08 Nov 2019 15:20:10 +0100 Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 14:20:15 -0000 > Probably there is no formal requirement for prefixes to be stable > across crashes and reboots[*], but there is a behaviour of the > client to send CONFIRM after reboot or wake-up from sleep, as > described in the RFC DHCPv6. Sending a CONFIRM after a reboot requires that the client writes the lease to presistant storage. As far as I know, there is no requirement for clients to have suitable persistent storage. Of course, the big issue is: do we want to delay IPv6 by making IPv6 deliberately incompatible with common IPv4 deploy strategies? If the answer is that we don't care about IPv6 roll-out, then indeed there is no need to fix this scenario. There are other scenarios, but I believe they should be fixed in the host. Or not at all, if we also declare those operational errors. From nobody Fri Nov 8 07:30:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D309712086C for ; Fri, 8 Nov 2019 07:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEmPy9iDJ5cB for ; Fri, 8 Nov 2019 07:30:41 -0800 (PST) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEAF1208C7 for ; Fri, 8 Nov 2019 07:30:39 -0800 (PST) Received: by mail-yb1-xb2a.google.com with SMTP id f6so2944569ybp.1 for ; Fri, 08 Nov 2019 07:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=na+HVUjEGL3GUm8WDIoYTBwc5SAoUIZuD+KOAOTMW2w=; b=rkVIG4zUbvyPPY+x30n2h3mYstQzM2QYVF82XCozGqkTAMwvnkUxJjuKboQUpTI/lX ECtlQ9QM/5jv5IpF+BZZtzM+vWlkO4kGj/3BmoRXHqNEEt8ew0zDVbVERa34cTeGPVsk XZnsZVRfZiYs0rZinfmSiPvtnmKd1voGr4R3whDeCrVYP4+g+MOYlZAdbvqr7hxPWvzE sA9v1RIW/ji1Opgteh4HoQgQSHVi01nLeqoryYC3nrYnVhP3Oz09uEhI8oQ6apvoE3Cv G2ITd32aS3TsFKiCLdkZTaDbPq24kTPY0rLJ+AF2qj8w+fMdkB4xPvzNtpvwSojwG7eb hIcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=na+HVUjEGL3GUm8WDIoYTBwc5SAoUIZuD+KOAOTMW2w=; b=JWWXZ6gBAr004kDlefESUxXs28kvOd2hoBKhsxT/WN43VnADoUXePgG34dePTAvrC+ Vlufoq/2kB7I9ACKfd7LdZ5Bm+HncDSUWhBoScwzFRS83FPYVlkt22BsCOYgO3SWt6aC K3Bnk7vU1nCS8iwvA3KbSCFLgpnwPECYtZFeK7/eVtt/NHagBz/H7xWahGF+pXr6abyA GaZv46gML7xJa4ozmbpuF26IJLsSQ9N01504URtL8UOgekdqwy3NX/gWACJByf/yy0ZF 6DWC2KSj2m8jt5Mm8kW9A7nghgFV1sfDfOrxkSYtuDE7FR+5qQIqqPXuhXTZ6jH8r557 vnIg== X-Gm-Message-State: APjAAAWUBY9pQrwNGdeyzjB/vYo5FwwRxFi/0mHvd5JEfwsc9SA5OkSK bFgZ5jJxJ524TO5wxxqUJi2NGoC91nmhyg== X-Google-Smtp-Source: APXvYqwzS27pmmgn/IjOsR8pxZVsk9UjPrOxv+BsbWvHFDq73bptjTkkue/R5cZlSiLKO/UXUc1Few== X-Received: by 2002:a25:bb42:: with SMTP id b2mr9475507ybk.411.1573227037720; Fri, 08 Nov 2019 07:30:37 -0800 (PST) Received: from [10.14.226.40] (mobile-166-170-54-200.mycingular.net. [166.170.54.200]) by smtp.gmail.com with ESMTPSA id t15sm1548784ywh.70.2019.11.08.07.30.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Nov 2019 07:30:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 8 Nov 2019 16:30:31 +0100 Message-Id: <974D7BE3-AC63-45D4-BC49-F696E3FF1158@fugue.com> References: Cc: v6ops@ietf.org In-Reply-To: To: Philip Homburg X-Mailer: iPhone Mail (17B84) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 15:30:50 -0000 why would we have to delay deployment? > On Nov 8, 2019, at 15:20, Philip Homburg wrot= e: >=20 > =EF=BB=BF >>=20 >> Probably there is no formal requirement for prefixes to be stable >> across crashes and reboots[*], but there is a behaviour of the >> client to send CONFIRM after reboot or wake-up from sleep, as >> described in the RFC DHCPv6. >=20 > Sending a CONFIRM after a reboot requires that the client writes the > lease to presistant storage. >=20 > As far as I know, there is no requirement for clients to have suitable > persistent storage. >=20 > Of course, the big issue is: do we want to delay IPv6 by making IPv6 > deliberately incompatible with common IPv4 deploy strategies? If the answe= r > is that we don't care about IPv6 roll-out, then indeed there is no need > to fix this scenario. >=20 > There are other scenarios, but I believe they should be fixed in the host.= > Or not at all, if we also declare those operational errors. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Nov 8 13:50:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B96812013F for ; Fri, 8 Nov 2019 13:50:20 -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=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 jBzrD8Q2nRka for ; Fri, 8 Nov 2019 13:50:19 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DAE0120058 for ; Fri, 8 Nov 2019 13:50:18 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id r24so6442963otk.12 for ; Fri, 08 Nov 2019 13:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gUOPRKGV6sc8PGMj1+VsXSUJQh7YWbtf1InPphvpU/A=; b=CwjHbJOx1QhY4A3KcH+pzND6WRGgD+2UTFwCdrrXHFjShTiNo+0aEyZ9bajn2eJs9s AcXJveLHdp/WZ2SJdHjfLPwhiE05KjU75TEBdIqv8qHE3n/GY4w7b+v3EJYVP6YsiJEL iuPr9+ZxDGl5qVDqVyqVlGaoyHVsGqvYB5dokRfGn16L151bXij7pzZZ56fz6oBcyDc6 0+oVpCEKtREEO8zWm6sZC5OncQUJWnfspIbAubJO3G0+qxB27A9iqIrl1mkYj2VUPPv6 eEDyNL7nnsIIOjoj8mQ+DS7rEi/eKYxcRCfzbvEEgGDI5RWo8OV7+bdqlqcNHT+WAoH/ LmDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gUOPRKGV6sc8PGMj1+VsXSUJQh7YWbtf1InPphvpU/A=; b=uilCNprqKLyMjGt6/tlS7mBrTvS0aEh51pZ6a4SowguLbmbDth7wOi+RyfP++gQBFS Cow33WPRUQ3yPKFKeKK29Fe+v0mLeB+E/p2yc7xZvfn/m4JHYLAsPva7LXHmegTeZ+/6 4h9Fb8Wi2uDo9QrKUzgZALipagyGi/JML+F1wNi/801N8kp7WaQfIvcLttz/efpfMPJr QxNlC8QopGmM1sojVxsDMk3nIKLUkvHk9xqHKYdnpv9pD81DWb7X+Yrkdm0QMqoL2/ma zoqT+IzefpttoJ3DCE0Q4ErmE+is1EUSPVF5fM0mm5N5VMW8PvJ68d+COVSmSBCRJNHQ 3zTQ== X-Gm-Message-State: APjAAAUnvHLxW5DPU/VygAQ3A9LFTuAyxP5neo+BYK6bM4Ativd53RbD TSQovKR86KRtGw5VC0CRTgg9ER22sOPIsiAqlHgdPQ== X-Google-Smtp-Source: APXvYqwliW4Rx3rqLgTMHAIpUDMp9BWX4d435aJYbA9tV7p4LcMAn/IYkIF3HXga9vQNGmtnq85LezLkrDY7cs6lBvk= X-Received: by 2002:a05:6830:17c2:: with SMTP id p2mr10941132ota.74.1573249817384; Fri, 08 Nov 2019 13:50:17 -0800 (PST) MIME-Version: 1.0 References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> In-Reply-To: From: Mark Smith Date: Sat, 9 Nov 2019 08:50:07 +1100 Message-ID: To: Philip Homburg Cc: v6ops list Content-Type: multipart/alternative; boundary="000000000000821ab90596dcc4dc" Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 21:50:21 -0000 --000000000000821ab90596dcc4dc Content-Type: text/plain; charset="UTF-8" One of the best questions to often ask is "why?" On Sat, 9 Nov 2019, 01:20 Philip Homburg, wrote: > > Probably there is no formal requirement for prefixes to be stable > > across crashes and reboots[*], but there is a behaviour of the > > client to send CONFIRM after reboot or wake-up from sleep, as > > described in the RFC DHCPv6. > > Sending a CONFIRM after a reboot requires that the client writes the > lease to presistant storage. > > As far as I know, there is no requirement for clients to have suitable > persistent storage. > > Of course, the big issue is: do we want to delay IPv6 by making IPv6 > deliberately incompatible with common IPv4 deploy strategies? Why do you think that this "strategy" exists in IPv4 deployments? Why is it relevant and preferable today for IPv6? Why is it best for IPv6 when people get something different in IPv6 than in IPv4 - public address space to use on their LAN. If the answer > is that we don't care about IPv6 roll-out, then indeed there is no need > to fix this scenario. > > There are other scenarios, but I believe they should be fixed in the host. > Or not at all, if we also declare those operational errors. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000821ab90596dcc4dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the best questions to often ask is "why?= "

On Sat, 9 Nov 2019, 01:20 Philip Homburg, <pch-v6ops-9@u-1.p= hicoh.com> wrote:
> Pro= bably there is no formal requirement for prefixes to be stable
> across crashes and reboots[*], but there is a behaviour of the
> client to send CONFIRM after reboot or wake-up from sleep, as
> described in the RFC DHCPv6.

Sending a CONFIRM after a reboot requires that the client writes the
lease to presistant storage.

As far as I know, there is no requirement for clients to have suitable
persistent storage.

Of course, the big issue is: do we want to delay IPv6 by making IPv6
deliberately incompatible with common IPv4 deploy strategies?
<= /div>

Why do you think t= hat this "strategy" exists in IPv4 deployments?

Why is it relevant and preferable today f= or IPv6?

Why is it best = for IPv6 when people get something different in IPv6 than in IPv4 - public = address space to use on their LAN.



If the answer
is that we don't care about IPv6 roll-out, then indeed there is no need=
to fix this scenario.

There are other scenarios, but I believe they should be fixed in the host.<= br> Or not at all, if we also declare those operational errors.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops
--000000000000821ab90596dcc4dc-- From nobody Fri Nov 8 14:16:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B91E120104 for ; Fri, 8 Nov 2019 14:15: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 PPqYSgY628pu for ; Fri, 8 Nov 2019 14:15:56 -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 772F2120025 for ; Fri, 8 Nov 2019 14:15:56 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 5365786AC8; Fri, 8 Nov 2019 23:15:53 +0100 (CET) To: Mark Smith , Philip Homburg Cc: v6ops list References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <0e18cdbf-10c5-7d83-00a1-c20f3ea1f8bc@si6networks.com> Date: Fri, 8 Nov 2019 19:15:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 22:15:58 -0000 On 8/11/19 18:50, Mark Smith wrote: > One of the best questions to often ask is "why?" > > On Sat, 9 Nov 2019, 01:20 Philip Homburg, > wrote: > > > Probably there is no formal requirement for prefixes to be stable > > across crashes and reboots[*], but there is a behaviour of the > > client to send CONFIRM after reboot or wake-up from sleep, as > > described in the RFC DHCPv6. > > Sending a CONFIRM after a reboot requires that the client writes the > lease to presistant storage. > > As far as I know, there is no requirement for clients to have suitable > persistent storage. > > Of course, the big issue is: do we want to delay IPv6 by making IPv6 > deliberately incompatible with common IPv4 deploy strategies? > > > Why do you think that this "strategy" exists in IPv4 deployments? > > Why is it relevant and preferable today for IPv6? > > Why is it best for IPv6 when people get something different in IPv6 than > in IPv4 - public address space to use on their LAN. Asking "why" is nice. BUt as for many other uses of the question, it doesn't solve the problem. Over 30% of IPv6 deployments do dynamic prefixes, and hence are prone to face this. That's the deployed reality. That aside, I reiterate this is *one of many* possible scenarios where this issue may be faced. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Nov 8 15:41:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A5312011E for ; Fri, 8 Nov 2019 15:41:17 -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=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 TnDbyVhWduGy for ; Fri, 8 Nov 2019 15:41:15 -0800 (PST) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B79F120026 for ; Fri, 8 Nov 2019 15:41:15 -0800 (PST) Received: by mail-ot1-x342.google.com with SMTP id t4so6709251otr.1 for ; Fri, 08 Nov 2019 15:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RLTX6EuzU+3o1tb8Ti5077iXD9q6WPbtrl906y7gJEI=; b=GV3sa9SLmVgx6PgfH/e9gegxwi/zK/pw1t+ErsVZmARWqDhtprPlLwTGfVWi3hA3XS 3xUfOiugMHk774rtYphnDQIlBoY8dsxGQ2k/ivL9MM0emAGLVeWdP0U4w0QmguGa5SuT AAIJ3baVdoUt8rG1i3wnC4qXcvNMY9ha03+Dn+xyRh6hBvuclGjNB/3sYGpTLjP3SvMg lfwbswaXKpu/Xi/4tURL6kAUqJPYRU7IbcpgFiLnRSbDAdt9OQgjculCq7MJKPdMwLIv 6pFAO1nnCLcQcK9XQ2ZnSZJ8u21ZMyrD/X+NzTRAg2FKdnpipRD1i8sQ980KYANfGYPr fL/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RLTX6EuzU+3o1tb8Ti5077iXD9q6WPbtrl906y7gJEI=; b=HFIFQBuLqYgl+gbs7HGgbzK3E0nWuMMSDAU6O59OA3w1K9fIdCsVZ3hgPljn8oEB6n rm3RF9GACs6hfCTGnBkxP1Us3ZoF3gdnHU8Cc79X3WTIw5R8NkPhQQJ0VzVXcn7sMBnf mGzh95nnmRXJ3MgfGVCJOt6BkQ66gUG+q6ZLKQkMvYvraojlvMXhRjqdkBzyr3gvltdq jzrVhqj0y93R6xiv4puufG79pzOz5QGmf4s8BSVAj6/RPW7ndUxMBkKO1TXuJYtGIbwe 2dsuUXKw9Yo2thrQD8wDWl9W2ifhyJJ3d3QKG1pE8dCBp2LAkNq5PHe/30my8exkEdpc R2Ow== X-Gm-Message-State: APjAAAUNNvxwWSXYBGTUjPaqLkBrobgaDT8I7iuwWb3UfJjY8eHWjTqv P5lTRdeMrfa2WXGhEMojvD2abq8Yt39CnJS7+brpaQ== X-Google-Smtp-Source: APXvYqxp+5Zb4b6pkyqX81uGtuVUDRCf6bgEzGQeMAme80BYtap4BKxxfH4120aL3Fcfyb+RBaWYCRMfuAVNcgctGS4= X-Received: by 2002:a9d:74d6:: with SMTP id a22mr11068481otl.153.1573256474659; Fri, 08 Nov 2019 15:41:14 -0800 (PST) MIME-Version: 1.0 References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> <0e18cdbf-10c5-7d83-00a1-c20f3ea1f8bc@si6networks.com> In-Reply-To: <0e18cdbf-10c5-7d83-00a1-c20f3ea1f8bc@si6networks.com> From: Mark Smith Date: Sat, 9 Nov 2019 10:41:04 +1100 Message-ID: To: Fernando Gont Cc: Philip Homburg , v6ops list Content-Type: multipart/alternative; boundary="000000000000500edb0596de51a7" Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 23:41:18 -0000 --000000000000500edb0596de51a7 Content-Type: text/plain; charset="UTF-8" On Sat, 9 Nov 2019, 09:15 Fernando Gont, wrote: > On 8/11/19 18:50, Mark Smith wrote: > > One of the best questions to often ask is "why?" > > > > On Sat, 9 Nov 2019, 01:20 Philip Homburg, > > wrote: > > > > > Probably there is no formal requirement for prefixes to be stable > > > across crashes and reboots[*], but there is a behaviour of the > > > client to send CONFIRM after reboot or wake-up from sleep, as > > > described in the RFC DHCPv6. > > > > Sending a CONFIRM after a reboot requires that the client writes the > > lease to presistant storage. > > > > As far as I know, there is no requirement for clients to have > suitable > > persistent storage. > > > > Of course, the big issue is: do we want to delay IPv6 by making IPv6 > > deliberately incompatible with common IPv4 deploy strategies? > > > > > > Why do you think that this "strategy" exists in IPv4 deployments? > > > > Why is it relevant and preferable today for IPv6? > > > > Why is it best for IPv6 when people get something different in IPv6 than > > in IPv4 - public address space to use on their LAN. > > Asking "why" is nice. BUt as for many other uses of the question, it > doesn't solve the problem. It gets to the root of the problem, so you can determine where the problem truly exists, and where to then prevent the problem. The Five whys method suggests you need to ask "why" around 5 times to get to the root cause of a problem. Five whys https://en.m.wikipedia.org/wiki/Five_whys Prevention is better than cure or mitigation. Mitigation is all that is being proposed here. As someone who has implemented and had had distributed mitigations for this in 'radvd' (the DecrementLifetimes and DeprecatePrefix options), they're not as effective as preventing the problem where it actually exists. Have a look at how horrible the problem gets and how ineffective these mitigations are when someone has a routed network using the dynamic PD prefix. https://github.com/reubenhwk/radvd/issues/116 Over 30% of IPv6 deployments do dynamic > prefixes, and hence are prone to face this. That's the deployed reality. > Why are they doing it that way when it causes problems for their customers? Why don't we know the answer to that question? Why do we always have to try to solve technology problems with more technology, when sometimes education about a different and better way to solve the problem can be cheaper, quicker and more effective? Why is "the ISP is always right" assumed? Why aren't the IETF allowed to say to ISPs, "this is not the way this protocol was designed to be deployed, the correct way is 'X'"? > That aside, I reiterate this is *one of many* possible scenarios where > this issue may be faced. > If it is common, why haven't we heard about it here in the IETF in any other context other than ISPs doing dynamic PD prefixes? > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --000000000000500edb0596de51a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 9 Nov 2019, 09:15 Fernando Gont, <fg= ont@si6networks.com> wrote:
= On 8/11/19 18:50, Mark Smith wrote:
> One of the best questions to often ask is "why?"
>
> On Sat, 9 Nov 2019, 01:20 Philip Homburg, <pch= -v6ops-9@u-1.phicoh.com
> <mailto:pch-v6ops-9@u-1.phicoh.com>>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0> Probably there is no formal requirement for pr= efixes to be stable
>=C2=A0 =C2=A0 =C2=A0> across crashes and reboots[*], but there is a = behaviour of the
>=C2=A0 =C2=A0 =C2=A0> client to send CONFIRM after reboot or wake-up= from sleep, as
>=C2=A0 =C2=A0 =C2=A0> described in the RFC DHCPv6.
>
>=C2=A0 =C2=A0 =C2=A0Sending a CONFIRM after a reboot requires that the = client writes the
>=C2=A0 =C2=A0 =C2=A0lease to presistant storage.
>
>=C2=A0 =C2=A0 =C2=A0As far as I know, there is no requirement for clien= ts to have suitable
>=C2=A0 =C2=A0 =C2=A0persistent storage.
>
>=C2=A0 =C2=A0 =C2=A0Of course, the big issue is: do we want to delay IP= v6 by making IPv6
>=C2=A0 =C2=A0 =C2=A0deliberately incompatible with common IPv4 deploy s= trategies?
>
>
> Why do you think that this "strategy" exists in IPv4 deploym= ents?
>
> Why is it relevant and preferable today for IPv6?
>
> Why is it best for IPv6 when people get something different in IPv6 th= an
> in IPv4 - public address space to use on their LAN.

Asking "why" is nice. BUt as for many other uses of the question,= it
doesn't solve the problem.
It gets to the root of the problem, so you can de= termine where the problem truly exists, and where to then prevent the probl= em.

The Five whys method= suggests you need to ask "why" around 5 times to get to the root= cause of a problem.

Fiv= e whys
Prevention is better than cure or mitigatio= n.

Mitigation is all tha= t is being proposed here. As someone who has implemented and had had distri= buted mitigations for this in 'radvd' (the DecrementLifetimes and D= eprecatePrefix options), they're not as effective as preventing the pro= blem where it actually exists.

Have a look at how horrible the problem gets and how ineffective the= se mitigations are when someone has a routed network using the dynamic PD p= refix.



=
Over 30% of IPv6 deployments do dynamic
prefixes, and hence are prone to face this. That's the deployed reality= .


Why are they doing it that way when it causes = problems for their customers? Why don't we know the answer to that ques= tion?

Why do we always h= ave to try to solve technology problems with more technology, when sometime= s education about a different and better way to solve the problem can be ch= eaper, quicker and more effective?

Why is "the ISP is always right" assumed?

Why aren't the IETF allowed to s= ay to ISPs, "this is not the way this protocol was designed to be depl= oyed, the correct way is 'X'"?


That aside, I reiterate this is *one of many* possible scenarios where
this issue may be faced.

=
If it is common, why haven't we heard about it = here in the IETF in any other context other than ISPs doing dynamic PD pref= ixes?





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




--000000000000500edb0596de51a7-- From nobody Sat Nov 9 16:50:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3BE12010E for ; Sat, 9 Nov 2019 16:50:36 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFqxWrqa8-lV for ; Sat, 9 Nov 2019 16:50:31 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9019D1200D5 for ; Sat, 9 Nov 2019 16:50:31 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id k13so6635487pgh.3 for ; Sat, 09 Nov 2019 16:50:31 -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=20sXUClfdiGsvLL11Y6igd/gB+Ote2K+WcJxzvV+Ydo=; b=aWsq82OuP9w56M7jmQ5lWmWs8f2H716CPdeSj2VRxz8l3ksLIyRmUxUMwCwMzRBQPu WC8OhaSyGimGWb8fnv+bGH+DLOGgu0GxrtxRtbZIfaq3mD4aNP7lxLmTXWUKgTkJC21Z KRZh2rQnKjx2fu/EpfGy7fygmGxEOcetX0RcxvjW0PZEpljd/zuDrYcnpgW3FjT0XIgx TeXr9Q6trHN+keQ3giON+gPrWhLbmNW8hTYe2L6qA6WuuYtNEl06/rt/np+i1jGsWMJw 832k3A69Z3Dlc5b6373BCCPu/f6wF6AzxFovBOJejEJjXvXGpjpjymRfvZqpGH02AC+g ofog== 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=20sXUClfdiGsvLL11Y6igd/gB+Ote2K+WcJxzvV+Ydo=; b=KYYmyvniC1LD0kmpEdB74FGSzjTXGzqOQGW0v6TOkJYXq3XyjuCjV37UcKH3W+krpp OwUnbag1DODR2apcjeGzW50vNGJTGZxm411TQ7KQqvcMrNyc8PmV7fbWft16AeHsEW4Z 2NIXQiJTCtZcdiEaPUEb6N1BY8SaoTT+s5EeOTafsIRtL2CaNeRTW/06ghW++Anzi/LT L66DBzaGeGm5mJDhFYQ8HPHoJguyqSEAVVvgKed5s9YCuw6o4spGbSBkJ8FTc5BWzU10 7cHvgXsjt84mWL54DdXWPJIX3PMga5Ud+Nk3JFQPnrU4fCzvd8KZTjK0QkpPT45z23Dp va1Q== X-Gm-Message-State: APjAAAU4XR/PgbRbtqYSNiyknGd15g4msyOjlatVSArLG1WyEQbOyClL QU9T6LLSFD29i/+mjWrcucX6kcAj X-Google-Smtp-Source: APXvYqxUMAAA/UhoJd4/TKGHKw8aVAbaLi8v2B3yVHyKFXHlvpDwd+iwr6vyxaS1ghAigR6VRoPFgA== X-Received: by 2002:a17:90a:48:: with SMTP id 8mr23637899pjb.82.1573347031002; Sat, 09 Nov 2019 16:50:31 -0800 (PST) Received: from [192.168.1.11] (ip70-185-147-118.sb.sd.cox.net. [70.185.147.118]) by smtp.gmail.com with ESMTPSA id t13sm10868302pfh.12.2019.11.09.16.50.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 16:50:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.2\)) From: Fred Baker In-Reply-To: Date: Sat, 9 Nov 2019 16:50:29 -0800 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <895EAAE8-E24D-429C-8C1D-552B3331BE11@gmail.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.2) Archived-At: Subject: Re: [v6ops] V6ops status as of this morning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 00:50:36 -0000 As I have said before, I am looking for supportive comment on the = mailing list of your drafts. I saw that you sent a note to Nanog, and = some replied copying the v6ops list. At the meeting a week or so hence, I have put you on the agenda to = discuss your drafts. If you don't plan to be in Singapore, that's your = choice; you can be on MeetEcho. But I *would* like for you to discuss = your drafts with the working group. As we usually do, I'll take a hum of = those there, and if there is support, I'll put out an email to the = larger list, and folks can express their support or lack thereof. I asked you a specific question in the email you are replying to. Would = you consider answering it? > On Nov 7, 2019, at 11:21 AM, Fernando Gont = wrote: >=20 > Fred, >=20 > On 5/11/19 15:47, Fred Baker wrote: >> With the closing of the Internet Draft repository at 23:59 UTC >> yesterday, the draft status in v6ops looks like the attached. I >> shared this in July, and some folks found it useful, so I'm sharing >> it again for IETF 106. >=20 > What would be the next step for v6ops to be polled for adoption of: >=20 > * draft-gont-v6ops-slaac-renum > * draft-gont-v6ops-cpe-slaac-renum >=20 > ? >=20 > While there are certainly details to be worked out, based on the = recent > discussion (and earlier discussion this year), as a co-author I = believe > both docs are in shape for v6ops to decide whether the group wants to > work on this or not. >=20 > Thoughts? >=20 > Thanks! >=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 From nobody Mon Nov 11 00:47:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3822812011F for ; Mon, 11 Nov 2019 00:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 0K-D5MDCZKfu for ; Mon, 11 Nov 2019 00:47:05 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 55E3F12004D for ; Mon, 11 Nov 2019 00:47:04 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iU5Lh-0000LOC; Mon, 11 Nov 2019 09:47:01 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <974D7BE3-AC63-45D4-BC49-F696E3FF1158@fugue.com> In-reply-to: Your message of "Fri, 8 Nov 2019 16:30:31 +0100 ." <974D7BE3-AC63-45D4-BC49-F696E3FF1158@fugue.com> Date: Mon, 11 Nov 2019 09:47:00 +0100 Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 08:47:07 -0000 In your letter dated Fri, 8 Nov 2019 16:30:31 +0100 you wrote: >why would we have to delay deployment? Assume that an ISP has a setup with IPv4 that results in flash renumbering. On IPv4 that is masked by NAT in the CPE. On IPv6 that results in downtime for the customer because the problem is not masked. So the ISP delays rolling out IPv6 until either the problem is fixed in IPv6 or, less likely, the ISP has a chance to re-engineer their setup to avoid flash renumbering. From nobody Mon Nov 11 00:52:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5A4120886 for ; Mon, 11 Nov 2019 00:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 zBelKWb2a_Nk for ; Mon, 11 Nov 2019 00:52:34 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 BC8AD120884 for ; Mon, 11 Nov 2019 00:52:33 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iU5Qw-0000LGC; Mon, 11 Nov 2019 09:52:26 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> In-reply-to: Your message of "Sat, 9 Nov 2019 08:50:07 +1100 ." Date: Mon, 11 Nov 2019 09:52:23 +0100 Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 08:52:36 -0000 >Why do you think that this "strategy" exists in IPv4 deployments? One way to end up in this scenario is to have a pool of IPv4 addresses in the access router. A redundant access network makes it possible for customers to end up on different access routers. So when the CPE reboots, the line goes down, and the customer gets assigned to the best access router. If that is a different one from before then the customer experiences flash renumbering. >Why is it relevant and preferable today for IPv6? We want to make it easy for ISPs to turn on IPv6. If we first make them redesign their networks then it will be more costly and take more time, so there will be less IPv6. >Why is it best for IPv6 when people get something different in IPv6 than in >IPv4 - public address space to use on their LAN. It doesn't have much to with wether addresses are public or not. Flash renumbering happens with public IPv4 addresses. From nobody Mon Nov 11 03:01:34 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46731200CE for ; Mon, 11 Nov 2019 03:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec952IpkWEZL for ; Mon, 11 Nov 2019 03:01:29 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E701200DB for ; Mon, 11 Nov 2019 03:01:29 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id t8so15216445qtc.6 for ; Mon, 11 Nov 2019 03:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=RlnLJNfaPagg94WtErdm99TRAAG3uVZSsIwY2kYgRyo=; b=l0AB5g0QMTWtbGgUu7n1ygBJLty6OWkKLkRYWRbGMZNjhkW+/uPAIvOvwKTeVxv+3a +SU4RNf+gm2Rr+us0hcMe87Mk/OG8+Z8KT5GiP8JpT3VBdah403QuAh0TVBTBxCGFGYf peyQ8spUnJi+al9zyVGipg74dq7OnlW8eb+O5XXUdLY3HU/gqsjBVWl5W/dGsGgHVXxY 2YyfZ5GeOOlaJJkHgFCm0HQj66Cdkk29Bk89aJPMR67BaNvUz/Of+uebbMdZremYXsmG NjK/vWtdBoC+Lwjs5tH5yUQ0ryrDJW1djOFNajZ2lwgnzlYbkRCs4GhWGGGtCZHPuQQj OTxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=RlnLJNfaPagg94WtErdm99TRAAG3uVZSsIwY2kYgRyo=; b=rT+utX56Wb3GYCOhFCjIH8ULSBf1TAkkVlAY9MTB8cEvONsXwa4tpMH/Ne5VbqdzNY pfvjzL6WKuRY8cyTjNRy1UJqdip5l3Bkqbe4ubVeV+5stCXcXWXn/XAEETvfzEeM6o7j dgOmg8DWUoyW4UODEQvPOUvomhRJb6ZsL/ifZx7KRo6g1eIqCrl+dtTeVK8aophCzLjF BqtCB1rezkU7yNDCJMgFDJG/fZ7uZx0AAYSvmH9lB6f/UjHFr6hFJS9As8+uE7s67EUp 3NoBRVGJ97VPUk9UkwNJA3Csks05L6XVVD9LlLR+bURHsZ1+uY5W4YvtxoCbD3c+ET0/ BzuA== X-Gm-Message-State: APjAAAU8NEjWYfqILVcxaEzd7Yr3SZbSU5aAFkexxNwgUbng+QiqfXm0 wyp1imnxgpXownATKDfM6nEdgLxEN4JfyQ== X-Google-Smtp-Source: APXvYqy03bbV2NkoEhnPN+pQb7BnYreQ2u2SNUrTF/bsIBQud1OWpbAXj2cdBO7Vt435QxZkRShiKg== X-Received: by 2002:ac8:7111:: with SMTP id z17mr24878421qto.199.1573470088342; Mon, 11 Nov 2019 03:01:28 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e0ba:2180:fcde:58d3? ([2601:18b:300:36ee:e0ba:2180:fcde:58d3]) by smtp.gmail.com with ESMTPSA id q17sm9615176qtq.58.2019.11.11.03.01.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 03:01:27 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D81597CD-65BC-4154-B245-B89B94F93223 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 11 Nov 2019 06:01:26 -0500 Message-Id: References: Cc: v6ops@ietf.org In-Reply-To: To: Philip Homburg X-Mailer: iPad Mail (17B84) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 11:01:33 -0000 --Apple-Mail-D81597CD-65BC-4154-B245-B89B94F93223 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 11, 2019, at 3:47 AM, Philip Homburg wro= te: >=20 > =EF=BB=BFIn your letter dated Fri, 8 Nov 2019 16:30:31 +0100 you wrote: >> why would we have to delay deployment? >=20 > So the ISP delays rolling out IPv6 until either the problem is fixed in > IPv6 or, less likely, the ISP has a chance to re-engineer their setup to > avoid flash renumbering. The ISP has to install a DHCPv6 server in order to do an IPv6 deployment. W= e=E2=80=99ve already heard from one of the main vendors of DHCPv6 servers th= at their server behaves correctly and does not do flash renumbering. The t= wo DHCPv6 servers that I have worked on don=E2=80=99t either. So why is the= ISP going to have to delay? The one time I was asked to help an ISP to set= up DHCPv6 in a way that would allow frequent renumbering, it was a major en= gineering effort (which we wound up not doing). The ISP would have to go o= ut of their way to not support stable prefixes. So where is the impediment to deployment?= --Apple-Mail-D81597CD-65BC-4154-B245-B89B94F93223 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 11, 2019, at 3:47 AM, Philip Homburg= <pch-v6ops-9@u-1.phicoh.com> wrote:

=EF=BB=BFIn your letter dated Fri, 8 Nov 2019 16:30:31 +0100 you wr= ote:
why would we have to delay de= ployment?

So the ISP delays ro= lling out IPv6 until either the problem is fixed in
IPv6 or,= less likely, the ISP has a chance to re-engineer their setup to
<= span>avoid flash renumbering.

The ISP h= as to install a DHCPv6 server in order to do an IPv6 deployment.  We=E2= =80=99ve already heard from one of the main vendors of DHCPv6 servers that t= heir server behaves correctly and does not do flash renumbering.   The t= wo DHCPv6 servers that I have worked on don=E2=80=99t either.  So why i= s the ISP going to have to delay?  The one time I was asked to help an I= SP to set up DHCPv6 in a way that would allow frequent renumbering, it was a= major engineering effort (which we wound up not doing).   The ISP woul= d have to go out of their way to not support stable prefixes.

So where is the impediment to deployment?
= --Apple-Mail-D81597CD-65BC-4154-B245-B89B94F93223-- From nobody Mon Nov 11 03:21:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7F3120820 for ; Mon, 11 Nov 2019 03:21:50 -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_HELO_NONE=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 mEyn7bPHhfpL for ; Mon, 11 Nov 2019 03:21:48 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07FF1200DB for ; Mon, 11 Nov 2019 03:21:48 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 A3F6786AF1; Mon, 11 Nov 2019 12:21:45 +0100 (CET) To: Fred Baker Cc: IPv6 Operations References: <895EAAE8-E24D-429C-8C1D-552B3331BE11@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <65cad6d5-72ce-028f-b768-e507c5874d68@si6networks.com> Date: Mon, 11 Nov 2019 08:19:28 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] V6ops status as of this morning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 11:21:51 -0000 Fred, On 9/11/19 21:50, Fred Baker wrote: > As I have said before, I am looking for supportive comment on the mailing list of your drafts. we never asked that question. Some folks have gone ahead and expressed support of the drafts. However, as authors we just asked for feedback on the document(s) -- and that's what most of the discussion has been about. > I saw that you sent a note to Nanog, and some replied copying the v6ops list. > > At the meeting a week or so hence, I have put you on the agenda to discuss your drafts. If you don't plan to be in Singapore, that's your choice; you can be on MeetEcho. But I *would* like for you to discuss your drafts with the working group. As we usually do, I'll take a hum of those there, and if there is support, I'll put out an email to the larger list, and folks can express their support or lack thereof. > > I asked you a specific question in the email you are replying to. Would you consider answering it? The email I replied to was your post of the status of several drafts (hence the subject of this email). There was no question in the email, nor in the attachment. So... what's the question that you asked, and where did you ask it? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Nov 11 08:21:51 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6621212010F for ; Mon, 11 Nov 2019 08:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=helix-net-nz.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 sHcqn7fgCwcd for ; Mon, 11 Nov 2019 08:21:47 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25651200B6 for ; Mon, 11 Nov 2019 08:21:46 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id x21so15220109iol.2 for ; Mon, 11 Nov 2019 08:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MyyEGuiidn9TfbRedbc7ThjJy+o8kozAe3KTE//Fb7Y=; b=H6Eis1LVid7bJbX7rYtO21b29MyaWW2JpF1z6KuLoqqoVYWAFVHyAVhvHHE7tyVkYg Z39jtdmFfPZY67pqlzuYkojOZLXTP7bVbnOrXHuFfw9fpOEL7nzCXBD9bWvl/XBVIfN1 loKDgpAbE09h7sS87MZky+RQJkjV7313CyePs/ybbICia+HslIwG5jC5KfMrRdlh2FLd kEEAvNbXi2W7wO/+nprYEEKjoUZddPmhkjkry7m9ys5fWZvIyL7ia4dtE8Owu1hDHZbP EVnqqu1g5X86gsOlmB1OIYVNJQFP6Rm91VD0Yj2OokG/x0GsVvI/09dMOsZAXLVgObfV 4+0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MyyEGuiidn9TfbRedbc7ThjJy+o8kozAe3KTE//Fb7Y=; b=LBge6K9yTj96Oh9MJW0XgAtr5JmfXuCGrZOxY784/VEDQ8jM9THBkwFueo3dTpZNB3 UK1zFEI3yIrdREvT1dGScRfrMiWi2nTgUD+cjA6eBUcJ5fx5CSLiEwwo4n0hcxAhe1AG OovQRtIJMr6U4nqe49HaOSNwEryUhT/Q3qnC6rfHOzxn6E/DTG18zmzExLjLsdh481KJ PQR+uFqzMBUWkRdZoGTUlpLLevyEm0KLRqfaF6BQhO3eyirUki9ERvj051Hmc2SS5Qxp jSLGNQL7Yg7UGqRRTxM8loEx7DO30G0ouGF74qoEuCsUpmiyBy/peZolbpuX4U/f56zN jvKA== X-Gm-Message-State: APjAAAVmjuqOCjKXEE+Rd3ggYLsETauQ3BhFYJmo2AhfRFOJmIMcSXpH uqB39K2RWWRJt7hh/JR4ccLRO8Lv1yE= X-Google-Smtp-Source: APXvYqyT0ex11rO7mZ83tD6hvypN5nrEH/oRhfiJ0Zb5NNq0uaJEHE291kSkmnOMshBrTyDqYFSqgA== X-Received: by 2002:a6b:a0c:: with SMTP id z12mr24826080ioi.142.1573489305874; Mon, 11 Nov 2019 08:21:45 -0800 (PST) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com. [209.85.166.49]) by smtp.gmail.com with ESMTPSA id g28sm1258260iob.33.2019.11.11.08.21.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 08:21:45 -0800 (PST) Received: by mail-io1-f49.google.com with SMTP id v17so14116722iol.12 for ; Mon, 11 Nov 2019 08:21:45 -0800 (PST) X-Received: by 2002:a5e:a916:: with SMTP id c22mr21266167iod.177.1573489304851; Mon, 11 Nov 2019 08:21:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Patterson Date: Mon, 11 Nov 2019 16:21:33 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="00000000000012dbd1059714875a" Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 16:21:51 -0000 --00000000000012dbd1059714875a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 11 Nov 2019 at 11:02, Ted Lemon wrote: > > The ISP has to install a DHCPv6 server in order to do an IPv6 deployment. > We=E2=80=99ve already heard from one of the main vendors of DHCPv6 server= s that > their server behaves correctly and does not do flash renumbering. The t= wo > DHCPv6 servers that I have worked on don=E2=80=99t either. So why is the= ISP going > to have to delay? The one time I was asked to help an ISP to set up DHCP= v6 > in a way that would allow frequent renumbering, it was a major engineerin= g > effort (which we wound up not doing). The ISP would have to go *out of > their way* to not support stable prefixes. > This is an oversimplification, ignoring the complexities introduced by various topology, architectural and indeed vendor decisions. i.e. - Centralised vs distributed DHCP server. Distributed helps scale but centralised is easier to manage. Centralised would require some topology-awareness to know where a subscriber is to be numbered from, unless you're OK with deaggregation and the scaling impact it has. - Via a relay or direct? Direct could mean large broadcast domains and may not scale, but helps minimise the need for the server to be topology-aware. Relays would help scale but will need to keep state, and to completely avoid flash renumbering during planned or unplanned outages, they would need to write leases to persistent storage also. (see draft-fkhp-dhc-dhcpv6-pd-relay-requirements ) - DHCPv6 server colocated on the BNG/CMTS, or an off-box solution? Off-box solution is yet-another-thing to manage and scale. Presumably there'll also need to be an IPAM, if we're to do 100% fixed statics, just for subscriber assignments. BNG/CMTS Vendor server may have it's on constraints and limitations. As a network operator, we can make sure we do as much as we can to keep PDs stable and honour leases up to the lease-time advertised, but there will always be the risk that sometimes we have to revoke the validity of a lease, either intentionally or unintentionally. And sadly in the worse case scenarios, we may not be able to offer the same PD or NA as previously leased. If we can offer some recommendations to CPE & DHCP client/relay/server developers, as well as Operators, to help minimise this impact, I think it's worthwhile to do. If we can slightly tweak protocols to help minimise this impact, I understand that it may be a contentious idea, but would like to think it's also worthwhile looking in to? --00000000000012dbd1059714875a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 11 Nov 2019 at 11:02, Ted Lemon &= lt;mellon@fugue.com> wrote:
<= /div>

The ISP has to install a DHCPv6 server in= order to do an IPv6 deployment.=C2=A0 We=E2=80=99ve already heard from one= of the main vendors of DHCPv6 servers that their server behaves correctly = and does not do flash renumbering. =C2=A0 The two DHCPv6 servers that I hav= e worked on don=E2=80=99t either.=C2=A0 So why is the ISP going to have to = delay?=C2=A0 The one time I was asked to help an ISP to set up DHCPv6 in a = way that would allow frequent renumbering, it was a major engineering effor= t (which we wound up not doing). =C2=A0 The ISP would have to go out of = their way=C2=A0to not support stable prefixes.
=

This is an oversimplification, ignoring the complexitie= s introduced by various topology, architectural and indeed vendor decisions= .
i.e.
- Centralised vs distributed DHCP server.
<= div>Distributed helps scale but centralised is easier to manage.
= Centralised would require some topology-awareness to know where a subscribe= r is to be numbered from, unless you're OK with deaggregation and the s= caling impact it has.=C2=A0

- Via a relay or direc= t?
Direct could mean large broadcast domains and may not scale, b= ut helps minimise the need for the server to be topology-aware.
<= div>Relays would help scale but will need to keep state, and to completely = avoid flash renumbering during planned or unplanned outages, they would nee= d to write leases to persistent storage also.=C2=A0 =C2=A0 (see=C2=A0draft-fkhp-dhc-dhcpv6-pd-relay-req= uirements )

- DHCPv6 server colocated on the BN= G/CMTS, or an off-box solution?
Off-box solution is yet-another-t= hing to manage and scale.=C2=A0 Presumably there'll also need to be an = IPAM, if we're to do 100% fixed statics, just for subscriber assignment= s.
BNG/CMTS Vendor server may have it's on constraints and li= mitations.


As a network operator, w= e can make sure we do as much as we can to keep PDs stable and honour lease= s up to the lease-time advertised, but there will always be the risk that s= ometimes we have to revoke the validity of a lease, either intentionally or= unintentionally.=C2=A0 And sadly in the worse case scenarios, we may not b= e able to offer the same PD or NA as previously leased.
If we can= offer some recommendations to CPE & DHCP client/relay/server developer= s, as well as Operators, to help minimise this impact, I think it's wor= thwhile to do.
If we can slightly tweak protocols to help minimis= e this impact, I understand that it may be a contentious idea, but would li= ke to think it's also worthwhile looking in to?



=C2=A0
--00000000000012dbd1059714875a-- From nobody Mon Nov 11 09:11:26 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AF8120A4B for ; Mon, 11 Nov 2019 09:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6txs4HzfuVbc for ; Mon, 11 Nov 2019 09:11:19 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3DA120A44 for ; Mon, 11 Nov 2019 09:11:19 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id t20so16404567qtn.9 for ; Mon, 11 Nov 2019 09:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=ys2Mo6kUnIUxNVp7UHtUSeA4QkS5P5H46rT2EdHuL7s=; b=KdrCtH2Mgu+bXd1zsAG2iIAuvizD1YoVeuj2S2qXlAlqbLxv+PShqoSI2UVxyq0SpE qFLjXnK7zDNBb3+MLKkdDuy8o8FHTriEnPC41Wxt9KQL/FepKisRqRoUuZ+nlYX5X0Rz NlB6IgG8SCXcjx+DIRk3hQ8SLMR8zmw0+SC1NoLxQN8Iq2QKb0BrhmhCE0JPf4yHw2ew tf6TxJmzR4+jBYKThbFxGfSVvAaZFLdVL3QPr9XFFfoobkezeNIF8cdr04bU+7l6ccuv QVWDBn3IB8iPt6wNcmSTdr40coZ89E961TJ0jEXNZvIDVqlXp0jwn/m7ZQF1aOP50Z22 1C8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=ys2Mo6kUnIUxNVp7UHtUSeA4QkS5P5H46rT2EdHuL7s=; b=tnOtJB7YMFQ7kDrEHlF7joCkAF9miA0WEVPntaYo0GdrVjECOucp8HcAVhk9X0K7Xt WwpUr+5jga1F1dLRAOikV91r72adcVYOxsGmiNuR/PSvoF4ZNMj3SMnn9yCFikQefEmp /uk7CRRBEvEVVyDIPQBevl/tzAPv+bvZZalGzKRuY5AmjC7yWykJfc19jxZzvP8HS5PR 1VPbwsXB4R101KtqMR7Ln4FyARKg6iqVU7iIoS4lDpEuq+5kwBQWIG6tg7jyJsrATkxk 5iMnIpZ9dbAXYpuG4/DosvyAFSVpmvT1egPprx+sQhhVScv5dVPKFueApcTXQC0ZznMV YZkg== X-Gm-Message-State: APjAAAWQaT8iMcnq88A1V+DmnPk6p2jNWaC4zS8hBAhgBoLqeJG/92qU DtPkceKGQXLXDJpLLS2h8x3tb/fcwMtTJw== X-Google-Smtp-Source: APXvYqxrd1UFqwPYf6HjzNLj1IERcHR12+DEXVkcb5XVGs5QkykMn30K3gHQ+3dq5k1pebtAbPtxbg== X-Received: by 2002:ac8:4686:: with SMTP id g6mr26121219qto.215.1573492278135; Mon, 11 Nov 2019 09:11:18 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:789b:98b5:343d:2290? ([2601:18b:300:36ee:789b:98b5:343d:2290]) by smtp.gmail.com with ESMTPSA id i12sm7541513qkm.78.2019.11.11.09.11.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 09:11:17 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-72118C97-DB68-41B4-9B38-3A88D45CA961 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Ted Lemon In-Reply-To: Cc: "v6ops@ietf.org list" Date: Mon, 11 Nov 2019 12:11:16 -0500 Message-Id: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> References: To: Richard Patterson X-Mailer: iPhone Mail (17B84) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 17:11:24 -0000 --Apple-Mail-72118C97-DB68-41B4-9B38-3A88D45CA961 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Nobody is expecting you to never renumber. Well, at least I am not. What I= am talking about here is deliberate, opportunistic renumbering. If your top= ology changes and you have to renumber, so be it. If you can avoid that it=E2= =80=99s better, and if you can give notice it=E2=80=99s also better. If you c= an do it gracefully with temporary routes, even better. But you shouldn=E2=80= =99t be renumbering just =E2=80=98cuz.=20 >> On Nov 11, 2019, at 11:21, Richard Patterson wrote= : > =EF=BB=BF >>> On Mon, 11 Nov 2019 at 11:02, Ted Lemon wrote: >>=20 >> The ISP has to install a DHCPv6 server in order to do an IPv6 deployment.= We=E2=80=99ve already heard from one of the main vendors of DHCPv6 servers= that their server behaves correctly and does not do flash renumbering. Th= e two DHCPv6 servers that I have worked on don=E2=80=99t either. So why is t= he ISP going to have to delay? The one time I was asked to help an ISP to s= et up DHCPv6 in a way that would allow frequent renumbering, it was a major e= ngineering effort (which we wound up not doing). The ISP would have to go o= ut of their way to not support stable prefixes. >=20 > This is an oversimplification, ignoring the complexities introduced by var= ious topology, architectural and indeed vendor decisions. > i.e. > - Centralised vs distributed DHCP server. > Distributed helps scale but centralised is easier to manage. > Centralised would require some topology-awareness to know where a subscrib= er is to be numbered from, unless you're OK with deaggregation and the scali= ng impact it has.=20 >=20 > - Via a relay or direct? > Direct could mean large broadcast domains and may not scale, but helps min= imise the need for the server to be topology-aware. > Relays would help scale but will need to keep state, and to completely avo= id flash renumbering during planned or unplanned outages, they would need to= write leases to persistent storage also. (see draft-fkhp-dhc-dhcpv6-pd-r= elay-requirements ) >=20 > - DHCPv6 server colocated on the BNG/CMTS, or an off-box solution? > Off-box solution is yet-another-thing to manage and scale. Presumably the= re'll also need to be an IPAM, if we're to do 100% fixed statics, just for s= ubscriber assignments. > BNG/CMTS Vendor server may have it's on constraints and limitations. >=20 >=20 > As a network operator, we can make sure we do as much as we can to keep PD= s stable and honour leases up to the lease-time advertised, but there will a= lways be the risk that sometimes we have to revoke the validity of a lease, e= ither intentionally or unintentionally. And sadly in the worse case scenari= os, we may not be able to offer the same PD or NA as previously leased. > If we can offer some recommendations to CPE & DHCP client/relay/server dev= elopers, as well as Operators, to help minimise this impact, I think it's wo= rthwhile to do. > If we can slightly tweak protocols to help minimise this impact, I underst= and that it may be a contentious idea, but would like to think it's also wor= thwhile looking in to? --Apple-Mail-72118C97-DB68-41B4-9B38-3A88D45CA961 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Nobody is= expecting you to never renumber.   Well, at least I am not. What I am t= alking about here is deliberate, opportunistic renumbering. If your topology= changes and you have to renumber, so be it. If you can avoid that it=E2=80=99= s better, and if you can give notice it=E2=80=99s also better. If you can do= it gracefully with temporary routes, even better. But you shouldn=E2=80=99t= be renumbering just =E2=80=98cuz. 

On Nov 11, 2019, at 11:21, Richard Patterson <richard@he= lix.net.nz> wrote:

=EF=BB=BF
On Mon, 11 Nov 201= 9 at 11:02, Ted Lemon <mellon@fugue.c= om> wrote:

The ISP has to install= a DHCPv6 server in order to do an IPv6 deployment.  We=E2=80=99ve alre= ady heard from one of the main vendors of DHCPv6 servers that their server b= ehaves correctly and does not do flash renumbering.   The two DHCPv6 se= rvers that I have worked on don=E2=80=99t either.  So why is the ISP go= ing to have to delay?  The one time I was asked to help an ISP to set u= p DHCPv6 in a way that would allow frequent renumbering, it was a major engi= neering effort (which we wound up not doing).   The ISP would have to g= o out of their way to not support stable prefixes.

This is an oversimplification, ignoring the c= omplexities introduced by various topology, architectural and indeed vendor d= ecisions.
i.e.
- Centralised vs distributed DHCP server.=
Distributed helps scale but centralised is easier to manage.
Centralised would require some topology-awareness to know where a subs= criber is to be numbered from, unless you're OK with deaggregation and the s= caling impact it has. 

- Via a relay or direct= ?
Direct could mean large broadcast domains and may not scale, but= helps minimise the need for the server to be topology-aware.
Relays would help scale but will need to keep state, and to completely avoi= d flash renumbering during planned or unplanned outages, they would need to w= rite leases to persistent storage also.    (see draft-fkhp-dhc-dhcpv6-pd-relay-requirements= )

- DHCPv6 server colocated on the BNG/CMTS, or a= n off-box solution?
Off-box solution is yet-another-thing to manag= e and scale.  Presumably there'll also need to be an IPAM, if we're to d= o 100% fixed statics, just for subscriber assignments.
BNG/CMTS Ve= ndor server may have it's on constraints and limitations.


As a network operator, we can make sure we do as much a= s we can to keep PDs stable and honour leases up to the lease-time advertise= d, but there will always be the risk that sometimes we have to revoke the va= lidity of a lease, either intentionally or unintentionally.  And sadly i= n the worse case scenarios, we may not be able to offer the same PD or NA as= previously leased.
If we can offer some recommendations to CPE &a= mp; DHCP client/relay/server developers, as well as Operators, to help minim= ise this impact, I think it's worthwhile to do.
If we can slightly= tweak protocols to help minimise this impact, I understand that it may be a= contentious idea, but would like to think it's also worthwhile looking in t= o?



 
=
= --Apple-Mail-72118C97-DB68-41B4-9B38-3A88D45CA961-- From nobody Mon Nov 11 10:56:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A1F120C31 for ; Mon, 11 Nov 2019 10:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=helix-net-nz.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 dKXDTaT0FH1e for ; Mon, 11 Nov 2019 10:55:58 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E711200F8 for ; Mon, 11 Nov 2019 10:55:41 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id c11so15732587iom.10 for ; Mon, 11 Nov 2019 10:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rifsLm6szRdff1EhZo95L00vBwcfdNkTm2GTNE8704A=; b=VxF08kC/GUXfIwkSqP1RpYELVDKC13qmkZYpzp30ENYC1F2dpFp2Z+0VNkRoObWMvh f3hEUgapYd9tESf5fhvwhht62+/3Uy93AOUG7f/xZJT22hejor/xFKUczS0JpAW5SRUs gtWBppSqiOlBHOEgK6IUmaSjpe//phi+EsrBeBvZTihzXPROIUjspW5m+BFLLB8RKE49 7RrCXyQw4gj3dztsx8mypfX7FlDABTRz9tN2Td7l/Q5lWDbxU+VxCr1JqXVC08EY9HQ2 0eLJL0qGtHdBn+1Kz1h9H8a9cdCg+A0K6TmDmU0TEpN5eCa7QJu9gtjktyKgtl3RDaAk lQNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rifsLm6szRdff1EhZo95L00vBwcfdNkTm2GTNE8704A=; b=QsXutMkRd60XDyL9vaM21OEiBJBcO1lbiPaSDMjHJK0594iOuYdSj8gTkE3rY8/7YU ZPoHD1jggSRnjjjXvXpTSE5fyB7qqmk/u5/vpZChr2EUQlwJ0QRUHd2BkjNPo4xiLjHv HH1K+JUkFJsrhD6Z8bLTZxCsqVa9ViQCvdoGapvE8CVOCAl0ITvaxHKGKaM7AFcG3CsZ BLRLWTtJEnG7Hb50H5OfFHhxlfw7ib5FNvCTbDNqLJJJKgh8rJ2Y2FHu1PG37ZQU70dJ MCsSrnllVZHW6joj2dcdkvhZrACUASs8neFhVzzdVjZVDyCGY8MCxBl0F9mUGnc+/+Kx duWg== X-Gm-Message-State: APjAAAWuHCN8opkGPFX0QPCjo9RLK/qzv/4/VcOONzU2liV0NL2/uzmQ JUcLXwciYPOnwylNbKFxaxEI4hB3pZs= X-Google-Smtp-Source: APXvYqz9C7ShmC+8KTF+RKlmHinyEfYfuGpwsvD+Cl5ht8ExvMJprRKRa9xKEZq4M0GoUvDHoiJ3RA== X-Received: by 2002:a6b:c809:: with SMTP id y9mr21681700iof.232.1573498540852; Mon, 11 Nov 2019 10:55:40 -0800 (PST) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id w1sm2323058ilq.62.2019.11.11.10.55.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 10:55:39 -0800 (PST) Received: by mail-il1-f179.google.com with SMTP id m5so13078356ilq.0 for ; Mon, 11 Nov 2019 10:55:39 -0800 (PST) X-Received: by 2002:a92:188:: with SMTP id 130mr32578065ilb.177.1573498539501; Mon, 11 Nov 2019 10:55:39 -0800 (PST) MIME-Version: 1.0 References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> In-Reply-To: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> From: Richard Patterson Date: Mon, 11 Nov 2019 18:55:28 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Ted Lemon , "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000008072bc059716ad2e" Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 18:56:00 -0000 --0000000000008072bc059716ad2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 11 Nov 2019 at 17:11, Ted Lemon wrote: > Nobody is expecting you to never renumber. Well, at least I am not. Wha= t > I am talking about here is deliberate, opportunistic renumbering. If your > topology changes and you have to renumber, so be it. If you can avoid tha= t > it=E2=80=99s better, and if you can give notice it=E2=80=99s also better.= If you can do it > gracefully with temporary routes, even better. But you shouldn=E2=80=99t = be > renumbering just =E2=80=98cuz. > In that case I think we agree, an operator shouldn't intentionally renumber "just 'cuz". However the scenarios I mentioned are far from the Operator going *out of their way* to not support stable prefixes. The question is just around how stable they are, and once you start having to ask that question, then shouldn't we be looking at ways to mitigate the impact to an end-user? --0000000000008072bc059716ad2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 11 Nov 2019 at 17:11, Ted Lemon &= lt;mellon@fugue.com> wrote:
<= /div>
Nobody is expect= ing you to never renumber. =C2=A0 Well, at least I am not. What I am talkin= g about here is deliberate, opportunistic renumbering. If your topology cha= nges and you have to renumber, so be it. If you can avoid that it=E2=80=99s= better, and if you can give notice it=E2=80=99s also better. If you can do= it gracefully with temporary routes, even better. But you shouldn=E2=80=99= t be renumbering just =E2=80=98cuz.=C2=A0

In that case I think we agree, an operator shouldn't i= ntentionally renumber "just 'cuz".=C2=A0 However the scenario= s I mentioned are far from the Operator going out of their way to no= t support stable prefixes. The question is just around=C2=A0how stable they= are, and once you start having to ask that question, then shouldn't we= be looking at ways to mitigate the impact to an end-user?

--0000000000008072bc059716ad2e-- From nobody Mon Nov 11 11:31:59 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087FC12084F for ; Mon, 11 Nov 2019 11:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Itcf1DQTdXY for ; Mon, 11 Nov 2019 11:31:54 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AFA12081C for ; Mon, 11 Nov 2019 11:31:45 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id r20so2819682qtp.13 for ; Mon, 11 Nov 2019 11:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=RPQLrZ4JhmSI6dx6DksETKVWJ+7FstG52RmvUygX4jc=; b=BlwNZ97wW9bMvxcwch9qZR1eA9NjgdKo76p4hmgFrBdY4jqD+cq/zo50Y456ShwBWL yjRu1BAcCpULE7YVl9KcsXg2rrSsEMMrkoNWtY+twV+Cs6f8m7l47cHetdHrQebxcLad /TsoBVk5r09BvKVzWocCuyEpLCX4/dgZL1/permW2r2Ppdqc6ittc0nT3n6wtqHO7SYx VWmTDKoBnIoEfvhmKD4T110xpAIimfnMSLoHCpj3LETSo1lc2wNGGSoC4aKDKwJcpwV/ oRFf6tnyYqliAD1DfxtpR5h1jBJbgH5gw6sSFf/iNzFDdqYNMOCRiPg/sh35s506gm5H WVlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=RPQLrZ4JhmSI6dx6DksETKVWJ+7FstG52RmvUygX4jc=; b=tL7IG68VnPkk3m+zEi8+qa8rMfnJZR9GV5nTdB5HtMWaKWc/2y0FK+gFylcV6gk7Rt vnrGpzgvytG4KO0LVg+s9vbxZR8OpylkDvd5pHxvzFB4wnmGysuRIoI5Hhiwey1JUcyF GtM5HD9okMmePItut03A5/b6jqQiYthE0ZxPAg0md+UzSlpUmZLZFfKpVkZqptmpDQiK gpoXvZvpB+BlFmV2nivWctoeQz3vMcNyWjBNiEMqd4/KEutTjUafT9V4e9kiwlST8JsQ xiBKt8ZVPncPBObsc3MKh3tKRkTeDm7ge8nt1vYnJoujlF3Psnk0YAXMmXk7ZjyBX44W DE/Q== X-Gm-Message-State: APjAAAU9aj8tTU3m7v+gjezpl2Ouyewdi0qijmYBlTNYjOhBFP9fpVrW WKnte/99W8pF6uClfOluoLX4hU/XLB2kYg== X-Google-Smtp-Source: APXvYqyrMNErU5sYPAv7yp8BZh3UBAElBTkgflREjjFcvgs6yoCpyTZrCbU5dphhBIczERZsBsSl6A== X-Received: by 2002:aed:228b:: with SMTP id p11mr27960286qtc.196.1573500704630; Mon, 11 Nov 2019 11:31:44 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:789b:98b5:343d:2290? ([2601:18b:300:36ee:789b:98b5:343d:2290]) by smtp.gmail.com with ESMTPSA id t2sm7667419qkt.95.2019.11.11.11.31.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 11:31:43 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-7FB3904F-615C-443C-836E-DD294A23FCD3 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 11 Nov 2019 14:31:43 -0500 Message-Id: <1FE980D2-C9B9-4CB0-B793-E3005799F8E7@fugue.com> References: Cc: "v6ops@ietf.org list" In-Reply-To: To: Richard Patterson X-Mailer: iPhone Mail (17B84) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 19:31:57 -0000 --Apple-Mail-7FB3904F-615C-443C-836E-DD294A23FCD3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Definitely.=20 > On Nov 11, 2019, at 13:55, Richard Patterson wrote:= >=20 > =EF=BB=BF >> On Mon, 11 Nov 2019 at 17:11, Ted Lemon wrote: >=20 >> Nobody is expecting you to never renumber. Well, at least I am not. Wha= t I am talking about here is deliberate, opportunistic renumbering. If your t= opology changes and you have to renumber, so be it. If you can avoid that it= =E2=80=99s better, and if you can give notice it=E2=80=99s also better. If y= ou can do it gracefully with temporary routes, even better. But you shouldn=E2= =80=99t be renumbering just =E2=80=98cuz.=20 >=20 > In that case I think we agree, an operator shouldn't intentionally renumbe= r "just 'cuz". However the scenarios I mentioned are far from the Operator g= oing out of their way to not support stable prefixes. The question is just a= round how stable they are, and once you start having to ask that question, t= hen shouldn't we be looking at ways to mitigate the impact to an end-user? >=20 --Apple-Mail-7FB3904F-615C-443C-836E-DD294A23FCD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Definitely. 

On Nov 11, 2019, at 13:55, Richa= rd Patterson <richard@helix.net.nz> wrote:

<= blockquote type=3D"cite">
=EF=BB=BF
On Mon, 11 Nov 2019 at 17:11, Ted Lemon <mellon@fugue.com> wrote:
Nobody is expecting you to never renumber. &nb= sp; Well, at least I am not. What I am talking about here is deliberate, opp= ortunistic renumbering. If your topology changes and you have to renumber, s= o be it. If you can avoid that it=E2=80=99s better, and if you can give noti= ce it=E2=80=99s also better. If you can do it gracefully with temporary rout= es, even better. But you shouldn=E2=80=99t be renumbering just =E2=80=98cuz.=  

In that case I thin= k we agree, an operator shouldn't intentionally renumber "just 'cuz".  H= owever the scenarios I mentioned are far from the Operator going out of t= heir way to not support stable prefixes. The question is just around&nbs= p;how stable they are, and once you start having to ask that question, then s= houldn't we be looking at ways to mitigate the impact to an end-user?
<= div>
= --Apple-Mail-7FB3904F-615C-443C-836E-DD294A23FCD3-- From nobody Mon Nov 11 11:47:38 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231C21208C2 for ; Mon, 11 Nov 2019 11:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 U5t-GXorXuXb for ; Mon, 11 Nov 2019 11:47:33 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA82B120105 for ; Mon, 11 Nov 2019 11:47:33 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id d5so12275441otp.4 for ; Mon, 11 Nov 2019 11:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cKPdATfLqFxNKQceaHzy4L9j3FR8JdAEZvgVmWJpISQ=; b=g9FQ4scaR6a0OXqZJ6tSBA4sOsMtvaJ++KKmzMAN8CY71xI6hTZd2vAggGykh4A5/Q SQEpNyqNqD/4jvPBMKMfti7CoVuSxeetHjsPi50mZ3103Zp+PdLUQ8l10Et8AVmohM+r /4cmhLFa901Bp/e9uYZoOTyUkI/ETC4Je3he9E5O9Q6UQjBUoGczE+EzZxxpoiCym1iH hMPXswrXv9eefADIewHnufDdcmjXb8gH57h9+2CeO/Plea2RfQsHPXsP+sijQbax5Yv4 AX5ruSU3TRYTZpkHgZO7SOkP1YJRBVcQYtJBGFLbX4faFvm6+/9aJQq/sWMCUeqD+qdb 0b0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cKPdATfLqFxNKQceaHzy4L9j3FR8JdAEZvgVmWJpISQ=; b=TA4rAuguOpG2mHIdQAYzH49ePdjVcVdYdJtYcbI/Ba9D6/cRQY/qZkD0bYvjFyJ7Gf T8ag5FqSxes98dGjquQmucKwKdi8rljj3/HnxYeahGrtgLBD8ciFIf7xulN9C3LIDkhy C7ezPf5HJmdz7KHQPVcfrXplOzrVkX+bVXNKjk0BqNA8qaunus/gg4gWwMFANVGOseHU XrtKYD7HIRt8exziezxu2eDnS8X8e1mqGFZhcdzdR4OU95EZhcRMUtXixhHlhc3t4UsI frb8UzUguR9eDt2kU40ZmYZRSAl29p+BGU5xhYlamE4WUioD4Vg0hPsm4WT9pmSb/iTW i9mQ== X-Gm-Message-State: APjAAAVn/iY0R0AunkzFBWsvGlqwJWl32MbAk0HiBD+KFvpQbdfqQF8T IRHaHFDG9bMf7wKgBAhter00j1tfp69uGOLzpgZ3Gw== X-Google-Smtp-Source: APXvYqyh8ZQNaV+fvIJxycgwQsC0jwibARh0kzOEk2AbSrjbhpYnSVGl+yuBBMTMDG4WGIkcZv5XYXqULPUsF06Hrgc= X-Received: by 2002:a05:6830:c2:: with SMTP id x2mr191110oto.257.1573501652984; Mon, 11 Nov 2019 11:47:32 -0800 (PST) MIME-Version: 1.0 References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> In-Reply-To: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> From: Mark Smith Date: Tue, 12 Nov 2019 06:47:22 +1100 Message-ID: To: Ted Lemon Cc: Richard Patterson , v6ops list Content-Type: multipart/alternative; boundary="0000000000001466e7059717676b" Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 19:47:36 -0000 --0000000000001466e7059717676b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 12 Nov 2019, 04:11 Ted Lemon, wrote: > Nobody is expecting you to never renumber. Well, at least I am not. > I'm not either. IPv6's Preferred and Valid lifetime mechanisms are for planned renumbering. What I am talking about here is deliberate, opportunistic renumbering. If > your topology changes and you have to renumber, so be it. > Unplanned "flash" renumbering due to a topology change implies an unplanned "flash" topology change. That's going to be a rare event, and ideally shouldn't ever occur, because I think it is a sign that some other planning hasn't been occurring. I don't really understand what is so hard about all this. You either provide prefix stability using a client's DUID, or you can use RADIUS. Stable PD prefixes are similar to IPv4 RADIUS Framed-Routes. IETF RADIUS attributes exist to provide IPv6 PD prefixes to BNGs that use them with their local DHCPV6-PD server - see RFC 6911. This is the method used on the IPv6 residential broadband project I worked on in 2010, and I'm pretty confident it is still being used today, as I've been a customer of it for the past 8 years. If you can avoid that it=E2=80=99s better, and if you can give notice it=E2= =80=99s also > better. If you can do it gracefully with temporary routes, even better. B= ut > you shouldn=E2=80=99t be renumbering just =E2=80=98cuz. > > On Nov 11, 2019, at 11:21, Richard Patterson wrote= : > > =EF=BB=BF > On Mon, 11 Nov 2019 at 11:02, Ted Lemon wrote: > >> >> The ISP has to install a DHCPv6 server in order to do an IPv6 >> deployment. We=E2=80=99ve already heard from one of the main vendors of= DHCPv6 >> servers that their server behaves correctly and does not do flash >> renumbering. The two DHCPv6 servers that I have worked on don=E2=80=99= t either. >> So why is the ISP going to have to delay? The one time I was asked to h= elp >> an ISP to set up DHCPv6 in a way that would allow frequent renumbering, = it >> was a major engineering effort (which we wound up not doing). The ISP >> would have to go *out of their way* to not support stable prefixes. >> > > This is an oversimplification, ignoring the complexities introduced by > various topology, architectural and indeed vendor decisions. > i.e. > - Centralised vs distributed DHCP server. > Distributed helps scale but centralised is easier to manage. > Centralised would require some topology-awareness to know where a > subscriber is to be numbered from, unless you're OK with deaggregation an= d > the scaling impact it has. > > - Via a relay or direct? > Direct could mean large broadcast domains and may not scale, but helps > minimise the need for the server to be topology-aware. > Relays would help scale but will need to keep state, and to completely > avoid flash renumbering during planned or unplanned outages, they would > need to write leases to persistent storage also. (see draft-fkhp-dhc-d= hcpv6-pd-relay-requirements > ) > > - DHCPv6 server colocated on the BNG/CMTS, or an off-box solution? > Off-box solution is yet-another-thing to manage and scale. Presumably > there'll also need to be an IPAM, if we're to do 100% fixed statics, just > for subscriber assignments. > BNG/CMTS Vendor server may have it's on constraints and limitations. > > > As a network operator, we can make sure we do as much as we can to keep > PDs stable and honour leases up to the lease-time advertised, but there > will always be the risk that sometimes we have to revoke the validity of = a > lease, either intentionally or unintentionally. And sadly in the worse > case scenarios, we may not be able to offer the same PD or NA as previous= ly > leased. > If we can offer some recommendations to CPE & DHCP client/relay/server > developers, as well as Operators, to help minimise this impact, I think > it's worthwhile to do. > If we can slightly tweak protocols to help minimise this impact, I > understand that it may be a contentious idea, but would like to think it'= s > also worthwhile looking in to? > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000001466e7059717676b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 12 Nov 2019, 04:11 Ted Lemon, <mellon@fugue.com> wrote:
Nobody = is expecting you to never renumber. =C2=A0 Well, at least I am not.

I'm not either.

IPv6's Preferred and Valid lifetime mechanisms are for planned renumb= ering.


What I am talking about here= is deliberate, opportunistic renumbering. If your topology changes and you= have to renumber, so be it.

Unplanned "flash" renu= mbering due to a topology change implies an unplanned "flash" top= ology change. That's going to be a rare event, and ideally shouldn'= t ever occur, because I think it is a sign that some other planning hasn= 9;t been occurring.


=
I don't really understand what is so hard about= all this.=C2=A0

You eit= her provide prefix stability using a client's DUID, or you can use RADI= US.

Stable PD prefixes a= re similar to IPv4 RADIUS Framed-Routes.

<= div dir=3D"auto">IETF RADIUS attributes exist to provide IPv6 PD prefixes t= o BNGs that use them with their local DHCPV6-PD server - see RFC 6911.=C2= =A0

This is the method u= sed on the IPv6 residential broadband project I worked on in 2010, and I= 9;m pretty confident it is still being used today, as I've been a custo= mer of it for the past 8 years.

If you can avoid that it=E2=80= =99s better, and if you can give notice it=E2=80=99s also better. If you ca= n do it gracefully with temporary routes, even better. But you shouldn=E2= =80=99t be renumbering just =E2=80=98cuz.=C2=A0

On Nov 11, 2019, at 11:21, Richard Patterson <richard@helix.net.nz> wro= te:

= =EF=BB=BF
On Mon, 11 Nov 2019 at 11:02, Te= d Lemon <mellon@fugue.com&= gt; wrote:

The ISP has to install a D= HCPv6 server in order to do an IPv6 deployment.=C2=A0 We=E2=80=99ve already= heard from one of the main vendors of DHCPv6 servers that their server beh= aves correctly and does not do flash renumbering. =C2=A0 The two DHCPv6 ser= vers that I have worked on don=E2=80=99t either.=C2=A0 So why is the ISP go= ing to have to delay?=C2=A0 The one time I was asked to help an ISP to set = up DHCPv6 in a way that would allow frequent renumbering, it was a major en= gineering effort (which we wound up not doing). =C2=A0 The ISP would have t= o go out of their way=C2=A0to not support stable prefixes.

This is an oversimplification, ignoring = the complexities introduced by various topology, architectural and indeed v= endor decisions.
i.e.
- Centralised vs distributed DHCP= server.
Distributed helps scale but centralised is easier to man= age.
Centralised would require some topology-awareness to know wh= ere a subscriber is to be numbered from, unless you're OK with deaggreg= ation and the scaling impact it has.=C2=A0

- Via a= relay or direct?
Direct could mean large broadcast domains and m= ay not scale, but helps minimise the need for the server to be topology-awa= re.
Relays would help scale but will need to keep state, and= to completely avoid flash renumbering during planned or unplanned outages,= they would need to write leases to persistent storage also.=C2=A0 =C2=A0 (= see=C2=A0draft-fkhp-dhc-dhcp= v6-pd-relay-requirements )

- DHCPv6 server colo= cated on the BNG/CMTS, or an off-box solution?
Off-box solution i= s yet-another-thing to manage and scale.=C2=A0 Presumably there'll also= need to be an IPAM, if we're to do 100% fixed statics, just for subscr= iber assignments.
BNG/CMTS Vendor server may have it's on con= straints and limitations.


As a netw= ork operator, we can make sure we do as much as we can to keep PDs stable a= nd honour leases up to the lease-time advertised, but there will always be = the risk that sometimes we have to revoke the validity of a lease, either i= ntentionally or unintentionally.=C2=A0 And sadly in the worse case scenario= s, we may not be able to offer the same PD or NA as previously leased.
If we can offer some recommendations to CPE & DHCP client/relay/s= erver developers, as well as Operators, to help minimise this impact, I thi= nk it's worthwhile to do.
If we can slightly tweak protocols = to help minimise this impact, I understand that it may be a contentious ide= a, but would like to think it's also worthwhile looking in to?



=C2=A0
____________________________________________= ___
v6ops mailing list
v6ops@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/v6ops
--0000000000001466e7059717676b-- From nobody Mon Nov 11 12:05:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2068120105 for ; Mon, 11 Nov 2019 12:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WzeC7511QCS for ; Mon, 11 Nov 2019 12:05:20 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F7212081C for ; Mon, 11 Nov 2019 12:05:20 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id e187so12320514qkf.4 for ; Mon, 11 Nov 2019 12:05:20 -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=CV5t+fQV7noBGnt2kjDHdSaDBbGSyQ1l1ljPCsUAOhQ=; b=hHO+51f+l1cInBqNuA/yGzRH0FU81Z9lN5T4Kg9wfUHGuoZllAmj+/cpAcUOdBWurt HVTIZVX+kCmYUjmBspNn6hf9on736qqe47iqZ96zBBwWmqrCXoblNU4ZGj6crogHfMbH D/7VwuKQ1KKfecpREbD4XzVXyTKHe4T9+gclsXwHowwKEjNbz8LIapsCpYvfvlvai2gQ fjb3hh5kTXTZ9SOadix+lgSJ3v/cRk7sg3gM169rdZgTt03ONQXV2RirxKAcGKI/7CbF ht9H8TXwEvxppIGIXkKzOgGMRyCqVkJNl3HjioAcCdobjOpRrLwyGj0NYGVY6IER4Shg BWIA== 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=CV5t+fQV7noBGnt2kjDHdSaDBbGSyQ1l1ljPCsUAOhQ=; b=oT9fegBcnMAaLVGDsiMDsifLcftgeRShYAa0+cRXbO6sXArbBpLJFmmimX7DSGXtO0 55DtGtv0j2cCpdSJMoq+19hWtnSWkP7c/cir0cYB+7RXV1OaTNgasABVDkoJ0T9t5rRz DYyxVCNuCEsByGrta+EHAQpyq8mBsH1wiUli+iMhhXrSni57IOj5xCT2xWigG9s6vxFj pBgisHr+/tThD8rVddqs+oUZ7p1rCKNe1ciuGR9Hh+rrwPn+Cgl3HyQ81bx+3OQWYjd1 0QaRjN9My9Ey6obQm/L9c3fQpf7bSu7FoLyGebV3UPfiV7FE2+9q9zb6JfwbKYa9iOIT M8zg== X-Gm-Message-State: APjAAAWXWjNNvG/zF3BIUxIOmlgQ6v07+JQkJPqizc/dDbyYkfOXbBBX nYR7WM1DCcW6m7Cwz22HuOVPig== X-Google-Smtp-Source: APXvYqyhRTehGxk320tXCIxUV3wvrkXmcF/QJAA08jjH4K/p817z37P9mniatRI910QzTeFg535alQ== X-Received: by 2002:a37:4906:: with SMTP id w6mr2262895qka.82.1573502719122; Mon, 11 Nov 2019 12:05:19 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:1513:f8e0:6f18:51cb? ([2601:18b:300:36ee:1513:f8e0:6f18:51cb]) by smtp.gmail.com with ESMTPSA id c128sm1528592qkg.124.2019.11.11.12.05.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Nov 2019 12:05:18 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ABD43F9B-D7FE-4622-B082-501F77072CB0" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Mon, 11 Nov 2019 15:05:16 -0500 In-Reply-To: Cc: Richard Patterson , v6ops list To: Mark Smith References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 20:05:22 -0000 --Apple-Mail=_ABD43F9B-D7FE-4622-B082-501F77072CB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 11, 2019, at 2:47 PM, Mark Smith wrote: > Unplanned "flash" renumbering due to a topology change implies an = unplanned "flash" topology change. That's going to be a rare event, and = ideally shouldn't ever occur, because I think it is a sign that some = other planning hasn't been occurring. It=E2=80=99s not quite as simple as that. A topological bifurcation = (or any similar division) should be pretty easy to manage without flash = renumbering, because you can just renumber before you change the = topology. Assuming you have time. But anything more complicated is = going to require the propagation of network routes for each customer to = multiple places in the network. I think this is eminently doable, but = it=E2=80=99s not trivial, and I wouldn=E2=80=99t be surprised if it=E2=80=99= s not something an operator can easily do with their existing tooling. --Apple-Mail=_ABD43F9B-D7FE-4622-B082-501F77072CB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 11, 2019, at 2:47 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
Unplanned "flash" renumbering due to a topology change = implies an unplanned "flash" topology change. That's going to be a rare = event, and ideally shouldn't ever occur, because I think it is a sign = that some other planning hasn't been = occurring.

It=E2=80=99s = not quite as simple as that.   A topological bifurcation (or any = similar division) should be pretty easy to manage without flash = renumbering, because you can just renumber before you change the = topology.   Assuming you have time.  But anything more = complicated is going to require the propagation of network routes for = each customer to multiple places in the network.   I think this is = eminently doable, but it=E2=80=99s not trivial, and I wouldn=E2=80=99t = be surprised if it=E2=80=99s not something an operator can easily do = with their existing tooling.

= --Apple-Mail=_ABD43F9B-D7FE-4622-B082-501F77072CB0-- From nobody Mon Nov 11 13:06:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57556120823 for ; Mon, 11 Nov 2019 13:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 R_LAS2P3YyrV for ; Mon, 11 Nov 2019 13:06:07 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D47F120812 for ; Mon, 11 Nov 2019 13:06:07 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id c19so12397743otr.11 for ; Mon, 11 Nov 2019 13:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AGRoSf2rv31EcYVz3007MxVUIDpTvkxv9hgQqVh6nho=; b=ZF2A50jpAsEP15Nqi5koVP8br1p1HYwBdCODKxLKkkPpdoh5vTXPoMBjZ+DNB4/3uW MGwwwcJLEdtLwIjFvpcLZti3Fjeh2dTAk0jtq6mdSn4lQ38bwGlLYzn3W5o42Vzaaubt /aT+g9s2SRviCovtBhgMq8O7CY89ZSes0g6Oh4xygztuGUnEEdxDpxKfvOkgEKjUWi/s mht+IzMGFmZ72tyW7vPaXNRrmVCCZVYSphn6C8qzhcNbaEig6X+F3ehYgVe3sSVX6rrz EJviXJdLGxBF/avDTCc1oei4EcjCkNSWrx26R0V89liVe733YGpfeArcav6jsWCdkjWt bEjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AGRoSf2rv31EcYVz3007MxVUIDpTvkxv9hgQqVh6nho=; b=lAlOAFmo1I+PGA53RTcdgSau4LQPI10IZdnK/gCwkt9JISjik9fY7yhWJWaJiJ9PL4 slEf5ub3mmaN0RDyugCdruZ+xueDGgQTBC2acHVObFKPA5mZUB1YqXhhPoimSYltmIYw n3H2rbapkRJ3xMgHOWpRr8vvvPy8tfoUBq2l8xyRc+kUtIWsvBpZUpW750Meu7OfJjK5 Xy/lAxeYhAku22ImOVPfXzzA5vvzlVt8g09Gns6hZxyb7e58Y3sl+HO87FKPTNVdRMun gtPwli3Yphp4rmPu3R/H1GF9nAVsCa0sze1LpZ2LzuawR4KVbDC7KeRIMGTY5vPKuJYv AQtA== X-Gm-Message-State: APjAAAUHcHaPysWZLuMSYDoPjQjWeWxFPOxzkbFzq2oE2jjwCw+G/2Fe g7kiPlpX2FIRNrn/1UAhUEZ15Ob/kB3PYsbuzuenHg== X-Google-Smtp-Source: APXvYqyXgono+lf2nJN8zEW6dYK6tDPDh4QJaiN2hKUPfoUDf9ak3eSQGIf5fTOCwISrItaRxYDB51e56//PrKJ5HFE= X-Received: by 2002:a9d:7cc7:: with SMTP id r7mr10482825otn.94.1573506366699; Mon, 11 Nov 2019 13:06:06 -0800 (PST) MIME-Version: 1.0 References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> In-Reply-To: From: Mark Smith Date: Tue, 12 Nov 2019 08:05:56 +1100 Message-ID: To: Richard Patterson Cc: Ted Lemon , v6ops list Content-Type: multipart/alternative; boundary="00000000000009fc32059718804f" Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 21:06:09 -0000 --00000000000009fc32059718804f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 12 Nov 2019, 05:56 Richard Patterson, wrote: > On Mon, 11 Nov 2019 at 17:11, Ted Lemon wrote: > >> Nobody is expecting you to never renumber. Well, at least I am not. >> What I am talking about here is deliberate, opportunistic renumbering. I= f >> your topology changes and you have to renumber, so be it. If you can avo= id >> that it=E2=80=99s better, and if you can give notice it=E2=80=99s also b= etter. If you can >> do it gracefully with temporary routes, even better. But you shouldn=E2= =80=99t be >> renumbering just =E2=80=98cuz. >> > > In that case I think we agree, an operator shouldn't intentionally > renumber "just 'cuz". However the scenarios I mentioned are far from the > Operator going *out of their way* to not support stable prefixes. > "What you allow, you encourage." - Michael Josephson. If the IETF believe that stable prefixes are the correct solution, because that is the Internet architecture (transport layer connections are to tolerate transient connectivity faults through retransmission, and that relies on persistent host IP addresses across transient connectivity faults), then I don't think the IETF should try to purposefully accommodate unstable prefixes. Purposefully accommodating unstable prefixes will only encourage ISPs to use them. If an ISP chooses to provide a bad experience to their customers through unstable prefixes, then the pain and consequences of that decision should be entirely borne by the ISP, rather than them then expecting the IETF, CPE and host implementation vendors to then come up with and wear the development and deployment costs of imperfect work arounds. These ISPs are choosing to create a problem that doesn't need to exist. The question is just around how stable they are, > The answer is easy. What the ISP said it would be in the Valid Lifetime field. It's a broken promise if it isn't, and ISPs should only break promises when they have no other choice i.e. emergency network reconfiguration in a dire fault situation. If an ISP wants to provide short life addresses, they can specify a ValidLifetime as low as 2 hours, per RFC 4862, 5.5.3, (e). That would seem to me to be contradictory to the "always on" nature of the Internet service they're selling, however that's up to them as long as they wear the consequences of that decision. and once you start having to ask that question, then shouldn't we be > looking at ways to mitigate the impact to an end-user? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000009fc32059718804f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 12 Nov 2019, 05:56 Richard Patterson, <richard@helix.net.nz> wrote:
On Mon, 1= 1 Nov 2019 at 17:11, Ted Lemon <mellon@fugue.com> wrote:
Nobody is expecting you to never renumber. =C2=A0 We= ll, at least I am not. What I am talking about here is deliberate, opportun= istic renumbering. If your topology changes and you have to renumber, so be= it. If you can avoid that it=E2=80=99s better, and if you can give notice = it=E2=80=99s also better. If you can do it gracefully with temporary routes= , even better. But you shouldn=E2=80=99t be renumbering just =E2=80=98cuz.= =C2=A0

In that case I thi= nk we agree, an operator shouldn't intentionally renumber "just &#= 39;cuz".=C2=A0 However the scenarios I mentioned are far from the Oper= ator going out of their way to not support stable prefixes.

"What you allow, you encourage." - Michael Josephson.
<= div dir=3D"auto">
If the IETF believe that stabl= e prefixes are the correct solution, because that is the Internet architect= ure (transport layer connections are to tolerate transient connectivity fau= lts through retransmission, and that relies on persistent host IP addresses= across transient connectivity faults), then I don't think the IETF sho= uld try to purposefully accommodate unstable prefixes.

Purposefully accommodating unstable prefixes= will only encourage ISPs to use them.

If an ISP chooses to provide a bad experience to their custo= mers through unstable prefixes, then the pain and consequences of that deci= sion should be entirely borne by the ISP, rather than them then expecting t= he IETF, CPE and host implementation vendors to then come up with and wear = the development and deployment costs of imperfect work arounds.

These ISPs are choosing to create a= problem that doesn't need to exist.

<= div dir=3D"auto">
The question is just around=C2=A0how stable they are,
=

The = answer is easy.

What the= ISP said it would be in the Valid Lifetime field.
<= br>
It's a broken promise if it isn't, and I= SPs should only break promises when they have no other choice i.e. emergenc= y network reconfiguration in a dire fault situation.

If an ISP wants to provide short life addresse= s, they can specify a ValidLifetime as low as 2 hours, per RFC 4862, 5.5.3,= (e).

That would seem to= me to be contradictory to the "always on" nature of the Internet= service they're selling, however that's up to them as long as they= wear the consequences of that decision.

<= div dir=3D"auto">
and once you start having to ask that question, then shouldn't we be = looking at ways to mitigate the impact to an end-user?

=
_______________________________________________
v6ops mailing list
v6ops@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/v6ops
--00000000000009fc32059718804f-- From nobody Mon Nov 11 13:25:36 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE59120877 for ; Mon, 11 Nov 2019 13:25:35 -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_HELO_NONE=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 v15muTF2huDn for ; Mon, 11 Nov 2019 13:25:33 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D488F120142 for ; Mon, 11 Nov 2019 13:25:33 -0800 (PST) Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 2DC124E11A75; Mon, 11 Nov 2019 21:25:33 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id B6DE02298668; Mon, 11 Nov 2019 22:25:28 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: Date: Mon, 11 Nov 2019 22:25:28 +0100 Cc: Ted Lemon , "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> To: Richard Patterson X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 21:25:35 -0000 > On Mon, 11 Nov 2019 at 17:11, Ted Lemon wrote: > Nobody is expecting you to never renumber. Well, at least I am not. = What I am talking about here is deliberate, opportunistic renumbering. = If your topology changes and you have to renumber, so be it. If you can = avoid that it=E2=80=99s better, and if you can give notice it=E2=80=99s = also better. If you can do it gracefully with temporary routes, even = better. But you shouldn=E2=80=99t be renumbering just =E2=80=98cuz.=20 >=20 > In that case I think we agree, an operator shouldn't intentionally = renumber "just 'cuz". However the scenarios I mentioned are far from = the Operator going out of their way to not support stable prefixes. The = question is just around how stable they are, and once you start having = to ask that question, then shouldn't we be looking at ways to mitigate = the impact to an end-user? I agree with you, we should look at ways to mitigate the impact for the = end-user. Can we find a way that do that without relegating IPv6 end-users to be = clients and consumers only, like they are on the NATed IPv4 Internet? Would you join in effort to try to define how that would look like and = what the gaps are? The big question: "What would it take to make a network with ephemeral addressing work = (work as in not limit the user to only run "client only" applications)?" And sure, there might be lower hanging fruits, but let's not pick those = that can serve as encouragement that this addressing model works = correctly today. Best regards, Ole= From nobody Mon Nov 11 13:56:59 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FA2120893 for ; Mon, 11 Nov 2019 13:56:58 -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, SPF_HELO_NONE=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 TYRIMJKK_OCT for ; Mon, 11 Nov 2019 13:56:56 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B7F120089 for ; Mon, 11 Nov 2019 13:56:56 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9FFA23AB00A; Mon, 11 Nov 2019 21:56:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 772D116005C; Mon, 11 Nov 2019 21:56:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 47DC516007A; Mon, 11 Nov 2019 21:56:55 +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 mJmlJXsFX1Zh; Mon, 11 Nov 2019 21:56:55 +0000 (UTC) Received: from [172.30.42.69] (n1-40-244-161.bla1.nsw.optusnet.com.au [1.40.244.161]) by zmx1.isc.org (Postfix) with ESMTPSA id 3C4C616005C; Mon, 11 Nov 2019 21:56:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: Date: Tue, 12 Nov 2019 08:56:51 +1100 Cc: Richard Patterson , "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <6A290AB5-8CEB-44E6-9A89-5D10160E5B63@isc.org> References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> To: Ole Troan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 21:56:58 -0000 > On 12 Nov 2019, at 08:25, Ole Troan wrote: >=20 >> On Mon, 11 Nov 2019 at 17:11, Ted Lemon wrote: >> Nobody is expecting you to never renumber. Well, at least I am not. = What I am talking about here is deliberate, opportunistic renumbering. = If your topology changes and you have to renumber, so be it. If you can = avoid that it=E2=80=99s better, and if you can give notice it=E2=80=99s = also better. If you can do it gracefully with temporary routes, even = better. But you shouldn=E2=80=99t be renumbering just =E2=80=98cuz.=20 >>=20 >> In that case I think we agree, an operator shouldn't intentionally = renumber "just 'cuz". However the scenarios I mentioned are far from = the Operator going out of their way to not support stable prefixes. The = question is just around how stable they are, and once you start having = to ask that question, then shouldn't we be looking at ways to mitigate = the impact to an end-user? >=20 > I agree with you, we should look at ways to mitigate the impact for = the end-user. > Can we find a way that do that without relegating IPv6 end-users to be = clients and consumers only, like they are on the NATed IPv4 Internet? >=20 > Would you join in effort to try to define how that would look like and = what the gaps are? > The big question: > "What would it take to make a network with ephemeral addressing work = (work as in not limit the user to only run "client only" applications)?" >=20 > And sure, there might be lower hanging fruits, but let's not pick = those that can serve as encouragement that this addressing model works = correctly today. >=20 > Best regards, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops One low piece of hanging fruit is getting nodes to register themselves = in the DNS when their addresses change. This is easy to do with DNS UPDATE (RFC = 2136) and SIG(0) (RFC 2931). It just requires that a KEY record be added to the DNS for = the UPDATE request to be authenticated against when the node is commissioned. That = can be done with DNS UPDATE and TSIG (RFC 2845) or SIG(0). Similarly registering PTR records for themselves when they get new = addresses. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Nov 11 15:38:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871061200B6 for ; Mon, 11 Nov 2019 15:38:35 -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_HELO_NONE=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 xzVtrlswzChY for ; Mon, 11 Nov 2019 15:38:33 -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 2089F120090 for ; Mon, 11 Nov 2019 15:38:32 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 1C203864D7; Tue, 12 Nov 2019 00:38:28 +0100 (CET) To: Mark Smith , Ted Lemon Cc: v6ops list References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> Date: Mon, 11 Nov 2019 20:35:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 23:38:36 -0000 On 11/11/19 16:47, Mark Smith wrote: > > > On Tue, 12 Nov 2019, 04:11 Ted Lemon, > wrote: > > Nobody is expecting you to never renumber.   Well, at least I am not. > > > I'm not either. > > IPv6's Preferred and Valid lifetime mechanisms are for planned renumbering. > > > What I am talking about here is deliberate, opportunistic > renumbering. If your topology changes and you have to renumber, so > be it. > > > Unplanned "flash" renumbering due to a topology change implies an > unplanned "flash" topology change. That's going to be a rare event, and > ideally shouldn't ever occur, because I think it is a sign that some > other planning hasn't been occurring. > > > I don't really understand what is so hard about all this.  > > You either provide prefix stability using a client's DUID, or you can > use RADIUS. As noted elsewhere, we have an RFC for DUID radnomization ("dhcp anynimity profile", iirc). Besides, it's also understandable the possible expectation of a user to get a new prefix upon CPE reboot (due to privacy considerations). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Nov 11 16:13:23 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03221200E0 for ; Mon, 11 Nov 2019 16:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 LSP-SFiJWpMp for ; Mon, 11 Nov 2019 16:13:18 -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 4EB8F1200B6 for ; Mon, 11 Nov 2019 16:13:18 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 941B48606E; Tue, 12 Nov 2019 01:13:14 +0100 (CET) To: Ole Troan , Richard Patterson Cc: "v6ops@ietf.org list" References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <3d55e9ba-d761-1497-455a-8a75fc014319@si6networks.com> Date: Mon, 11 Nov 2019 21:13:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 00:13:21 -0000 On 11/11/19 18:25, Ole Troan wrote: >> On Mon, 11 Nov 2019 at 17:11, Ted Lemon wrote: >> Nobody is expecting you to never renumber. Well, at least I am not. What I am talking about here is deliberate, opportunistic renumbering. If your topology changes and you have to renumber, so be it. If you can avoid that it’s better, and if you can give notice it’s also better. If you can do it gracefully with temporary routes, even better. But you shouldn’t be renumbering just ‘cuz. >> >> In that case I think we agree, an operator shouldn't intentionally renumber "just 'cuz". However the scenarios I mentioned are far from the Operator going out of their way to not support stable prefixes. The question is just around how stable they are, and once you start having to ask that question, then shouldn't we be looking at ways to mitigate the impact to an end-user? > > I agree with you, we should look at ways to mitigate the impact for the end-user. > Can we find a way that do that without relegating IPv6 end-users to be clients and consumers only, like they are on the NATed IPv4 Internet? > > Would you join in effort to try to define how that would look like and what the gaps are? > The big question: > "What would it take to make a network with ephemeral addressing work (work as in not limit the user to only run "client only" applications)?" + IPv6 UPnP support for punching holes in the fw (a big fail for many CPEs) + Resilience to renumbering (slaac-renum) + Dynamic DNS updates In the IPv4 world, assuming no CGNAT, this works just fine: + there's IPv4 UPnP suport + renumbering is masqueraded by NATs + You do dynamic DNS updates with small TTLs P.S.: Since nobody guarantees there will be no fw and not renumbering, you have to accommodate for them, or plan to fail. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Nov 11 16:34:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289D21200B6 for ; Mon, 11 Nov 2019 16:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 xk2xFfyTnmW1 for ; Mon, 11 Nov 2019 16:34:16 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E3912003F for ; Mon, 11 Nov 2019 16:34:16 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id u13so12863101ote.0 for ; Mon, 11 Nov 2019 16:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=45qP3lJNlCsjNyx7CzRzZWDe/LIb1xI6nhHbVwlwSgo=; b=mFnqq55IKTQXI9Pd/HCzfxdvqUThNSTifbUzhpbyEwbBEuNSdg3xWLgURIrQeweg+3 Y1wYE8wEEKOLKX/JwkIZfIVQygQ1f8QW1wELpqBn8u3NG6EuYbGr3CLHlfsmXBKpAw7Q W2Zp/a7YI4BOA1L2+PDuZfOSJsZ1f0UY1WeHyeQr0xpaJIKyvHA6w1TrF6m6RiTmAKE0 5JGUrnyCjk+2BkiMoSNcL6CW1uLbkaOqmigxD8l35+RASS1NQ6XGNtf09J74JfIQweT5 PnIYetamPUzWfdoaNKYiEkhKqRYSmIjLImtqyWBxcIP7pOJ6QToh9qB+xV7gaPDN5yiO P3YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=45qP3lJNlCsjNyx7CzRzZWDe/LIb1xI6nhHbVwlwSgo=; b=aRWg92wvUIj4XY928WaCjyGAw+D7GRsgAqbjbmS4CLd50za5JGlN3prBynF7FqKdHH NdLN5fMPkAaKXsdJL09Wcf+JNv5q6BUFYBnX1a8R12k0E0D20u1/j1+dgSHsLFrFJwf4 3y1kDHVJf3p9KUXCewLprfK/kbBP0dtq54dx1KnobjaH+V5TL1mBmf7CLE3bPJyFseNW CV2wA8Ne8dO+Cgi7MSldQXmBiRgw9p779N1BtLa/cjdmabkb5Lji8uo8OBtX5x+4MoFO BiisDcMC3l3OTVZ58CbzYbBpU+Xw96sxdjxkfQ8Z5qu66xWl2ncs7tUoIIkzAjz/2Z1c 7yGg== X-Gm-Message-State: APjAAAVsKyaFB2lXeAVA4XKBTEY3XCcdycFibl9IXOldY/v3ZyDEU4cb O3ePaQJrDpgnSiXbu4DgqOZNmV1+Drsxfi7hf2o0XUhm X-Google-Smtp-Source: APXvYqwyBohPSWwUib6739QmsNt0JKwwlHtjTUBfeU5tKK6dSqlZzIfaiHoeguMG2H8TnZFBn6MDL2LHSBTTViHYWoc= X-Received: by 2002:a9d:611c:: with SMTP id i28mr21883890otj.348.1573518855284; Mon, 11 Nov 2019 16:34:15 -0800 (PST) MIME-Version: 1.0 References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> In-Reply-To: <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> From: Mark Smith Date: Tue, 12 Nov 2019 11:33:48 +1100 Message-ID: To: Fernando Gont Cc: Ted Lemon , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 00:34:18 -0000 On Tue, 12 Nov 2019 at 10:38, Fernando Gont wrote: > > > I don't really understand what is so hard about all this. > > > > You either provide prefix stability using a client's DUID, or you can > > use RADIUS. > > As noted elsewhere, we have an RFC for DUID radnomization ("dhcp > anynimity profile", iirc). Besides, it's also understandable the > possible expectation of a user to get a new prefix upon CPE reboot (due > to privacy considerations). > The trouble with this discussion is that it still hasn't defined the problem properly. Different people have different scenarios in mind, and then scenarios are sometimes changed to suit an argument. What are the specific design requirements? Is the fundamental goal a stable prefix or not? To suit commonly deployed transport layer protocols' requirements, address stability is needed so that connections can survive transient connectivity faults - which is what a CPE reboot is, or what a BRAS reboot is. On the other hand, the privacy argument says that an unstable prefix is optimal, with as unstable as possible the most optimal. Addresses used by transport layer protocols should only last as long as the transport layer protocol connection using the address and no longer - basically "Transient Addressing for Related Processes: Improved Firewalling by Using IPV6 and Multiple Addresses per Host" - https://www.cs.columbia.edu/~smb/papers/tarp/tarp.html Are we trying to address a fault situation, or an intentional, non-fault action to achieve some other goal (CPE reboot to acquire new prefix for privacy)? Is the "flash" renumber event a very rare event that an ISP does as a last resort during troubleshooting, despite them having infrastructure to support providing stable prefixes (i.e. RADIUS/DUID above)? Say occurring no more than once every 2 years, ideally no more than once every 5, and ideally never. Is the "flash" renumber event a reasonably rare event that coincides with an occasional BRAS/BNG reboot that causes customers to land on a different BRAS/BNG with a different PD pool, and the ISP hasn't gone to the effort of putting in stable prefix infrastructure? Say occurring no more than once every six months (that was my minimum up time expectation for a production BRAS/BNG). Is the "flash" renumber event a reasonably rare event triggered by a customer who wants a stable prefix for as long as they're comfortable with the privacy they have, and will actively trigger a prefix change when they consider they need to "reinitialise" their privacy with a different prefix? Say once every month or two. Is the "flash" renumber event a fairly common event because ISPs don't want to provide stable prefix infrastructure, because they've divided the their customers into two classes - "clients only" and a higher paying, typically SOHO/SME premium "full service" (client, and server/service if desired - i.e. peer) class. Say, once every week or two for "client only" residential customers. Until requirements are locked down, we can never know if you've achieved them or not, and the discussion goes in never ending circles - as it is. All of the above are impossible to achieve at once because there are unresolveable conflicts. For example, for an ISP that provides a stable prefix, how can they know that a CPE reboot is intentional to get a different prefix for privacy? It could also be because of a mains power failure, or a CPE reboot due to a bug. From nobody Mon Nov 11 16:50:43 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2534F1208BA for ; Mon, 11 Nov 2019 16:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNOa881JZlEL for ; Mon, 11 Nov 2019 16:50:35 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 329FB120143 for ; Mon, 11 Nov 2019 16:50:33 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xAC0mLMv017646 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 16:48:25 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xAC0mLMv017646 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1573519710; bh=7EjpPN5fWTkZCNWxK2tJkG+Z5EidmXarAqt3sdvcCj0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=rgTfw3MBTxbfTwbH62/yFLH6/FIX0s3cMzEE6lH78eOrNfB9g59OznpDm/APWtPXP Hkm8Do2oDm+XY1/HPyfr71jcpJjrxiu52Dt01KybTmA+BzFDHnuAZ46Ywl/SYq54kr vMRKhtsSvlo/Yvf2ZotT0a2064XrFvGNxDbPnkPg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <65cad6d5-72ce-028f-b768-e507c5874d68@si6networks.com> Date: Mon, 11 Nov 2019 16:48:21 -0800 Cc: Fred Baker , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <8BD93428-0C75-446E-9E01-699D63B8FE66@delong.com> References: <895EAAE8-E24D-429C-8C1D-552B3331BE11@gmail.com> <65cad6d5-72ce-028f-b768-e507c5874d68@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 11 Nov 2019 16:48:30 -0800 (PST) Archived-At: Subject: Re: [v6ops] V6ops status as of this morning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 00:50:41 -0000 Fred, I support working group adoption of both drafts. Fernando has done an excellent job of capturing the issues at hand and = several common sense and rational improvements that could help to = mitigate them. Further, the reception and comments on the drafts in the context of the = NANOG mailing list, while perhaps not =E2=80=9Cadmissible=E2=80=9D as WG = support should be viewed as input from the operational community to the = greatest extent possible under IETF policies and procedures. As you may well know, participation in the IETF by operators has long = been a difficult road. First, the IETF core and Operators often have = quite opposing points of view on what is needed for a network. Operators = often have little understanding of what is required to develop silicon = solutions, fast forwarding, an the software to support it. Conversely, = vendors and others in the IETF often have very limited perspective on = the day to day realities of operating an ISP or other significant = internet operation. Both sides would benefit from extensive effort to listen to each other = in a meaningful way as the combined expertise is required to produce = useful solutions. Unfortunately, operators that attempt participation in = IETF are often met with vitriolic comments such that only the thickest = of skins are able to remain long enough to make significant = contributions. Sadly, the same is true of what happens to engineers who poke their = heads into operational fora. We can all do better in this area. Owen > On Nov 11, 2019, at 03:19 , Fernando Gont = wrote: >=20 > Fred, >=20 > On 9/11/19 21:50, Fred Baker wrote: >> As I have said before, I am looking for supportive comment on the = mailing list of your drafts.=20 >=20 > we never asked that question. Some folks have gone ahead and expressed > support of the drafts. However, as authors we just asked for feedback = on > the document(s) -- and that's what most of the discussion has been = about. >=20 >=20 >=20 >> I saw that you sent a note to Nanog, and some replied copying the = v6ops list. >>=20 >> At the meeting a week or so hence, I have put you on the agenda to = discuss your drafts. If you don't plan to be in Singapore, that's your = choice; you can be on MeetEcho. But I *would* like for you to discuss = your drafts with the working group. As we usually do, I'll take a hum of = those there, and if there is support, I'll put out an email to the = larger list, and folks can express their support or lack thereof. >>=20 >> I asked you a specific question in the email you are replying to. = Would you consider answering it? >=20 > The email I replied to was your post of the status of several drafts > (hence the subject of this email). There was no question in the email, > nor in the attachment. >=20 > So... what's the question that you asked, and where did you ask it? >=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Nov 11 20:17:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A50D1200C4 for ; Mon, 11 Nov 2019 20:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ERiWjusDSIn for ; Mon, 11 Nov 2019 20:17:44 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id AB4A81200C3 for ; Mon, 11 Nov 2019 20:17:43 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xAC4GcGg029932 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 20:16:42 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xAC4GcGg029932 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1573532202; bh=2qc+f73aJrzSNft0Xyzy40hDLjh6xcH5SOIwdab+88U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=J+pzHwbfi5aJmRbM40OROALBydAMtSFq2CeSLv+r8mUcp5S2krCaxYlv3djJbFFIl QQQmwxwUnS7calZDzGStRGku5KZvweQ8Up0aae0D1uGeH0f4nwglDN4p0gaavFGs33 yR42y2K+o+T0F1Vubt6+F9j/SouXkMgSscaSCaTE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Mon, 11 Nov 2019 20:16:38 -0800 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> To: Philip Homburg X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 11 Nov 2019 20:16:42 -0800 (PST) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 04:17:47 -0000 > On Nov 11, 2019, at 00:52 , Philip Homburg = wrote: >=20 >> Why do you think that this "strategy" exists in IPv4 deployments? >=20 > One way to end up in this scenario is to have a pool of IPv4 addresses = in > the access router. A redundant access network makes it possible for=20 > customers to end up on different access routers. >=20 > So when the CPE reboots, the line goes down, and the customer gets = assigned > to the best access router. If that is a different one from before then > the customer experiences flash renumbering. Does anyone actually do IPv4 this way? I am not aware of anyone. To my = knowledge, the two most common IPv4 multihoming scenarios are: 1. Public addressing of hosts using an RIR-issued prefix or a = prefix from one provider routed to two providers via local BGP announcement. 2. An external address (pool) from each provider which is used for = source NAPT of outbound packets from internal hosts using RFC-1918 or = similar addressing. Neither of these scenarios has the issue described. In scenario 1, there = is no such thing as renumbering without notice. In scenario 2, renumbering affects only the outbound NAPT router(s). = Sessions may be dropped in a failure, but retries will receive different external = source addresses via NAPT and be routed via said alternate provider. >> Why is it relevant and preferable today for IPv6? >=20 > We want to make it easy for ISPs to turn on IPv6. If we first make = them=20 > redesign their networks then it will be more costly and take more = time, > so there will be less IPv6. >=20 >> Why is it best for IPv6 when people get something different in IPv6 = than in >> IPv4 - public address space to use on their LAN. >=20 > It doesn't have much to with wether addresses are public or not. > Flash renumbering happens with public IPv4 addresses. This hasn=E2=80=99t been my experience. However, if the prior poster = can=E2=80=99t understand the benefits of end-to-end addressing in IPv6 vs. the lack thereof in = the majority of IPv4 deployments, then it=E2=80=99s difficult to know where to start = in explaining it. Owen From nobody Mon Nov 11 20:19:30 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2F21200C3 for ; Mon, 11 Nov 2019 20:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vg-H35jbFBE for ; Mon, 11 Nov 2019 20:19:26 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDFD120115 for ; Mon, 11 Nov 2019 20:19:26 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xAC4IC7n030473 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 20:18:17 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xAC4IC7n030473 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1573532298; bh=amUYQYc6yxCKwxO3X8PNMhpoVXwTu3bcrnuDu3/aUuc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ef/MM5m14U+W1Tu3MjxZ1UVImigT6yq4Z72cKS4W7AA4cu3yS9njqx1fvZhliYUkY c3+Mx7JKHkpWhl0an9zKZ7xfmQguXHAplPNksZ3UZ+METgLVBFJiINm7+Lstdu/FEO bSw9EL6TIMJ+YOBPGykPXV1DhWZ6/nLlERuTnk7s= From: Owen DeLong Message-Id: <4705CFC1-BD69-4C2B-8AC0-BA3ADF2D0DE2@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FAFD616F-EEF0-4DE0-89BF-6FD36B87EDD2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 11 Nov 2019 20:18:12 -0800 In-Reply-To: Cc: Philip Homburg , v6ops@ietf.org To: Ted Lemon References: X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 11 Nov 2019 20:18:18 -0800 (PST) Archived-At: Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 04:19:28 -0000 --Apple-Mail=_FAFD616F-EEF0-4DE0-89BF-6FD36B87EDD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 11, 2019, at 03:01 , Ted Lemon wrote: >=20 > On Nov 11, 2019, at 3:47 AM, Philip Homburg = wrote: >>=20 >> =EF=BB=BFIn your letter dated Fri, 8 Nov 2019 16:30:31 +0100 you = wrote: >>> why would we have to delay deployment? >>=20 >> So the ISP delays rolling out IPv6 until either the problem is fixed = in >> IPv6 or, less likely, the ISP has a chance to re-engineer their setup = to >> avoid flash renumbering. >=20 > The ISP has to install a DHCPv6 server in order to do an IPv6 = deployment. We=E2=80=99ve already heard from one of the main vendors of = DHCPv6 servers that their server behaves correctly and does not do flash = renumbering. The two DHCPv6 servers that I have worked on don=E2=80=99t = either. So why is the ISP going to have to delay? The one time I was = asked to help an ISP to set up DHCPv6 in a way that would allow frequent = renumbering, it was a major engineering effort (which we wound up not = doing). The ISP would have to go out of their way to not support = stable prefixes. >=20 > So where is the impediment to deployment? We=E2=80=99ve also heard from at least one cable provider how flash = renumbering is inflicted on their customers due to splits/combines/moves = of blocks of customers from one CMTS to another. Owen --Apple-Mail=_FAFD616F-EEF0-4DE0-89BF-6FD36B87EDD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 11, 2019, at 03:01 , Ted Lemon <mellon@fugue.com> = wrote:

On Nov 11, 2019, at 3:47 AM, = Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:

=EF=BB=BFIn your letter dated = Fri, 8 Nov 2019 16:30:31 +0100 you wrote:
why would we have to delay = deployment?

So the ISP delays rolling out IPv6 until = either the problem is fixed in
IPv6 = or, less likely, the ISP has a chance to re-engineer their setup = to
avoid flash = renumbering.

The ISP has to install a DHCPv6 server in order to do an IPv6 = deployment.  We=E2=80=99ve already heard from one of the main = vendors of DHCPv6 servers that their server behaves correctly and does = not do flash renumbering.   The two DHCPv6 servers that I have = worked on don=E2=80=99t either.  So why is the ISP going to have to = delay?  The one time I was asked to help an ISP to set up DHCPv6 in = a way that would allow frequent renumbering, it was a major engineering = effort (which we wound up not doing).   The ISP would have to go out of their way to not support stable = prefixes.

So = where is the impediment to = deployment?

We=E2=80=99ve also heard from at least one cable = provider how flash renumbering is inflicted on their customers due to = splits/combines/moves of blocks of customers from one CMTS to = another.

Owen

= --Apple-Mail=_FAFD616F-EEF0-4DE0-89BF-6FD36B87EDD2-- From nobody Mon Nov 11 23:11:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0492120170 for ; Mon, 11 Nov 2019 23:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UfDeBFIT4Pe for ; Mon, 11 Nov 2019 23:11:47 -0800 (PST) Received: from zm-out-02.forthnet.gr (zm-out-02.forthnet.gr [194.219.0.14]) (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 D00B51200A4 for ; Mon, 11 Nov 2019 23:11:46 -0800 (PST) Received: from zm-in-02.cloud.forthnet.prv (zm-in-02.cloud.forthnet.prv [10.24.31.16]) by zm-out-02.forthnet.gr (Postfix) with ESMTP id B8743121BB6 for ; Tue, 12 Nov 2019 09:11:44 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTP id AC1B212188B; Tue, 12 Nov 2019 09:11:44 +0200 (EET) X-DSPAM-Result: Innocent Authentication-Results: zm-in-02.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-02.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-02.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id fPpIlbbNGuw0; Tue, 12 Nov 2019 09:11:43 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTP id B300012188F; Tue, 12 Nov 2019 09:11:43 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-02.cloud.forthnet.prv B300012188F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1573542703; bh=16Y6fSaogdwNH142fsdvP4OQ4ShmhhEZgOYWbx/AKXQ=; h=Subject:From:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=65sdUYTwLFH6wPZEseUgImL3T03OqIyvqE+QNQe9si7VDOwo82Pv/g9938qZK+4Gc 8S7NJX7+zZCNUtdd+sBveEOJe1pOPJSkY7iyd8EQ7uQaOPQoV3tcvB8+wq/EsTOhrg BjBd8MVBE0PFL6uWPZTr4mErMx2uOPqbkCAw4xN4= X-Virus-Scanned: amavisd-new at zm-in-02.cloud.forthnet.prv Received: from zm-in-02.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-02.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id k3mULUhFklGQ; Tue, 12 Nov 2019 09:11:43 +0200 (EET) Received: from [IPv6:2a02:2149:8769:2d00:f9d1:946c:c61:6b44] (unknown [IPv6:2a02:2149:8769:2d00:f9d1:946c:c61:6b44]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTPA id 875B612188C; Tue, 12 Nov 2019 09:11:43 +0200 (EET) Cc: v6ops list References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> From: Tassos Chatzithomaoglou Openpgp: preference=signencrypt Autocrypt: addr=achatz@forthnet.gr; keydata= mQENBFPWrY4BCADa9txOlMMGA1PvelU2qfkJ3cIoF+M9wXhSvZTI63FfgZAMWVM/NryJQ74q kiaWFyprgqo2BBk6vWkCw0N8pVwx0Z0sbPisB1fo/zB29cyM0HeB8lnu+Z5AvkfjwekMtGJd 3+tsRwOqdAJpCpJNhS0cVAkk1lIe3i8pdBbbKYJ5VNpBTyi0zL18WRvz9qf8nnP50rQOF8Oc LNCyKrT5S02SonWH5fQDTMVaSDVRvzRLU34pL0WEsIfTQciwg9LhjRpGj6mHxX1OdRHBpHmH WAI05lg7xRwYZq2/X/9Xizd0j9hbr6Ph7oiW7u6e4zAndvPSxXaBVCzpVI0hhaJl11yVABEB AAG0G1Rhc3NvcyA8Y2hhdGFzb3NAeWFob28uY29tPokBPwQTAQIAKQUCU9atjgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG9JgN4loaV7D0kIAKfyVLWFzOfYM0uT m78iJsh9nAaxYiM0t40oF+HY7Cri35FDAzrRjbB0os/KehCz6uuBqDe+3swkVX9bwE9/GsHc Tb5C1IOdvgb2Rp3MfSF1+Ju/3uGtiktQIqZ5YrIZhIjGiwUCVC6ewpC3VRiFVo/HvE23p16y 6Ws9y4xoRNuxs0952twZjT9jwVub8TWm/uES6RERZ68FGA1jVFXtAgMXljP29KcL8zRw9xiY VNI1MgUIRhOKENzpChS+7jZSDWKKD9fwPUNDNPG9kNuXoinRX1g2wlgWKmaBNVBOZMunR20P eVewZ2v35uaiHyzzHw92vjjfxOtpXoW0QFlT5cg= Message-ID: <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> Date: Tue, 12 Nov 2019 09:11:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 07:11:50 -0000 Mark Smith wrote on 12/11/19 02:33: > On Tue, 12 Nov 2019 at 10:38, Fernando Gont wrote: > > > >>> I don't really understand what is so hard about all this. >>> >>> You either provide prefix stability using a client's DUID, or you can >>> use RADIUS. >> As noted elsewhere, we have an RFC for DUID radnomization ("dhcp >> anynimity profile", iirc). Besides, it's also understandable the >> possible expectation of a user to get a new prefix upon CPE reboot (due >> to privacy considerations). >> > The trouble with this discussion is that it still hasn't defined the > problem properly. Different people have different scenarios in mind, > and then scenarios are sometimes changed to suit an argument. > > What are the specific design requirements? > > Is the fundamental goal a stable prefix or not? > > To suit commonly deployed transport layer protocols' requirements, > address stability is needed so that connections can survive transient > connectivity faults - which is what a CPE reboot is, or what a BRAS > reboot is. > > On the other hand, the privacy argument says that an unstable prefix > is optimal, with as unstable as possible the most optimal. Addresses > used by transport layer protocols should only last as long as the > transport layer protocol connection using the address and no longer - > basically "Transient Addressing for Related Processes: Improved > Firewalling by Using IPV6 and Multiple Addresses per Host" - > https://www.cs.columbia.edu/~smb/papers/tarp/tarp.html > > Are we trying to address a fault situation, or an intentional, > non-fault action to achieve some other goal (CPE reboot to acquire new > prefix for privacy)? > > Is the "flash" renumber event a very rare event that an ISP does as a > last resort during troubleshooting, despite them having infrastructure > to support providing stable prefixes (i.e. RADIUS/DUID above)? Say > occurring no more than once every 2 years, ideally no more than once > every 5, and ideally never. > > Is the "flash" renumber event a reasonably rare event that coincides > with an occasional BRAS/BNG reboot that causes customers to land on a > different BRAS/BNG with a different PD pool, and the ISP hasn't gone > to the effort of putting in stable prefix infrastructure? Say > occurring no more than once every six months (that was my minimum up > time expectation for a production BRAS/BNG). > > Is the "flash" renumber event a reasonably rare event triggered by a > customer who wants a stable prefix for as long as they're comfortable > with the privacy they have, and will actively trigger a prefix change > when they consider they need to "reinitialise" their privacy with a > different prefix? Say once every month or two. > > Is the "flash" renumber event a fairly common event because ISPs don't > want to provide stable prefix infrastructure, because they've divided > the their customers into two classes - "clients only" and a higher > paying, typically SOHO/SME premium "full service" (client, and > server/service if desired - i.e. peer) class. Say, once every week or > two for "client only" residential customers. > > Until requirements are locked down, we can never know if you've > achieved them or not, and the discussion goes in never ending circles > - as it is. > > All of the above are impossible to achieve at once because there are > unresolveable conflicts. > > For example, for an ISP that provides a stable prefix, how can they > know that a CPE reboot is intentional to get a different prefix for > privacy? It could also be because of a mains power failure, or a CPE > reboot due to a bug. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > The subscriber should have the choice to decide and the technology should give the means to support his/her choices. We're building a page inside our subscriber portal, where the subscriber chooses how frequently the LAN IPv6 assigned prefix should change. Default is to change at every PPP reconnect, but the subscriber can choose specific periods (x weeks/months) or action (once at next reconnect). SOHO/SME accounts do not have these options and have stable prefixes forever. Non-SOHO/SME accounts are not guaranteed to follow subscriber's choice due to network conditions. -- Tassos From nobody Tue Nov 12 01:42:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E88B12010F for ; Tue, 12 Nov 2019 01:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.068 X-Spam-Level: X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 WJ7kRJk8mb3z for ; Tue, 12 Nov 2019 01:42:17 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1739A120033 for ; Tue, 12 Nov 2019 01:42:16 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAC9gEHK009011 for ; Tue, 12 Nov 2019 10:42:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F192220352D for ; Tue, 12 Nov 2019 10:42:13 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DDF13203372 for ; Tue, 12 Nov 2019 10:42:13 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAC9gDPh009950 for ; Tue, 12 Nov 2019 10:42:13 +0100 From: Alexandre Petrescu To: "v6ops@ietf.org" References: Message-ID: Date: Tue, 12 Nov 2019 10:42:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] DANIR questions draft-shytyi-v6ops-danir-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 09:42:19 -0000 Hello participants to v6ops WG, With respect to draft-shytyi-v6ops-danir-04, of which I am a co-author, I would like to ask: - do you think it is useful that smartphones run DHCPv6-PD clients on their 4G interfaces? - do you think a router behaviour where it runs a Client DHCPv6-PD on one side, derive sub-prefixes and subsequently run SLAAC RA on the other side - has been described somewhere else than in this DANIR draft? Yours, Alex From nobody Tue Nov 12 03:10:03 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A65A12003E for ; Tue, 12 Nov 2019 03:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 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_HELO_NONE=0.001, 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 nKZhX9PPa8H7 for ; Tue, 12 Nov 2019 03:10:02 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::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 3891212025D for ; Tue, 12 Nov 2019 03:10:02 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id l20so14387019oie.10 for ; Tue, 12 Nov 2019 03:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r81VrBFj3U1Ks6sGiRIkq2tUDUFenEDcgEppE0LbReo=; b=hZischlLszfAqHv24tbMP4wpGMCQ5t1ne/MHvpbYcOTOsZkwkyXZqxm1JO0U9SLZSI 5xNgY3BjFDByr7bGs/pAgpLtlajll6nLz4JYBbc5Go4vOi2bFtXvu+WuhFf9JRisVQYy MhGFW4EN5J9NgJnw1i4Sd1+Y/T6OaLFZeG9VgWQNObbN3qCCxt4FSCSjaTF7ZJZbZwve RsK8xFaEMvrKdTGW7TbiLYpCs7WQU+oPYxFdYApXU5RMjbRu2/65h5DzzzizBRP1tKaT +Xxq6kkcTsylvX1K3yH7ylAf3oye93in+ZioATLJECDlYK+UTtiydzNN9W0dfoCtHVnO Hd+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r81VrBFj3U1Ks6sGiRIkq2tUDUFenEDcgEppE0LbReo=; b=T++5NJ8V48JyDUooMfzWdxqRtLy+P/O9JtxlDLq3/SYf/WVfUW2n0+WygipysN689i 0l/iZwx2miSGcqACR75/xUuGecvbKgU/KGR/sk5ZNDgv1bBxhsoKI6SpQVou6j16Hj07 7+Q8n29Dm/x8HKwpFWvqcK3KuMtf2xyWVeOdyhkNttBdjPmw8nZKkIUkpt1ZJAmgppSb AKRXXj3aayLyZtCSmhElysNbo98sBmxA8t3lxataS1eeN4tx+I5wmdd5I1rXmOFNlXZx 9S1WWQfx4PVuFqCjwfCtPzyflNRYzSQ4EUucVS0jNcQWm/V+fynsHsZlj3mEnz4IXKGR s4/Q== X-Gm-Message-State: APjAAAVrMK859JN/vED5x8qhHPm8hQXv2MHvzH4QBc0jKLMhRZa/5E06 i1mKWrHBia0i5yWm3LAg6+cQkYfZ3iC8Fn21Cso= X-Google-Smtp-Source: APXvYqxTERZITTg1ia825SJZ2mhQdhFJcEz3xP4aKCASKkQL65uxFNNg76uP/lXkSmAHy83Kh+WOk1MbpS8HTJOFvX0= X-Received: by 2002:aca:bb86:: with SMTP id l128mr1596061oif.164.1573557001334; Tue, 12 Nov 2019 03:10:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Tue, 12 Nov 2019 22:09:51 +1100 Message-ID: To: Alexandre Petrescu Cc: v6ops list Content-Type: multipart/alternative; boundary="0000000000001931fc0597244af9" Archived-At: Subject: Re: [v6ops] DANIR questions draft-shytyi-v6ops-danir-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 11:10:03 -0000 --0000000000001931fc0597244af9 Content-Type: text/plain; charset="UTF-8" On Tue, 12 Nov 2019, 20:42 Alexandre Petrescu, wrote: > Hello participants to v6ops WG, > > With respect to draft-shytyi-v6ops-danir-04, of which I am a co-author, > I would like to ask: > > - do you think it is useful that smartphones run DHCPv6-PD clients on > their 4G interfaces? > Broadly yes as that would be a conventional IPv6 router WAN behaviour. Trouble from that perspective with smartphones is how that fits with 3GPPs worldview. > - do you think a router behaviour where it runs a Client DHCPv6-PD on > one side, derive sub-prefixes and subsequently run SLAAC RA on the > other side - has been described somewhere else than in this DANIR > draft? > Yes, it is described in RFC 7084. I think a variation of DHCPv6 between the downstream and upstream interfaces would be better because a DHCPv6 relay is DHCPv6 option transparent. The combination of a client and a server limits the options that can be passed between the upstream and downstream interfaces. To support passing new options, they would have to be upgraded; a DHCPv6 relay wouldn't. IPv6 CE Device DHCPv6 Option Transparency https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 Regards, Mark. > Yours, > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000001931fc0597244af9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 12 Nov 2019, 20:42 Alexandre Petrescu, <alexandre.petrescu@gmail.com>= ; wrote:
Hello participants to v6op= s WG,

With respect to draft-shytyi-v6ops-danir-04, of which I am a co-author,
I would like to ask:

- do you think it is useful that smartphones run DHCPv6-PD clients on
=C2=A0 =C2=A0their 4G interfaces?

Broadly yes as that would be a conventiona= l IPv6 router WAN behaviour.

Trouble from that perspective with smartphones is how that fits with 3= GPPs worldview.


- do you think a router behaviour where it runs a Client DHCPv6-PD on
=C2=A0 =C2=A0one side, derive sub-prefixes and subsequently run SLAAC RA on= the
=C2=A0 =C2=A0other side - has been described somewhere else than in this DA= NIR
=C2=A0 =C2=A0draft?

Yes, it is described in RFC 7084.=C2=A0

I think a variation of DHCPv6 between th= e downstream and upstream interfaces would be better because a DHCPv6 relay= is DHCPv6 option transparent.

The combination of a client and a server limits the options that can= be passed between the upstream and downstream interfaces. To support passi= ng new options, they would have to be upgraded; a DHCPv6 relay wouldn't= .

IPv6 CE Device DHCPv6 Option Transparency
https://tools.ietf.org/html=
/draft-smith-v6ops-ce-dhcpv6-transparency-00

Regards,
=
Mark.


Yours,

Alex

_______________________________________________
v6ops mailing list
v6ops@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/v6ops
--0000000000001931fc0597244af9-- From nobody Tue Nov 12 03:13:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C7D12029C for ; Tue, 12 Nov 2019 03:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 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_HELO_NONE=0.001, 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 BC4ICD4h0ZCX for ; Tue, 12 Nov 2019 03:13:01 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169B812003E for ; Tue, 12 Nov 2019 03:13:01 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id 5so127090otk.1 for ; Tue, 12 Nov 2019 03:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J58qzlfkgw8W5iIBDVpK2yYTGdhshxEvwdwv3Optzqs=; b=nhx33mI35oUZ1YXASr+2FzMCJsOU3XEDifYGDnbmlW96Ltgiyu4PMMvUvTQNO/9vAp qCnqcONdE6JEVWasUt6WpvV4xGjUmfOYqm0CAoFrIfo0JQ/FiNsHaPjTOt0AEQ705ZcG dyD4e48rDjnVOyKxxJn+9y7MW8MywAcBqoq6vuUGQ7SzqUoRbL6/6r5Vwy8RsIe4oSeT t8qO6XFpnTWSx7L5z3X6x2/CgC2IUewh1mNDFp6MG4H3NaAIFz4PCSG83Mu+vUn0bj8U uq79qXTEbvMmcxf6Bf11le1QeAXk4J3eRvPLxOl5UaAIHUaE+/I35EGQDPrsGJT8kIA6 QNHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J58qzlfkgw8W5iIBDVpK2yYTGdhshxEvwdwv3Optzqs=; b=XuO26qpjuGA4WyitcmQNUyD9osXyarBZMIx9ERAN47hp/pfel98hLZ9AXodD+w2u8f z2/efUf5RVHe8MxQb39pYJjjkDCTczL6+bR3IUuxPcK2eui2nt0MnXTiEEvtq9TLj5Nx IvNxp/gfTTzlBUP072fuzpd7273GxMLdRrIME7eEtXtpdWOkantzU+wmQlim5e11XQFb vsRA8jmVo7orHE2qhLxAk6eK4fAINGM+Hlf1uggmc7MuFz8Ssle+AHzOxqOZJBXgqGA6 uRsQLxSiiF8JPPyfpamnB1GRe6k1NLKXtS6Mh10jWFxI3Yq60zEmPItE0wZeDrwIcpm1 tgkA== X-Gm-Message-State: APjAAAXhVl6BXivUi5HwNHPy0Kr+woOZbw2AAs1s2xVZZuo00tBNlfdo ck5IKUONwHfJExXBdZuNwEl6hzjtNwZxCNjy1O0= X-Google-Smtp-Source: APXvYqxAjLbNKGWO+EKFIRqOzNE7mexjsxAeo84EnnNaAY2YF/EKWzZbke4So3semGMaw0UhhulqdJJfj9sTgx/FBaE= X-Received: by 2002:a05:6830:c2:: with SMTP id x2mr2548587oto.257.1573557180426; Tue, 12 Nov 2019 03:13:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Tue, 12 Nov 2019 22:12:50 +1100 Message-ID: To: Alexandre Petrescu Cc: v6ops list Content-Type: multipart/alternative; boundary="000000000000c5ecfd05972454a4" Archived-At: Subject: Re: [v6ops] DANIR questions draft-shytyi-v6ops-danir-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 11:13:03 -0000 --000000000000c5ecfd05972454a4 Content-Type: text/plain; charset="UTF-8" Missed a few words, touchscreen keyboard! On Tue, 12 Nov 2019, 22:09 Mark Smith, wrote: > > > On Tue, 12 Nov 2019, 20:42 Alexandre Petrescu, < > alexandre.petrescu@gmail.com> wrote: > >> Hello participants to v6ops WG, >> >> With respect to draft-shytyi-v6ops-danir-04, of which I am a co-author, >> I would like to ask: >> >> - do you think it is useful that smartphones run DHCPv6-PD clients on >> their 4G interfaces? >> > > Broadly yes as that would be a conventional IPv6 router WAN behaviour. > > Trouble from that perspective with smartphones is how that fits with 3GPPs > worldview. > > >> - do you think a router behaviour where it runs a Client DHCPv6-PD on >> one side, derive sub-prefixes and subsequently run SLAAC RA on the >> other side - has been described somewhere else than in this DANIR >> draft? >> > > Yes, it is described in RFC 7084. > > I think a variation of DHCPv6 > a variation of a DHCPv6 relay between the downstream and upstream interfaces would be better because a > DHCPv6 relay is DHCPv6 option transparent. > > The combination of a client and a server limits the options that can be > passed between the upstream and downstream interfaces. To support passing > new options, they would have to be upgraded; a DHCPv6 relay wouldn't. > > IPv6 CE Device DHCPv6 Option Transparency > > https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 > > > Regards, > > Mark. > > > >> Yours, >> >> Alex >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > --000000000000c5ecfd05972454a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Missed a few words, touchscreen keyboard!

On Tue, 12 No= v 2019, 22:09 Mark Smith, <mar= kzzzsmith@gmail.com> wrote:
=


On Tue, 12 Nov 2019, 20:42 Alexandre Petrescu, <alexandre.petrescu@gmail= .com> wrote:
Hello participa= nts to v6ops WG,

With respect to draft-shytyi-v6ops-danir-04, of which I am a co-author,
I would like to ask:

- do you think it is useful that smartphones run DHCPv6-PD clients on
=C2=A0 =C2=A0their 4G interfaces?

Broadly yes as that would be a conventiona= l IPv6 router WAN behaviour.

Trouble from that perspective with smartphones is how that fits with 3= GPPs worldview.


- do you think a router behaviour where it runs a Client DHCPv6-PD on
=C2=A0 =C2=A0one side, derive sub-prefixes and subsequently run SLAAC RA on= the
=C2=A0 =C2=A0other side - has been described somewhere else than in this DA= NIR
=C2=A0 =C2=A0draft?

Yes, it is described in RFC 7084.=C2=A0

I think a variation of DHCPv6

a = variation of a DHCPv6 relay

between the downstream and upstream interfaces would= be better because a DHCPv6 relay is DHCPv6 option transparent.

The combination of a client and a s= erver limits the options that can be passed between the upstream and downst= ream interfaces. To support passing new options, they would have to be upgr= aded; a DHCPv6 relay wouldn't.

IPv6 CE Device DHCPv6 Option=
 Transparency
https://tools.ietf.org/html/draft-smith-v6o=
ps-ce-dhcpv6-transparency-00

=
Regards,
Mark.=


Yours,

Alex

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000c5ecfd05972454a4-- From nobody Tue Nov 12 06:31:58 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C9D1200B8 for ; Tue, 12 Nov 2019 06:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 hFXrmO7e9ZdN for ; Tue, 12 Nov 2019 06:31:54 -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 9D31C12002E for ; Tue, 12 Nov 2019 06:31:53 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 5C403869B1; Tue, 12 Nov 2019 15:31:49 +0100 (CET) To: Mark Smith Cc: v6ops list References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <6429ee28-d941-b6dc-3e61-e235cef6855a@si6networks.com> Date: Tue, 12 Nov 2019 11:28:31 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 14:31:57 -0000 On 11/11/19 21:33, Mark Smith wrote: > On Tue, 12 Nov 2019 at 10:38, Fernando Gont wrote: >> > > > > >>> I don't really understand what is so hard about all this. >>> >>> You either provide prefix stability using a client's DUID, or you can >>> use RADIUS. >> >> As noted elsewhere, we have an RFC for DUID radnomization ("dhcp >> anynimity profile", iirc). Besides, it's also understandable the >> possible expectation of a user to get a new prefix upon CPE reboot (due >> to privacy considerations). >> > > The trouble with this discussion is that it still hasn't defined the > problem properly. Different people have different scenarios in mind, > and then scenarios are sometimes changed to suit an argument. > > What are the specific design requirements? > > Is the fundamental goal a stable prefix or not? It can't be a fundamental goal. It is not stated anywhere, and that ship has sailed: over 30% of surveyed ISPs do dynamic prefixes. SO that ship has sailed. Besides, as noted by numerous folks on-list, even when it's not the goal, it can happen. And when it does happen, you should ba able to handle it gracefully. > To suit commonly deployed transport layer protocols' requirements, > address stability is needed so that connections can survive transient > connectivity faults - which is what a CPE reboot is, or what a BRAS > reboot is. Not really. IN a world where in the vast majority of cases a CPE does NAT (in IPv4) or a stateful firewall, when the firewall reboots, you loose state, and with it your ongoing connections. > On the other hand, the privacy argument says that an unstable prefix > is optimal, with as unstable as possible the most optimal. Addresses > used by transport layer protocols should only last as long as the > transport layer protocol connection using the address and no longer - > basically "Transient Addressing for Related Processes: Improved > Firewalling by Using IPV6 and Multiple Addresses per Host" - > https://www.cs.columbia.edu/~smb/papers/tarp/tarp.html > > Are we trying to address a fault situation, or an intentional, > non-fault action to achieve some other goal (CPE reboot to acquire new > prefix for privacy)? Mostly a fault situation that, at times, may arise due to an intentional action. (e.g. an ISP moving customers around, a user "fixing" their network by reseting the CPE, etc.) > Is the "flash" renumber event a very rare event that an ISP does as a > last resort during troubleshooting, despite them having infrastructure > to support providing stable prefixes (i.e. RADIUS/DUID above)? Say > occurring no more than once every 2 years, ideally no more than once > every 5, and ideally never. You can't know. BUt if you handle it gracefully, it doesn't matter. > Is the "flash" renumber event a reasonably rare event triggered by a > customer who wants a stable prefix for as long as they're comfortable > with the privacy they have, and will actively trigger a prefix change > when they consider they need to "reinitialise" their privacy with a > different prefix? Say once every month or two. May happen. And may also happen when a user just decides to "fix" his network by rebooting the CPE. [...] > Until requirements are locked down, we can never know if you've > achieved them or not, and the discussion goes in never ending circles > - as it is. I don't think we need to enumerate every possible reason for which this might happen. In fact, it would probably be impossible to do so. For example, when you implement resiliency to packet loss or duplication in TCP, you don't go around analyzing every possible reason for which that might happen. As long as you have concrete indications that the scenario is possible, you design mechanisms to mitigate the problems. > All of the above are impossible to achieve at once because there are > unresolveable conflicts. > > For example, for an ISP that provides a stable prefix, how can they > know that a CPE reboot is intentional to get a different prefix for > privacy? It could also be because of a mains power failure, or a CPE > reboot due to a bug. I think you're trying to boil the ocean. This work is on resiliency to flsh-renumbering. The scenario of an ISP trying to figure out whether they should deliver the same or different prefix (by inferring what the user wants) is a totally different problem. I reiterate a previous question, that remains unanswered: is there in cpe-slaac-renum that you think shouldn't be there anyway? 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 Nov 12 06:33:55 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B627B1200B8 for ; Tue, 12 Nov 2019 06:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 DAqi0_tJAkR4 for ; Tue, 12 Nov 2019 06:33:52 -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 65BD912002E for ; Tue, 12 Nov 2019 06:33:52 -0800 (PST) Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (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 0A7DE867E9; Tue, 12 Nov 2019 15:33:49 +0100 (CET) To: Tassos Chatzithomaoglou Cc: v6ops list References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> Date: Tue, 12 Nov 2019 11:33:15 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 14:33:54 -0000 On 12/11/19 04:11, Tassos Chatzithomaoglou wrote: > > Mark Smith wrote on 12/11/19 02:33: >> On Tue, 12 Nov 2019 at 10:38, Fernando Gont wrote: >> >> [....] >> > > The subscriber should have the choice to decide and the technology should give the means to support his/her choices. > We're building a page inside our subscriber portal, where the subscriber chooses how frequently the LAN IPv6 assigned prefix should change. > Default is to change at every PPP reconnect, but the subscriber can choose specific periods (x weeks/months) or action (once at next reconnect). So, upon a CPE crash and reboot, the subscriber would get a different prefix. Right? 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 Nov 12 13:20:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115401200EB for ; Tue, 12 Nov 2019 13:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=forthnet.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g-F73MVvhj8 for ; Tue, 12 Nov 2019 13:20:28 -0800 (PST) Received: from zm-out-01.forthnet.gr (zm-out-01.forthnet.gr [194.219.0.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1687B120019 for ; Tue, 12 Nov 2019 13:20:27 -0800 (PST) Received: from zm-in-01.cloud.forthnet.prv (zm-in-01.cloud.forthnet.prv [10.24.31.15]) by zm-out-01.forthnet.gr (Postfix) with ESMTP id 13DDB121C85; Tue, 12 Nov 2019 23:20:22 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id 053C7120831; Tue, 12 Nov 2019 23:20:22 +0200 (EET) X-DSPAM-Result: Spam Authentication-Results: zm-in-01.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id 84GAs5iWmEup; Tue, 12 Nov 2019 23:20:21 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id 2BFCD12082C; Tue, 12 Nov 2019 23:20:21 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-01.cloud.forthnet.prv 2BFCD12082C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1573593621; bh=fm7NhFY7AWETCmxP51uacZwsncCVDtrb3Z2pSwhiheU=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=hLaSqMVh9Hlk2R1r+vg3ljD2RdjqdLeBy6x2tFhdHv9VZURWx3+wyefDWvIOOwj2e GVWzmZh+oD9RCUULRpySvCpoOkKxoAlumO4/YeAEHvX9D1ctDW7oZuFQOHNijTCR2m F/pTUJWdT6RulTWAvACwKcD8SS0dqPv5PdHJl4hQ= X-Virus-Scanned: amavisd-new at zm-in-01.cloud.forthnet.prv Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id BeZMJbxvTZWP; Tue, 12 Nov 2019 23:20:21 +0200 (EET) Received: from [IPv6:2a02:2149:8769:2d00:602c:f317:7805:8d7e] (unknown [IPv6:2a02:2149:8769:2d00:602c:f317:7805:8d7e]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTPA id D9FD511FE73; Tue, 12 Nov 2019 23:20:20 +0200 (EET) To: Fernando Gont Cc: v6ops list References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> From: Tassos Chatzithomaoglou Openpgp: preference=signencrypt Autocrypt: addr=achatz@forthnet.gr; keydata= mQENBFPWrY4BCADa9txOlMMGA1PvelU2qfkJ3cIoF+M9wXhSvZTI63FfgZAMWVM/NryJQ74q kiaWFyprgqo2BBk6vWkCw0N8pVwx0Z0sbPisB1fo/zB29cyM0HeB8lnu+Z5AvkfjwekMtGJd 3+tsRwOqdAJpCpJNhS0cVAkk1lIe3i8pdBbbKYJ5VNpBTyi0zL18WRvz9qf8nnP50rQOF8Oc LNCyKrT5S02SonWH5fQDTMVaSDVRvzRLU34pL0WEsIfTQciwg9LhjRpGj6mHxX1OdRHBpHmH WAI05lg7xRwYZq2/X/9Xizd0j9hbr6Ph7oiW7u6e4zAndvPSxXaBVCzpVI0hhaJl11yVABEB AAG0G1Rhc3NvcyA8Y2hhdGFzb3NAeWFob28uY29tPokBPwQTAQIAKQUCU9atjgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG9JgN4loaV7D0kIAKfyVLWFzOfYM0uT m78iJsh9nAaxYiM0t40oF+HY7Cri35FDAzrRjbB0os/KehCz6uuBqDe+3swkVX9bwE9/GsHc Tb5C1IOdvgb2Rp3MfSF1+Ju/3uGtiktQIqZ5YrIZhIjGiwUCVC6ewpC3VRiFVo/HvE23p16y 6Ws9y4xoRNuxs0952twZjT9jwVub8TWm/uES6RERZ68FGA1jVFXtAgMXljP29KcL8zRw9xiY VNI1MgUIRhOKENzpChS+7jZSDWKKD9fwPUNDNPG9kNuXoinRX1g2wlgWKmaBNVBOZMunR20P eVewZ2v35uaiHyzzHw92vjjfxOtpXoW0QFlT5cg= Message-ID: Date: Tue, 12 Nov 2019 23:20:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5 MIME-Version: 1.0 In-Reply-To: <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 21:20:31 -0000 Fernando Gont wrote on 12/11/19 16:33: > On 12/11/19 04:11, Tassos Chatzithomaoglou wrote: > >> The subscriber should have the choice to decide and the technology should give the means to support his/her choices. >> We're building a page inside our subscriber portal, where the subscriber chooses how frequently the LAN IPv6 assigned prefix should change. >> Default is to change at every PPP reconnect, but the subscriber can choose specific periods (x weeks/months) or action (once at next reconnect). > So, upon a CPE crash and reboot, the subscriber would get a different > prefix. Right? > > Thanks! > > Cheers, Yes, the current default is for the subscriber to get a different prefix after a CPE crash and reboot (like in IPv4). But a CPE crash is not a common case. The most common case for prefix change is a DSL disconnect (due to line issues) or a PPP disconnect (due to network issues). Also, many of our CPEs store internally the prefix, so after a PPP reconnect they inform the LAN hosts about its release. -- Tassos From nobody Tue Nov 12 14:29:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61161200B9 for ; Tue, 12 Nov 2019 14:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 dnzaACrro_6F for ; Tue, 12 Nov 2019 14:29:18 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F62D120018 for ; Tue, 12 Nov 2019 14:29:18 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id 14so10404093oir.12 for ; Tue, 12 Nov 2019 14:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TijewTMMh40ZlbPDx075DZAeoG3EFJx6bZskP8OxhVc=; b=lwXPbMVg1d3ahw9EYwLVuJ+E9kFPhn5OPopae3bBoppjQke1+G7qpIWSgFvrxF0lQt eqiz7Uj8yLkXECb+C/wZ1tnkH5TvmlhsvqbPrTC/loH4RDQzofwiTqMio8Y1vm+Wy2n7 9nwDfrUx5JNeb60bjKP2IpikZKeukTl7lQTAfpovTh9+cuJPCCkh2emeA+xkU5k2E4Ml HgeNjx0G/6YeFiJZbVZAdMJgVklhg/gh47mNTqeh+evBP+G7EudV9M4W19iOPTsNSNBp ewEpWNcFpY8xkNwLL5Ny0q8tUKZdg2situ60ZjT2DIjt054dcBAwDRpkOMZKzxshZDXY VIqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TijewTMMh40ZlbPDx075DZAeoG3EFJx6bZskP8OxhVc=; b=L/6tnTt8yDdi5dz/QqxAlhbTJSq8GaP2Xbs9Z/FNMRmIKU03w9RWWCWF+ZaR25YfLT 6UwNEuA3yHmA57osYCAt8j++oRMzg9JSCkoiGEIToOQQlC9gVxprkv9URYedsogJm4b7 +WotcF8WQLmEw/quYd6IrtFj0emPBj2cKEsycbCRHnoLUqksG126PUCUT5C7ydHdjA6W 10ufeGykaqnvoEWp2yNJUokgK8WbVeWYbBpImPxoTzcLLSARw9d/S0OWyKA5wJudJkYh 8xyjYT5ofOhbHbBfd534dySoar478gGWWfdbPWfKPzWTWpLSGU0Z+ao7NzViPeHlenH/ R5IA== X-Gm-Message-State: APjAAAW5Q0IsSkP/LRbecvxkvg6Prwntg35/CWO9R5F++6XWVDOL5vRn e57sRVUiDRk9+JdlauDl9y03yMee649FNRphGFMrHH+i X-Google-Smtp-Source: APXvYqwLZJritdiSEPRUmiwhvHnltnxk+la1sPEa91mn4COebbUkr2jt3BkZmylBDX1EeGn9TR1BpBuYI9E9FqgW1Ps= X-Received: by 2002:aca:f553:: with SMTP id t80mr70813oih.60.1573597757402; Tue, 12 Nov 2019 14:29:17 -0800 (PST) MIME-Version: 1.0 References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> In-Reply-To: From: Mark Smith Date: Wed, 13 Nov 2019 09:28:49 +1100 Message-ID: To: Tassos Chatzithomaoglou Cc: Fernando Gont , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 22:29:20 -0000 On Wed, 13 Nov 2019 at 08:20, Tassos Chatzithomaoglou wrote: > > > Fernando Gont wrote on 12/11/19 16:33: > > On 12/11/19 04:11, Tassos Chatzithomaoglou wrote: > > > >> The subscriber should have the choice to decide and the technology should give the means to support his/her choices. > >> We're building a page inside our subscriber portal, where the subscriber chooses how frequently the LAN IPv6 assigned prefix should change. > >> Default is to change at every PPP reconnect, but the subscriber can choose specific periods (x weeks/months) or action (once at next reconnect). > > So, upon a CPE crash and reboot, the subscriber would get a different > > prefix. Right? > > > > Thanks! > > > > Cheers, > Yes, the current default is for the subscriber to get a different prefix after a CPE crash and reboot (like in IPv4). "like in IPv4" Why are you giving customers delegated IPv6 prefixes - that's not like IPv4? Other than "like in IPv4", why are you making the PD prefix change upon reconnect when you don't have to? What if your competitors provide stable prefixes, and their customers get a better service experience than your customers do, without having to wait possibly years for CPE and/or host upgrades per this ID's proposal? What is stopping them doing that? If they already have stable prefix supporting infrastructure, why wouldn't they switch it on when they can, when it could mean stealing customers from you and reducing their numbers of helpdesk calls? >But a CPE crash is not a common case. The most common case for prefix change is a DSL disconnect (due to line issues) or a PPP disconnect (due to network issues). > Also, many of our CPEs store internally the prefix, so after a PPP reconnect they inform the LAN hosts about its release. > > -- > Tassos > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Nov 12 16:19:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8C81201A3 for ; Tue, 12 Nov 2019 16:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=shytyi.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-ZvdTbGCXK5 for ; Tue, 12 Nov 2019 16:19:38 -0800 (PST) Received: from sender11-of-o52.zoho.eu (sender11-of-o52.zoho.eu [185.20.211.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400CF120044 for ; Tue, 12 Nov 2019 16:19:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573604374; cv=none; d=zohomail.eu; s=zohoarc; b=dM0owRLESy/KolsUtNy+8/zfmsHMcF4Cr7O/jwGXDuzEXCdXi3D3h2/a8YUPrhvS2HccxE80CHRHDFzlXNb7IZ1wVSHdDl9j1ZX7+zvF5eV13Wp9XxMUI7tBvoSR/L3jCCSMAUzaTT0CvhkyZWsIcF0hxebKfnyzo/J1jxjQfZE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1573604374; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=kecQyTlYZn+miXH0f2i3aJcFrAZLqfOmGqLa0hECug4=; b=FOv7/PvWqg7vE1XErCw2oghLCFejIwEE6dKrKSnYYZF62+BiFd6y/sPeCi7LZrMJgzY7Jviz+2m1UbgX+damSH2ZwI1AANjQZA26p3teKHeqoaLcPLYJEL+zOUmJxVDKqU67/TlUe1IOR6J5LWr7jbWbAwxVWMw7VdHBbxM0aFg= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=shytyi.net; spf=pass smtp.mailfrom=ietf.dmytro@shytyi.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1573604374; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=19343; bh=kecQyTlYZn+miXH0f2i3aJcFrAZLqfOmGqLa0hECug4=; b=exB77/gak9lS4ZPVaAWsPN9qewwQWKuKy3ZO9oDiR+fFZlwLlDI6BwkxsC5OoT9s 7sEkd/mqhU4ufz+jEx5A6z6t9HzxUL/740Ck0uMKo+OjxsA5Fl5CsRdG6Z9dqVCgodk 640AEafpdcVtk27N8INAL7rrvJhnRPgYN5Np9hko= Received: from sender.zoho.eu (172.26.23.79 [172.26.23.79]) by mx.zohomail.com with SMTPS id 1573604374323704.227312679889; Wed, 13 Nov 2019 01:19:34 +0100 (CET) Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1573604374244543.5415894457697; Wed, 13 Nov 2019 01:19:34 +0100 (CET) Date: Wed, 13 Nov 2019 01:19:34 +0100 From: Dmytro Shytyi To: "Mark Smith" Cc: "Alexandre Petrescu" , "v6ops list" Message-Id: <16e622136e0.1124af1ab166077.189641254825395816@shytyi.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_470161_1626207155.1573604374241" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMailClient: External Archived-At: Subject: Re: [v6ops] DANIR questions draft-shytyi-v6ops-danir-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 00:19:41 -0000 ------=_Part_470161_1626207155.1573604374241 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mark, Please find my comments inline. ______________ Dmytro SHYTYI ---- On Tue, 12 Nov 2019 12:12:50 +0100 Mark Smith = wrote ---- Missed a few words, touchscreen keyboard! On Tue, 12 Nov 2019, 22:09 Mark Smith, wrot= e: On Tue, 12 Nov 2019, 20:42 Alexandre Petrescu, wrote: Hello participants to v6ops WG, =20 With respect to draft-shytyi-v6ops-danir-04, of which I am a co-author, I would like to ask: =20 - do you think it is useful that smartphones run DHCPv6-PD clients on =C2=A0 =C2=A0their 4G interfaces? Broadly yes as that would be a conventional IPv6 router WAN behaviour. Great. Thank you for this comment! Trouble from that perspective with smartphones is how that fits with 3GPPs = worldview. - do you think a router behaviour where it runs a Client DHCPv6-PD on =C2=A0 =C2=A0one side, derive sub-prefixes and subsequently run SLAAC RA o= n the =C2=A0 =C2=A0other side - has been described somewhere else than in this D= ANIR =C2=A0 =C2=A0draft? Yes, it is described in RFC 7084.=C2=A0 In the RFC 7084 the behaviour of IPv6 Customer Edge Router in home or small= -office use is described.=20 Citation: "ipv6 CE router - is=C2=A0 node intended for home or small-office use that forwards IPv6 packets not explicitly addressed to itself. " In the Danir draft we consider IoT Router. Where the IoT devices can be used to enable: -=C2=A0numerous IoT applications in farming. (Comment: is home or small-ofi= ce use?) -=C2=A0remote health monitoring=C2=A0and=C2=A0emergency notification system= s. (Comment:=C2=A0If we consider the human-wearable elements can we say tha= t it is home/small-office use?) -=C2=A0the integration of communications, control, and information processi= ng across various=C2=A0transportation systems.=C2=A0(Comment:=C2=A0Transpor= tation system is a home or a small-office?) - the procedure to=C2=A0=C2=A0acquire and analyze data from connected equip= ment, operational technology, locations and people.=C2=A0It helps to regula= te industrial systems. (Comment:=C2=A0is it home/small-office use?) .... Does the the RFC 7084=C2=A0 address the different environments above such a= s=C2=A0 DANIR daft addresses (DHCPv6_PD and NDP Implementation in IoT Route= r)? I think a variation of DHCPv6 a variation of a DHCPv6 relay=C2=A0between the downstream and upstream inte= rfaces would be better because a DHCPv6 relay is DHCPv6 option transparent. As far as we mention the DHCP relay we have to consider DHCP clients... So how we address the next information? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Here is a feature request on Android fo= r dhcpv6 client since Jun 3 2012... https://issuetracker.google.com/issues/36949085 Seems that this feature request was taken into account so far.... between the downstream and upstream interfaces would be better because a DH= CPv6 relay is DHCPv6 option transparent. The combination of a client and a server limits the options that can be pas= sed between the upstream and downstream interfaces. To support passing new = options, they would have to be upgraded; a DHCPv6 relay wouldn't. IPv6 CE Device DHCPv6 Option Transparency https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 Regards, Mark. Yours, =20 Alex =20 _______________________________________________ v6ops mailing list mailto:v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list=20 mailto:v6ops@ietf.org=20 https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_470161_1626207155.1573604374241 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hello Mark,

Please fi= nd my comments inline.
______________
Dmytro SHYTYI
<= br>

---- On Tue, 12 Nov 2019 12:12= :50 +0100 Mark Smith <markzzzsmith@gmail.com> wrote ----




=
In the RFC 7084 the behaviour of IPv6 Customer Edge Router in home or = small-office use is described.
Citation: "ipv6 CE router - i= s  node intended for home or small-office use that forwards IPv6 packets not explicitly addressed to itself. "

In the Danir draft we consider IoT Router.
<= br>
Where the IoT devices can be used to enable:<= /span>
- numerous IoT applications in= farming. (Comment: is home or small-ofice use?)
<= div>- remote health monitoring and&nb= sp;emergency notification systems. (Comment: <= /span>If we consider the human-wearable = elements can we say that it is home/small-office use?)=
- the integration of communications= , control, and information processing across various transportation sy= stems. (Comment: Transportation system is a home or a small-office?= )
- the procedure t= o  acquire and analyze data from connected equipment, operation= al technology, locations and people. It helps to regulate indust= rial systems. <= span class=3D"font" style=3D"font-family:sans-serif">(Comment: <= /span>is it home/small-office use?)
....

Does the the RFC 7084  address the diff= erent environments above such as  DANIR daft addresses (DHCPv6_PD and NDP Implementation in IoT Router= )?
I think a va= riation of DHCPv6

a variation of a DHCPv6 relay between the= downstream and upstream interfaces would be better because a DHCPv6 relay = is DHCPv6 option transparent.
=
As far as we mention the DHCP relay we have to consider DHCP cl= ients...

So how we address the next informatio= n?
      Here is a feature requ= est on Android for dhcpv6 client since Jun 3 2012...
Seems that this feature request was taken into accoun= t so far....



between the downstream and= upstream interfaces would be better because a DHCPv6 relay is DHCPv6 optio= n transparent.

The c= ombination of a client and a server limits the options that can be passed b= etween the upstream and downstream interfaces. To support passing new optio= ns, they would have to be upgraded; a DHCPv6 relay wouldn't.

IPv6 CE Device DHCPv6 Option Transparency
https://tools.ietf.org/h=
tml/draft-smith-v6ops-ce-dhcpv6-transparency-00

Regards,
Mark.


Yours,

Alex
_______________________________________________
v6ops mailing li= st
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
__________________________= _____________________
v6ops mailing list


------=_Part_470161_1626207155.1573604374241-- From nobody Tue Nov 12 17:05:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B897120058 for ; Tue, 12 Nov 2019 17:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 8lo_8T4avXYT for ; Tue, 12 Nov 2019 17:05:10 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A449120019 for ; Tue, 12 Nov 2019 17:05:10 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id f10so156141oto.3 for ; Tue, 12 Nov 2019 17:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QOfczgALlTpCKZDySxe9VimrddT25tM142LJV75cBy8=; b=KenB153a+EzjUuuh0E2zBLezhWQWRnqmYdMFn5wRJ1Qe75LBH9AoxU3UK4M0dQFyn5 MHaq1+1EldcD6HzmjHe+Q3z6p1lQmP0I/4WUJ9wg2pV64UXAzmuzW3rTbl5cpXoXGDUu hck9IRfdsqaCwXfcsMFMmE8/FnVYxlMVgZJpCUkoZKIDlvDwZA27z0+Mdhw7hQTDbDrx 8bpG4ZlSebHbM9HgpGuFRw/5EUYPXcis/A7aV19sLldgaKN6xr9UEJEks5qLXat7Mp3c Pt/wyTYpRWw9yvj8rrqgn+GJGiG/9YKGv5qhsOn9CklgeQb1RAwA/cEuBYGVwgpNUfGO zPPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QOfczgALlTpCKZDySxe9VimrddT25tM142LJV75cBy8=; b=VzmmAm7vu5oMJ6+ZQMjCigcDCyS6CFfitkJq1VSExAJCbSFnwmK6b1eE+LD2NlnQ0i ILiiPnafAPGRcbaMzvFdgkxVlB6QleoI/568rlvZMxKloOc8AhnM6juga2qdK4L39eE2 IIkqztfGHTmMlzGukzRZFnUMdC17KjiyUnP7F63BHbNcB6p/rGEpagCH+iCdcSlZ8l3O k2Pli2MI0X5WRMU/9yKpDLiAF4Rd5qRzZu2stEV6dtZ2q2YEBM0z+GUwVtDvWeeDuXXq bwaYASI09c00d6VfMDnvNMGFA6UNawUtRbgqGwqfDJOvSVsmDr3iSUFMunvasxbbpSFM 0AiQ== X-Gm-Message-State: APjAAAXmXO/ydii94ujfj15hGmp7fZPaIyfNhnq5daXGnp571X726Q9k MkE7AeF9vCmXy+SqvZPSmwyFWlqjvPlKrfxD4ES0jQ== X-Google-Smtp-Source: APXvYqxj5l2EoZwzmB+9qLApvJ63L7lPb79pOAy0j6flp+Dhi9JOEDReDuZWMic7TCIPdMRticVe7Pi8XQybLMKWIAs= X-Received: by 2002:a9d:5a9b:: with SMTP id w27mr395046oth.153.1573607109802; Tue, 12 Nov 2019 17:05:09 -0800 (PST) MIME-Version: 1.0 References: <16e622136e0.1124af1ab166077.189641254825395816@shytyi.net> In-Reply-To: <16e622136e0.1124af1ab166077.189641254825395816@shytyi.net> From: Mark Smith Date: Wed, 13 Nov 2019 12:04:43 +1100 Message-ID: To: Dmytro Shytyi Cc: Alexandre Petrescu , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] DANIR questions draft-shytyi-v6ops-danir-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 01:05:13 -0000 On Wed, 13 Nov 2019 at 11:19, Dmytro Shytyi wrote: > > Hello Mark, > > Please find my comments inline. > ______________ > Dmytro SHYTYI > > > ---- On Tue, 12 Nov 2019 12:12:50 +0100 Mark Smith wrote ---- > > Missed a few words, touchscreen keyboard! > > On Tue, 12 Nov 2019, 22:09 Mark Smith, wrote: > > > > On Tue, 12 Nov 2019, 20:42 Alexandre Petrescu, wrote: > > Hello participants to v6ops WG, > > With respect to draft-shytyi-v6ops-danir-04, of which I am a co-author, > I would like to ask: > > - do you think it is useful that smartphones run DHCPv6-PD clients on > their 4G interfaces? > > > Broadly yes as that would be a conventional IPv6 router WAN behaviour. > > > Great. Thank you for this comment! > > Trouble from that perspective with smartphones is how that fits with 3GPPs worldview. > > > - do you think a router behaviour where it runs a Client DHCPv6-PD on > one side, derive sub-prefixes and subsequently run SLAAC RA on the > other side - has been described somewhere else than in this DANIR > draft? > > > Yes, it is described in RFC 7084. > > > In the RFC 7084 the behaviour of IPv6 Customer Edge Router in home or small-office use is described. > Citation: "ipv6 CE router - is node intended for home or small-office use that forwards IPv6 packets not explicitly addressed to itself. " > > In the Danir draft we consider IoT Router. > > Where the IoT devices can be used to enable: > - numerous IoT applications in farming. (Comment: is home or small-ofice use?) > - remote health monitoring and emergency notification systems. (Comment: If we consider the human-wearable elements can we say that it is home/small-office use?) > - the integration of communications, control, and information processing across various transportation systems. (Comment: Transportation system is a home or a small-office?) > - the procedure to acquire and analyze data from connected equipment, operational technology, locations and people. It helps to regulate industrial systems. (Comment: is it home/small-office use?) > .... > > Does the the RFC 7084 address the different environments above such as DANIR daft addresses (DHCPv6_PD and NDP Implementation in IoT Router)? > Is this device an IPv6 router or not, per RFC 8200's IPv6 router definition? What makes an "IoT" device special in this context? An "IoT" device today is going to be more powerful and have more memory that a general purpose IPv6 router of 20 years ago (e.g. Cisco 2500). > I think a variation of DHCPv6 > > > a variation of a DHCPv6 relay between the downstream and upstream interfaces would be better because a DHCPv6 relay is DHCPv6 option transparent. > > > > As far as we mention the DHCP relay we have to consider DHCP clients... > > So how we address the next information? > Here is a feature request on Android for dhcpv6 client since Jun 3 2012... > https://issuetracker.google.com/issues/36949085 > Seems that this feature request was taken into account so far.... > > Is Android an "IoT" OS? If you're all about IoT, then I wouldn't think Android's IPv6 capabilities are relevant. I don't entirely agree with Google's position however I don't entirely disagree with it either. I don't think there is a need for stateful DHCPv6 for addressing (and it doesn't solve an IPv6 address in use for security purpose some people think it does), and if a device doesn't need anything more than DNS settings, then there's no need for a DHCPv6 client at all. (The use cases I think about regarding using a stateless DHCPv6 client are supplying NTP time sources, time zone information to a device and possibly geographical location. Android acquires that information via other methods). > > between the downstream and upstream interfaces would be better because a DHCPv6 relay is DHCPv6 option transparent. > > The combination of a client and a server limits the options that can be passed between the upstream and downstream interfaces. To support passing new options, they would have to be upgraded; a DHCPv6 relay wouldn't. > > IPv6 CE Device DHCPv6 Option Transparency > > https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 > > > Regards, > > Mark. > > > > Yours, > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Tue Nov 12 21:08:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1411200E0 for ; Tue, 12 Nov 2019 21:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW-Umn8fX6VO for ; Tue, 12 Nov 2019 21:08:16 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36ED1200C4 for ; Tue, 12 Nov 2019 21:08:16 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id q17so578160pgt.9 for ; Tue, 12 Nov 2019 21:08:16 -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=zRLlqpILc4MJ7IZb0GnvTVvBxLfcqDO9FE1BaSsl9Z4=; b=uLviiKuY5JRuUOyyslZEEdnAUJUqzANmrONzKSve2j3306Tdipc2DBW5XnqsOEDHAk iHWRiuX2NldGeePgv1jrrDH85SP7tkuYwR0f+xmqWqk8zqgEf0TI7nbfZRDix99mi04y AQJ4MuP2DfDO2uP2HaxC0GCRik26TjMhPS/i4sXiha/W6tdXtFsAYcCgtqoBkmDkXNUU 29w92icbbXUtECqlwxmpCTTLy0X3HPZtRJDV7tbh8DAR2scYRkOdduKUBmXbMy/qUA1T c/rYP1e0OR3MIxAY4c8s8fI8vqTj6C/Z9e8Xek05x4Enk+UxgMaQ22nJ3jXICUqjim52 jiZw== 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=zRLlqpILc4MJ7IZb0GnvTVvBxLfcqDO9FE1BaSsl9Z4=; b=E83M4py9d3Ba4Ptkefrff08qYwaVXMQH0MEQbyoDWUrwvrQ7XweUVlbOulxbi6CyO7 bB5BRYFGEisBrCcmNO5+PEuGnTLcnz5/FGtPMJCXKxoxsT++2kk3diMzF35lfihZbWjX r+YsPpNtOCnidsHmy2EjEbUBMdO3M0ID0QQxxVIGfMq8E16iiFbdSEuOK3V4YIDwy/Yj G3PgOgqyRa0X2Hrit5ZKYNtIq6lKt3lzjUoGkszgT7UEzy6QlDZp2qaGxfTc5lGe68V5 i9CRunnoifHBNp1Qyfq03yf4e0y0Ln5wXYi+GluMudFvkVuqtO2k2TQ8IXfKqdL4GZLd yH4A== X-Gm-Message-State: APjAAAV5IfNiwTuOzQC7StDo7C3qmmJC8+Y6+jFaWllRnM9qg5NvFiPn mqV20rNznAnBvqNhNnJUe0plv6cleuc= X-Google-Smtp-Source: APXvYqyer0T41KLv31PKbp1yM0pvCxwV+oOR+Si6w9toV0GvswbMtbbpHSP7WkklT6XVRfDQaay6GA== X-Received: by 2002:a63:7015:: with SMTP id l21mr1432587pgc.200.1573621695911; Tue, 12 Nov 2019 21:08:15 -0800 (PST) Received: from 237.66.20.149.in-addr.arpa (237.66.20.149.in-addr.arpa. [149.20.66.237]) by smtp.gmail.com with ESMTPSA id s24sm768144pfm.144.2019.11.12.21.08.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Nov 2019 21:08:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.2\)) From: Fred Baker In-Reply-To: <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> Date: Wed, 13 Nov 2019 10:38:11 +0530 Cc: Tassos Chatzithomaoglou , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <33554C26-5007-483C-8C5E-6CC6DEB7724F@gmail.com> References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.2) Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 05:08:18 -0000 > On Nov 12, 2019, at 8:03 PM, Fernando Gont = wrote: >=20 > So, upon a CPE crash and reboot, the subscriber would get a different > prefix. Right? Change "would" to "could", and you're probably close. In general, I = would expect ISPs to not want to randomly change their routing, and so = it would not be deterministic - if the customer is no longer using a = prefix (e.g., the CPE crashed and routing has changed anyway), when the = CPE comes back up they might give it a different prefix. However, I'd be = surprised if they did it "just because".= From nobody Tue Nov 12 23:33:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91700120874 for ; Tue, 12 Nov 2019 23:33:03 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=forthnet.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kbi1lzYBUc2 for ; Tue, 12 Nov 2019 23:33:00 -0800 (PST) Received: from zm-out-01.forthnet.gr (zm-out-01.forthnet.gr [194.219.0.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0244212022D for ; Tue, 12 Nov 2019 23:32:59 -0800 (PST) Received: from zm-in-01.cloud.forthnet.prv (zm-in-01.cloud.forthnet.prv [10.24.31.15]) by zm-out-01.forthnet.gr (Postfix) with ESMTP id 6A4A1121C85 for ; Wed, 13 Nov 2019 09:32:57 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id 658B812083C; Wed, 13 Nov 2019 09:32:57 +0200 (EET) X-DSPAM-Result: Innocent Authentication-Results: zm-in-01.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id uqmEOZNhevrV; Wed, 13 Nov 2019 09:32:54 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTP id 63AE8120888; Wed, 13 Nov 2019 09:32:54 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-01.cloud.forthnet.prv 63AE8120888 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1573630374; bh=mIHCDJmV9CU8NR5pXV2k/tQ/lEelvZjSoWrKi/IpMlA=; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=W6Jiv8PaphnHu83wxHOINxTFcVHzJINc+u3HOlIeKiuqtgPt/cfIXjQ9d7U3aQw6I eWlR5GBK+bjUwv/zhz0sf0Bvqr+5pxuL/+fwfH3wXxSjD/YdHg0utsyyOLz9nlPkbZ B8f47MSOGIzVjfnLEVxJZmLoXlwUB9N6iDJBD5+c= X-Virus-Scanned: amavisd-new at zm-in-01.cloud.forthnet.prv Received: from zm-in-01.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-01.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id ZLmYfXGZLwUz; Wed, 13 Nov 2019 09:32:54 +0200 (EET) Received: from [IPv6:2a02:2149:8769:2d00:e063:ae13:1d9c:d56e] (unknown [IPv6:2a02:2149:8769:2d00:e063:ae13:1d9c:d56e]) by zm-in-01.cloud.forthnet.prv (Postfix) with ESMTPA id 36C73120886; Wed, 13 Nov 2019 09:32:54 +0200 (EET) References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> From: Tassos Chatzithomaoglou Openpgp: preference=signencrypt Autocrypt: addr=achatz@forthnet.gr; keydata= mQENBFPWrY4BCADa9txOlMMGA1PvelU2qfkJ3cIoF+M9wXhSvZTI63FfgZAMWVM/NryJQ74q kiaWFyprgqo2BBk6vWkCw0N8pVwx0Z0sbPisB1fo/zB29cyM0HeB8lnu+Z5AvkfjwekMtGJd 3+tsRwOqdAJpCpJNhS0cVAkk1lIe3i8pdBbbKYJ5VNpBTyi0zL18WRvz9qf8nnP50rQOF8Oc LNCyKrT5S02SonWH5fQDTMVaSDVRvzRLU34pL0WEsIfTQciwg9LhjRpGj6mHxX1OdRHBpHmH WAI05lg7xRwYZq2/X/9Xizd0j9hbr6Ph7oiW7u6e4zAndvPSxXaBVCzpVI0hhaJl11yVABEB AAG0G1Rhc3NvcyA8Y2hhdGFzb3NAeWFob28uY29tPokBPwQTAQIAKQUCU9atjgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG9JgN4loaV7D0kIAKfyVLWFzOfYM0uT m78iJsh9nAaxYiM0t40oF+HY7Cri35FDAzrRjbB0os/KehCz6uuBqDe+3swkVX9bwE9/GsHc Tb5C1IOdvgb2Rp3MfSF1+Ju/3uGtiktQIqZ5YrIZhIjGiwUCVC6ewpC3VRiFVo/HvE23p16y 6Ws9y4xoRNuxs0952twZjT9jwVub8TWm/uES6RERZ68FGA1jVFXtAgMXljP29KcL8zRw9xiY VNI1MgUIRhOKENzpChS+7jZSDWKKD9fwPUNDNPG9kNuXoinRX1g2wlgWKmaBNVBOZMunR20P eVewZ2v35uaiHyzzHw92vjjfxOtpXoW0QFlT5cg= To: v6ops list Message-ID: <670c10fd-f010-e3b7-c3c8-08de2dbc06f8@forthnet.gr> Date: Wed, 13 Nov 2019 09:32:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 07:33:03 -0000 Mark Smith wrote on 13/11/19 00:28: > On Wed, 13 Nov 2019 at 08:20, Tassos Chatzithomaoglou > wrote: >> >> Fernando Gont wrote on 12/11/19 16:33: >>> On 12/11/19 04:11, Tassos Chatzithomaoglou wrote: >>> >>>> The subscriber should have the choice to decide and the technology should give the means to support his/her choices. >>>> We're building a page inside our subscriber portal, where the subscriber chooses how frequently the LAN IPv6 assigned prefix should change. >>>> Default is to change at every PPP reconnect, but the subscriber can choose specific periods (x weeks/months) or action (once at next reconnect). >>> So, upon a CPE crash and reboot, the subscriber would get a different >>> prefix. Right? >>> >>> Thanks! >>> >>> Cheers, >> Yes, the current default is for the subscriber to get a different prefix after a CPE crash and reboot (like in IPv4). > "like in IPv4" > > Why are you giving customers delegated IPv6 prefixes - that's not like IPv4? Between ULA+NAT66 and PD we chose PD due to CPEs supporting it by default (and following the end-to-end connectivity principle). > > Other than "like in IPv4", why are you making the PD prefix change > upon reconnect when you don't have to? We do the same in IPv4 because many subscribers had asked for it. They wanted to easily (disconnect the line or reboot the CPE) change addresses. > What if your competitors provide stable prefixes, and their customers > get a better service experience than your customers do, without having > to wait possibly years for CPE and/or host upgrades per this ID's > proposal? > What is stopping them doing that? If they already have stable prefix > supporting infrastructure, why wouldn't they switch it on when they > can, when it could mean stealing customers from you and reducing their > numbers of helpdesk calls? > That's mostly a commercial decision. Commercially we want to differentiate static vs dynamic. The biggest technical issue i see is routing de-aggregation due to many different BRAS serving the same customers. Aggregating at another level is not an option, because we don't want to have hundreds of thousands of /56s at this level. Note: Largest percentage of our IPv6 related helpdesk calls is about DS-Lite subscribers having problems using a service requiring port forwarding (and their CPE doesn't support PCP), which we then change to the default Dual-Stack. >> But a CPE crash is not a common case. The most common case for prefix change is a DSL disconnect (due to line issues) or a PPP disconnect (due to network issues). >> Also, many of our CPEs store internally the prefix, so after a PPP reconnect they inform the LAN hosts about its release. >> >> -- >> Tassos >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Nov 12 23:54:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD7F12010C for ; Tue, 12 Nov 2019 23:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.267 X-Spam-Level: * X-Spam-Status: No, score=1.267 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, SPOOFED_FREEMAIL=1.999] 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 f32QVVQOzlcH for ; Tue, 12 Nov 2019 23:54:42 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9CB1200CE for ; Tue, 12 Nov 2019 23:54:42 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAD7seUA035421 for ; Wed, 13 Nov 2019 08:54:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4154A2024F6 for ; Wed, 13 Nov 2019 08:54:40 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3589E200B50 for ; Wed, 13 Nov 2019 08:54:40 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAD7sefG004605 for ; Wed, 13 Nov 2019 08:54:40 +0100 To: "v6ops@ietf.org" From: Alexandre Petrescu Message-ID: Date: Wed, 13 Nov 2019 08:54:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8BD6598832F6BEF966D4588B" Content-Language: fr Archived-At: Subject: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 07:54:44 -0000 This is a multi-part message in MIME format. --------------8BD6598832F6BEF966D4588B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, v6opsers, While reading through RFC7084 I couldnt find a place where the CE Router is mandated to put a prefix in the PIO, even though there is a (strange?) requirement to use RIO. I would like to ask: - which existing particular requirement the author assumes to be putting a derived /64 in the PIO in the RA? - what does it mean 'An IPv6 CE router MUST advertise itself as a router for the delegated prefix(es) [...] using the "Route Information Option" specified in Section 2.3 of [RFC4191].'?  (I am asking because I suspect this requirement is wrong: the CE Router must certainly not use RIO with these prefixes). Alex --------------8BD6598832F6BEF966D4588B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, v6opsers,

While reading through RFC7084 I couldnt find a place where the CE Router is mandated to put a prefix in the PIO, even though there is a (strange?) requirement to use RIO.

I would like to ask:

- which existing particular requirement the author assumes to be putting a derived /64 in the PIO in the RA?

- what does it mean 'An IPv6 CE router MUST advertise itself as a router for the delegated prefix(es) [...] using the "Route Information Option" specified in Section 2.3 of [RFC4191].'?  (I am asking because I suspect this requirement is wrong: the CE Router must certainly not use RIO with these prefixes).

Alex

--------------8BD6598832F6BEF966D4588B-- From nobody Wed Nov 13 02:50:46 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2CA120072 for ; Wed, 13 Nov 2019 02:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=helix-net-nz.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 g1xnurmNVZnn for ; Wed, 13 Nov 2019 02:50:42 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E1F12010F for ; Wed, 13 Nov 2019 02:50:42 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id i13so2016537ioj.5 for ; Wed, 13 Nov 2019 02:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5N7FINgfrwOXqoGZjVTcDoCP3NAIUrNWos8+Aji0CDM=; b=B/p+/+Cac8fyANyae4ZPTUbLbgVCw5KzOtirGiDo0COwagT5fom9S4vC+OcGxQ/1bV IY8LzR2iOlxdNV9L59tBV7jJsGFw9tAcc2Ugr5o+nT02FeMfziAZBLAPrRkIADxhTySl xVV17b8/YzdKBDZ6m41c307b3eE5FwaB2hvZ7Wbl9lSuOtsco5JjTTWqKnmaCmS5Xb+G hUEhSjEaZW5ZxWZACjJlcHp65bXu+U/zm+06k5Bbr0bi+4JdVPgwqhH+2qsbQFqK0ViI XXIX31+Jpz1XhOD/AG7oZwaPagCwewvty65BxeHxDWeVIXUzrDML+WU+FgbNDexb35D/ gaLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5N7FINgfrwOXqoGZjVTcDoCP3NAIUrNWos8+Aji0CDM=; b=QKqq7N1m6C2tDxUQjEOUT7Vs8qYuInpEXnoYaW16ldQyuqpm68MjeJnRWlpoff1Zy+ LjA1Jtz8RDZ5zFM4ZFjd0GyygP7YJ6psNDj06P2H2VuKbt9mmmZoxGHPtJ2GvZDxwTRY tYWZPv9+KumunLU/dSFivq7m4BIRtVMV3hFed/f1KetSjNMjTkKGeNJkqcYMI6Z9SExH Fvwjf8OBsoDhxwglXTD7WqR8+qvUnCNd3eTKJpEAh+4/4wWFl/WYhoE3Pv3Umjrbe2hm InGc+UwlM+kGs0L1JAFNpkx4IpUqzuJ1b9ttqg8NXIyHmpkqrW2dl+BeR4ozIFHgfOPg shaA== X-Gm-Message-State: APjAAAV2GXGtdz9n4TptJpAfrjUkDgwJHgMn7dpVces9IJ4VtcmAA4JF FX7NVwj++RxcT4EFXR5U2rzsPaG0yb4= X-Google-Smtp-Source: APXvYqx3RD3+AyMBaTUer8dJR9f6gyMkSf+Xrs3MyimWyU/hvjr0/uYvPlE924pfxqtcrJwYpn7f5g== X-Received: by 2002:a5e:8601:: with SMTP id z1mr51964ioj.214.1573642241373; Wed, 13 Nov 2019 02:50:41 -0800 (PST) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com. [209.85.166.172]) by smtp.gmail.com with ESMTPSA id d8sm221363ilr.82.2019.11.13.02.50.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 02:50:40 -0800 (PST) Received: by mail-il1-f172.google.com with SMTP id m5so1386056ilq.0 for ; Wed, 13 Nov 2019 02:50:40 -0800 (PST) X-Received: by 2002:a92:9ace:: with SMTP id c75mr3071844ill.296.1573642240329; Wed, 13 Nov 2019 02:50:40 -0800 (PST) MIME-Version: 1.0 References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> <33554C26-5007-483C-8C5E-6CC6DEB7724F@gmail.com> In-Reply-To: <33554C26-5007-483C-8C5E-6CC6DEB7724F@gmail.com> From: Richard Patterson Date: Wed, 13 Nov 2019 10:50:28 +0000 X-Gmail-Original-Message-ID: Message-ID: To: v6ops list Content-Type: multipart/alternative; boundary="000000000000bd10e60597382297" Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 10:50:45 -0000 --000000000000bd10e60597382297 Content-Type: text/plain; charset="UTF-8" On Wed, 13 Nov 2019 at 05:08, Fred Baker wrote: > Change "would" to "could", and you're probably close. In general, I would > expect ISPs to not want to randomly change their routing, and so it would > not be deterministic - if the customer is no longer using a prefix (e.g., > the CPE crashed and routing has changed anyway), when the CPE comes back up > they might give it a different prefix. However, I'd be surprised if they > did it "just because". > Depends on the vendor. For example, one of our BNGs (that's operating as a DHCPv6 server) will keep a lease in a "held" state for a configurable duration after the Valid Lifetime expires. We set that value to 7 days, allowing a CPE to come back and get the same PD within a week. A different BNG vendor of ours however, doesn't have this configurable hold time concept; once the Valid LIfetime expires, the MAC+DUID binding to the PD is cleared. They do have setting to retain the MAC+DUID->PD lease binding indefinitely, however they didn't satisfactorily answer my question about cleanup if these bindings are exhausted (CPEs that use dynamic DUID values perhaps? Even though even the DUID-LLT method is *supposed* to be stable). --000000000000bd10e60597382297 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 13 Nov 2019 at 05:08, Fred Baker = <fredbaker.ietf@gmail.com> wrote:
Change "would" to "could", and = you're probably close. In general, I would expect ISPs to not want to r= andomly change their routing, and so it would not be deterministic - if the= customer is no longer using a prefix (e.g., the CPE crashed and routing ha= s changed anyway), when the CPE comes back up they might give it a differen= t prefix. However, I'd be surprised if they did it "just because&q= uot;.


--000000000000bd10e60597382297-- From nobody Wed Nov 13 06:17:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788812003E for ; Wed, 13 Nov 2019 06:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DajZHFr0jQpR for ; Wed, 13 Nov 2019 06:17:12 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C6E1201E4 for ; Wed, 13 Nov 2019 06:17:12 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id b17so2194203wmj.2 for ; Wed, 13 Nov 2019 06:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C3aLI1ZlwSBETF+CUsKFlRcXAaDCq5vpfMEZKWiyHlw=; b=Rb2kcmqTx4PxSsDaBqvZSkBJgXcjO/jPpwr4KDT49OUmSv3FbTxnUzbK7M5ekGYK3R nF6UEIxX84fvlP8nhh4u7XIiMDKQfqctvQBmQh+UZxGyjl239twpmeeAP4uurb0VzZtZ tpvRnJJsSEMBIiOVUdgQNClkZ3O7uAobMEJpc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C3aLI1ZlwSBETF+CUsKFlRcXAaDCq5vpfMEZKWiyHlw=; b=I6nEqwdJFiOWUoh9E9Iysjdpx7VSNUaw+Ojlq4ZJBXw4mSuyxkaWSJ6XWUjG1peVim OZrrFOWbBuVKtoML1kHH3Xqp+Mhnom0DKK4Zm/fZTPrrZhnHY4uz/1ZU8gXk+LV25bMY 3T+ZRkQXvQcXefZLPSqQyJSDyuz3ES13ghR0V97IYvKs13qmO70P8l/p/nmyM/DAIzW2 deDw+ACcV4pOfkB9f5oj9kl8CZB+8wQpwc31TXaD1TwoPnceVjmYZi6Htp+mMQGEO+KQ apYuMbSlSbAyhVrhAaYx1horRYkCs12/X4G8vrSJDyTx7lxsGRHSfyAKe0XJSlm5Ejxw Lf5w== X-Gm-Message-State: APjAAAU08vZS/dKi3pq9abcJxHa1Kk/Q7phXl8aV9BsRHjslmagdvet8 yNWH6gaROJm0WeAin93EIX5PC0kWFpzFoRbePh+W6w== X-Google-Smtp-Source: APXvYqzPPStBuyPZ1rF1TSpXlBwc/7zfleHzF6euWcvPWz6QU/8upYD1wUpRIvx8Ci3rAtRAA8unMDS187KM8v+9dXM= X-Received: by 2002:a1c:4c10:: with SMTP id z16mr2789365wmf.24.1573654630884; Wed, 13 Nov 2019 06:17:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Timothy Winters Date: Wed, 13 Nov 2019 09:16:59 -0500 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046076405973b055c" Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 14:17:15 -0000 --00000000000046076405973b055c Content-Type: text/plain; charset="UTF-8" Hi Alex, On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hi, v6opsers, > > While reading through RFC7084 I couldnt find a place where the CE Router > is mandated to put a prefix in the PIO, even though there is a (strange?) > requirement to use RIO. > > I would like to ask: > > - which existing particular requirement the author assumes to be putting a > derived /64 in the PIO in the RA? > The placing of the prefixes in the PIO from the IA_PD was originally located in RFC 3633, so it's not covered in 7084. > - what does it mean 'An IPv6 CE router MUST advertise itself as a router > for the delegated prefix(es) [...] using the "Route Information Option" > specified in Section 2.3 of [RFC4191].'? (I am asking because I suspect > this requirement is wrong: the CE Router must certainly not use RIO with > these prefixes). > CE Routers should place the RIO in the RAs on the LAN interface to have Host route traffic for those prefixes to that Router if they have multi-homed. > Alex > Regards, Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000046076405973b055c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

On Wed, Nov 13, 2019 at 2:54 AM A= lexandre Petrescu <alexa= ndre.petrescu@gmail.com> wrote:
=20 =20 =20

Hi, v6opsers,

While reading through RFC7084 I couldnt find a place where the CE Router is mandated to put a prefix in the PIO, even though there is a (strange?) requirement to use RIO.

I would like to ask:

- which existing particular requirement the author assumes to be putting a derived /64 in the PIO in the RA?

The placing of the prefixes in the PIO from the IA_PD was origina= lly located in RFC 3633, so it's not covered in 7084.

- what does it mean = 9;An IPv6 CE router MUST advertise itself as a router for the delegated prefix(es) [...] using the "Route Information Option" specified in Section 2.3 of [RFC4191].'?=C2=A0 (= I am asking because I suspect this requirement is wrong: the CE Router must certainly not use RIO with these prefixes).

CE Routers should place the RIO in the RAs on the = LAN interface to have Host route traffic for those prefixes to that Router = if they have multi-homed.

Alex
<= /p>

Regards,
Tim=C2=A0

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000046076405973b055c-- From nobody Wed Nov 13 07:19:07 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74831200B8 for ; Wed, 13 Nov 2019 07:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 UB-aSsxN2Ing for ; Wed, 13 Nov 2019 07:19:01 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61BC12002E for ; Wed, 13 Nov 2019 07:19:01 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id z23so2002848qkj.10 for ; Wed, 13 Nov 2019 07:19:01 -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=UoJinkglksfAyPgUldTqkQLqHbluQIbqKgR4mvg6ClY=; b=zNSra8KVcv4Hj4pxb13HiUZD5FKsDx3q+mjQrh5NGhcnAFk21Q+Uz3m+R6dke4JZYB 6g8mnS2yynXcy5hAwU5QzwKW2jrgTIa2LZseX7xpaqidpNHT0MtaBPnmtpPCgKEoRQmE qGXJrcOj4GhrXlAx8IxTrkCk/EzN6ZsuOwF/VvLn0+Ub6vVdrWJukLmNkFi2zZUw+Xat OcL7fP9KsVXbuGL1Lqm21i6/fjlL/UMbgp69tgy+LoihfKIy7af2X4Sa0o8MHEq+XF4r 0SQftqgLbJZOO/qenwdxS/flxgHHRwo7FtItJjQhlBS93ndao40C/e5sJS/CDSyneoJo 33XA== 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=UoJinkglksfAyPgUldTqkQLqHbluQIbqKgR4mvg6ClY=; b=H/cO+Cw+b4fkEzaxCcL3p7iBnmaRK2Qvym4FvBfGxRcB+8/0p+HZ1wsPWyJFuJ/eox 4nr/Cp8g7+XLlKiwBTzF86n/XLmiu6xtMIM70ZIz3gfjv4oOfK7zAC/x8K5KMjoSgFzK 2JC44WyHCKSrJDhTXrIFPgMbUd8f4YGHcmffXs0eGMi/jKXq1jKT8+vVlvX8/nWnA9Ih ze2glYGLH9Jt1Mx4B26F91bufrIm356StS02V49J50INa5hUATAs7ilqGIdNn4XK7VUv 1N2MMluQcN/vyeDhfDtDQBu/4RjAtcB0r2MmxubDwIkK3oePa+nHqXDMlnidGPmjZcOq 76yQ== X-Gm-Message-State: APjAAAXKGQxqeQAaULmdfIxTmYZXkhhvV7ccaWqFuwL00jenNbyjAq87 yciK5D6Qov2T4qyVMycy/eEiI/CJapQJGg== X-Google-Smtp-Source: APXvYqy+WEK9k87R9z88zT6HDupFvHOqfFAP7CViQxwP6S5AIUD/pW4xJopD0DdnqcdVNcQJ/y4x8A== X-Received: by 2002:a37:9c44:: with SMTP id f65mr2958316qke.33.1573658340494; Wed, 13 Nov 2019 07:19:00 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:900d:f981:2ce3:f5f8? ([2601:18b:300:36ee:900d:f981:2ce3:f5f8]) by smtp.gmail.com with ESMTPSA id u9sm1091714qke.50.2019.11.13.07.18.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 07:18:59 -0800 (PST) From: Ted Lemon Message-Id: <72D242F5-CD98-48CB-AA65-3B866B2D19E1@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_91758C25-BB1E-4E1A-92F7-12187C1A6226" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 13 Nov 2019 10:18:53 -0500 In-Reply-To: <670c10fd-f010-e3b7-c3c8-08de2dbc06f8@forthnet.gr> Cc: v6ops list To: Tassos Chatzithomaoglou References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> <670c10fd-f010-e3b7-c3c8-08de2dbc06f8@forthnet.gr> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 15:19:05 -0000 --Apple-Mail=_91758C25-BB1E-4E1A-92F7-12187C1A6226 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 13, 2019, at 2:32 AM, Tassos Chatzithomaoglou = wrote: > We do the same in IPv4 because many subscribers had asked for it. They = wanted to easily (disconnect the line or reboot the CPE) change = addresses. Supposing IPv6 customers ask for this. Why would you not give it to = them with graceful renumbering rather than flash renumbering? > That's mostly a commercial decision. Commercially we want to = differentiate static vs dynamic. So you are charging customers to not do something that costs you money = and them reliability to do. Customers who pay you get nothing, and = customers who don=E2=80=99t pay you get what amounts to a punishment. = I guess that=E2=80=99s your prerogative, but again, if you are going to = do this, why not do it right? Don=E2=80=99t flash renumber=E2=80=94renumb= er gracefully. You still are able to punish customers who don=E2=80=99t = pay you, but you aren=E2=80=99t creating a support problem for yourself = in the process. > The biggest technical issue i see is routing de-aggregation due to = many different BRAS serving the same customers. So am I to understand that you have many different routes to the = customer, and no way to be consistent about which route the customer = gets when they disconnect and reconnect? Isn=E2=80=99t that a problem = with the BRAS setup? > Aggregating at another level is not an option, because we don't want = to have hundreds of thousands of /56s at this level. Absolutely. But is that your only option? E.g., if you were to just = have a route at this level for every customer that had been renumbered = and still needed their old prefix to be routed, would that tend to be = hundreds of thousands? If so, isn=E2=80=99t that evidence that = there=E2=80=99s something wrong with your setup? --Apple-Mail=_91758C25-BB1E-4E1A-92F7-12187C1A6226 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 13, 2019, at 2:32 AM, Tassos Chatzithomaoglou <achatz@forthnet.gr> = wrote:
We do the = same in IPv4 because many subscribers had asked for it. They wanted to = easily (disconnect the line or reboot the CPE) change = addresses.

Supposing IPv6 customers ask for this.   Why = would you not give it to them with graceful renumbering rather than = flash renumbering?

That's mostly a commercial decision. Commercially we want to = differentiate static vs dynamic.

So you = are charging customers to not do something that costs you money and them = reliability to do.   Customers who pay you get nothing, and = customers who don=E2=80=99t pay you get what amounts to a punishment. =   I guess that=E2=80=99s your prerogative, but again, if you are = going to do this, why not do it right?  Don=E2=80=99t flash = renumber=E2=80=94renumber gracefully.   You still are able to = punish customers who don=E2=80=99t pay you, but you aren=E2=80=99t = creating a support problem for yourself in the process.

The biggest technical = issue i see is routing de-aggregation due to many different BRAS serving = the same customers.

So am I to understand = that you have many different routes to the customer, and no way to be = consistent about which route the customer gets when they disconnect and = reconnect?   Isn=E2=80=99t that a problem with the BRAS = setup?

Aggregating at another level is not an option, because we = don't want to have hundreds of thousands of /56s at this = level.

Absolutely.   But = is that your only option?   E.g., if you were to just have a route = at this level for every customer that had been renumbered and still = needed their old prefix to be routed, would that tend to be hundreds of = thousands?   If so, isn=E2=80=99t that evidence that there=E2=80=99s = something wrong with your setup?

= --Apple-Mail=_91758C25-BB1E-4E1A-92F7-12187C1A6226-- From nobody Wed Nov 13 07:20:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529E312023E for ; Wed, 13 Nov 2019 07:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 8yE95TSEf3O6 for ; Wed, 13 Nov 2019 07:20:31 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F80F12002E for ; Wed, 13 Nov 2019 07:20:31 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id i17so2982572qtq.1 for ; Wed, 13 Nov 2019 07:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GWhJMV203met4jq40BGXG5jyRNQdIxLnf+tnqZZqw6A=; b=ccJ/jxWdpN5Ci28aeki+En8bhLCZS/MePUwufSSFoRSVIBYI6GimLoK91lxkpR1SA2 HbvqwdPVHV2QDHeRG506wuCwSp/oo39xYn5zDtN6V4M8tDW94+g5gAySO7Vy/isVXujQ LwPDNRnpVrUsBm7o4W6G4+lroRsvNT4/G3nzredSlR60C3ikUP5niWrLZw+jUczLF4Z/ 2vaX1aYjdBItA9/XrcyHvuDT1ZV62ZtoKMdZRj4oBTdcyj4XLCIUeyTYZ9E9Pf6BOq7k 8gYQiBHt6Ypsu1NgUgNICzWBymOixBU2vehVKpOuYvFH6k0I3Kcfo1igZVD37ow8OMCP 8x9g== 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=GWhJMV203met4jq40BGXG5jyRNQdIxLnf+tnqZZqw6A=; b=eBNuQ14zUuKW/c1+2qG/bebSkya/pCze6kihatJ6N1orftJKb/CBKHmk59ozLpg8uw yld48IXedMwq6DiSXEdct6D6IO/J+bCKgsrKXbPBxLXT0nVzTP0RqK/W5/RbEdjhi0jb gfmvfY8f4uUupu5T2bPoF4kGTqd5P3PrrAXmwFOe1osl1LaU2jeuTaLSvzaMZOnu1eqW InvFUaEBqofLuIR7wIze9kiAMS3sYpIWh3f3VyyXF2M0eiB6NYRk7PsUygHlOfenDre/ G6To0LyyTE29723JnBjHs8TW5PbkzNeCmDo4gutuXRE37HxprL1+Do6weOYMlmu+7pRS +OHw== X-Gm-Message-State: APjAAAXzhBeQVQtdcPJhAJM7fezLOg6F8746OJfi708G32zDDNfaHyCi k29Sh1nSQjrz2OdZoQsO1AORk7rCoVODhA== X-Google-Smtp-Source: APXvYqzClVHnTPFolRy6nzxDQQxnCbrSXXnqMsmVTZwT9liPB1LTOv165qyqecZz4vidIWrqd2+ocQ== X-Received: by 2002:aed:241c:: with SMTP id r28mr3191804qtc.148.1573658430503; Wed, 13 Nov 2019 07:20:30 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:900d:f981:2ce3:f5f8? ([2601:18b:300:36ee:900d:f981:2ce3:f5f8]) by smtp.gmail.com with ESMTPSA id f21sm1380170qte.36.2019.11.13.07.20.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 07:20:29 -0800 (PST) From: Ted Lemon Message-Id: <164CA370-09B7-4501-8474-A2A308368177@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7F63AA54-CE61-465C-945C-9A3068DDAE64" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 13 Nov 2019 10:20:25 -0500 In-Reply-To: Cc: v6ops list To: Richard Patterson References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> <33554C26-5007-483C-8C5E-6CC6DEB7724F@gmail.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 15:20:33 -0000 --Apple-Mail=_7F63AA54-CE61-465C-945C-9A3068DDAE64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 13, 2019, at 5:50 AM, Richard Patterson = wrote: > A different BNG vendor of ours however, doesn't have this configurable = hold time concept; once the Valid LIfetime expires, the MAC+DUID binding = to the PD is cleared. > They do have setting to retain the MAC+DUID->PD lease binding = indefinitely, however they didn't satisfactorily answer my question = about cleanup if these bindings are exhausted (CPEs that use dynamic = DUID values perhaps? Even though even the DUID-LLT method is *supposed* = to be stable). FWIW, I don=E2=80=99t think there=E2=80=99s anything wrong with this. = The network is not obliged to remember that you had a prefix after the = valid lifetime of the prefix (the promise you made) has expired. I = know that you=E2=80=99ve heard a few people here say that you should = keep this prefix for the customer pretty much forever, but I don=E2=80=99t= think that=E2=80=99s the consensus. If you keep it until the valid = lifetime has expired, I think you have kept your promise. --Apple-Mail=_7F63AA54-CE61-465C-945C-9A3068DDAE64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 13, 2019, at 5:50 AM, Richard Patterson <richard@helix.net.nz> wrote:
A different BNG vendor of ours = however, doesn't have this configurable hold time concept; once the = Valid LIfetime expires, the MAC+DUID binding to the PD is = cleared.
They do have setting to retain the MAC+DUID->PD = lease binding indefinitely, however they didn't satisfactorily answer my = question about cleanup if these bindings are exhausted (CPEs that use = dynamic DUID values perhaps?  Even though even the DUID-LLT method = is *supposed* to be stable).

FWIW, I don=E2=80=99t think there=E2=80=99s = anything wrong with this.   The network is not obliged to remember = that you had a prefix after the valid lifetime of the prefix (the = promise you made) has expired.   I know that you=E2=80=99ve heard a = few people here say that you should keep this prefix for the customer = pretty much forever, but I don=E2=80=99t think that=E2=80=99s the = consensus.   If you keep it until the valid lifetime has expired, I = think you have kept your promise.



= --Apple-Mail=_7F63AA54-CE61-465C-945C-9A3068DDAE64-- From nobody Wed Nov 13 11:39:13 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AB612084A for ; Wed, 13 Nov 2019 11:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 kxc70TMT4pPy for ; Wed, 13 Nov 2019 11:39:09 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34DB12003E for ; Wed, 13 Nov 2019 11:39:09 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id q26so2306414pfn.11 for ; Wed, 13 Nov 2019 11:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tLO5SyB80+Mb5rLn4j+090TIUbPJAq7qczuportTdf4=; b=t40gokhPEC0tmkRDEfLXFsEAxcEz99jCqDWTEP2OSBEAJRe03UIccGfeycvT1JS4uz iW+acJMDasTkpixS9nfbEYddP5ndIV0KYtZ6L+Iwe0Ptrd0yGGaQg0Ng0z0E0SW4wCsb NN+MES/5my602oYJs7ESXsDwwPoIx1vD2xlIoomPIJb3yDHVe8MTVqe3N7U54x7DGmT2 7kNbDk+o5QXN7Cp1m/BnkH6HXGePdTMHsjsjJYkzNNpfwCBPeVP+S2eaNLLcvK0gZLRL ZeEcqMAEJoMpRIwBd2WiLxrLM404kBBSCOxZQPKxnFlRfwJ4IU0pLLtPmy/5oB/BAOjO J9zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tLO5SyB80+Mb5rLn4j+090TIUbPJAq7qczuportTdf4=; b=eTtHA+6VU9wGNSKiDrlU2NdUc1g4oldM1JsM01sWmoMo0ajMqGthAybThx0mZgSbPE mMyHVQYwBUew2Z9nEPOrJ8Z1/rxkGoc02c+//GXJPIbdit4XbkN6NjFw3+SrJ9driy4E v6UMRhhXDQ0CFdahvYTzwpDJ7zIpTND3Ny+OU3ADuBzb08emuf1fxvHK6QakZFx7+a5m U1lQXKdPnpRyrDOPX1bJbJH6he0QlfpUIIvB48Lk4ePjkezYF0ALYIOdn9b1Wg3p92uC Eq9XE8Vhg0zOWftkoBvikqstBim6L/ooDSAD1b5jv31qMm6o0jOft3kLt3X5eoVW6Iz4 4GMg== X-Gm-Message-State: APjAAAU9X5Z8+oh2l9tjctSPOTyr2WPjbVOkaQWmn9aHQwzdxRgPfRpC aUnimT1HzrvQ+gUZg1TFUAM0GQq8 X-Google-Smtp-Source: APXvYqxZzK5DWic3cJ/N1IbFZBeWGJAjDM7J2Y4GOZIM7e9QexpfR7XAT6RLnqUF4spPC3N5UAA5zg== X-Received: by 2002:aa7:961d:: with SMTP id q29mr6226455pfg.89.1573673949113; Wed, 13 Nov 2019 11:39:09 -0800 (PST) Received: from [192.168.178.30] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id l21sm3035508pjt.28.2019.11.13.11.39.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 11:39:08 -0800 (PST) To: Timothy Winters , Alexandre Petrescu Cc: "v6ops@ietf.org" References: From: Brian E Carpenter Message-ID: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> Date: Thu, 14 Nov 2019 08:39:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 19:39:11 -0000 On 14-Nov-19 03:16, Timothy Winters wrote: > Hi Alex, >=20 > On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu > wrote: >=20 >> Hi, v6opsers, >>=20 >> While reading through RFC7084 I couldnt find a place where the CE = Router is mandated to put a prefix in the PIO, even though there is a (st= range?) requirement to use RIO. >>=20 >> I would like to ask: >>=20 >> - which existing particular requirement the author assumes to be p= utting a derived /64 in the PIO in the RA? >=20 > The placing of the prefixes in the PIO from the IA_PD was originally lo= cated in RFC 3633, so it's not covered in 7084. More to the point of Alex's question, 7084 says: >>> The IPv6 CE router MUST support router behavior according to >>> Neighbor Discovery for IPv6 [RFC4861]. which therefore requires properly formed PIOs. >>=20 >> - what does it mean 'An IPv6 CE router MUST advertise itself as a = router for the delegated prefix(es) [...] using the "Route Information Op= tion" specified in Section 2.3 of [RFC4191].'? (I am asking because I su= spect this requirement is wrong: the CE Router must certainly not use RIO= with these prefixes). Why is that wrong? It is under "LAN requirements:" and seems to mean exac= tly what Alex says next: >> CE Routers should place the RIO in the RAs on the LAN interface to hav= e Host route traffic for those prefixes to that Router if they have multi= -homed (Although, not surprisingly, I would like to see RFC8028 mandated too.) Regards Brian >>=20 >> Alex >=20 > Regards, > Tim=C2=A0 From nobody Wed Nov 13 12:06:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FAF12003E for ; Wed, 13 Nov 2019 12:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 xXR9vwe_tnMz for ; Wed, 13 Nov 2019 12:06:29 -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 D84B412004A for ; Wed, 13 Nov 2019 12:06:28 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xADJw147009676; Wed, 13 Nov 2019 15:06:24 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2w8qyq96ab-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Nov 2019 15:06:23 -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 xADK6MPL007458; Wed, 13 Nov 2019 15:06:23 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xADK6FIJ007224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Nov 2019 15:06:15 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id B44FD4009E93; Wed, 13 Nov 2019 20:06:15 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30487.vci.att.com (Service) with ESMTPS id 9FAF94009E83; Wed, 13 Nov 2019 20:06:15 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.98]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0468.000; Wed, 13 Nov 2019 15:06:15 -0500 From: "STARK, BARBARA H" To: "'Brian E Carpenter'" , "'Timothy Winters'" , "'Alexandre Petrescu'" CC: "'v6ops@ietf.org'" Thread-Topic: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? Thread-Index: AQHVmfepFgFbIMAaoE+bicSKfOr07aeJeeiAgABZ/wD//66noA== Date: Wed, 13 Nov 2019 20:06:14 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611536D06CA@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> In-Reply-To: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-13_04:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=684 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911130162 Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 20:06:30 -0000 PiBGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFu IEUgQ2FycGVudGVyDQo+IE9uIDE0LU5vdi0xOSAwMzoxNiwgVGltb3RoeSBXaW50ZXJzIHdyb3Rl Og0KPiA+IEhpIEFsZXgsDQo+ID4NCj4gPiBPbiBXZWQsIE5vdiAxMywgMjAxOSBhdCAyOjU0IEFN IEFsZXhhbmRyZSBQZXRyZXNjdQ0KPiA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbSA8bWFp bHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+Pg0KPiB3cm90ZToNCj4gPg0KPiA+PiAg ICAgSGksIHY2b3BzZXJzLA0KPiA+Pg0KPiA+PiAgICAgV2hpbGUgcmVhZGluZyB0aHJvdWdoIFJG QzcwODQgSSBjb3VsZG50IGZpbmQgYSBwbGFjZSB3aGVyZSB0aGUgQ0UNCj4gUm91dGVyIGlzIG1h bmRhdGVkIHRvIHB1dCBhIHByZWZpeCBpbiB0aGUgUElPLCBldmVuIHRob3VnaCB0aGVyZSBpcyBh DQo+IChzdHJhbmdlPykgcmVxdWlyZW1lbnQgdG8gdXNlIFJJTy4NCj4gPj4NCj4gPj4gICAgIEkg d291bGQgbGlrZSB0byBhc2s6DQo+ID4+DQo+ID4+ICAgICAtIHdoaWNoIGV4aXN0aW5nIHBhcnRp Y3VsYXIgcmVxdWlyZW1lbnQgdGhlIGF1dGhvciBhc3N1bWVzIHRvIGJlDQo+IHB1dHRpbmcgYSBk ZXJpdmVkIC82NCBpbiB0aGUgUElPIGluIHRoZSBSQT8NCj4gPg0KPiA+IFRoZSBwbGFjaW5nIG9m IHRoZSBwcmVmaXhlcyBpbiB0aGUgUElPIGZyb20gdGhlIElBX1BEIHdhcyBvcmlnaW5hbGx5IGxv Y2F0ZWQNCj4gaW4gUkZDIDM2MzMsIHNvIGl0J3Mgbm90IGNvdmVyZWQgaW4gNzA4NC4NCj4gDQo+ IE1vcmUgdG8gdGhlIHBvaW50IG9mIEFsZXgncyBxdWVzdGlvbiwgNzA4NCBzYXlzOg0KPiANCj4g Pj4+IFRoZSBJUHY2IENFIHJvdXRlciBNVVNUIHN1cHBvcnQgcm91dGVyIGJlaGF2aW9yIGFjY29y ZGluZyB0bw0KPiA+Pj4gTmVpZ2hib3IgRGlzY292ZXJ5IGZvciBJUHY2IFtSRkM0ODYxXS4NCj4g DQo+IHdoaWNoIHRoZXJlZm9yZSByZXF1aXJlcyBwcm9wZXJseSBmb3JtZWQgUElPcy4NCg0KWWVz LiBSRkMgNDg2MSBTZWN0aW9uIDYuMi4zIHJlcXVpcmVzIHRoZSBQSU8gb3B0aW9uIGJlIGluY2x1 ZGVkIGluIGEgUm91dGVyIEFkdmVydGlzZW1lbnQuIFJGQyA3MDg0IEwtMSByZXF1aXJlcyBSRkMg NDg2MSByb3V0ZXIgYmVoYXZpb3IgYW5kIEwtNSBzcGVjaWZpY2FsbHkgcmVxdWlyZXMgUkFzIHRv IGJlIHNlbnQuIEluIGFkZGl0aW9uLCBMLTYgcmVxdWlyZXMgdGhlIEEgYW5kIEwgZmxhZ3MgaW4g dGhlc2UgUkEgUElPcyBiZSBzZXQgdG8gMSBieSBkZWZhdWx0Lg0KIA0KPiA+PiAgICAgLSB3aGF0 IGRvZXMgaXQgbWVhbiAnQW4gSVB2NiBDRSByb3V0ZXIgTVVTVCBhZHZlcnRpc2UgaXRzZWxmIGFz IGEgcm91dGVyDQo+IGZvciB0aGUgZGVsZWdhdGVkIHByZWZpeChlcykgWy4uLl0gdXNpbmcgdGhl ICJSb3V0ZSBJbmZvcm1hdGlvbiBPcHRpb24iDQo+IHNwZWNpZmllZCBpbiBTZWN0aW9uIDIuMyBv ZiBbUkZDNDE5MV0uJz8gIChJIGFtIGFza2luZyBiZWNhdXNlIEkgc3VzcGVjdCB0aGlzDQo+IHJl cXVpcmVtZW50IGlzIHdyb25nOiB0aGUgQ0UgUm91dGVyIG11c3QgY2VydGFpbmx5IG5vdCB1c2Ug UklPIHdpdGggdGhlc2UNCj4gcHJlZml4ZXMpLg0KPiANCj4gV2h5IGlzIHRoYXQgd3Jvbmc/IEl0 IGlzIHVuZGVyICJMQU4gcmVxdWlyZW1lbnRzOiIgYW5kIHNlZW1zIHRvIG1lYW4NCj4gZXhhY3Rs eSB3aGF0IEFsZXggc2F5cyBuZXh0Og0KPiANCj4gPj4gQ0UgUm91dGVycyBzaG91bGQgcGxhY2Ug dGhlIFJJTyBpbiB0aGUgUkFzIG9uIHRoZSBMQU4gaW50ZXJmYWNlIHRvDQo+ID4+IGhhdmUgSG9z dCByb3V0ZSB0cmFmZmljIGZvciB0aG9zZSBwcmVmaXhlcyB0byB0aGF0IFJvdXRlciBpZiB0aGV5 DQo+ID4+IGhhdmUgbXVsdGktaG9tZWQNCj4gDQo+IChBbHRob3VnaCwgbm90IHN1cnByaXNpbmds eSwgSSB3b3VsZCBsaWtlIHRvIHNlZSBSRkM4MDI4IG1hbmRhdGVkIHRvby4pDQo+DQo+IFJlZ2Fy ZHMNCj4gICAgIEJyaWFuDQo+ID4+DQo+ID4+ICAgICBBbGV4DQo+ID4NCj4gPiBSZWdhcmRzLA0K PiA+IFRpbQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1U U1FpY3ZqSWcmcj1Mb0d6aEMtDQo+IDhzYzhTWThUcTR2cmZvZyZtPW5LNm1HaVdZSFBLU3JYVEVv OEMxTFNkUTBRRmpOWTdEaE9sTXV5RkJvQmsNCj4gJnM9SU8xZ1BuNGo0enpicjFRc0pvdkp0T0Ff WlJqckJUbXBNeFdHMGFTMkJhZyZlPQ0K From nobody Wed Nov 13 12:58:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3362F12004D for ; Wed, 13 Nov 2019 12:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.504 X-Spam-Level: X-Spam-Status: No, score=0.504 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, FREEMAIL_REPLY=1, 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_HELO_NONE=0.001, 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 uG3-zzfdO738 for ; Wed, 13 Nov 2019 12:57:59 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::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 120AA120046 for ; Wed, 13 Nov 2019 12:57:59 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id 14so3106122oir.12 for ; Wed, 13 Nov 2019 12:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=78qd0txAaic5QEbABdC3NY83YamCDWLHH7+I14bj0Ss=; b=HJNqq7ACbvgMKVdHoHzF6S3PocLzqiAWKtTyBHLd814c9gf7vaju7KfbjD4bSnbmdU 3Y20gsrJSlgQaIFWrgq6ec2EpdWQBqC5/0Vzpf22Ggwkx5vM8xXqmDFWIFzTaw0F2Z5q c1KxTu3fV2H65hKnmkDW22poBubtxsmJ0d/jcqHAdRo8MvMli0JXgjziNlJ45uA+2z1P P6I53w5wajeSjQ16YFknvBQx2J3hkdc2Xm1AmmZyXb6sQQMzYvoH6tdDb6KZ2S0KfGcQ PKchI5T+hWDMbIViEksjE7Qcp+UQdFq9NFuNqkdx+bMyfR3l+M3mg5f1O6i+wvTJoaur Gshw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=78qd0txAaic5QEbABdC3NY83YamCDWLHH7+I14bj0Ss=; b=rkT47VISWul+tW0JRsQrRXr6ulbI+0vKG3rgSpaLNHA2+Cguaq74+QR120BJ5a2inZ utoOW8f9IcuO/EA4AZjHFwolBsLJwx2eJRty3c1BWKVIKeUeLD2Wu5k/vnoMY/ZQ/Y/f /PSjLohQtG9ufo5MOgxjuWSY7QUnXEZGuJ6x8aC3bQoN+E4mpJv3SnQ/Ve6sIf46Mfm2 C630LOPw7PDiBbMiMYMZpwxWzPdORZkFSg/6LAVscKFm3OlGJS913qNDfBPxbW+PB1GO uV6e9vsNOwQ0uA6J7B0FXD08FT0XcS0XSTVb/PUCCq9lMv7uF1/g6ZZNdFzMlXxYE6yt TUdg== X-Gm-Message-State: APjAAAWDXjJ1m79BSmRvzQ4i2X8Pcysk7yoyZTE8nY9ZDs3ItZtAVi/7 IlXDCzxgl7iXCFAaEbjQhF29SWGVEByZ0CNW04w= X-Google-Smtp-Source: APXvYqxecvzgwe361QExkLyBkHXANMUXsPQD4m0dFNIX1pyW5WKSvArxHxbKS58LsWtOyQPdBuRDI5qwLMh1ZYCuWlU= X-Received: by 2002:aca:af95:: with SMTP id y143mr575828oie.38.1573678678303; Wed, 13 Nov 2019 12:57:58 -0800 (PST) MIME-Version: 1.0 References: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> In-Reply-To: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> From: Mark Smith Date: Thu, 14 Nov 2019 07:57:46 +1100 Message-ID: To: Brian E Carpenter Cc: Timothy Winters , Alexandre Petrescu , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009c68300597409e03" Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 20:58:01 -0000 --0000000000009c68300597409e03 Content-Type: text/plain; charset="UTF-8" On Thu, 14 Nov 2019, 06:39 Brian E Carpenter, wrote: > On 14-Nov-19 03:16, Timothy Winters wrote: > > Hi Alex, > > > > On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu < > alexandre.petrescu@gmail.com > wrote: > > > >> Hi, v6opsers, > >> > >> While reading through RFC7084 I couldnt find a place where the CE > Router is mandated to put a prefix in the PIO, even though there is a > (strange?) requirement to use RIO. > >> > >> I would like to ask: > >> > >> - which existing particular requirement the author assumes to be > putting a derived /64 in the PIO in the RA? > > > > The placing of the prefixes in the PIO from the IA_PD was originally > located in RFC 3633, so it's not covered in 7084. > > More to the point of Alex's question, 7084 says: > > >>> The IPv6 CE router MUST support router behavior according to > >>> Neighbor Discovery for IPv6 [RFC4861]. > > which therefore requires properly formed PIOs. > > >> > >> - what does it mean 'An IPv6 CE router MUST advertise itself as a > router for the delegated prefix(es) [...] using the "Route Information > Option" specified in Section 2.3 of [RFC4191].'? (I am asking because I > suspect this requirement is wrong: the CE Router must certainly not use RIO > with these prefixes). > > Why is that wrong? It is under "LAN requirements:" and seems to mean > exactly what Alex says next: > I'm pretty sure using RIOs was to work around this: ULA-5: An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime greater than zero whenever all of its configured and delegated prefixes are ULA prefixes If hosts don't have a default router because of that, then they need to have other sourced knowledge of the site's ULA prefixes reachable via the router. I don't agree with that ULA-5 requirement. The router lifetime in an RA is a statement of the router's default router status on the link the RA is sent on, not for the whole site. It would be fine for hosts to default to a CE for a ULA only site. If they try to send to somewhere else (e.g. a GUA DA they've somehow acquired), the DA route lookup would fail in the CE's default free route table, and the CE would generate an ICMPv6 Destination Unreachable. There was a fault with a CPE I looked at back in 2010 where it wouldn't send ICMPv6 Destination Unreachables in this scenario. That caused long IPv6 timeouts. Other CPE would send an ICMPv6 Destination Unreachable, and the browser would switch to IPv4 almost immediately. HappyEyeballs was effectively motivated by a bug, although it does cover off ICMPv6 Destination Unreachables not being sent because of ICMPv6 send rate limits, per RFC 4443, 2.4, (f). > >> CE Routers should place the RIO in the RAs on the LAN interface to have > Host route traffic for those prefixes to that Router if they have > multi-homed > > (Although, not surprisingly, I would like to see RFC8028 mandated too.) > > Regards > Brian > >> > >> Alex > > > > Regards, > > Tim > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000009c68300597409e03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 14 Nov 2019, 06:39 Brian E Carpenter, <brian.e.carpenter@gmail.com> wrote:
On 14-Nov-19 03:16, Timothy Winters wrote:
> Hi Alex,
>
> On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
>
>>=C2=A0 =C2=A0 =C2=A0Hi, v6opsers,
>>
>>=C2=A0 =C2=A0 =C2=A0While reading through RFC7084 I couldnt find a = place where the CE Router is mandated to put a prefix in the PIO, even thou= gh there is a (strange?) requirement to use RIO.
>>
>>=C2=A0 =C2=A0 =C2=A0I would like to ask:
>>
>>=C2=A0 =C2=A0 =C2=A0- which existing particular requirement the aut= hor assumes to be putting a derived /64 in the PIO in the RA?
>
> The placing of the prefixes in the PIO from the IA_PD was originally l= ocated in RFC 3633, so it's not covered in 7084.

More to the point of Alex's question, 7084 says:

>>> The IPv6 CE router MUST support router behavior according to >>> Neighbor Discovery for IPv6 [RFC4861].

which therefore requires properly formed PIOs.

>>
>>=C2=A0 =C2=A0 =C2=A0- what does it mean 'An IPv6 CE router MUST= advertise itself as a router for the delegated prefix(es) [...] using the = "Route Information Option" specified in Section 2.3 of [RFC4191].= '?=C2=A0 (I am asking because I suspect this requirement is wrong: the = CE Router must certainly not use RIO with these prefixes).

Why is that wrong? It is under "LAN requirements:" and seems to m= ean exactly what Alex says next:

I'm pretty sure using RIOs was to work = around this:



   ULA-5:  An IPv6 CE router MUST NOT advertise itself as a default
           router with a Router Lifetime greater than zero whenever all
           of its configured and delegated prefixes are ULA prefixes
<= /div>


If hosts don't have a default router because of that, then they nee= d to have other sourced knowledge of the site's ULA prefixes reachable = via the router.

I don= 9;t agree with that ULA-5 requirement. The router lifetime in an RA is a st= atement of the router's default router status on the link the RA is sen= t on, not for the whole site.

It would be fine for hosts to default to a CE for a ULA only site. If= they try to send to somewhere else (e.g. a GUA DA they've somehow acqu= ired), the DA route lookup would fail in the CE's default free route ta= ble, and the CE would generate an ICMPv6 Destination Unreachable.

There was a fault with a CPE I lo= oked at back in 2010 where it wouldn't send ICMPv6 Destination Unreacha= bles in this scenario. That caused long IPv6 timeouts. Other CPE would send= an ICMPv6 Destination Unreachable, and the browser would switch to IPv4 al= most immediately.

HappyE= yeballs was effectively motivated by a bug, although it does cover off ICMP= v6 Destination Unreachables not being sent because of ICMPv6 send rate limi= ts, per RFC 4443, 2.4, (f).


>> CE Routers should place the RIO in the RAs on the LAN interface to= have Host route traffic for those prefixes to that Router if they have mul= ti-homed

(Although, not surprisingly, I would like to see RFC8028 mandated too.)

Regards
=C2=A0 =C2=A0 Brian
>>
>>=C2=A0 =C2=A0 =C2=A0Alex
>
> Regards,
> Tim=C2=A0

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mai= lman/listinfo/v6ops
--0000000000009c68300597409e03-- From nobody Wed Nov 13 15:41:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70640120859 for ; Wed, 13 Nov 2019 15:41:32 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=forthnet.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DakayLt05oy0 for ; Wed, 13 Nov 2019 15:41:28 -0800 (PST) Received: from zm-out-02.forthnet.gr (zm-out-02.forthnet.gr [194.219.0.14]) (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 EA13F120848 for ; Wed, 13 Nov 2019 15:41:27 -0800 (PST) Received: from zm-in-02.cloud.forthnet.prv (zm-in-02.cloud.forthnet.prv [10.24.31.16]) by zm-out-02.forthnet.gr (Postfix) with ESMTP id DDD04121927 for ; Thu, 14 Nov 2019 01:41:23 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTP id CEEB6121B55; Thu, 14 Nov 2019 01:41:23 +0200 (EET) X-DSPAM-Result: Spam Authentication-Results: zm-in-02.cloud.forthnet.prv (amavisd-new); dkim=pass (1024-bit key) header.d=forthnet.gr Received: from zm-in-02.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-02.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id 1RlJ_J5jhFXd; Thu, 14 Nov 2019 01:41:23 +0200 (EET) Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTP id 1E390121B5D; Thu, 14 Nov 2019 01:41:23 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.9.2 zm-in-02.cloud.forthnet.prv 1E390121B5D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forthnet.gr; s=zm; t=1573688483; bh=Z+85r+VopbtfYqHnsQReqY74Pu04VLUkerN+KOC8QEA=; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=N1Q1QE5F03CO64CecotgCZfEF/kuzurlky7cEMEeuhRSKar9c/x06RNHIUz34Lx25 /Nms2bbdqTSYGtopzfEd+7KBWzFj6CfAURVQutwipqb+NN5QxIAX/k64Dg40hKbXUw I1biQyaLHYStdRXrNZR1u3a7ubucVnPVgXLRwuOY= X-Virus-Scanned: amavisd-new at zm-in-02.cloud.forthnet.prv Received: from zm-in-02.cloud.forthnet.prv ([IPv6:::1]) by localhost (zm-in-02.cloud.forthnet.prv [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id k60HAeCPoWj5; Thu, 14 Nov 2019 01:41:23 +0200 (EET) Received: from [192.168.1.2] (77.49.254.206.dsl.dyn.forthnet.gr [77.49.254.206]) by zm-in-02.cloud.forthnet.prv (Postfix) with ESMTPA id CA0F7121B55; Thu, 14 Nov 2019 01:41:22 +0200 (EET) References: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> <670c10fd-f010-e3b7-c3c8-08de2dbc06f8@forthnet.gr> <72D242F5-CD98-48CB-AA65-3B866B2D19E1@fugue.com> From: Tassos Chatzithomaoglou Openpgp: preference=signencrypt Autocrypt: addr=achatz@forthnet.gr; keydata= mQENBFPWrY4BCADa9txOlMMGA1PvelU2qfkJ3cIoF+M9wXhSvZTI63FfgZAMWVM/NryJQ74q kiaWFyprgqo2BBk6vWkCw0N8pVwx0Z0sbPisB1fo/zB29cyM0HeB8lnu+Z5AvkfjwekMtGJd 3+tsRwOqdAJpCpJNhS0cVAkk1lIe3i8pdBbbKYJ5VNpBTyi0zL18WRvz9qf8nnP50rQOF8Oc LNCyKrT5S02SonWH5fQDTMVaSDVRvzRLU34pL0WEsIfTQciwg9LhjRpGj6mHxX1OdRHBpHmH WAI05lg7xRwYZq2/X/9Xizd0j9hbr6Ph7oiW7u6e4zAndvPSxXaBVCzpVI0hhaJl11yVABEB AAG0G1Rhc3NvcyA8Y2hhdGFzb3NAeWFob28uY29tPokBPwQTAQIAKQUCU9atjgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG9JgN4loaV7D0kIAKfyVLWFzOfYM0uT m78iJsh9nAaxYiM0t40oF+HY7Cri35FDAzrRjbB0os/KehCz6uuBqDe+3swkVX9bwE9/GsHc Tb5C1IOdvgb2Rp3MfSF1+Ju/3uGtiktQIqZ5YrIZhIjGiwUCVC6ewpC3VRiFVo/HvE23p16y 6Ws9y4xoRNuxs0952twZjT9jwVub8TWm/uES6RERZ68FGA1jVFXtAgMXljP29KcL8zRw9xiY VNI1MgUIRhOKENzpChS+7jZSDWKKD9fwPUNDNPG9kNuXoinRX1g2wlgWKmaBNVBOZMunR20P eVewZ2v35uaiHyzzHw92vjjfxOtpXoW0QFlT5cg= To: v6ops list Message-ID: <554dfc6d-0a29-aa4e-a8ae-57943b02930e@forthnet.gr> Date: Thu, 14 Nov 2019 01:41:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5 MIME-Version: 1.0 In-Reply-To: <72D242F5-CD98-48CB-AA65-3B866B2D19E1@fugue.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 23:41:32 -0000 Ted Lemon wrote on 13/11/19 17:18: > On Nov 13, 2019, at 2:32 AM, Tassos Chatzithomaoglou > wrote: >> We do the same in IPv4 because many subscribers had asked for it. They= wanted to easily (disconnect the line or reboot the CPE) change addresse= s. > > Supposing IPv6 customers ask for this. =C2=A0 Why would you not give it= to them with graceful renumbering rather than flash renumbering? > >> That's mostly a commercial decision. Commercially we want to different= iate static vs dynamic. > > So you are charging customers to not do something that costs you money = and them reliability to do. =C2=A0 Customers who pay you get nothing, and= customers who don=E2=80=99t pay you get what amounts to a punishment. =C2= =A0 I guess that=E2=80=99s your prerogative, but again, if you are going = to do this, why not do it right? =C2=A0Don=E2=80=99t flash renumber=E2=80= =94renumber gracefully. =C2=A0 You still are able to punish customers who= don=E2=80=99t pay you, but you aren=E2=80=99t creating a support problem= for yourself in the process. > I can see a disadvantage (it's a customer choice after all), but not a pu= nishment. As i said in my previous emails, we haven't got any such compla= ints. So, either the customers don't care/understand, or the customers do= n't experience such issues (invalidating the previous prefix at next reco= nnect helps). >> The biggest technical issue i see is routing de-aggregation due to man= y different BRAS serving the same customers. > > So am I to understand that you have many different routes to the custom= er, and no way to be consistent about which route the customer gets when = they disconnect and reconnect? =C2=A0 Isn=E2=80=99t that a problem with t= he BRAS setup? > >> Aggregating at another level is not an option, because we don't want t= o have hundreds of thousands of /56s at this level. > > Absolutely. =C2=A0 But is that your only option? =C2=A0 E.g., if you we= re to just have a route at this level for every customer that had been re= numbered and still needed their old prefix to be routed, would that tend = to be hundreds of thousands? =C2=A0 If so, isn=E2=80=99t that evidence th= at there=E2=80=99s something wrong with your setup? > We do have this for static customers who are a very small percentage. I g= uess for dynamic customers it wouldn't be hundreds of thousands in time t= 0, but i would see it easily increasing to tens of thousands in time t1 (= after few weeks). Not to mention all the routing updates which would move= deeper into the core of the network. That's because our N+1 BRAS cluster= ing scheme has been designed with a simple concept in mind: provide the h= ighest possible availability using the lowest possible budget. By increas= ing the budget, we can have more M+1 (M X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E6E120842 for ; Wed, 13 Nov 2019 16:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 eaAiqRr45Qi5 for ; Wed, 13 Nov 2019 16:02:20 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A9012008D for ; Wed, 13 Nov 2019 16:02:20 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id o11so4688635qtr.11 for ; Wed, 13 Nov 2019 16:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=GOYJLnXQ2KHs77Z2DZWxGVF0W18JfrG+j0SA+wDAm2g=; b=c83Tk83XDfs3X+hTyr1cRyljWm4BaK3GTuLXjaV4zFYJVaX3EFT3B0jCScvyzWxuDH nfyBMQz92MZ3JiLHW0EYr7HAUhHVbg9VRcBUSx/vHr5GmtthzKMOXjXyN/zcL6/JLw6d XngWaOheL2zfZeA1gzAzt5lF8sB3m+zzwNQFnxAbeo4TQuxHU5sy0MpQPRug1Z9bdulm hnwl7h+heeeKI8xMFdZ0nXrhoLfZYMI5HpB2R7MKWbyskTS0bUu61DpyFu3LW9lN29Qt LpHyZIMdKiu6I9gXiDwRxuWHlK1thCQT0klR9crMXXsjRRGBkhWUIlPalDpNPgDETgFB fcjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=GOYJLnXQ2KHs77Z2DZWxGVF0W18JfrG+j0SA+wDAm2g=; b=ZVN+6oKfjazKDZyvsqKYIAqlvlgSMStXsky0dkasTUjru3uDWoAknZj2N+3blYQpSG Z4a5IryzF4Babq0Wv6f45safDgAr1fGYYxH1/MUjUL/5Bzjdx2IC1wQ57W7ZZ4CJExzE rAVeK8GNNlogH/A2d4mozcjCTTSw9PkKEZE3yTGNh6aI6EAeuH3wHe6o/0I4/X7XmXZY DylLinOBKj86ttsTtbo1SQEeRu6msG/d5Tc+400lY0hTsHEEYmJZWACUf6zAroSZz5s4 KZ8ElsriFJXUXvxDwxODjRYyPcnVybvdQbbhIPBIp/JM0ZmqBpqZGgKn1MDvNXwpJRgJ fH0A== X-Gm-Message-State: APjAAAVNhuCkuwRktNe/sAKVmBPbjCjm16o7EHt2cZOVCnMNDXBvAdQW KOyiwfqs5QxFKknWxgV7yfaMxk6CcF3ldA== X-Google-Smtp-Source: APXvYqx9YGWzzuPbI9+GCzcJJVqj1VWuV4ejN8hMMYHIh1ZvvOocaqfrKZyCfmd3JntbTiQBn9Eqrw== X-Received: by 2002:ac8:608:: with SMTP id d8mr5592749qth.258.1573689739567; Wed, 13 Nov 2019 16:02:19 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:b5d9:8475:5209:db41? ([2601:18b:300:36ee:b5d9:8475:5209:db41]) by smtp.gmail.com with ESMTPSA id f6sm1703588qke.16.2019.11.13.16.02.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 16:02:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 13 Nov 2019 19:02:17 -0500 Message-Id: References: <554dfc6d-0a29-aa4e-a8ae-57943b02930e@forthnet.gr> Cc: v6ops list In-Reply-To: <554dfc6d-0a29-aa4e-a8ae-57943b02930e@forthnet.gr> To: Tassos Chatzithomaoglou X-Mailer: iPhone Mail (17B84) Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 00:02:25 -0000 Your lifetimes should not be so long. Graceful renumbering means advertising= two prefixes, one deprecated. You keep the route for the deprecated prefix u= p until the valid lifetime expires. Then you eliminate it. The number of rou= tes should not grow over time.=20 > On Nov 13, 2019, at 18:41, Tassos Chatzithomaoglou wr= ote: >=20 > =EF=BB=BF > Ted Lemon wrote on 13/11/19 17:18: >>> On Nov 13, 2019, at 2:32 AM, Tassos Chatzithomaoglou > wrote: >>> We do the same in IPv4 because many subscribers had asked for it. They w= anted to easily (disconnect the line or reboot the CPE) change addresses. >>=20 >> Supposing IPv6 customers ask for this. Why would you not give it to the= m with graceful renumbering rather than flash renumbering? >>=20 >>> That's mostly a commercial decision. Commercially we want to differentia= te static vs dynamic. >>=20 >> So you are charging customers to not do something that costs you money an= d them reliability to do. Customers who pay you get nothing, and customers= who don=E2=80=99t pay you get what amounts to a punishment. I guess that=E2= =80=99s your prerogative, but again, if you are going to do this, why not do= it right? Don=E2=80=99t flash renumber=E2=80=94renumber gracefully. You s= till are able to punish customers who don=E2=80=99t pay you, but you aren=E2= =80=99t creating a support problem for yourself in the process. >>=20 > I can see a disadvantage (it's a customer choice after all), but not a pun= ishment. As i said in my previous emails, we haven't got any such complaints= . So, either the customers don't care/understand, or the customers don't exp= erience such issues (invalidating the previous prefix at next reconnect help= s). >>> The biggest technical issue i see is routing de-aggregation due to many d= ifferent BRAS serving the same customers. >>=20 >> So am I to understand that you have many different routes to the customer= , and no way to be consistent about which route the customer gets when they d= isconnect and reconnect? Isn=E2=80=99t that a problem with the BRAS setup?= >>=20 >>> Aggregating at another level is not an option, because we don't want to h= ave hundreds of thousands of /56s at this level. >>=20 >> Absolutely. But is that your only option? E.g., if you were to just h= ave a route at this level for every customer that had been renumbered and st= ill needed their old prefix to be routed, would that tend to be hundreds of t= housands? If so, isn=E2=80=99t that evidence that there=E2=80=99s somethin= g wrong with your setup? >>=20 >=20 > We do have this for static customers who are a very small percentage. I gu= ess for dynamic customers it wouldn't be hundreds of thousands in time t0, b= ut i would see it easily increasing to tens of thousands in time t1 (after f= ew weeks). Not to mention all the routing updates which would move deeper in= to the core of the network. That's because our N+1 BRAS clustering scheme ha= s been designed with a simple concept in mind: provide the highest possible a= vailability using the lowest possible budget. By increasing the budget, we c= an have more M+1 (M=20 > -- > Tassos >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 14 04:21:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD1A120025 for ; Thu, 14 Nov 2019 04:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 A4Zfis4bWoel for ; Thu, 14 Nov 2019 04:21:33 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E45120105 for ; Thu, 14 Nov 2019 04:21:33 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAECLUPY031302; Thu, 14 Nov 2019 13:21:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6DCFE2064B6; Thu, 14 Nov 2019 13:21:30 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5F27A2064B4; Thu, 14 Nov 2019 13:21:30 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAECLUca022141; Thu, 14 Nov 2019 13:21:30 +0100 To: Mark Smith Cc: v6ops list References: From: Alexandre Petrescu Message-ID: <26bc5eb7-1581-d83b-12fe-3bc5f230ae3b@gmail.com> Date: Thu, 14 Nov 2019 13:21:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DANIR questions draft-shytyi-v6ops-danir-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 12:21:35 -0000 Le 12/11/2019 à 12:09, Mark Smith a écrit : > > > On Tue, 12 Nov 2019, 20:42 Alexandre Petrescu, > > > wrote: > > Hello participants to v6ops WG, > > With respect to draft-shytyi-v6ops-danir-04, of which I am a > co-author, I would like to ask: > > - do you think it is useful that smartphones run DHCPv6-PD clients > on their 4G interfaces? > > > Broadly yes as that would be a conventional IPv6 router WAN > behaviour. > > Trouble from that perspective with smartphones is how that fits with > 3GPPs worldview. > > > - do you think a router behaviour where it runs a Client DHCPv6-PD > on one side, derive sub-prefixes and subsequently run SLAAC RA on > the other side - has been described somewhere else than in this > DANIR draft? > > > Yes, it is described in RFC 7084. I dont think it's RFC7084. With help, I could find that this might actually come from DHCPv6 RFC 8415, when it says "[typically] client subnets a single delegated /48 prefix into /64 prefixes and assigns one /64 prefix to each of the links in the subscriber network." That behaviour indeed approaches a lot to what we do in the DANIR draft. However - we in DANIR draft propose a Stds Track document that standardizes that behaviour. It is not just an example, or a typical behaviour. > > I think a variation of DHCPv6 between the downstream and upstream > interfaces would be better because a DHCPv6 relay is DHCPv6 option > transparent. > > The combination of a client and a server limits the options that can > be passed between the upstream and downstream interfaces. To support > passing new options, they would have to be upgraded; a DHCPv6 relay > wouldn't. > > IPv6 CE Device DHCPv6 Option Transparency > > https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 I read the introductory parts. It suggests option transparency, under the form of DHCP Relay (even if you say above it's not really the same), to be run in the CE Router. DANIR does not implement Relay functionality in the IoT Router. If/when we do, we will have to use the valuable advice from the option transparency draft (i.e. Relay functionality or similar in CE Router). I speculate, but if we want to put DHCP Relay in an IoT Router, then we might face some problems we already faced when putting DHCPv6 Client in an IoT Router: namely the UDP port blocking by certain modem manufacturers. This leads me to ask: what are the implementation aspects spotted when executing a vanilla DHCP Relay on CE Router? Alex > > > Regards, > > Mark. > > > > Yours, > > Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 14 04:26:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1792B1201A3 for ; Thu, 14 Nov 2019 04:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 N6G-S9aSwha6 for ; Thu, 14 Nov 2019 04:26:33 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94CB120025 for ; Thu, 14 Nov 2019 04:26:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAECQUSa016728; Thu, 14 Nov 2019 13:26:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2AAC620643A; Thu, 14 Nov 2019 13:26:30 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1C54B2039CB; Thu, 14 Nov 2019 13:26:30 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAECQUm4024708; Thu, 14 Nov 2019 13:26:30 +0100 To: Timothy Winters Cc: "v6ops@ietf.org" References: From: Alexandre Petrescu Message-ID: <0dafa657-880e-58eb-4c1c-5d301fa7b418@gmail.com> Date: Thu, 14 Nov 2019 13:26:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 12:26:35 -0000 Le 13/11/2019 à 15:16, Timothy Winters a écrit : > Hi Alex, > > On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu > > wrote: > > Hi, v6opsers, > > While reading through RFC7084 I couldnt find a place where the CE > Router is mandated to put a prefix in the PIO, even though there is > a (strange?) requirement to use RIO. > > I would like to ask: > > - which existing particular requirement the author assumes to be > putting a derived /64 in the PIO in the RA? > > The placing of the prefixes in the PIO from the IA_PD was originally > located in RFC 3633, so it's not covered in 7084. Thanks for the clarification. It is probably the example from DHCPv6 RFC 8415 "[typically] client subnets a single delegated /48 prefix into /64 prefixes and assigns one /64 prefix to each of the links in the subscriber network." RFC7084 doesnt say it, but it refers to RFC8415 who indeed says something close to putting a prefix in a PIO. (it says 'assign to interface', which could be something else than putting a prefix in the PIO). > - what does it mean 'An IPv6 CE router MUST advertise itself as a > router for the delegated prefix(es) [...] using the "Route > Information Option" specified in Section 2.3 of [RFC4191].'?  (I am > asking because I suspect this requirement is wrong: the CE Router > must certainly not use RIO with these prefixes). > > CE Routers should place the RIO in the RAs on the LAN interface to have > Host route traffic for those prefixes to that Router if they have > multi-homed. I think I agree: if CE Router is multi-homed to two ISPs, each with its own ULA space for a content server then the CE Router might want to put these spaces in distinct RIO options in same RA sent by CE Router on LAN. However, the draft does not read that way. The RIO requirement is placed right after a requirement talking about deriving prefixes. IT made me thing it wants the derived prefixes in the RIO (should be in the PIO). I am not asking clarification, I am not asking for Errata. But I do not agree to say that that RFC is clear. Alex > > Alex > > Regards, > Tim > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 14 04:50:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9F4120857 for ; Thu, 14 Nov 2019 04:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 QZ9ATaM7L2M3 for ; Thu, 14 Nov 2019 04:50:00 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D01120824 for ; Thu, 14 Nov 2019 04:50:00 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAECnwsc000713; Thu, 14 Nov 2019 13:49:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 00D522064E7; Thu, 14 Nov 2019 13:49:58 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E685620652A; Thu, 14 Nov 2019 13:49:57 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAECnvHT006047; Thu, 14 Nov 2019 13:49:57 +0100 To: Brian E Carpenter Cc: Timothy Winters , "v6ops@ietf.org" References: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> From: Alexandre Petrescu Message-ID: <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com> Date: Thu, 14 Nov 2019 13:49:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 12:50:04 -0000 Brian, Thanks for the reply. Le 13/11/2019 à 20:39, Brian E Carpenter a écrit : > On 14-Nov-19 03:16, Timothy Winters wrote: >> Hi Alex, >> >> On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu >> > > wrote: >> >>> Hi, v6opsers, >>> >>> While reading through RFC7084 I couldnt find a place where the >>> CE Router is mandated to put a prefix in the PIO, even though >>> there is a (strange?) requirement to use RIO. >>> >>> I would like to ask: >>> >>> - which existing particular requirement the author assumes to be >>> putting a derived /64 in the PIO in the RA? >> >> The placing of the prefixes in the PIO from the IA_PD was >> originally located in RFC 3633, so it's not covered in 7084. > > More to the point of Alex's question, 7084 says: > >>>> The IPv6 CE router MUST support router behavior according to >>>> Neighbor Discovery for IPv6 [RFC4861]. > > which therefore requires properly formed PIOs. It is clear to certain readers. But to me it is a long stretch. It is a long stretch to consider RFC7084 ref to RFC4861 to consider that RFC7084 requires prefixes be present in the PIO. For one, RFC7084 also refers to DHCPv6 RFC, which in turns talks about 'assigning a prefix to an interface', and not about putting a prefix in the PIO. In practice, assigning a prefix to an interface does not mean putting it in the PIO in the RA. It means to add a particular kind of entry in the routing table for that prefix and that interface. Second, RFC4861 never talks about 'assigning a prefix to an interface'. Where RFC4861 assigns something it is either addresses to interfaces (not prefixes), or numbers at IANA. >>> - what does it mean 'An IPv6 CE router MUST advertise itself as >>> a router for the delegated prefix(es) [...] using the "Route >>> Information Option" specified in Section 2.3 of [RFC4191].'? (I >>> am asking because I suspect this requirement is wrong: the CE >>> Router must certainly not use RIO with these prefixes). > > Why is that wrong? It is under "LAN requirements:" and seems to mean > exactly what Alex says next: > >>> CE Routers should place the RIO in the RAs on the LAN interface >>> to have Host route traffic for those prefixes to that Router if >>> they have multi-homed a. reading L-2 after L-3 makes think (IMHO) that the prefix derived from the delegated prefix would be put in the RIO. That is wrong. It should be put in the PIO, not in the RIO. b. L-3 "[on LAN] CE router MUST advertise itself as a router for the delegated prefix(es)" is wrong in many readings I could try. The right statements are: - CE router MUST advertise itself as a router for reaching the Internet. - CE router MUST put in PIO in RA some prefix useful for SLAAC; this prefix is obtained out of the delegated prefix, or elsewhere. this prefix MUST NOT be the delegated prefix. - CE router MUST NOT advertise itself as a router for the delegated prefix(es); it is the router situated in the ISP premisses that must do that. > (Although, not surprisingly, I would like to see RFC8028 mandated> > too.) I think RFC8028 sounds in context: "First-Hop Router Selection in a Multi-Prefix Network". However, I am not sure where RFC8028 would apply: is it between the CE Router and the two ISPs? Or is it between in-house Host and the single CE Router? Alex > > Regards Brian >>> >>> Alex >> >> Regards, Tim > From nobody Thu Nov 14 07:46:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B87A120896 for ; Thu, 14 Nov 2019 07:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 bWh7Zup_UYNB for ; Thu, 14 Nov 2019 07:46:15 -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 A43181208A8 for ; Thu, 14 Nov 2019 07:46:15 -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 xAEFkE6r003953 for ; Thu, 14 Nov 2019 16:46:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F13D120802D for ; Thu, 14 Nov 2019 16:46:13 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E69F1208029 for ; Thu, 14 Nov 2019 16:46:13 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAEFkDtr009172 for ; Thu, 14 Nov 2019 16:46:13 +0100 To: v6ops@ietf.org References: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com> From: Alexandre Petrescu Message-ID: <858c9dc2-374c-41a3-5726-90794c6af1f3@gmail.com> Date: Thu, 14 Nov 2019 16:46:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 15:46:19 -0000 It boils down to distinct intepretations of these terms: - a router _advertises_ itself as a router for prefix A: - does it mean it puts A in PIO in Router Advertisement? - does it mean it puts A in Link-State Advertisement of OSPF? - does it mean that some other router has a route for that prefix A pointing to this router? - a prefix is 'assigned' to an interface: - does it mean the ifconfig add address/prefix was run on that interface? - does it mean that the prefis is put in the RA in PIO put on that interface? There are other difficulties with other terms, such as 'delegate prefix', 'subnetted prefix' and 'assigned prefix'. I propose that we clarify these. Alex Le 14/11/2019 à 13:49, Alexandre Petrescu a écrit : > Brian, > > Thanks for the reply. > > Le 13/11/2019 à 20:39, Brian E Carpenter a écrit : >> On 14-Nov-19 03:16, Timothy Winters wrote: >>> Hi Alex, >>> >>> On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu >>> > >>> wrote: >>> >>>> Hi, v6opsers, >>>> >>>> While reading through RFC7084 I couldnt find a place where the >>>> CE Router is mandated to put a prefix in the PIO, even though >>>> there is a (strange?) requirement to use RIO. >>>> >>>> I would like to ask: >>>> >>>> - which existing particular requirement the author assumes to be >>>> putting a derived /64 in the PIO in the RA? >>> >>> The placing of the prefixes in the PIO from the IA_PD was originally >>> located in RFC 3633, so it's not covered in 7084. >> >> More to the point of Alex's question, 7084 says: >> >>>>> The IPv6 CE router MUST support router behavior according to >>>>> Neighbor Discovery for IPv6 [RFC4861]. >> >> which therefore requires properly formed PIOs. > > It is clear to certain readers.  But to me it is a long stretch.  It is > a long stretch to consider RFC7084 ref to RFC4861 to consider that > RFC7084 requires prefixes be present in the PIO. > > For one, RFC7084 also refers to DHCPv6 RFC, which in turns talks about > 'assigning a prefix to an interface', and not about putting a prefix in > the PIO. > > In practice, assigning a prefix to an interface does not mean putting it > in the PIO in the RA.  It means to add a particular kind of entry in the > routing table for that prefix and that interface. > > Second, RFC4861 never talks about 'assigning a prefix to an interface'. >  Where RFC4861 assigns something it is either addresses to interfaces > (not prefixes), or numbers at IANA. > >>>> - what does it mean 'An IPv6 CE router MUST advertise itself as >>>> a router for the delegated prefix(es) [...] using the "Route >>>> Information Option" specified in Section 2.3 of [RFC4191].'?  (I am >>>> asking because I suspect this requirement is wrong: the CE Router >>>> must certainly not use RIO with these prefixes). >> >> Why is that wrong? It is under "LAN requirements:" and seems to mean >> exactly what Alex says next: >> >>>> CE Routers should place the RIO in the RAs on the LAN interface to >>>> have Host route traffic for those prefixes to that Router if they >>>> have multi-homed > > a. reading L-2 after L-3 makes think (IMHO) that the prefix derived from >    the delegated prefix would be put in the RIO.  That is wrong.  It >    should be put in the PIO, not in the RIO. > > b.  L-3 "[on LAN] CE router MUST advertise itself as a router for the >     delegated prefix(es)" is wrong in many readings I could try. >     The right statements are: >    - CE router MUST advertise itself as a router for reaching the >      Internet. >    - CE router MUST put in PIO in RA some prefix useful for SLAAC; >      this prefix is obtained out of the delegated prefix, or elsewhere. >      this prefix MUST NOT be the delegated prefix. >    - CE router MUST NOT advertise itself as a router for the delegated >      prefix(es); it is the router situated in the ISP premisses that >      must do that. > >> (Although, not surprisingly, I would like to see RFC8028 mandated> >> too.) > > I think RFC8028 sounds in context: "First-Hop Router Selection in a > Multi-Prefix Network". > > However, I am not sure where RFC8028 would apply: is it between the CE > Router and the two ISPs?  Or is it between in-house Host and the single > CE Router? > > Alex > >> >> Regards Brian >>>> >>>> Alex >>> >>> Regards, Tim >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 14 08:43:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E066120878 for ; Thu, 14 Nov 2019 08:43:10 -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_HELO_NONE=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 EkSs5gzTugOr for ; Thu, 14 Nov 2019 08:43:09 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73A012087D for ; Thu, 14 Nov 2019 08:43:08 -0800 (PST) Received: from astfgl.hanazo.no (unknown [38.98.37.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 975BF4E11A4F; Thu, 14 Nov 2019 16:43:06 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id BDE9F22D95C8; Fri, 15 Nov 2019 00:42:59 +0800 (+08) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: Date: Fri, 15 Nov 2019 00:42:59 +0800 Cc: Tassos Chatzithomaoglou , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <6DD7FBFA-A95B-43C0-97CF-6A408DC288D5@employees.org> References: <554dfc6d-0a29-aa4e-a8ae-57943b02930e@forthnet.gr> To: Ted Lemon X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:43:10 -0000 > Your lifetimes should not be so long. Graceful renumbering means = advertising two prefixes, one deprecated. You keep the route for the = deprecated prefix up until the valid lifetime expires. Then you = eliminate it. The number of routes should not grow over time.=20 Actually that's not quite what graceful renumbering means, since it = wouldn't be so graceful if you did it that way. Basically it's two valid prefixes overlapping. Where you ensure no new = sessions use it by letting preferred lifetime go to zero, and ensure = that the deprecated timers doesn't expire before after the longest = expected session lifetime has passed. Cheers, Ole= From nobody Thu Nov 14 10:16:53 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9048D120108 for ; Thu, 14 Nov 2019 10:16:52 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU8N8vnq2RTL for ; Thu, 14 Nov 2019 10:16:50 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4C6120100 for ; Thu, 14 Nov 2019 10:16:50 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id f19so4275764pgk.11 for ; Thu, 14 Nov 2019 10:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W6+L5p6sCuKeS4wTRKbMp3VLzZmRFURJ02R0/kMy1VU=; b=ECIFzUNp2CivohgS1YsYivjQehJ6adtESjwLy1XljwqRGCgWeGg/ifaqvLmHg7JExM A/dq/HjXULrnaHatTN/6rHUk0eFR5j8e3T8CM45HnYou0ByDqc5vE4NZnKFAdONJgrzu Tu0VpQxB3hOq2Y5ygmk++vT4mp1Hpktah56bUG/lYgliYKixSwSl6UgmiCKwUyNgCLE6 JZGtqKY66NHewSQEmhd9M3rToXIWySY32RKTP+R/ZFbVkWNP01mqCxyuoPJ+lLXlPuoe T3xq58kN6VcGBJp/GOt/t5m9tEFgn/R1z7MQ9KKczi7qTv4gVqc3jnLLmt9eKLIy69Qr /DMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=W6+L5p6sCuKeS4wTRKbMp3VLzZmRFURJ02R0/kMy1VU=; b=cmCk1pH5/mzcWJk7OvjecE5yAsMTPdsjKBFfCJINKgUfu5zSt6WAe3enydmW4dXw9x DZYR0QxOJRiQumb6JQmI1Xgm/XrQJ9yEzmcoVtYVnuXGhV6qLRlSUud0kgbWvAapAxBV kMT3d88YP2lbaB7er7NqDZimTnHnVmc53beOqeIIYYgKiZ4aX9R0ZqCw6HpBFkDjmPNg Qfu9FOWEhCDxJ39D9lWAWbqYb1KycaX5/AP3M970h1wi7+tuOJMHLAzHWQGTZgvNndy5 JBRORjH8qI3btN7FXENXZRAHFzYOOg8XMkzwSKdGylEbGQO6HrpT8evVWBBea3K2N58p 7P5g== X-Gm-Message-State: APjAAAXlQQuUhQ/lwyOysKIHxvB81Jv7CKcjeFxDZCOLheULv5/gsP4L Pj+6b7i9UapGLgDae8lX9wQVvKjc X-Google-Smtp-Source: APXvYqzItWh3Nz7IHsH63PdHBDjbD3a9IZftWM+HINMbY6TaB8kzOGfUWsEmoRZsJbLnZ2DjD0szRQ== X-Received: by 2002:a17:90a:86c3:: with SMTP id y3mr14251558pjv.102.1573755409419; Thu, 14 Nov 2019 10:16:49 -0800 (PST) Received: from [192.168.178.21] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id z10sm7077740pgg.39.2019.11.14.10.16.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Nov 2019 10:16:48 -0800 (PST) To: Alexandre Petrescu Cc: Timothy Winters , "v6ops@ietf.org" References: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com> From: Brian E Carpenter Message-ID: <4568b864-ceff-f2d5-6941-638dd9d10027@gmail.com> Date: Fri, 15 Nov 2019 07:16:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 18:16:53 -0000 On 15-Nov-19 01:49, Alexandre Petrescu wrote: ... > I think RFC8028 sounds in context: "First-Hop Router Selection in a > Multi-Prefix Network". > > However, I am not sure where RFC8028 would apply: is it between the CE > Router and the two ISPs? Or is it between in-house Host and the single > CE Router? It is only useful in the case of *more than one* CE Router. As far as I know, that is not illegal. Brian From nobody Thu Nov 14 15:17:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19315120059 for ; Thu, 14 Nov 2019 15:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 HHH5u9H9SyzP for ; Thu, 14 Nov 2019 15:17:22 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::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 C6650120058 for ; Thu, 14 Nov 2019 15:17:22 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id d22so3925oic.7 for ; Thu, 14 Nov 2019 15:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zeTiAa+pUcTeeMyHVk+eqtWgm9Tc0FzZJsahcYcd19U=; b=jqn/43wArtEXmd7Qn7MGErHqQbe3L8ErR8xvFM1WTfLdlb3QMxlNxihYyKFmlEINvC HpoxcM4ALVRdxRY1Y2vtBcpUtDaokt/y2WNo/PNjmvxw79OEnLTiwLRpLXFgUpxPEMZt HFX5S5tGwYBET/7YgNWN/wYdhH6l3EdzMyqlKWNQABWi6I9SvkVBoUo4ML16gqRh1zik SvRGvZtzjJ3hN7TP8qzW0hQmcqiFM6Dq/owq5SpG7CiLZ/VbH5ni+HCOHUSh2eURcuTa H/hGTiUFE6N7K8c1fS+J8RvKtwI61whACX08nYoP+qJjisq/QVkHfxbzF2/3yjK85rjA Bzag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zeTiAa+pUcTeeMyHVk+eqtWgm9Tc0FzZJsahcYcd19U=; b=rv/CsU24Q+16Ax9NoUEg6MdPaFS0MCclXnkzBJc3ALvVZ9ETAZDWHwVKoVxFX/SCxw T356SUtf0TwVg9p1e3KVEmZP/U39sdd7/C28J+mxr3X9MCTDuHm08KZnu5nY+sdWLdFw 6egreUHrIT9DmGHgWKDYb9xUkqKCx4lIs7r69SmMrCaqHlS/yLVbiUErKcr2H517BbM0 o46lLKZlbZEbDAvXKfkoy430zpTJ6x7lx7hYt+yVnNDluUsj1PdO82NRDiqqBUN5hdNd aMRdr7+uk6Q2og0R05Sb0EIHNslQDUaWM75ts0G4GtJdqJStCe/qb7jmFDM0B5lLnu6d qqZw== X-Gm-Message-State: APjAAAW/5/tmhPa4TmyzC6Cyyx7WHra1hk773VLOMGgRMiUXlgApUlff rCHKT1IBUXVLHjogaGcxjxlRWLa9TS6pj4+f9qU= X-Google-Smtp-Source: APXvYqxQVYE4CL8VM7IHN65YryoEJQ1+NdEXdv0kQoPLHvpNcLzpgHhGJBjgRBJ1UBd0vA57CdzlqCTDUPuGUMhbyaU= X-Received: by 2002:aca:f553:: with SMTP id t80mr5510234oih.60.1573773441943; Thu, 14 Nov 2019 15:17:21 -0800 (PST) MIME-Version: 1.0 References: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com> <4568b864-ceff-f2d5-6941-638dd9d10027@gmail.com> In-Reply-To: <4568b864-ceff-f2d5-6941-638dd9d10027@gmail.com> From: Mark Smith Date: Fri, 15 Nov 2019 10:17:08 +1100 Message-ID: To: Brian E Carpenter Cc: Alexandre Petrescu , v6ops list Content-Type: multipart/alternative; boundary="000000000000f6cf68059756ae39" Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 23:17:24 -0000 --000000000000f6cf68059756ae39 Content-Type: text/plain; charset="UTF-8" On Fri, 15 Nov 2019, 05:17 Brian E Carpenter, wrote: > On 15-Nov-19 01:49, Alexandre Petrescu wrote: > .... > > I think RFC8028 sounds in context: "First-Hop Router Selection in a > > Multi-Prefix Network". > > > > However, I am not sure where RFC8028 would apply: is it between the CE > > Router and the two ISPs? Or is it between in-house Host and the single > > CE Router? > > It is only useful in the case of *more than one* CE Router. As far as > I know, that is not illegal. > I think it is a good idea to always imagine two or more router scenarios. It helps prevent solutions being designed that will only work or only easily work with one router. Redundancy is constantly getting cheaper to have, may as well make it easy to use. (I have two routers on my LAN at home, current one IPv4 only, the other IPv6 only. The IPv4 only router does have a dynamic IPv6 /64 for the LAN interface if I wanted to use it - although marginal benefit, as from the same ISP over the same ADSL link.) > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000f6cf68059756ae39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 15 Nov 2019, 05:17 Brian E Carpenter, <brian.e.carpenter@gmail.com&= gt; wrote:
On 15-Nov-19 01:49, Alex= andre Petrescu wrote:
....
> I think RFC8028 sounds in context: "First-Hop Router Selection in= a
> Multi-Prefix Network".
>
> However, I am not sure where RFC8028 would apply: is it between the CE=
> Router and the two ISPs?=C2=A0 Or is it between in-house Host and the = single
> CE Router?

It is only useful in the case of *more than one* CE Router. As far as
I know, that is not illegal.
=
I think it is a good idea to always imagine two= or more router scenarios. It helps prevent solutions being designed that w= ill only work or only easily work with one router.
<= br>
Redundancy is constantly getting cheaper to have= , may as well make it easy to use.

(I have two routers on my LAN at home, current one IPv4 only, th= e other IPv6 only. The IPv4 only router does have a dynamic IPv6 /64 for th= e LAN interface if I wanted to use it - although marginal benefit, as from = the same ISP over the same ADSL link.)



=C2=A0 =C2=A0Brian

_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000f6cf68059756ae39-- From nobody Fri Nov 15 01:57:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAEF1201CE for ; Fri, 15 Nov 2019 01:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 BUih1bVucB3t for ; Fri, 15 Nov 2019 01:57:44 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92079120143 for ; Fri, 15 Nov 2019 01:57:44 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAF9vfIe027181; Fri, 15 Nov 2019 10:57:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 82FC4206714; Fri, 15 Nov 2019 10:57:41 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 730FE202770; Fri, 15 Nov 2019 10:57:41 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAF9vfGl019966; Fri, 15 Nov 2019 10:57:41 +0100 To: Brian E Carpenter Cc: Timothy Winters , "v6ops@ietf.org" References: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com> <4568b864-ceff-f2d5-6941-638dd9d10027@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 15 Nov 2019 10:57:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <4568b864-ceff-f2d5-6941-638dd9d10027@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2019 09:57:47 -0000 Le 14/11/2019 à 19:16, Brian E Carpenter a écrit : > On 15-Nov-19 01:49, Alexandre Petrescu wrote: > ... >> I think RFC8028 sounds in context: "First-Hop Router Selection in a >> Multi-Prefix Network". >> >> However, I am not sure where RFC8028 would apply: is it between the CE >> Router and the two ISPs? Or is it between in-house Host and the single >> CE Router? > > It is only useful in the case of *more than one* CE Router. As far as > I know, that is not illegal. I think too that a design of the home network should allow for more than one CE Router. Some home networks do that. For that it makes sense to require the use of RFC8028. However, I am not sure how to express the need of RIO. There might be no need of the use of RIO if there is only one CE Router, because that is the default router for Hosts in home. As such, it is strange that RFC7084 requires RIO without telling why. If there are two CE Routers, I am not sure how to fit the use of RIO. If RIO _is_ used in the context of two CE Routers, then there are certainly some requirements on how to use them, in combination with the default router capability, and with a requirement to avoid large loops cross-ISPs. There might be a case where only one of the CE Router is the default router for Hosts at home, and thus it must not use RIO. The other CE Router must use RIO but must not advertise itself as a default router. There might be a case where both CE Routers are default routers for Hosts at home, but each advertises in PIO a distinct prefix. In that case, there is no need of RIO at all. Then, there might be cases where there are 3 CE Routers, or more. That would need to be described as well. Alex From nobody Fri Nov 15 01:59:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397991201CE for ; Fri, 15 Nov 2019 01:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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_MED=-2.3, SPF_HELO_NONE=0.001, 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 ApMxClRGEccq for ; Fri, 15 Nov 2019 01:59:28 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76514120143 for ; Fri, 15 Nov 2019 01:59:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAF9xQQm027966; Fri, 15 Nov 2019 10:59:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 495FE20690C; Fri, 15 Nov 2019 10:59:26 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 38F4C206905; Fri, 15 Nov 2019 10:59:26 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAF9xQer021199; Fri, 15 Nov 2019 10:59:26 +0100 To: Mark Smith , Brian E Carpenter Cc: v6ops list References: <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com> <4568b864-ceff-f2d5-6941-638dd9d10027@gmail.com> From: Alexandre Petrescu Message-ID: <61dcf7bc-b9be-23a9-07e4-cd11687b2b6a@gmail.com> Date: Fri, 15 Nov 2019 10:59:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2019 09:59:30 -0000 Le 15/11/2019 à 00:17, Mark Smith a écrit : [...] > (I have two routers on my LAN at home, current one IPv4 only, the other > IPv6 only. The IPv4 only router does have a dynamic IPv6 /64 for the LAN > interface if I wanted to use it - although marginal benefit, as from the > same ISP over the same ADSL link.) I think that behaviour should be put in an RFC. It is what is used. We should describe first and more of what is used, than what we think might be used. Alex > > > >    Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Nov 17 00:37:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484FF1200D5 for ; Sun, 17 Nov 2019 00:37:24 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzeTRHoYXW9k for ; Sun, 17 Nov 2019 00:37:23 -0800 (PST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8611200E9 for ; Sun, 17 Nov 2019 00:37:22 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id a16so617887pjs.13 for ; Sun, 17 Nov 2019 00:37:22 -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=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=phvgD9Ub9GtfZj7IEQivB+H26YaIRpFw3EzjK60rWE3Z1pHzblms1Oq+Rt5kPfnj34 LEKtLTWd+4BqsG1xsZnLsq7nX8AKB/KGSg/9zpBtpKF5EC3OHScqO6KBdG6Oth1U4Ole yvo5FokTzbxEkNEg9J4w0N8w6kPt70Wtuhfb9Zg2jwnriwm46u0aMrRCf+WkLUavM1cB qz1i0rN1W50+nFEC90ElU7H1+ASbYm9WPcHlMEo5cCv53+n0baYmqcK+VrwEDz85SLY2 oD/xJdW01ffFbJE3hJkKJhTWXBOTKdxjT0do6kYu21jTV9H00JwyQnh97ol2LRrwkzJn 1fIw== 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=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=HlXZlVnhcww6EmcCDZc6GhXO7IlwXcj//2+9LRG3c+OZTTKrMgwsDnbwmRLBUEHITk sGnuw3up2XUW0wNxv/t0lFSRUeL15IS9S54bDVe0f27KAeWZji9DDYeHqNXH40xWp67s 2nCTQTcx0bQU7lyK8cNjFp4O0WVIB9UHK85jn1+LvmOy6ZJCelYY4wIsCnqY5f6ONdl/ 2GoWUqoOkOlP7uJPKH/8L9Tif67pFWHonc8hVCNjsqjMWNzs+cQkUELP5cmtZoRmlDKu y5xKfSUZ2UWvXieN98PG0s0YvBSz9oq8F/Ew+vjFo7/g+0E9AHeMA+Oev8vNLo22XR60 R6yA== X-Gm-Message-State: APjAAAWj8heIWAVA19rZ+ZebjYwA2/4vGfcQBr2a9/sf7lGK7Rkgorp1 i+JB+6k9JdIxJ7666Pb22o7c3epohTw= X-Google-Smtp-Source: APXvYqwGnPoFNGz0QPgrkuSVVTVcpje5t6uMk0thienj4XYr+vCLQUryfxDt0sCxKApIz9Gp8t+JSg== X-Received: by 2002:a17:902:8497:: with SMTP id c23mr22074690plo.209.1573979842338; Sun, 17 Nov 2019 00:37:22 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:f9c9:79a9:2f7c:8c7e? ([2001:67c:370:128:f9c9:79a9:2f7c:8c7e]) by smtp.gmail.com with ESMTPSA id g3sm15967426pfo.82.2019.11.17.00.37.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 00:37:21 -0800 (PST) From: Fred Baker Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Message-Id: Date: Sun, 17 Nov 2019 16:37:20 +0800 To: v6ops list X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: [v6ops] Looking for a jabber scribe and a minute taker X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 08:37:24 -0000 From nobody Mon Nov 18 06:30:19 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459731201DB for ; Mon, 18 Nov 2019 06:30:18 -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, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 WZst7ZsySXyf for ; Mon, 18 Nov 2019 06:30:17 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83097120105 for ; Mon, 18 Nov 2019 06:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1574087413; x=1574692213; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=BA58wHpm6Sy3/OpDEDasg zsBjUsR5XXoCmH6KiWcKuc=; b=Q/WtimwAB6/1YlHMSAdIiHlIrXMHCafn8Ydd9 xnQrfvUKOLQK7A/6zYxM7EiLigHQF9eb+05zXW38SV+sreUH9W8SwwD5yUsvGTpm YZTlxSfRY8MXhin17al7ET23UJvaEC/0phsf4Q5naG4RX+Z1gt8w8A57p/m6FD6x r8grTM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 18 Nov 2019 15:30:13 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 18 Nov 2019 15:30:13 +0100 Received: from [172.20.4.214] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006471788.msg for ; Mon, 18 Nov 2019 15:30:12 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [172.20.4.214] X-MDArrival-Date: Mon, 18 Nov 2019 15:30:12 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=122534dadc=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.1f.0.191110 Date: Mon, 18 Nov 2019 22:30:02 +0800 From: JORDI PALET MARTINEZ To: Message-ID: <4727C58E-8A79-43C1-9ED6-27D5FB6D5628@consulintel.es> Thread-Topic: draft-palet-v6ops-464xlat-opt-cdn-caches impact on DNS privacy Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches impact on DNS privacy X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 14:30:18 -0000 Hi all, Jared and Fred have asked the same question during the WG meeting, for different scenarios. We have described this under section 4.2.12 (foreign DNS), and we believe that it is not an issue. Anyway, here is a short clarification on that. a) If a device/app is not using the DNS proxy from the CE, the optimization will not be done for that device/app. The EAMT entry will not be created. b) Consequently, the same apply if we are talking about DNS privacy (DoT, DoH, DoQ, etc.). c) If the DNS is modified (even if not using DNS privacy) in the OS, will not have impact for the same reasons, and even less when we are talking about a dual-stack OS. Remember that we only create the EAMT if an IPv4-only device is detected using the CLAT+DNS proxy. If a dual-stack devices is being detected as IPv4-only, the result is the same as if the device is using IPv6. Even if the device uses HE to fall back from IPv6 (because IPv6 is not working) to IPv4, the device will not be able to connect neither with IPv4 or IPv6, because the access is IPv6-only (this is described in section 4.2.11). d) If the user modify the DNS in the CE, the optimization is not affected, because it doesn't requires using the ISP DNS, it is based in using the CE DNS proxy. e) You can imagine combinations of the above scenarios and the result is the same. Either the optimization is not done, or not affected, but I don't think there is any negative impact. Now, how it changes all this if the scenario is not a residential user with a CE, but an enterprise? We didn't considered this a different case, because I think the enterprise will be c or d above, or both of them. In fact, it may happen that the enterprise router is not supporting the optimization, or it has been disabled via GUI or CLI. If the enterprise is already doing something to avoid DNS privacy, because the optimization is not "changing" the way a "foreign DNS" is working, we don't impact on that. The optimization is based only in using the CE DNS proxy. Enterprises, unless they are SMEs, typically will have their own DNS proxy, so no optimization is performed. This is not a big impact, because the "main" target of the optimization is not an old STB or SmartTV uses from time to time in an enterprise, but the massive residential users (which are the ones, in general, creating more traffic to the CDNs from IPv4-only devices). Does it makes sense? Fred, others, if you believe the way enterprises are trying to avoid DNS privacy may impact this, can you point to specific documents? Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From fhfrediani@gmail.com Wed Nov 20 07:27:41 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46A8120024 for ; Wed, 20 Nov 2019 07:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVChIas2rpjw for ; Wed, 20 Nov 2019 07:27:39 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81092120013 for ; Wed, 20 Nov 2019 07:27:39 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id y10so29346035qto.3 for ; Wed, 20 Nov 2019 07:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=0JJk4EUTTvLlKlwLs2ahl/bK+yi2dWhGCbWgnzQO7e8=; b=usjb2svcfaJSuBsf0znVmnfsd30H3P+iCGOoWfZU35ZmemI/ARqSGa37qyfxZ44NPm JggQOwvilpMWYAJLd60A/WhOL226SCnhxkNOAOZ0vtBaYrbuQoYpxIBbRJW+6HFigIUv BOGjiE5tyaT+ENnq7MAsi4ZOtgeRznP5/CuZFl00N7ApV1k1PaH+iJSnYFkq+fr9YrGe Z5giy/hRkppPBn+fTZJAHjIt2i9DWWq8+EjeBJ4kwuuABwCOvMjKh8VXFbd8RoH+tvOn nynwXlECLgQNRHMIuy14utD875ZZcLYBA0iwFpkMKf/eumRvHEjFTcvW8FUI9xTBpOwv iOjQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=0JJk4EUTTvLlKlwLs2ahl/bK+yi2dWhGCbWgnzQO7e8=; b=hIfQ2AiOhmev1NEdPddrF3uQBid3m3UI1LSQKAZdjafcs1bSGumMREY4/J4g46lRPA P101O+L8vIwJ1/oS31MRQ4VzTi3wGZ8JQDXzwAPvZcDH00/ifUnPliWw+vL+rEWpP073 kBha68CFhU1i1F9yEy76o4dTV7wM92urVJbXOJB3IOqqNfTaVgJYmbkiPJN3W4IpLyQ+ cVvUD2h2Ec6kfXR9/iFuvvyIy7BQUUEwMk8vhkaoN8tvxeyl9hBx5vbZbqYsoZu+c4At WYRImW7i2G8H5FtJcEDfPCp4/9uj7lveAfsc5r3T0PXPhmIi5RA7t8+/ouW4IcOaII4C hWrw== X-Gm-Message-State: APjAAAUFArvNmu8bG+7lHoBCo3BYQH43A122swmPgzcUhucngOz9aH35 w53DQBh2XRA+YUR9W3XkNpJczs87 X-Google-Smtp-Source: APXvYqylGCWtKXvnMuPXcZX03dEoLWoKxzedpZDxiHW7MJCaW3euJpDs0Fe7cdEYy8fg7Lje3BUy9Q== X-Received: by 2002:ac8:424d:: with SMTP id r13mr3199762qtm.111.1574263658183; Wed, 20 Nov 2019 07:27:38 -0800 (PST) Received: from ?IPv6:2804:368:9:8000:38b2:644d:3e6a:ed92? ([2804:368:9:8000:38b2:644d:3e6a:ed92]) by smtp.gmail.com with ESMTPSA id 70sm11824645qkj.48.2019.11.20.07.27.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Nov 2019 07:27:37 -0800 (PST) To: v6ops@ietf.org References: <8BD93428-0C75-446E-9E01-699D63B8FE66@delong.com> <30a305bf-2599-2547-d497-871b8e242a94@si6networks.com> From: Fernando Frediani Message-ID: Date: Wed, 20 Nov 2019 12:27:34 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <30a305bf-2599-2547-d497-871b8e242a94@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] V6ops status as of this morning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 21:01:21 -0000 I want also to support the working group adoption of both drafts and agree Fernando has done a great job in identifying these issues. They are very present in several situations in operations for ISPs and due to these issues it unfortunately helps damaging the credibility of IPv6 and its adoption by those who are still reluctant to do. Talking to several colleagues that work on day by day ISP operations they were able to report exactly what Fernando identified and present in some opportunities. If nothing is done right now at some point these issues will come back in a higher level that will cost a lot no only for IPv6 itself, but for operation that has been having issues related. Therefore the issues must be addressed in some way and I believe what is proposed is on the correct way. Best regards Fernando Frediani > Subject: Re: [v6ops] V6ops status as of this morning > Date: Mon, 11 Nov 2019 16:48:21 -0800 > From: Owen DeLong > To: Fernando Gont > CC: IPv6 Operations > > Fred, > > I support working group adoption of both drafts. > > Fernando has done an excellent job of capturing the issues at hand and > several common sense and rational improvements that could help to > mitigate them. > > Further, the reception and comments on the drafts in the context of the > NANOG mailing list, while perhaps not “admissible” as WG support should > be viewed as input from the operational community to the greatest extent > possible under IETF policies and procedures. > > As you may well know, participation in the IETF by operators has long > been a difficult road. First, the IETF core and Operators often have > quite opposing points of view on what is needed for a network. Operators > often have little understanding of what is required to develop silicon > solutions, fast forwarding, an the software to support it. Conversely, > vendors and others in the IETF often have very limited perspective on > the day to day realities of operating an ISP or other significant > internet operation. > > Both sides would benefit from extensive effort to listen to each other > in a meaningful way as the combined expertise is required to produce > useful solutions. Unfortunately, operators that attempt participation in > IETF are often met with vitriolic comments such that only the thickest > of skins are able to remain long enough to make significant contributions. > > Sadly, the same is true of what happens to engineers who poke their > heads into operational fora. > > We can all do better in this area. > > Owen > > >> On Nov 11, 2019, at 03:19 , Fernando Gont wrote: >> >> Fred, >> >> On 9/11/19 21:50, Fred Baker wrote: >>> As I have said before, I am looking for supportive comment on the mailing list of your drafts. >> we never asked that question. Some folks have gone ahead and expressed >> support of the drafts. However, as authors we just asked for feedback on >> the document(s) -- and that's what most of the discussion has been about. >> >> >> >>> I saw that you sent a note to Nanog, and some replied copying the v6ops list. >>> >>> At the meeting a week or so hence, I have put you on the agenda to discuss your drafts. If you don't plan to be in Singapore, that's your choice; you can be on MeetEcho. But I *would* like for you to discuss your drafts with the working group. As we usually do, I'll take a hum of those there, and if there is support, I'll put out an email to the larger list, and folks can express their support or lack thereof. >>> >>> I asked you a specific question in the email you are replying to. Would you consider answering it? >> The email I replied to was your post of the status of several drafts >> (hence the subject of this email). There was no question in the email, >> nor in the attachment. >> >> So... what's the question that you asked, and where did you ask it? >> >> 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 > _______________________________________________ > LACNOG mailing list > LACNOG@lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog From nobody Tue Nov 26 13:15:50 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32420120AE0; Tue, 26 Nov 2019 13:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RsSuh84L_Aw3; Tue, 26 Nov 2019 13:15:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D33120ADC; Tue, 26 Nov 2019 13:15:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4FF98F40704; Tue, 26 Nov 2019 13:15:17 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, v6ops@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20191126211517.4FF98F40704@rfc-editor.org> Date: Tue, 26 Nov 2019 13:15:17 -0800 (PST) Archived-At: Subject: [v6ops] =?utf-8?q?RFC_8683_on_Additional_Deployment_Guidelines_f?= =?utf-8?q?or_NAT64/464XLAT_in_Operator_and_Enterprise_Networks?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 21:15:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8683 Title: Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks Author: J. Palet Martinez Status: Informational Stream: IETF Date: November 2019 Mailbox: jordi.palet@theipv6company.com Pages: 38 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-nat64-deployment-08.txt URL: https://www.rfc-editor.org/info/rfc8683 DOI: 10.17487/RFC8683 This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadband ISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Nov 30 11:40:47 2019 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 1A7BC120801 for ; Sat, 30 Nov 2019 11:40:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157514284610.14503.3991520057315458610.idtracker@ietfa.amsl.com> Date: Sat, 30 Nov 2019 11:40:46 -0800 From: IETF Secretariat Archived-At: Subject: [v6ops] Milestones changed for v6ops WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2019 19:40:46 -0000 Changed milestone "Recommendations regarding the use of DNS64", resolved as "Done". URL: https://datatracker.ietf.org/wg/v6ops/about/ From nobody Sat Nov 30 12:14:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA865120105 for ; Sat, 30 Nov 2019 12:14:14 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=juniper.net header.b=HFUPDpLZ; dkim=pass (1024-bit key) header.d=juniper.net header.b=CLNU66hq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6n0GlxKWHB6 for ; Sat, 30 Nov 2019 12:14:13 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 81EC112008F for ; Sat, 30 Nov 2019 12:14:13 -0800 (PST) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAUKBXNg024911 for ; Sat, 30 Nov 2019 12:14:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=pQbAb7g0rgQFFOsD9gs47FbwI7LJX2uF4+tYO2h+mPQ=; b=HFUPDpLZrMzWHkrwj3zgzSYa6zzn7qFC/o6EEeH84/3zWXO8D2lr6OMkO3jIcxyXQbK6 gwI+mlu0CBJr0k8oY98b/UK6CVEbx6iGNh45NTQMXbnBMs61bqqWaTSul24abY2uYJe3 8Hxc+hleze51u+JyWV72Aw6lt0+gmkTLxMb3ynPaiDNcxzLg4Gk5+nPKV9PuR2Qy6Age gsR4ftgmaYn0jWW8RJIQGZj7WWdG3lLhVbmyzBks4+LeRh5WY++Em8FKFjP2vc3w4kv7 A4zIE7RpmQ0ChUFPrYgO8Cy8hciUGnvs3YkNPz4vgmPttAFTtG3pS1Evy8D/eN+Ay+MO iA== Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2052.outbound.protection.outlook.com [104.47.44.52]) by mx0a-00273201.pphosted.com with ESMTP id 2wkn0tgjjs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 30 Nov 2019 12:14:12 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cbGxAz+XdJX6++2u/IXQ2TBunlyU2Pygb/BbS1zOlhx5CBCFk5+pRxhiDLL31mzmXpa6NKcHCR4r0k+Q/9Qw7elwaOuQ0l0oPScveEAMYtqVTCHV7hXRy2hGrjHPRH83xpNQX8/gN8xc42grapuxzOLcypmPjfFFfwqgOo6eTot8boMcruquNn9G2qI8flwfW44z/NSkk22PaKq5qc0FLW7prvESJBalxGZ0GarHQ4/Bal3YQipd4uEygi3+DKJxm6kzn6Px7LGzq+udPc1rR+HS8GYGGrYaK80SlbHJTw6xHR9OaTZb4WXgtpSO6q0aQGuUtmKziyCu0pDdBL5aKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pQbAb7g0rgQFFOsD9gs47FbwI7LJX2uF4+tYO2h+mPQ=; b=Fzbr3yrLRmZ+1GWmub7u7ywRj/VY2FxjLw0uqHHKyV12ehdvwNQD8CZd0p6Fxdzk9cT/3IJIcoOIUASemqgnHGZtUJdQcW9Yw8c3eovRRn9LYbfLl8JqXu6DXEelR761tLMZyV/+6lryGuFzORjj38peY4vpkBKpFJH+nBWtz+mBTOby3C/zkjtKA6VYtCIVTKtnLUuNF2NKOP5ItUj0sETF/e9SkPzCe2zn0Vb/EESZ4xFf1GaV+aIJibk0bPCGmbzxdLR/Qik8Q9nxnIAlCwooHd9C/5v1GUYJylvRRnBj6fSSC0/HM2CIHr3UDlRL7+AM6CH0hFV+VaMBKwQ80w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pQbAb7g0rgQFFOsD9gs47FbwI7LJX2uF4+tYO2h+mPQ=; b=CLNU66hqo6qG6u4THW3Q6vk4d9qIBCvP0JVrHljBBShM9DCqzMQvSfVXNCZZtzBqeYtaxb6MTuGGscVEIAeNBS4no3UgOeY0sC+Zm3/YZTVUs7Gd7Sh3PNJtNfn2ug9xlPhdXA1SRk94/cTZFWRx0tME6H+93GJi3V0gMac7MSc= Received: from SN6PR05MB5710.namprd05.prod.outlook.com (20.178.7.89) by SN6PR05MB4928.namprd05.prod.outlook.com (52.135.117.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.4; Sat, 30 Nov 2019 20:14:10 +0000 Received: from SN6PR05MB5710.namprd05.prod.outlook.com ([fe80::d178:540a:4d4c:3e12]) by SN6PR05MB5710.namprd05.prod.outlook.com ([fe80::d178:540a:4d4c:3e12%5]) with mapi id 15.20.2516.003; Sat, 30 Nov 2019 20:14:09 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-smith-v6ops-local-only-addressing Thread-Index: AdWnuq+lq7h8YJ+2Qe66dW1npqyM2w== Content-Class: Date: Sat, 30 Nov 2019 20:14:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_7a6262c0-804d-4ff7-addc-c437ca753822_Enabled=True; MSIP_Label_7a6262c0-804d-4ff7-addc-c437ca753822_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_7a6262c0-804d-4ff7-addc-c437ca753822_Owner=rbonica@juniper.net; MSIP_Label_7a6262c0-804d-4ff7-addc-c437ca753822_SetDate=2019-11-30T20:13:25.0618184Z; MSIP_Label_7a6262c0-804d-4ff7-addc-c437ca753822_Name=Juniper Public; MSIP_Label_7a6262c0-804d-4ff7-addc-c437ca753822_Application=Microsoft Azure Information Protection; MSIP_Label_7a6262c0-804d-4ff7-addc-c437ca753822_ActionId=aca1adf6-b36b-4b88-97f8-0e0680179847; MSIP_Label_7a6262c0-804d-4ff7-addc-c437ca753822_Extended_MSFT_Method=Manual dlp-product: dlpe-windows dlp-version: 11.3.2.8 dlp-reaction: no-action x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a7f06228-d83e-49f2-adf2-08d775d1dc3b x-ms-traffictypediagnostic: SN6PR05MB4928: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 02379661A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(366004)(136003)(396003)(189003)(199004)(5660300002)(14454004)(2351001)(5640700003)(55016002)(6306002)(2906002)(9686003)(99286004)(6436002)(478600001)(8676002)(66066001)(81166006)(186003)(26005)(52536014)(66946007)(76116006)(64756008)(81156014)(102836004)(6506007)(7696005)(7736002)(2501003)(71200400001)(71190400001)(6916009)(66556008)(66446008)(66476007)(558084003)(25786009)(8936002)(316002)(790700001)(6116002)(3846002)(256004)(33656002)(74316002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB4928; H:SN6PR05MB5710.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Jp08C2au/hlex57+VfmgME+wzSBBRA+xtZp9NELHjzGPEo+khI8Y4on2BF6NDj+c8GL+K15erxWgU+4iSrX8SSBIjrEGFBXlezuIDHjrfltWTZbBYm6XhTHBuuha6aZK28wNdlo/PyY5E6Iugdtm0b05aUrENgwArCUb8Wl6WdBLJTBKKmw1MDFKQXwkXmjSwMff1VsUIbMsE6JvmPrg45yuglFj5hLnmDPBKl6A3vi2F3YZ0GKdGGFAX+n47fSlxFXgB70A7l9EFaojhSmezikKL/S8X9nWcfCXqYRYUOnRQWcJ+FWyVR5/VXniun96pOyP6OuLfIbJOgNsJR1oig2KgipLd1/VOQ8ERlELBdW5GyzeWzICmHAjK5QUlAo88KBNVx0fzKNNjgtThHBZKH77A9JZMlHXE69POB3ZPK5HHnIUKrElmM+JkiqFYMRX x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR05MB57109A5048345A6B2ECD6C5EAE410SN6PR05MB5710namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: a7f06228-d83e-49f2-adf2-08d775d1dc3b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2019 20:14:09.8628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VRcPL1c8tQwbwsIV9R+N4XO3MsPNJtCc+REF/r0q7vZjRMXa4eY2L/x5g0K59vCT6KjN73wDy924sKrPk5edFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4928 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-30_06:2019-11-29,2019-11-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 mlxlogscore=566 lowpriorityscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0 suspectscore=0 malwarescore=0 clxscore=1011 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911300179 Archived-At: Subject: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2019 20:14:15 -0000 --_000_SN6PR05MB57109A5048345A6B2ECD6C5EAE410SN6PR05MB5710namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Each week between now and IETF 107, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-smith-v6ops-local-only-addres= sing. Fred and Ron Juniper Public --_000_SN6PR05MB57109A5048345A6B2ECD6C5EAE410SN6PR05MB5710namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Each week between now and IETF 107, we will revie= w and discuss one draft with an eye towards progressing it.

 

This week, please review and comment on draft-smi= th-v6ops-local-only-addressing.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  Fred and Ron

 


Juniper Public

--_000_SN6PR05MB57109A5048345A6B2ECD6C5EAE410SN6PR05MB5710namp_--