From nobody Fri Feb 1 11:02:44 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 CBA1713126C; Fri, 1 Feb 2019 11:02:34 -0800 (PST) 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQnu_VAk1LLx; Fri, 1 Feb 2019 11:02:31 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8C1131266; Fri, 1 Feb 2019 11:02:31 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 17D83B2; Fri, 1 Feb 2019 20:02:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1549047748; bh=STORt7NHF1Oj22Ne/O5wUu+1Al8n07nx9qj8V+f+3Kc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=s/dy9TgCwxpyYfIhICP2MNWHHpUfO64SEIKy11TSpa3PMuY3GkWuYw2i2z1VqVPyo JIssaWOzpj+agMO9W/E8OuynlE8rCTT7OKgOXwHqfjzlKz7NlYcf6Y0ChH3aaVxxM2 a0H7/NDhMupdrLrds8vS/hnGs/9JFmhrs6mm0Y/o= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 13D02B0; Fri, 1 Feb 2019 20:02:28 +0100 (CET) Date: Fri, 1 Feb 2019 20:02:28 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont cc: ipv6@ietf.org, IPv6 Operations In-Reply-To: Message-ID: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 19:02:35 -0000 On Thu, 31 Jan 2019, Fernando Gont wrote: > Question: > How about making the update to the "Valid Lifetime" a SHOULD or MAY, > instead? Or, maybe, at least, set it to the current "Valid Lifetime"? > Otherwise, with the default values for the "Valid Lifetime", the > addresses might lie around for 1 month.... I had a real life example today. I have OpenWrt 18.06.1 HGW. This morning, I lost Internet access. After diagnosing I realised that WAN was not working correctly, so I did "ifdown wan" and "ifdown wan6", switched to my secondary provider (which I was still on contract with but don't normally use) and then did "ifup" on both. I received new IPv4 GUA and IPv6 GUA PD /56, which was then announced on my br-lan. I then ran on that for 3-4 hours until my regular provider had fixed their hardware problem. Then I did the whole ifddown procedure, swapped WAN cable to normal ISP, and did ifup again. Now, I saw IPv6 IA_NA for the temp ISP /56 with a week lifetime on wired LAN device so I was a bit worried this would cause long-time problems, but the prefixes were deprecated and I couldn't find any actual issues (source address selection worked properly). A few hours later all these addresses were gone even from my purely wired devices that hadn't seen any link down/up events. So potentially RFC7084 style solves most problems together with https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 style WAN down/up detection for the IPoE deployment case (PPPoE already have this). OpenWrt since 15.05 has been very much aimed to be RFC7084 compatible so I would propose to investigate further what hosts today actually do in reaction to RFC7084 signalling. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Feb 2 03:32: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 5290C130DEF; Sat, 2 Feb 2019 03:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOXrMei_5kNJ; Sat, 2 Feb 2019 03:32:18 -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 B94B4130D7A; Sat, 2 Feb 2019 03:32:17 -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 m1gptWx-0000G3C; Sat, 2 Feb 2019 12:32:15 +0100 Message-Id: To: ipv6@ietf.org Cc: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> In-reply-to: Your message of "Thu, 31 Jan 2019 17:02:43 -0300 ." Date: Sat, 02 Feb 2019 12:32:14 +0100 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 02 Feb 2019 11:32:20 -0000 >FWIW, our first initial version only changed the "Preferred Lifetime", >and never modified the "Valid Lifetime". Then we realized it was easy to >update the "Valid Lifetime" with the same "mechanism" and incorporated >that. THe most important bit is, indeed, updating the "Preferred Lifetime". > >Question: >How about making the update to the "Valid Lifetime" a SHOULD or MAY, >instead? Or, maybe, at least, set it to the current "Valid Lifetime"? >Otherwise, with the default values for the "Valid Lifetime", the >addresses might lie around for 1 month.... In think it is better to solve two separate problems independently and only merge the solutions if the same solution happens to apply to both. When router reboots and switches to a new prefix, hosts should switch to the new prefix as soon as possible. On the other hand, removing addresses that have preferred lifetime of zero is a bookkeeping task that can take more time. One question is whether it makes sense for routers to have valid lifetimes of more than a day for prefixes that are obtained using DHCP-PD. Another is whether general purpose hosts should accept lifetimes of more than a day. Maybe hosts should just truncate. If that doesn't solve the issue, then for the valid lifetime it make sense for the host to wait multiple RA intervals to make sure the router really doesn't advertise the prefix. >The mechanism in the document tries to accommodate the case where the >information conveyed in an RA is split among two RA messages -- so it's >the second RA with the PIO that causes the update, rather than the first >one. In all current practical cases, all info is normally conveyed into >a single RA. However, the mechanism that's currently in the I-D allows >for cases where it can be split in two. What happens if a router would advertise 4 prefixes in 4 separate RAs? From nobody Sat Feb 2 06:17: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 8923812426A; Sat, 2 Feb 2019 06:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vB-kJn6ceQU; Sat, 2 Feb 2019 06:17:15 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4690A1228B7; Sat, 2 Feb 2019 06:17:15 -0800 (PST) Received: from astfgl.hanazo.no (77.16.52.6.tmi.telenormobil.no [77.16.52.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 1BABAFECC0E8; Sat, 2 Feb 2019 14:17:14 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id AF6E1DE1251; Sat, 2 Feb 2019 12:57:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ole Troan In-Reply-To: Date: Sat, 2 Feb 2019 12:57:29 +0100 Cc: 6man WG , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> To: Philip Homburg X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 02 Feb 2019 14:17:17 -0000 > One question is whether it makes sense for routers to have valid = lifetimes of > more than a day for prefixes that are obtained using DHCP-PD. >=20 > Another is whether general purpose hosts should accept lifetimes of = more > than a day. Maybe hosts should just truncate. The (original) intended lifetime for DHCP PD is a lifetime equal to the = length of the contract with your ISP. Lifetimes become meaningless with =E2=80=9Cflash renumbering=E2=80=9D. = Neither SLAAC nor DHCP PD is designed for that. The simple solution to this problem is =E2=80=9Cif it hurts, stop doing = it=E2=80=9D. Cheers, Ole= From nobody Sat Feb 2 19:47: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 67AFD130EF2; Sat, 2 Feb 2019 19:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Wn_3dWmnt-I; Sat, 2 Feb 2019 19:47:32 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585471295D8; Sat, 2 Feb 2019 19:47:32 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id q1so5207103pfi.5; Sat, 02 Feb 2019 19:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0HuYjuS8oKLDgFcAJHnx62jexoVFEDK1gJRMP6APpko=; b=iPtWQRe704b+KC5dI+ACWbqAg1Ubh2ey80gy4bPa5H2QnufKhteZT4zJl45NpX+1Xh RMC688yCTbuFgnUzy4qVaRaUbF37wa8LdlT+k/Gw0ADa9W/WXHz5SoxpClw/zpDnr9pO K6NE5F2xBEs1rGraNvGW0ouSmWHaChtBuaNsGqQOEF9h35dVJE/dvyqhF84J2/Gr+joY 9n0GNGnfhjHX4TmzPA9ac4vzMBTKobgabiPpCLKEsQ8+DAnnLWROnGuOevtShLoDopox v5A3UB3h8RWFZXMdCkQm+jmnEiY0c/aNT28YyI6x0RsL4wrkHKniq1VgyO4kphDVkAJT UAyg== 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=0HuYjuS8oKLDgFcAJHnx62jexoVFEDK1gJRMP6APpko=; b=JLst759An3j2p8+TbN4sWg2OXjtdDg4XO3tcAIRvKS/ix6QSxMeSR42v2cuoCsCJji DaYTZbFx1YEFMIfbWVZy7nLtIHPRp3sGmOVHrioK8YWQrsfLoxVkd9TDrIeeMQdzh4ff 7/1hC3MLuPRG+YSwG637Q0lEg6baDrujNLSJ/2biGlmV9jPqWRARj4t3y3ZlNk1YJCkL ohi/rdd+WVpPOnW4fgnK+MpvrbHPXkGsahMXnvA/kVE8PDqGdyhkeBUXR+S5G2+dN5qC 7XoVKMezLzFP8PeIA20dHkKZc3Sdh7/XiUXtGpOF6ZfrP379kYaP5wMUWWfx+m4cjtkw k3jw== X-Gm-Message-State: AHQUAuZKh6jQrnYrSMk6pRIS7EE+2JuOvP42H7u2eJxl3orougM0ZAMe eBz6K6k+tpdTYIDb9FYZ8VWvyOWF X-Google-Smtp-Source: AHgI3IbpPqXv8uyt1aPkgYt+qaZtRnb3KH6r01Q8rlC0pFW7UpxPDeg39iDlOAMF4Gu7nMVKjoH/fQ== X-Received: by 2002:a63:b105:: with SMTP id r5mr8284887pgf.442.1549165651719; Sat, 02 Feb 2019 19:47:31 -0800 (PST) Received: from ?IPv6:2600:8801:d000:14a4:60ff:d5a1:a297:23b7? ([2600:8801:d000:14a4:60ff:d5a1:a297:23b7]) by smtp.gmail.com with ESMTPSA id a195sm25612638pfa.7.2019.02.02.19.47.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Feb 2019 19:47:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (16E5181f) In-Reply-To: Date: Sat, 2 Feb 2019 19:47:28 -0800 Cc: Fernando Gont , IPv6 Operations , ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5AEA3935-F25D-4F5E-BB7A-88693DB5362F@gmail.com> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> To: Mikael Abrahamsson Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 03:47:34 -0000 It sounds to me like you needed manual intervention to fix things. Mere mort= als need for it to sect that it was down and do the right thing, then detect= that it was restored and address that... Sent using a machine that autocorrects in interesting ways... > On Feb 1, 2019, at 11:02 AM, Mikael Abrahamsson wrote: >=20 >> On Thu, 31 Jan 2019, Fernando Gont wrote: >>=20 >> Question: >> How about making the update to the "Valid Lifetime" a SHOULD or MAY, >> instead? Or, maybe, at least, set it to the current "Valid Lifetime"? >> Otherwise, with the default values for the "Valid Lifetime", the >> addresses might lie around for 1 month.... >=20 > I had a real life example today. I have OpenWrt 18.06.1 HGW. This morning,= I lost Internet access. After diagnosing I realised that WAN was not workin= g correctly, so I did "ifdown wan" and "ifdown wan6", switched to my seconda= ry provider (which I was still on contract with but don't normally use) and t= hen did "ifup" on both. I received new IPv4 GUA and IPv6 GUA PD /56, which w= as then announced on my br-lan. I then ran on that for 3-4 hours until my re= gular provider had fixed their hardware problem. Then I did the whole ifddow= n procedure, swapped WAN cable to normal ISP, and did ifup again. >=20 > Now, I saw IPv6 IA_NA for the temp ISP /56 with a week lifetime on wired L= AN device so I was a bit worried this would cause long-time problems, but th= e prefixes were deprecated and I couldn't find any actual issues (source add= ress selection worked properly). A few hours later all these addresses were g= one even from my purely wired devices that hadn't seen any link down/up even= ts. >=20 > So potentially RFC7084 style solves most problems together with https://to= ols.ietf.org/html/draft-patterson-intarea-ipoe-health-05 style WAN down/up d= etection for the IPoE deployment case (PPPoE already have this). >=20 > OpenWrt since 15.05 has been very much aimed to be RFC7084 compatible so I= would propose to investigate further what hosts today actually do in reacti= on to RFC7084 signalling. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Feb 2 23:52: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 92E48130F1F; Sat, 2 Feb 2019 23:51:56 -0800 (PST) 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4yKYZ3e6C4E; Sat, 2 Feb 2019 23:51:54 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB664130EF5; Sat, 2 Feb 2019 23:51:53 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9C42BB2; Sun, 3 Feb 2019 08:51:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1549180309; bh=ywJyKCAyK1EqAYOPci5n4hJ3YCnSmuwsdww6nq+x2wQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oEr/220v68g3gnixLbJjPKGQK6kF/qd23/0OptYkOvp037NpLy8RJgk7kctqkUZBJ OFRsrXuJsUyVENkeknaMM7nhujn3KofAVaTZ4Dsu65LhtdxVrzBtWjDrAf3NaLrNJV Gl6MsmakogiDIMv4lq2s4F2A3ew2w4VZl/uO40W8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 965DEB0; Sun, 3 Feb 2019 08:51:49 +0100 (CET) Date: Sun, 3 Feb 2019 08:51:49 +0100 (CET) From: Mikael Abrahamsson To: Fred Baker cc: IPv6 Operations , ipv6@ietf.org In-Reply-To: <5AEA3935-F25D-4F5E-BB7A-88693DB5362F@gmail.com> Message-ID: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <5AEA3935-F25D-4F5E-BB7A-88693DB5362F@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 07:51:56 -0000 On Sat, 2 Feb 2019, Fred Baker wrote: > It sounds to me like you needed manual intervention to fix things. Mere > mortals need for it to sect that it was down and do the right thing, > then detect that it was restored and address that... If I had support for https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 then no manual intervention would have been needed. Problem I have with my setup is that my WAN physical port doesn't go down just because the upstream router goes unreachable. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Feb 3 01:43: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 02707130EF5; Sun, 3 Feb 2019 01:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdlyiLHGrkBf; Sun, 3 Feb 2019 01:43:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4785112D4EF; Sun, 3 Feb 2019 01:43:36 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 15B2080D5A; Sun, 3 Feb 2019 10:43:31 +0100 (CET) To: Philip Homburg , ipv6@ietf.org Cc: v6ops@ietf.org References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 3 Feb 2019 01:26:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 09:43:40 -0000 Hello, Philip, On 2/2/19 08:32, Philip Homburg wrote: >> FWIW, our first initial version only changed the "Preferred Lifetime", >> and never modified the "Valid Lifetime". Then we realized it was easy to >> update the "Valid Lifetime" with the same "mechanism" and incorporated >> that. THe most important bit is, indeed, updating the "Preferred Lifetime". >> >> Question: >> How about making the update to the "Valid Lifetime" a SHOULD or MAY, >> instead? Or, maybe, at least, set it to the current "Valid Lifetime"? >> Otherwise, with the default values for the "Valid Lifetime", the >> addresses might lie around for 1 month.... > > In think it is better to solve two separate problems independently and only > merge the solutions if the same solution happens to apply to both. > > When router reboots and switches to a new prefix, hosts should switch to the > new prefix as soon as possible. > > On the other hand, removing addresses that have preferred lifetime of zero > is a bookkeeping task that can take more time. The main concern is certainly "Preferred" addresses. However, the issue of lagging addresses is related. > One question is whether it makes sense for routers to have valid lifetimes of > more than a day for prefixes that are obtained using DHCP-PD. In principle, I guess that as long as you cap the "Valid" and "Preferred" lifetimes when you announce such prefixes on the LAN side according to the lease time, you are kind of "okish". Anyway: do you suggest that we split the "book-keeping stuff" (i.e., affecting the Valid Lifetime) into a separate section? > Another is whether general purpose hosts should accept lifetimes of more > than a day. Maybe hosts should just truncate. > > If that doesn't solve the issue, then for the valid lifetime it make sense for > the host to wait multiple RA intervals to make sure the router really doesn't > advertise the prefix. What we do in the I-D is equivalent, so to speak: if you do hear RAs from the router, but the prefix is not advertised, and a different prefix is, then that's a clear indication that the router has ceased to advertise the original prefix. Just waiting for RA intervals (without checking anything else) might mean the RAs were simply lost, whereas receiving RAs with PIOs that don't include the previous prefixes is an indication that RAs are getting through, but the previous prefixes are not advertised anymore... >> The mechanism in the document tries to accommodate the case where the >> information conveyed in an RA is split among two RA messages -- so it's >> the second RA with the PIO that causes the update, rather than the first >> one. In all current practical cases, all info is normally conveyed into >> a single RA. However, the mechanism that's currently in the I-D allows >> for cases where it can be split in two. > > What happens if a router would advertise 4 prefixes in 4 separate RAs? The addresses would oscillate between Preferred <-> non-preferred: Router Host RA, PIO={2001:DB8:1::/64, L=1, A=1} --------------------------------------> [Host configures addrs for this prefix] . . RA, PIO={2001:DB8:2::/64, L=1, A=1} --------------------------------------> deprecate=TRUE RA, PIO={2001:DB8:3::/64, L=1, A=1} --------------------------------------> Pref. Lftime=0 deprecate=FALSE RA, PIO={2001:DB8:4::/64, L=1, A=1} --------------------------------------> deprecate=TRUE RA, PIO={2001:DB8:1::/64, L=1, A=1} --------------------------------------> Valid and Preferred timers are reset deprecate=FALSE The address would only get removed if you advertise five different prefixes over five different RAs. I haven't seen any router implementation that is so broken, though -- All I've encountered follow the practice of "put as much info into each RA as possible". That said, I wouldn't mind providing alternative mechanisms for un-preferring and removing the addresses that involve timers. We went ahead with a mechanism like the one we documented because it makes sense engineering-wise: it's simple, encompasses realistic scenarios, and avoid timers. 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 Sun Feb 3 01:43: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 77DF1130F2D; Sun, 3 Feb 2019 01:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 m0-uZqHldLV7; Sun, 3 Feb 2019 01:43:42 -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 745F1130F27; Sun, 3 Feb 2019 01:43:42 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 5CE3C826AE; Sun, 3 Feb 2019 10:43:37 +0100 (CET) To: Ole Troan , Philip Homburg Cc: v6ops@ietf.org, 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 3 Feb 2019 01:29:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 09:43:49 -0000 On 2/2/19 08:57, Ole Troan wrote: >> One question is whether it makes sense for routers to have valid lifetimes of >> more than a day for prefixes that are obtained using DHCP-PD. >> >> Another is whether general purpose hosts should accept lifetimes of more >> than a day. Maybe hosts should just truncate. > > The (original) intended lifetime for DHCP PD is a lifetime equal to the length of the contract with your ISP. > Lifetimes become meaningless with “flash renumbering”. Neither SLAAC nor DHCP PD is designed for that. > > The simple solution to this problem is “if it hurts, stop doing it”. FWIW, lifetimes are mostly irrelevant to the problem that *we* are discussing (which is rather orthogonal to the problem mentioned above): our case is that in which the router just reboots -- so no matter what the lifetime was, the information will be invalid anyway. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 3 01:44: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 EB234130F33; Sun, 3 Feb 2019 01:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 lcVELAVgnrCO; Sun, 3 Feb 2019 01:43:46 -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 21D57130F73; Sun, 3 Feb 2019 01:43:46 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 6D6D180D5A; Sun, 3 Feb 2019 10:43:43 +0100 (CET) To: Mikael Abrahamsson Cc: ipv6@ietf.org, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 3 Feb 2019 02:17:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 09:43:54 -0000 On 1/2/19 16:02, Mikael Abrahamsson wrote: > On Thu, 31 Jan 2019, Fernando Gont wrote: > >> Question: >> How about making the update to the "Valid Lifetime" a SHOULD or MAY, >> instead?  Or, maybe, at least, set it to the current "Valid Lifetime"? >> Otherwise, with the default values for the "Valid Lifetime", the >> addresses might lie around for 1 month.... > > I had a real life example today. I have OpenWrt 18.06.1 HGW. This > morning, I lost Internet access. After diagnosing I realised that WAN > was not working correctly, so I did "ifdown wan" and "ifdown wan6", > switched to my secondary provider (which I was still on contract with > but don't normally use) and then did "ifup" on both. I received new IPv4 > GUA and IPv6 GUA PD /56, which was then announced on my br-lan. I then > ran on that for 3-4 hours until my regular provider had fixed their > hardware problem. Then I did the whole ifddown procedure, swapped WAN > cable to normal ISP, and did ifup again. > > Now, I saw IPv6 IA_NA for the temp ISP /56 with a week lifetime on wired > LAN device so I was a bit worried this would cause long-time problems, > but the prefixes were deprecated and I couldn't find any actual issues > (source address selection worked properly). A few hours later all these > addresses were gone even from my purely wired devices that hadn't seen > any link down/up events. > > So potentially RFC7084 style solves most problems together with > https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 style > WAN down/up detection for the IPoE deployment case (PPPoE already have > this). This is a different problem scenario: the router is in an easy position to clean up after itself, whereas in the case of crash-and-reboot most aren't (since most don't record the prefix they were advertising). > OpenWrt since 15.05 has been very much aimed to be RFC7084 compatible so > I would propose to investigate further what hosts today actually do in > reaction to RFC7084 signalling. What do you mean by "RFC7084 signaling"? 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 Sun Feb 3 02:33: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 F08B91277BB; Sun, 3 Feb 2019 02:32:55 -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, MIME_QP_LONG_LINE=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 HueI8eLUppfN; Sun, 3 Feb 2019 02:32:54 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5D8126C01; Sun, 3 Feb 2019 02:32:54 -0800 (PST) Received: from [10.208.15.221] (77.16.223.221.tmi.telenormobil.no [77.16.223.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id A0619FECC0F8; Sun, 3 Feb 2019 10:32:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (16D39) In-Reply-To: Date: Sun, 3 Feb 2019 11:32:49 +0100 Cc: Philip Homburg , v6ops@ietf.org, 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> To: Fernando Gont Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:32:56 -0000 > On 3 Feb 2019, at 05:29, Fernando Gont wrote: >=20 > On 2/2/19 08:57, Ole Troan wrote: >>> One question is whether it makes sense for routers to have valid lifetim= es of >>> more than a day for prefixes that are obtained using DHCP-PD. >>>=20 >>> Another is whether general purpose hosts should accept lifetimes of more= >>> than a day. Maybe hosts should just truncate. >>=20 >> The (original) intended lifetime for DHCP PD is a lifetime equal to the l= ength of the contract with your ISP. >> Lifetimes become meaningless with =E2=80=9Cflash renumbering=E2=80=9D. Ne= ither SLAAC nor DHCP PD is designed for that. >>=20 >> The simple solution to this problem is =E2=80=9Cif it hurts, stop doing i= t=E2=80=9D. >=20 > FWIW, lifetimes are mostly irrelevant to the problem that *we* are > discussing (which is rather orthogonal to the problem mentioned above): > our case is that in which the router just reboots -- so no matter what > the lifetime was, the information will be invalid anyway. >=20 That=E2=80=99s not how SLAAC and PD are designed. Lifetimes are not invalid j= ust because of a router reboot. Look at advertised lifetimes as a sort of co= ntract.=20 What you seem to be talking about is either a bug a misconfiguration or both= .=20 With that established, you are arguing that hosts/applications should behave= better in the case of this misconfiguration? If you want something like session survivability, that=E2=80=99s not a trivial problem to solve. Currently the network will give an ICMP destination unreachable code 5 and d= eprecate the invalid prefix if it has information to do so. Without getting into the multi-homing discussion and requiring hosts to =E2=80= =9Cthrow spaghetti on the wall=E2=80=9D, I don=E2=80=99t see how your draft i= mproves on that.=20 Ole > 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 From nobody Sun Feb 3 02:54:47 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 68C7C130F28; Sun, 3 Feb 2019 02:54:40 -0800 (PST) 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81ydEQ2uhYjq; Sun, 3 Feb 2019 02:54:38 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4CE126C01; Sun, 3 Feb 2019 02:54:38 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A8CC6B2; Sun, 3 Feb 2019 11:54:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1549191275; bh=+SbTTiwTAYwV4cTjVntUIfc80eLpJtCqFLfPaHaHEcg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2QgvTO44sXBTnri3ziTvq/4EQnycb/ETNsqEPFrkBDiYvoQCAnLyfXwRJKbFtdl8N ZMkC62mjn9dfTbGxwe/GjFIq/GN47LWivccF9WjLWCj+PRvyxCWWBanoP7P60AKq6E NIcb5LKYF7YdtxZlDsss8bzmrA5cDj3Enj7OZHS4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A6520B0; Sun, 3 Feb 2019 11:54:35 +0100 (CET) Date: Sun, 3 Feb 2019 11:54:35 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont cc: ipv6@ietf.org, IPv6 Operations In-Reply-To: Message-ID: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:54:41 -0000 On Sun, 3 Feb 2019, Fernando Gont wrote: >> OpenWrt since 15.05 has been very much aimed to be RFC7084 compatible so >> I would propose to investigate further what hosts today actually do in >> reaction to RFC7084 signalling. > > What do you mean by "RFC7084 signaling"? Sending RAs with PIOs with zero lifetime. >From my testing so far they do the right thing and stop using addresses from within those PIOs including if they're IA_NAs with a week lifetime, but I think it might be good if someone investigated current situation. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Feb 3 03:50: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 694A212896A; Sun, 3 Feb 2019 03:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pakr11mhtg05; Sun, 3 Feb 2019 03:50:07 -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 9C14A126CB6; Sun, 3 Feb 2019 03:50:06 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 02758847BB; Sun, 3 Feb 2019 12:50:00 +0100 (CET) To: Ole Troan Cc: Philip Homburg , v6ops@ietf.org, 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 3 Feb 2019 08:49:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 11:50:09 -0000 On 3/2/19 07:32, Ole Troan wrote: > > >> On 3 Feb 2019, at 05:29, Fernando Gont wrote: >> >> On 2/2/19 08:57, Ole Troan wrote: >>>> One question is whether it makes sense for routers to have valid lifetimes of >>>> more than a day for prefixes that are obtained using DHCP-PD. >>>> >>>> Another is whether general purpose hosts should accept lifetimes of more >>>> than a day. Maybe hosts should just truncate. >>> >>> The (original) intended lifetime for DHCP PD is a lifetime equal to the length of the contract with your ISP. >>> Lifetimes become meaningless with “flash renumbering”. Neither SLAAC nor DHCP PD is designed for that. >>> >>> The simple solution to this problem is “if it hurts, stop doing it”. >> >> FWIW, lifetimes are mostly irrelevant to the problem that *we* are >> discussing (which is rather orthogonal to the problem mentioned above): >> our case is that in which the router just reboots -- so no matter what >> the lifetime was, the information will be invalid anyway. >> > > That’s not how SLAAC and PD are designed. Lifetimes are not invalid just because of a router reboot. Look at advertised lifetimes as a sort of contract. Well, the problem is that you are making a contract on the LAN side for a contract you may not have on the WAN side. If the router reboots and the CEP no longer "owns" some prefix, then that contract is void. Ideally, the CPE will advertise that the contract is void. But it is clear that for most deployed CPEs, that will not happen. > What you seem to be talking about is either a bug a misconfiguration or both. It's neither of those. If anything, it's the result of under-specification of the necessary glue between automatic configuration on the WAN side, and automatic configuration on the LAN side. e.g., there were no requirements for CPEs to keep track of prefixes that they have been leased in the past -- if at all possible. > With that established, you are arguing that hosts/applications should behave better in the case of this misconfiguration? They should behave better in scenarios where the CPE may have rebooted and lost state of previously leased prefixes, which may have thus become invalid. > If you want something like session survivability, > that’s not a trivial problem to solve. Not sure what you mean by "session survivability". > > Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so. Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes? Answer: Nowhere. They don't get to do that. All ICMPv6 error messages are soft errors. And it would be a huge mistake (and huge vulnerability!) to behave otherwise. > Without getting into the multi-homing discussion and requiring hosts to “throw spaghetti on the wall”, I don’t see how your draft improves on that. Not sure what you mean. If the same router that advertised those prefixes doesn't advertise those prefixes anymore, why would you think they are still valid? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 3 04:27: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 C441C1271FF; Sun, 3 Feb 2019 04:27:37 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQrVblKe2yqV; Sun, 3 Feb 2019 04:27:36 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3663127B4C; Sun, 3 Feb 2019 04:27:35 -0800 (PST) Received: from [IPv6:2001:67c:1810:f051:805b:20ca:693a:4c94] (unknown [185.175.219.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id AA515FECC10E; Sun, 3 Feb 2019 12:27:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (16D39) In-Reply-To: Date: Sun, 3 Feb 2019 13:27:31 +0100 Cc: Philip Homburg , v6ops@ietf.org, 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> To: Fernando Gont Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 12:27:38 -0000 > On 3 Feb 2019, at 12:49, Fernando Gont wrote: >=20 >> On 3/2/19 07:32, Ole Troan wrote: >>=20 >>=20 >>> On 3 Feb 2019, at 05:29, Fernando Gont wrote: >>>=20 >>> On 2/2/19 08:57, Ole Troan wrote: >>>>> One question is whether it makes sense for routers to have valid lifet= imes of >>>>> more than a day for prefixes that are obtained using DHCP-PD. >>>>>=20 >>>>> Another is whether general purpose hosts should accept lifetimes of mo= re >>>>> than a day. Maybe hosts should just truncate. >>>>=20 >>>> The (original) intended lifetime for DHCP PD is a lifetime equal to the= length of the contract with your ISP. >>>> Lifetimes become meaningless with =E2=80=9Cflash renumbering=E2=80=9D. N= either SLAAC nor DHCP PD is designed for that. >>>>=20 >>>> The simple solution to this problem is =E2=80=9Cif it hurts, stop doing= it=E2=80=9D. >>>=20 >>> FWIW, lifetimes are mostly irrelevant to the problem that *we* are >>> discussing (which is rather orthogonal to the problem mentioned above): >>> our case is that in which the router just reboots -- so no matter what >>> the lifetime was, the information will be invalid anyway. >>>=20 >>=20 >> That=E2=80=99s not how SLAAC and PD are designed. Lifetimes are not inval= id just because of a router reboot. Look at advertised lifetimes as a sort o= f contract.=20 >=20 > Well, the problem is that you are making a contract on the LAN side for > a contract you may not have on the WAN side. If the router reboots and > the CEP no longer "owns" some prefix, then that contract is void. You have the contract on the WAN side. What makes you think not. E.g via PD l= earns that given prefix is valid until March 1 2020. A reboot doesn=E2=80=99t change that.=20 > Ideally, the CPE will advertise that the contract is void. But it is > clear that for most deployed CPEs, that will not happen. So a bug.=20 What you are talking about is the case where the ISP breaks the contract. Wh= ile it previously promised to delegate you a prefix until 20200301, all trac= e of that has gone.=20 >=20 >=20 >=20 >> What you seem to be talking about is either a bug a misconfiguration or b= oth.=20 >=20 > It's neither of those. If anything, it's the result of > under-specification of the necessary glue between automatic > configuration on the WAN side, and automatic configuration on the LAN side= . >=20 > e.g., there were no requirements for CPEs to keep track of prefixes that > they have been leased in the past -- if at all possible. DHCP PD will give you the old prefix back.=20 >=20 >=20 >=20 >> With that established, you are arguing that hosts/applications should beh= ave better in the case of this misconfiguration? >=20 > They should behave better in scenarios where the CPE may have rebooted > and lost state of previously leased prefixes, which may have thus become > invalid. It=E2=80=99s not the CPE reboot that=E2=80=99s the problem. It=E2=80=99s the= ISP breaking the contract and using the opportunity to flash renumber the u= ser.=20 >=20 >> If you want something like session survivability, >> that=E2=80=99s not a trivial problem to solve. >=20 > Not sure what you mean by "session survivability" Try to keep a TCP session active while changing addresses.=20 >=20 >>=20 >> Currently the network will give an ICMP destination unreachable code 5 an= d deprecate the invalid prefix if it has information to do so. >=20 > Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes? >=20 > Answer: Nowhere. They don't get to do that. All ICMPv6 error messages > are soft errors. And it would be a huge mistake (and huge > vulnerability!) to behave otherwise. It=E2=80=99s a strong hint to the host stack to pick a different source addr= ess.=20 >> Without getting into the multi-homing discussion and requiring hosts to =E2= =80=9Cthrow spaghetti on the wall=E2=80=9D, I don=E2=80=99t see how your dra= ft improves on that.=20 >=20 > Not sure what you mean. If the same router that advertised those > prefixes doesn't advertise those prefixes anymore, why would you think > they are still valid? Because that=E2=80=99s what the network previously advertised.=20 If source addresses from that prefix no longer works that=E2=80=99s a good h= int to the host to try something else. There=E2=80=99s a list of heuristics t= he host must use.=20 I still don=E2=80=99t see how your draft improves much on this. Can you expl= ain? Ole >=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 From nobody Sun Feb 3 07:01: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 AE788130D7A; Sun, 3 Feb 2019 07:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKRjc3SXmGI0; Sun, 3 Feb 2019 07:00:53 -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 59B5812426A; Sun, 3 Feb 2019 07:00:53 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 D2A2884544; Sun, 3 Feb 2019 16:00:46 +0100 (CET) From: Fernando Gont To: Ole Troan Cc: Philip Homburg , v6ops@ietf.org, 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 3 Feb 2019 12:00:27 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 15:00:57 -0000 On 3/2/19 09:27, Ole Troan wrote: > > >> On 3 Feb 2019, at 12:49, Fernando Gont wrote: >> >>> On 3/2/19 07:32, Ole Troan wrote: >>> >>> >>>> On 3 Feb 2019, at 05:29, Fernando Gont wrote: >>>> >>>> On 2/2/19 08:57, Ole Troan wrote: >>>>>> One question is whether it makes sense for routers to have valid lifetimes of >>>>>> more than a day for prefixes that are obtained using DHCP-PD. >>>>>> >>>>>> Another is whether general purpose hosts should accept lifetimes of more >>>>>> than a day. Maybe hosts should just truncate. >>>>> >>>>> The (original) intended lifetime for DHCP PD is a lifetime equal to the length of the contract with your ISP. >>>>> Lifetimes become meaningless with “flash renumbering”. Neither SLAAC nor DHCP PD is designed for that. >>>>> >>>>> The simple solution to this problem is “if it hurts, stop doing it”. >>>> >>>> FWIW, lifetimes are mostly irrelevant to the problem that *we* are >>>> discussing (which is rather orthogonal to the problem mentioned above): >>>> our case is that in which the router just reboots -- so no matter what >>>> the lifetime was, the information will be invalid anyway. >>>> >>> >>> That’s not how SLAAC and PD are designed. Lifetimes are not invalid just because of a router reboot. Look at advertised lifetimes as a sort of contract. >> >> Well, the problem is that you are making a contract on the LAN side for >> a contract you may not have on the WAN side. If the router reboots and >> the CEP no longer "owns" some prefix, then that contract is void. > > You have the contract on the WAN side. What makes you think not. E.g via PD learns that given prefix is valid until March 1 2020. > A reboot doesn’t change that. > >> Ideally, the CPE will advertise that the contract is void. But it is >> clear that for most deployed CPEs, that will not happen. > > So a bug. > What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. The CPE is the middle-man between the ISP and the LAN. No matter what you may *expect* the CPE to do, the CPE is currently not actually required to e.g. clean after the contract that the ISP broke (if you assume/think there's such a thing), or even adjust prefix timers according to the DHCPv6 lease times -- talk about under-specification of the glue between e.g. DHCPv6-PD and SLAAC. Besides, the layer-8 contract between the user and the ISP may be that you get dynamic prefixes. This means that whenever you request a lease, you get a different prefix. You might say that if you don't do another DHCPv6-PD request, you should be able to use the same prefix. But if you do ask a new prefix, you might indeed get a new one -- and this is what normally happens after reboots. The CPE should -- if possible -- be faithful to its LAN hosts, and advertise if previous contracts between the CPE and the LAN hosts are void. i.e., if the CPE does not get leased the same prefix as before, it shoudl notifiy its "clients". However, possibly for simplicity sake, CPEs don't record what information was previously advertised on the LAN -- they are not required, so.... when they reboot, they may not not be in a position to notify hosts accordingly. That's the environment hosts operate in -- no matter whether you or me like it. In that environment, hosts can and should be smarter. >>> What you seem to be talking about is either a bug a misconfiguration or both. >> >> It's neither of those. If anything, it's the result of >> under-specification of the necessary glue between automatic >> configuration on the WAN side, and automatic configuration on the LAN side. >> >> e.g., there were no requirements for CPEs to keep track of prefixes that >> they have been leased in the past -- if at all possible. > > DHCP PD will give you the old prefix back. Not necessarily. In fact, it may intentionally not do that. If you no longer own the addresses, the sessions will have to be torn down. >>> If you want something like session survivability, >>> that’s not a trivial problem to solve. >> >> Not sure what you mean by "session survivability" > > Try to keep a TCP session active while changing addresses. Of course that's not what we're trying to solve here. >>> Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so. >> >> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes? >> >> Answer: Nowhere. They don't get to do that. All ICMPv6 error messages >> are soft errors. And it would be a huge mistake (and huge >> vulnerability!) to behave otherwise. > > It’s a strong hint to the host stack to pick a different source address. You said "deprecate the invalid prefix if it has information to do so." -- selecting a different address is a very different thing than deprecating an address. In fact, for connection-less protocols that might not even make sense -- since it implies resending stuff that you might not even be able to resend (send buffer is gone). Besides, * You are assuming somebody will send an ICMPs. But they may not. * You are assuming that if they do, they will send code 5. But they may not. * You are assuming that code 5 is an indication of wrong address... but it may be an indication of incorrect route. * You are assuming that nodes will process icmp code 5 in one specific way. I don't know of any implementation that behaves in the way you describe. >>> Without getting into the multi-homing discussion and requiring hosts to “throw spaghetti on the wall”, I don’t see how your draft improves on that. >> >> Not sure what you mean. If the same router that advertised those >> prefixes doesn't advertise those prefixes anymore, why would you think >> they are still valid? > > Because that’s what the network previously advertised. > If source addresses from that prefix no longer works that’s a good hint to the host to try something else. There’s a list of heuristics the host must use. > > I still don’t see how your draft improves much on this. Can you explain? What our document wants to address is this: * Initially, unprefer addresses for the deprecated prefix. * subsequently, clean up the lagging addresses. One (more complex) way to achive this would be to e.g., wait for N * ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at least M RAs with PIOs have been received, but none of them contain PIOs for the (now invalid) prefix, deprecate the prefix. The solution we currently propose in the I-D is simpler, and just involves one additional bit per prefix in the local data structures. For a sample scenario, please check Appendix B of our draft. THe idea is simple: if two consecutive RAs with PIOs don't contain the previously-advertised prefix, un-prefer addresses for such prefix. Subsequently, once addresses have already been un-preferred, if you receive two additional RAs with PIOs that don't advertise the previously-advertised prefix, remove (invalidate) the corresponding addresses. So, after two RAs, the lagging addresses are not preferred anymore. After four RAs, you get rid 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 Sun Feb 3 07:26:33 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 845F012426A; Sun, 3 Feb 2019 07:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rzNMbsRregx; Sun, 3 Feb 2019 07:26:14 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37BA130F2C; Sun, 3 Feb 2019 07:26:14 -0800 (PST) Received: from astfgl.hanazo.no (77.16.218.19.tmi.telenormobil.no [77.16.218.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 8EB17FECC115; Sun, 3 Feb 2019 15:26:13 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 43831DF25F5; Sun, 3 Feb 2019 16:26:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ole Troan In-Reply-To: Date: Sun, 3 Feb 2019 16:26:08 +0100 Cc: Philip Homburg , "v6ops@ietf.org WG" , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> To: Fernando Gont X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 15:26:18 -0000 >>>=20 >>> Well, the problem is that you are making a contract on the LAN side = for >>> a contract you may not have on the WAN side. If the router reboots = and >>> the CEP no longer "owns" some prefix, then that contract is void. >>=20 >> You have the contract on the WAN side. What makes you think not. E.g = via PD learns that given prefix is valid until March 1 2020. >> A reboot doesn=E2=80=99t change that.=20 >>=20 >>> Ideally, the CPE will advertise that the contract is void. But it is >>> clear that for most deployed CPEs, that will not happen. >>=20 >> So a bug.=20 >> What you are talking about is the case where the ISP breaks the = contract. While it previously promised to delegate you a prefix until = 20200301, all trace of that has gone.=20 >=20 > The CPE is the middle-man between the ISP and the LAN. No matter what > you may *expect* the CPE to do, the CPE is currently not actually > required to e.g. clean after the contract that the ISP broke (if you > assume/think there's such a thing), or even adjust prefix timers > according to the DHCPv6 lease times -- talk about under-specification = of > the glue between e.g. DHCPv6-PD and SLAAC. RFC3633: Each prefix has an associated valid and preferred lifetime, which constitutes an agreement about the length of time over which the requesting router is allowed to use the prefix. A requesting router can request an extension of the lifetimes on a delegated prefix and is required to terminate the use of a delegated prefix if the valid lifetime of the prefix expires. This really isn=E2=80=99t hard. > Besides, the layer-8 contract between the user and the ISP may be that > you get dynamic prefixes. This means that whenever you request a = lease, > you get a different prefix. You might say that if you don't do another > DHCPv6-PD request, you should be able to use the same prefix. But if = you > do ask a new prefix, you might indeed get a new one -- and this is = what > normally happens after reboots. Not normally. That=E2=80=99s ISP allocation policy. And not recommended. But sure a correctly behaving DHCP PD implementation will include the = current prefixes in it=E2=80=99s request message. > The CPE should -- if possible -- be faithful to its LAN hosts, and > advertise if previous contracts between the CPE and the LAN hosts are > void. i.e., if the CPE does not get leased the same prefix as before, > it shoudl notifiy its "clients". However, possibly for simplicity = sake, > CPEs don't record what > information was previously advertised on the LAN -- they are not > required, so.... when they reboot, they may not not be in a position = to > notify hosts accordingly. >=20 > That's the environment hosts operate in -- no matter whether you or me > like it. >=20 > In that environment, hosts can and should be smarter. Sure. Hosts should always be smarter. That doesn=E2=80=99t mean an addressing policy which breaks connections = are not broken. >>>> What you seem to be talking about is either a bug a = misconfiguration or both.=20 >>>=20 >>> It's neither of those. If anything, it's the result of >>> under-specification of the necessary glue between automatic >>> configuration on the WAN side, and automatic configuration on the = LAN side. >>>=20 >>> e.g., there were no requirements for CPEs to keep track of prefixes = that >>> they have been leased in the past -- if at all possible. >>=20 >> DHCP PD will give you the old prefix back.=20 >=20 > Not necessarily. In fact, it may intentionally not do that. If you no > longer own the addresses, the sessions will have to be torn down. That=E2=80=99s not how IPv6 addressing and renumbering is intended to = work. I take it your goal isn=E2=80=99t to change that, but to improve the = situation where it unfortunately happens. (Which of course might encourage ISPs to do just that.) >>>> If you want something like session survivability, >>>> that=E2=80=99s not a trivial problem to solve. >>>=20 >>> Not sure what you mean by "session survivability" >>=20 >> Try to keep a TCP session active while changing addresses.=20 >=20 > Of course that's not what we're trying to solve here. No, but it is important to understand the implications of your work. >>>> Currently the network will give an ICMP destination unreachable = code 5 and deprecate the invalid prefix if it has information to do so. >>>=20 >>> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes? >>>=20 >>> Answer: Nowhere. They don't get to do that. All ICMPv6 error = messages >>> are soft errors. And it would be a huge mistake (and huge >>> vulnerability!) to behave otherwise. >>=20 >> It=E2=80=99s a strong hint to the host stack to pick a different = source address.=20 >=20 > You said "deprecate the invalid prefix if it has information to do = so." > -- selecting a different address is a very different thing than > deprecating an address. In fact, for connection-less protocols that > might not even make sense -- since it implies resending stuff that you > might not even be able to resend (send buffer is gone). No, I didn=E2=80=99t say that. I said the network will deprecate the prefix if it has information to = do. I.e. send a PIO with preferred lifetime =3D 0. And that the network will respond with a type 5 destination unreachable, = if an invalid source address is used. See BCP38. >=20 > Besides, >=20 > * You are assuming somebody will send an ICMPs. But they may not. Is it interesting discussion assumptions that aren=E2=80=99t part of the = specifications? >=20 > * You are assuming that if they do, they will send code 5. But they = may not. See above. >=20 > * You are assuming that code 5 is an indication of wrong address... = but > it may be an indication of incorrect route. No. >=20 > * You are assuming that nodes will process icmp code 5 in one specific > way. I don't know of any implementation that behaves in the way you > describe. Hosts can improve. My point was that it isn=E2=80=99t obivous that very much more can be = done from the network side. >>>> Without getting into the multi-homing discussion and requiring = hosts to =E2=80=9Cthrow spaghetti on the wall=E2=80=9D, I don=E2=80=99t = see how your draft improves on that.=20 >>>=20 >>> Not sure what you mean. If the same router that advertised those >>> prefixes doesn't advertise those prefixes anymore, why would you = think >>> they are still valid? >>=20 >> Because that=E2=80=99s what the network previously advertised.=20 >> If source addresses from that prefix no longer works that=E2=80=99s a = good hint to the host to try something else. There=E2=80=99s a list of = heuristics the host must use.=20 >>=20 >> I still don=E2=80=99t see how your draft improves much on this. Can = you explain? >=20 > What our document wants to address is this: >=20 > * Initially, unprefer addresses for the deprecated prefix. >=20 > * subsequently, clean up the lagging addresses. >=20 >=20 > One (more complex) way to achive this would be to e.g., wait for N * > ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at > least M RAs with PIOs have been received, but none of them contain = PIOs > for the (now invalid) prefix, deprecate the prefix. >=20 > The solution we currently propose in the I-D is simpler, and just > involves one additional bit per prefix in the local data structures. >=20 > For a sample scenario, please check Appendix B of our draft. THe idea = is > simple: if two consecutive RAs with PIOs don't contain the > previously-advertised prefix, un-prefer addresses for such prefix. > Subsequently, once addresses have already been un-preferred, if you > receive two additional RAs with PIOs that don't advertise the > previously-advertised prefix, remove (invalidate) the corresponding > addresses. >=20 > So, after two RAs, the lagging addresses are not preferred anymore. > After four RAs, you get rid of them. So the proposal is that an address is marked as not preferred after = anywhere between 6 and 20 minutes? I am not saying that we can=E2=80=99t and shouldn=E2=80=99t improve on = SLAAC=E2=80=A6 but I think we can do better. And existing heuristics are = better than this. Cheers, Ole= From nobody Sun Feb 3 08:01: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 A4D3212008F; Sun, 3 Feb 2019 08:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pJF0emmBlrK; Sun, 3 Feb 2019 08:01:36 -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 56EEC128CB7; Sun, 3 Feb 2019 08:01:35 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 31CBB84236; Sun, 3 Feb 2019 17:01:28 +0100 (CET) To: Ole Troan Cc: Philip Homburg , "v6ops@ietf.org WG" , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 3 Feb 2019 13:01:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 16:01:41 -0000 On 3/2/19 12:26, Ole Troan wrote: >>>> >>>> Well, the problem is that you are making a contract on the LAN side for >>>> a contract you may not have on the WAN side. If the router reboots and >>>> the CEP no longer "owns" some prefix, then that contract is void. >>> >>> You have the contract on the WAN side. What makes you think not. E.g via PD learns that given prefix is valid until March 1 2020. >>> A reboot doesn’t change that. >>> >>>> Ideally, the CPE will advertise that the contract is void. But it is >>>> clear that for most deployed CPEs, that will not happen. >>> >>> So a bug. >>> What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. >> >> The CPE is the middle-man between the ISP and the LAN. No matter what >> you may *expect* the CPE to do, the CPE is currently not actually >> required to e.g. clean after the contract that the ISP broke (if you >> assume/think there's such a thing), or even adjust prefix timers >> according to the DHCPv6 lease times -- talk about under-specification of >> the glue between e.g. DHCPv6-PD and SLAAC. > > RFC3633: > Each prefix has an associated valid and preferred lifetime, which > constitutes an agreement about the length of time over which the > requesting router is allowed to use the prefix. A requesting router > can request an extension of the lifetimes on a delegated prefix and > is required to terminate the use of a delegated prefix if the valid > lifetime of the prefix expires. > > This really isn’t hard. It's not hard. But it just doesn't happen in crash-and-reboot scenarios for most CPEs nowadays. >> Besides, the layer-8 contract between the user and the ISP may be that >> you get dynamic prefixes. This means that whenever you request a lease, >> you get a different prefix. You might say that if you don't do another >> DHCPv6-PD request, you should be able to use the same prefix. But if you >> do ask a new prefix, you might indeed get a new one -- and this is what >> normally happens after reboots. > > Not normally. That’s ISP allocation policy. > And not recommended. The RIPE document does not recommend it. In Germany, that's the expected default. At the end of the day, it's a policy. > But sure a correctly behaving DHCP PD implementation will include the current prefixes in it’s request message. But they may just not know what they were (unless the previously-leased prefix was recorded on stable storage). Or the DHCPv6 server might lease something else. >>>>> What you seem to be talking about is either a bug a misconfiguration or both. >>>> >>>> It's neither of those. If anything, it's the result of >>>> under-specification of the necessary glue between automatic >>>> configuration on the WAN side, and automatic configuration on the LAN side. >>>> >>>> e.g., there were no requirements for CPEs to keep track of prefixes that >>>> they have been leased in the past -- if at all possible. >>> >>> DHCP PD will give you the old prefix back. >> >> Not necessarily. In fact, it may intentionally not do that. If you no >> longer own the addresses, the sessions will have to be torn down. > > That’s not how IPv6 addressing and renumbering is intended to work. > I take it your goal isn’t to change that, but to improve the situation where it unfortunately happens. Exactly. We are trying to improve the situation when that happens. If possible, we'd like the situation to be avoided -- e.g., if you want dynamic prefixes, do so in an ordered way. But since we cannot rely on others behaving nicely, we want to make hosts more robust to these scenarios. > (Which of course might encourage ISPs to do just that.) > >>>>> If you want something like session survivability, >>>>> that’s not a trivial problem to solve. >>>> >>>> Not sure what you mean by "session survivability" >>> >>> Try to keep a TCP session active while changing addresses. >> >> Of course that's not what we're trying to solve here. > > No, but it is important to understand the implications of your work. Not sure what you mean. You mean the goal its not clearly stated? Something else? >>>>> Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so. >>>> >>>> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes? >>>> >>>> Answer: Nowhere. They don't get to do that. All ICMPv6 error messages >>>> are soft errors. And it would be a huge mistake (and huge >>>> vulnerability!) to behave otherwise. >>> >>> It’s a strong hint to the host stack to pick a different source address. >> >> You said "deprecate the invalid prefix if it has information to do so." >> -- selecting a different address is a very different thing than >> deprecating an address. In fact, for connection-less protocols that >> might not even make sense -- since it implies resending stuff that you >> might not even be able to resend (send buffer is gone). > > No, I didn’t say that. > I said the network will deprecate the prefix if it has information to do. I.e. send a PIO with preferred lifetime = 0. Who would be sending that, and in response to what? > And that the network will respond with a type 5 destination unreachable, if an invalid source address is used. See BCP38. Again: does this happen *in practice*? Besides: fgont@laptop:~$ curl -s https://tools.ietf.org/rfc/bcp/bcp38.txt | grep -P '(icmp|ICMP)' Similar attacks have been attempted using UDP and ICMP flooding. domain to reach their systems. The latter attack (ICMP flooding), >> Besides, >> >> * You are assuming somebody will send an ICMPs. But they may not. > > Is it interesting discussion assumptions that aren’t part of the specifications? > >> >> * You are assuming that if they do, they will send code 5. But they may not. > > See above. > >> >> * You are assuming that code 5 is an indication of wrong address... but >> it may be an indication of incorrect route. > > No. If the address failed ingress/egress policy you may have picked the wrong address or e.g. default route. >> * You are assuming that nodes will process icmp code 5 in one specific >> way. I don't know of any implementation that behaves in the way you >> describe. > > Hosts can improve. > My point was that it isn’t obivous that very much more can be done from the network side. CPEs can be required to advertise previously-advertised prefixes that are not valid anymore. And hosts can be improved so that they can detect that a prefix is no longer advertised, and hence shouldn't be used -- or, at the very least, should no longer be preferred. >> One (more complex) way to achive this would be to e.g., wait for N * >> ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at >> least M RAs with PIOs have been received, but none of them contain PIOs >> for the (now invalid) prefix, deprecate the prefix. >> >> The solution we currently propose in the I-D is simpler, and just >> involves one additional bit per prefix in the local data structures. >> >> For a sample scenario, please check Appendix B of our draft. THe idea is >> simple: if two consecutive RAs with PIOs don't contain the >> previously-advertised prefix, un-prefer addresses for such prefix. >> Subsequently, once addresses have already been un-preferred, if you >> receive two additional RAs with PIOs that don't advertise the >> previously-advertised prefix, remove (invalidate) the corresponding >> addresses. >> >> So, after two RAs, the lagging addresses are not preferred anymore. >> After four RAs, you get rid of them. > > So the proposal is that an address is marked as not preferred after anywhere between 6 and 20 minutes? No. It is marked as not preferred in less than one minute (RFC4861): For the first few advertisements (up to MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it becomes an advertising interface, if the randomly chosen interval is greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval for the initial advertisements increases the likelihood of a router being discovered quickly when it first becomes available, in the presence of possible packet loss. > I am not saying that we can’t and shouldn’t improve on SLAAC… but I think we can do better. And existing heuristics are better than this. What are the existing heuristics? If there was such a thing, there shouldn't be a problem in the first place. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 3 08:50: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 32CD8128CB7; Sun, 3 Feb 2019 08:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJzgPoeoOT0z; Sun, 3 Feb 2019 08:50:18 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621D9127598; Sun, 3 Feb 2019 08:50:18 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id k98so10254387otk.3; Sun, 03 Feb 2019 08: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:content-transfer-encoding; bh=9ygANistGw+fP7AJAPOtC3trzJ2+yE6XYUpj1eb3YKI=; b=QvuioKTzGaVcyS1ooZAZaQ9iIzz/7nBHLtF98gmt++mLlFSSuOWX/ysXNkUdxnt78l CGPBU2UQ4ShFPm7UBKdmWb3uBrWph9UJ7gvoyNJiIVZbwSAOiGO0T+Bwdzlg3yEMQsYy /gztAEsKh71oPyg+YBPXLSV4OuE0b4AngbmPTUuMi4amjT/iWCNUHF1KzPKfkqW+5cHL /lauq47+71By8T8JuMk2wYZ57ijV1+ZVpPOmJX4aDkKINoUSB9CSDXE19ivytp3SrT7r CLJg5pvLHuXyAOAdMz08U59XRcawRyJwy6GofbI0GebNW/J4XYZd36RrezjS6asEYw9n FA0g== 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:content-transfer-encoding; bh=9ygANistGw+fP7AJAPOtC3trzJ2+yE6XYUpj1eb3YKI=; b=R8+18tErPfSJy6X/+aadGHFn3xFb5cpJmwOMsFg5JfAv0W2IcGUTgOf1cps711rn4g oilQEy3rdPsPbC8iY+hiEpkr3RPaU4lB0xvLdUcrk+Y/4rUlAWa/I7As4fF6i3uGeaX+ cYykMmoO5sFDqNlw23YD6l0eua8ooJlEQeb+nSXnw4dGvs3SA3Kr5lv+HpwWcrbjHInW IjU5JBLWrFfWCU288iDgGIHdlJT3Q1if7L1/sC1y8OSA0u1Au+aa6ZT/N9tDCQLiBiEK LYKWhaLFY+VY8BW3ZIjbmLNRQTQ3kDFTK0o09GoMVDlFJyT0iuyHcGP4ED6qAHLL7mST 3stg== X-Gm-Message-State: AJcUukemVtwpD2vzuax3U95SbOHpNCpj84zwX5XXf0zfVhYe6GdvgJFL 7UvEM95wU5+lssNcUw1vJJrDoW39yEKaNAmb7eA= X-Google-Smtp-Source: ALg8bN7oZ7Fc1zQKT12NEm5u/TiJwGcBAdARUWpngD5sa1yBUkW8juni30nkBpcl+65lie4MfhNnPQHzE6whDm9G4Ms= X-Received: by 2002:a9d:3d42:: with SMTP id a60mr34733160otc.285.1549212617442; Sun, 03 Feb 2019 08:50:17 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> In-Reply-To: From: Mark Smith Date: Mon, 4 Feb 2019 03:49:49 +1100 Message-ID: To: Fernando Gont Cc: Ole Troan , v6ops list , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 16:50:21 -0000 On Mon, 4 Feb 2019 at 02:01, Fernando Gont wrote: > > On 3/2/19 09:27, Ole Troan wrote: > > > > > >> On 3 Feb 2019, at 12:49, Fernando Gont wrote: > >> > >>> On 3/2/19 07:32, Ole Troan wrote: > >>> > >>> > >>>> On 3 Feb 2019, at 05:29, Fernando Gont wrote= : > >>>> > >>>> On 2/2/19 08:57, Ole Troan wrote: > >>>>>> One question is whether it makes sense for routers to have valid l= ifetimes of > >>>>>> more than a day for prefixes that are obtained using DHCP-PD. > >>>>>> > >>>>>> Another is whether general purpose hosts should accept lifetimes o= f more > >>>>>> than a day. Maybe hosts should just truncate. > >>>>> > >>>>> The (original) intended lifetime for DHCP PD is a lifetime equal to= the length of the contract with your ISP. > >>>>> Lifetimes become meaningless with =E2=80=9Cflash renumbering=E2=80= =9D. Neither SLAAC nor DHCP PD is designed for that. > >>>>> > >>>>> The simple solution to this problem is =E2=80=9Cif it hurts, stop d= oing it=E2=80=9D. > >>>> > >>>> FWIW, lifetimes are mostly irrelevant to the problem that *we* are > >>>> discussing (which is rather orthogonal to the problem mentioned abov= e): > >>>> our case is that in which the router just reboots -- so no matter wh= at > >>>> the lifetime was, the information will be invalid anyway. > >>>> > >>> > >>> That=E2=80=99s not how SLAAC and PD are designed. Lifetimes are not i= nvalid just because of a router reboot. Look at advertised lifetimes as a s= ort of contract. > >> > >> Well, the problem is that you are making a contract on the LAN side fo= r > >> a contract you may not have on the WAN side. If the router reboots and > >> the CEP no longer "owns" some prefix, then that contract is void. > > > > You have the contract on the WAN side. What makes you think not. E.g vi= a PD learns that given prefix is valid until March 1 2020. > > A reboot doesn=E2=80=99t change that. > > > >> Ideally, the CPE will advertise that the contract is void. But it is > >> clear that for most deployed CPEs, that will not happen. > > > > So a bug. > > What you are talking about is the case where the ISP breaks the contrac= t. While it previously promised to delegate you a prefix until 20200301, al= l trace of that has gone. > > The CPE is the middle-man between the ISP and the LAN. No matter what > you may *expect* the CPE to do, the CPE is currently not actually > required to e.g. clean after the contract that the ISP broke (if you > assume/think there's such a thing), or even adjust prefix timers > according to the DHCPv6 lease times -- talk about under-specification of > the glue between e.g. DHCPv6-PD and SLAAC. > > Besides, the layer-8 contract between the user and the ISP may be that > you get dynamic prefixes. This means that whenever you request a lease, > you get a different prefix. You might say that if you don't do another > DHCPv6-PD request, you should be able to use the same prefix. But if you > do ask a new prefix, you might indeed get a new one -- and this is what > normally happens after reboots. That's against the architecture and design of the Internet protocols. A router reboot, anywhere along the path between communicating end-points, is supposed to have no more effect than a transient period of packet loss. Recovery is supposed to be via transport layer retransmission within the existing established connections. A first hop CPE rebooting and being given a different PD prefix is effectively changing a transient packet loss event into the movement of the CPE and its hosts to a different point of attachment to the network. That's the significance of what the ISP is imposing on their customers by having dynamic/unstable PD prefixes. It probably seems less significant than it really is because the links to the customers are virtual, e.g. PPPoE, rather than physical. > > The CPE should -- if possible -- be faithful to its LAN hosts, and > advertise if previous contracts between the CPE and the LAN hosts are > void. i.e., if the CPE does not get leased the same prefix as before, > it shoudl notifiy its "clients". However, possibly for simplicity sake, > CPEs don't record what > information was previously advertised on the LAN -- they are not > required, so.... when they reboot, they may not not be in a position to > notify hosts accordingly. > > That's the environment hosts operate in -- no matter whether you or me > like it. > > In that environment, hosts can and should be smarter. > > Multipath transport layer protocols for the win. They're splitting identifier semantics off from IP addresses. > > >>> What you seem to be talking about is either a bug a misconfiguration = or both. > >> > >> It's neither of those. If anything, it's the result of > >> under-specification of the necessary glue between automatic > >> configuration on the WAN side, and automatic configuration on the LAN = side. > >> > >> e.g., there were no requirements for CPEs to keep track of prefixes th= at > >> they have been leased in the past -- if at all possible. > > > > DHCP PD will give you the old prefix back. > > Not necessarily. In fact, it may intentionally not do that. If you no > longer own the addresses, the sessions will have to be torn down. > > > > > >>> If you want something like session survivability, > >>> that=E2=80=99s not a trivial problem to solve. > >> > >> Not sure what you mean by "session survivability" > > > > Try to keep a TCP session active while changing addresses. > > Of course that's not what we're trying to solve here. > > > > >>> Currently the network will give an ICMP destination unreachable code = 5 and deprecate the invalid prefix if it has information to do so. > >> > >> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes? > >> > >> Answer: Nowhere. They don't get to do that. All ICMPv6 error messages > >> are soft errors. And it would be a huge mistake (and huge > >> vulnerability!) to behave otherwise. > > > > It=E2=80=99s a strong hint to the host stack to pick a different source= address. > > You said "deprecate the invalid prefix if it has information to do so." > -- selecting a different address is a very different thing than > deprecating an address. In fact, for connection-less protocols that > might not even make sense -- since it implies resending stuff that you > might not even be able to resend (send buffer is gone). > > Besides, > > * You are assuming somebody will send an ICMPs. But they may not. > > * You are assuming that if they do, they will send code 5. But they may n= ot. > > * You are assuming that code 5 is an indication of wrong address... but > it may be an indication of incorrect route. > > * You are assuming that nodes will process icmp code 5 in one specific > way. I don't know of any implementation that behaves in the way you > describe. > > > > > >>> Without getting into the multi-homing discussion and requiring hosts = to =E2=80=9Cthrow spaghetti on the wall=E2=80=9D, I don=E2=80=99t see how y= our draft improves on that. > >> > >> Not sure what you mean. If the same router that advertised those > >> prefixes doesn't advertise those prefixes anymore, why would you think > >> they are still valid? > > > > Because that=E2=80=99s what the network previously advertised. > > If source addresses from that prefix no longer works that=E2=80=99s a g= ood hint to the host to try something else. There=E2=80=99s a list of heuri= stics the host must use. > > > > I still don=E2=80=99t see how your draft improves much on this. Can you= explain? > > What our document wants to address is this: > > * Initially, unprefer addresses for the deprecated prefix. > > * subsequently, clean up the lagging addresses. > > > One (more complex) way to achive this would be to e.g., wait for N * > ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at > least M RAs with PIOs have been received, but none of them contain PIOs > for the (now invalid) prefix, deprecate the prefix. > > The solution we currently propose in the I-D is simpler, and just > involves one additional bit per prefix in the local data structures. > > For a sample scenario, please check Appendix B of our draft. THe idea is > simple: if two consecutive RAs with PIOs don't contain the > previously-advertised prefix, un-prefer addresses for such prefix. > Subsequently, once addresses have already been un-preferred, if you > receive two additional RAs with PIOs that don't advertise the > previously-advertised prefix, remove (invalidate) the corresponding > addresses. > > So, after two RAs, the lagging addresses are not preferred anymore. > After four RAs, you get rid of them. > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sun Feb 3 09:15: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 2935B126DBF; Sun, 3 Feb 2019 09:14:52 -0800 (PST) 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VGRGoQwocjE; Sun, 3 Feb 2019 09:14:49 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2411200D7; Sun, 3 Feb 2019 09:14:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 469D3AF; Sun, 3 Feb 2019 18:14:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1549214087; bh=t6DkcpI8CksIeGMuELuJ6SLwFizQpfJUv0z2qZQ5+Mo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QIls2svbQ5FBAnN/EMcdqglwtgPcL6HmqT0B3KuiA0hCQmTKFiM0t3ieI1M2u5N/2 sAWYexH4UIdV9C2bRO6XEMr3UwkMqgcCBn3MwRxAwNqLSyv9dLFMTbTO1yTCWjgLHd t1jf5VHGkswy3/5/Bei2XDbhhvIS+Tn4PS1KP9OU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 425AB9F; Sun, 3 Feb 2019 18:14:47 +0100 (CET) Date: Sun, 3 Feb 2019 18:14:47 +0100 (CET) From: Mikael Abrahamsson To: Mark Smith cc: Fernando Gont , 6man WG , v6ops list In-Reply-To: Message-ID: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 17:14:52 -0000 On Mon, 4 Feb 2019, Mark Smith wrote: > A first hop CPE rebooting and being given a different PD prefix is > effectively changing a transient packet loss event into the movement of What about if it decides to choose a different /64 out of that /56? Do we cover this in any documents? The result to end systems is the same regardless if it's different /64 out of the /56 or if it's different /56. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Feb 3 09:41: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 4D4F41200D7; Sun, 3 Feb 2019 09:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDNHdx8Yp21l; Sun, 3 Feb 2019 09:40:49 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3155912008F; Sun, 3 Feb 2019 09:40:49 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 202A8843E6; Sun, 3 Feb 2019 18:40:44 +0100 (CET) To: Mark Smith Cc: Ole Troan , v6ops list , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 3 Feb 2019 14:03:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 17:40:52 -0000 On 3/2/19 13:49, Mark Smith wrote: [....] >>> So a bug. >>> What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. >> >> The CPE is the middle-man between the ISP and the LAN. No matter what >> you may *expect* the CPE to do, the CPE is currently not actually >> required to e.g. clean after the contract that the ISP broke (if you >> assume/think there's such a thing), or even adjust prefix timers >> according to the DHCPv6 lease times -- talk about under-specification of >> the glue between e.g. DHCPv6-PD and SLAAC. >> >> Besides, the layer-8 contract between the user and the ISP may be that >> you get dynamic prefixes. This means that whenever you request a lease, >> you get a different prefix. You might say that if you don't do another >> DHCPv6-PD request, you should be able to use the same prefix. But if you >> do ask a new prefix, you might indeed get a new one -- and this is what >> normally happens after reboots. > > That's against the architecture and design of the Internet protocols. > > A router reboot, anywhere along the path between communicating > end-points, is supposed to have no more effect than a transient period > of packet loss. Recovery is supposed to be via transport layer > retransmission within the existing established connections. If you change the addresses, all bets are off. Getting a different prefix might mean, in theory, that you¡re attached to a different point of the network topology. In any case, the debate here is how to improve things when such scenarios do happen. >> The CPE should -- if possible -- be faithful to its LAN hosts, and >> advertise if previous contracts between the CPE and the LAN hosts are >> void. i.e., if the CPE does not get leased the same prefix as before, >> it shoudl notifiy its "clients". However, possibly for simplicity sake, >> CPEs don't record what >> information was previously advertised on the LAN -- they are not >> required, so.... when they reboot, they may not not be in a position to >> notify hosts accordingly. >> >> That's the environment hosts operate in -- no matter whether you or me >> like it. >> >> In that environment, hosts can and should be smarter. > > > Multipath transport layer protocols for the win. They're splitting > identifier semantics off from IP addresses. That's mostly irrelevant -- because the thing here is to get rid of the invalid addresses which tends to be benefical for anything running on IP. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 3 09:41: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 C9A63130F32; Sun, 3 Feb 2019 09:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iclCK5UFUj-B; Sun, 3 Feb 2019 09:40:53 -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 E121012008F; Sun, 3 Feb 2019 09:40:52 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 A571184571; Sun, 3 Feb 2019 18:40:49 +0100 (CET) To: Mikael Abrahamsson , Mark Smith Cc: 6man WG , v6ops list References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com> Date: Sun, 3 Feb 2019 14:39:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 17:40:58 -0000 On 3/2/19 14:14, Mikael Abrahamsson wrote: > On Mon, 4 Feb 2019, Mark Smith wrote: > >> A first hop CPE rebooting and being given a different PD prefix is >> effectively changing a transient packet loss event into the movement of > > What about if it decides to choose a different /64 out of that /56? Do > we cover this in any documents? The result to end systems is the same > regardless if it's different /64 out of the /56 or if it's different /56. Agreed. In that case, if it is able to detect that the advertised prefix has changed, you might *expect* that it also advertises the original one with appropriate lifetimes. However, that implies that the prefix had been recorded in stable storage. And it all goes back to the same place: * expectations != requirements * Robustness has a lot to do with dealing with entities that might not behave nicely -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 3 09:46: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 07749124B0C; Sun, 3 Feb 2019 09:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrlZEpIUfscW; Sun, 3 Feb 2019 09:46:19 -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 022F31200D7; Sun, 3 Feb 2019 09:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1549215977; x=1549820777; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=of9nCQBiQVGSODxZ5DB7rdHAiH3Qf9J5POAoqhBDb6o=; b=rLDBE4BwbqbUa g62Y4Ydzy3Ve4BGt3gQ4di0q7UPwCOlP5UD+xE/KGv8l/kXE2pUYAyVMysENuqIp eKftVcHocScGsypSb1/IYhhkqhUEbzwS4MVBBHxB9mApPxx4qkMhrV7XEJ6Raeap 7prR9OKMl9PVFjdN8HdyWAm3Tw/zqw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 03 Feb 2019 18:46:17 +0100 X-Spam-Processed: mail.consulintel.es, Sun, 03 Feb 2019 18:46:16 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006139914.msg; Sun, 03 Feb 2019 18:46:15 +0100 X-MDRemoteIP: 2001:470:1f09:495:ec7e:caa4:9d9e:92d6 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Sun, 03 Feb 2019 18:46:15 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19377bc400=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Sun, 03 Feb 2019 18:46:11 +0100 From: JORDI PALET MARTINEZ To: Fernando Gont , Ole Troan CC: Philip Homburg , "v6ops@ietf.org WG" , 6man WG Message-ID: Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 17:46:22 -0000 The RIPE document does not recommend it. In Germany, that's the expected default. ----> This is not correct, in the context of another mailing list, a few day ago, some people (including people from Germany) confirmed that this is not true for Germany, neither there is any law or anything similar that requires dynamic prefixes. ********************************************** 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 nobody Sun Feb 3 10:30: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 F1435126BED; Sun, 3 Feb 2019 10:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POeaKnaN7PiC; Sun, 3 Feb 2019 10:30:16 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 17616124B0C; Sun, 3 Feb 2019 10:30:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43szsg4v4wz1KC9g; Sun, 3 Feb 2019 10:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1549218615; bh=/x8NrZZbcMEeJjJT/oEwG6IDVk5XiB/Bx+MtSpQ1oOA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=M0p9QTIgFv/ETnZs2U6a/IljvHQx7ORRjm5j1oZgavwD8Q7BrHdwzCps1MxNh1TlV YxSvdtUW8v8wfeHE1/MXdgX77UHYfoPEl3xudRouxK9vyWJ4M8N1vRauEor6oeZuuE xXa2UUCyi9ibYAThT2bID9M32/CQE8kRVQuwvv8s= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43szsc2qvXz1KC5m; Sun, 3 Feb 2019 10:30:12 -0800 (PST) To: Fernando Gont , Mikael Abrahamsson , Mark Smith Cc: v6ops list , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com> From: "Joel M. Halpern" Message-ID: <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> Date: Sun, 3 Feb 2019 13:30:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 18:30:18 -0000 I have been trying to follow the discussion. I think I have been able to reconstruct the problem being discussed. If I understand correctly, we are talking about CPE behavior when the CPE receives IPv6 prefixes via DHCP-PD, and then advertises prefixes for hust using RA PIO. The assumptions that I believe Fernando is making are: 1) The CPE Does not store its delegations across reboots. 2) The CPE crashes 3) The CPE requests a prefix from DHCP-PD 4) The CPE receives a different prefix than it received before. An Fernando seems to be saying that this results in the CPE violating its "contract" with the hosts from earlier PIO information. Given that if the CPE had stored the delegated prefix, it could have continued to use it, one could equally (and arguably with more justification) argue that the DHCP server violated its contract with the CPE when it did not return the still-valid prefix (with a correct lifetime). After all, the server madea "contract" when it handed over the address. Have I missed something in the "problem"? Robustness is nice. But let's not bend over backwards trying to fix a problem of multiple failures. Yours, Joel On 2/3/19 12:39 PM, Fernando Gont wrote: > On 3/2/19 14:14, Mikael Abrahamsson wrote: >> On Mon, 4 Feb 2019, Mark Smith wrote: >> >>> A first hop CPE rebooting and being given a different PD prefix is >>> effectively changing a transient packet loss event into the movement of >> >> What about if it decides to choose a different /64 out of that /56? Do >> we cover this in any documents? The result to end systems is the same >> regardless if it's different /64 out of the /56 or if it's different /56. > > Agreed. In that case, if it is able to detect that the advertised prefix > has changed, you might *expect* that it also advertises the original one > with appropriate lifetimes. However, that implies that the prefix had > been recorded in stable storage. > > And it all goes back to the same place: > > * expectations != requirements > * Robustness has a lot to do with dealing with entities that might not > behave nicely > > > From nobody Sun Feb 3 10:53: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 5E433126BED; Sun, 3 Feb 2019 10:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEkdQ11451PE; Sun, 3 Feb 2019 10:53:43 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07B5124B0C; Sun, 3 Feb 2019 10:53:42 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x13IrdXs052801 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2019 18:53:40 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: "Joel M. Halpern" Cc: v6ops list , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com> <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> From: Nick Hilliard Message-ID: Date: Sun, 3 Feb 2019 18:53:38 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.9 MIME-Version: 1.0 In-Reply-To: <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 18:53:46 -0000 Joel M. Halpern wrote on 03/02/2019 18:30: > Have I missed something in the "problem"?  Robustness is nice.  But > let's not bend over backwards trying to fix a problem of multiple failures. the issue is that when this happens, it causes a cascading failure situation which can only be fixed either by the end user manually prodding all the ipv6 interfaces on the network to refresh the prefix, or if the slaac prefix times out naturally across the home network. If this doesn't happen, the end user experience is going to be that ipv6 stops cat videos and I.M. apps from working properly. After a quick call-out, the family tech-support dude will cheerily confirm that this can be fixed by disabling ipv6, as she/he fumes while rebooting every goddamned device on the network because granny moved the cable modem and that jiggled the cable, third time this week (YU NO WORK??!?!?). Mikael pointed out a related problem that if the cpe is delegated a prefix via dhcp6-pd and splits this across multiple home networks, it needs to do this in a repeatable way so that even if the SP remembers what prefix it previously delegated, the CPE will divvy that up the same way it did before the reboot. For whatever sets of underlying reasons, this is a real world problem, which indicates that between CPE vendors and provisioning system vendors, there are problems which lead to end user loss of service. The IETF may well be able to offer reasonable guidance here. Nick From nobody Sun Feb 3 11:01: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 392521277D2; Sun, 3 Feb 2019 11:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, 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 jhk0x_4Toyz9; Sun, 3 Feb 2019 11:01:51 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BC1126BED; Sun, 3 Feb 2019 11:01:50 -0800 (PST) Received: from dooku.sandelman.ca (unknown [209.226.201.241]) by relay.sandelman.ca (Postfix) with ESMTPS id 70E2B1F8BE; Sun, 3 Feb 2019 19:01:48 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6C9BCFF2; Sun, 3 Feb 2019 14:01:24 -0500 (EST) From: Michael Richardson To: "Joel M. Halpern" cc: Fernando Gont , Mikael Abrahamsson , Mark Smith , v6ops list , 6man WG In-reply-to: <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com> <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Sun, 03 Feb 2019 13:30:08 -0500." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 03 Feb 2019 14:01:24 -0500 Message-ID: <31780.1549220484@dooku.sandelman.ca> Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 19:01:53 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > Given that if the CPE had stored the delegated prefix, it could have > continued to use it, one could equally (and arguably with more > justification) argue that the DHCP server violated its contract with > the CPE when it did not return the still-valid prefix (with a correct > lifetime). After all, the server madea "contract" when it handed over > the address. I mostly agree with your analysis. There are some additional situations that make this a bit murkier: 1) The CPE died and was replaced, reflashed, upgraded, etc. After which, it could well have a different DHCP DUID and the DHCP server thinks this is a different customer/device. This is hard to get wrong with PPPoE if one links the prefixes to the customer login (via radius or other). On cable it's easier to get wrong, particularly if the CPE failure results in the new one having a different ethernet address (ethernet randomization not always good or useful) 2) The ISP died and the user connected to a different ISP! The prefix is legitimately quite different. 3) The customer was moved to a different CMTS, with the result that really needs to be renumbered. I think that ISPs can do this correctly by setting correct lifetimes and doing some /60 routing until the lease expires, but... > Have I missed something in the "problem"? Robustness is nice. But > let's not bend over backwards trying to fix a problem of multiple > failures. I think that the flash write issue is really not that big a deal. It requires one write per renumber if done intelligently. Perhaps one can further enhance the heuristic to not bother if the lease time is less than a few hours: There are apparently jurisdictions where everyone gets renumbered at 1am, but in those places the lifetimes should be very small. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlxXOoMACgkQlUzhVv38 QpA6nAf+N08L6msPnk4NoNIeKjqodZ8NmZdH1PSnQ0910mQJVQhrIpihOYGRDHA8 B5LOkNCxvYw7XF+TaNmNrmIGU8p53fkATiRLWNWyNRlUybyQ4w5clL7uSHWWfGVT xaIdBgfVGX80qA6vKphKYYOYcVJECb1QGj8exDILm8umf39qn+p+k1T5Qc1B83sF CYzFapuqfMx2GWKJPOraXzOt0cXW39JRackJBW6jWYxfCOdj6V8fLGnHiUd3tNWo IzA0rFlTsA7OnwbE3molICsvISnZjb2qT5qhCEju1WRAU5vCjt7tLSylKC/LOb23 xbKExpbATwyw0aYqznoGGEBqLl1p0A== =PvBz -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 3 11:05: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 F101712870E for ; Sun, 3 Feb 2019 11:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEShtqpjWTMB for ; Sun, 3 Feb 2019 11:05:21 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7E21277D2 for ; Sun, 3 Feb 2019 11:05:21 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 42A6D418F7 for ; Sun, 3 Feb 2019 20:05:19 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 3034640D75; Sun, 3 Feb 2019 20:05:19 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1FBF983C8; Sun, 3 Feb 2019 20:05:19 +0100 (CET) Date: Sun, 3 Feb 2019 20:05:19 +0100 From: Gert Doering To: Nick Hilliard Cc: "Joel M. Halpern" , v6ops list , 6man WG Message-ID: <20190203190519.GY1543@Space.Net> References: <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com> <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 19:05:24 -0000 Hi, On Sun, Feb 03, 2019 at 06:53:38PM +0000, Nick Hilliard wrote: > The IETF may well be able to offer reasonable guidance here. But isn't much more fun to quarrel about semantics of some sentence in a long-dead RFC instead? Real world problems, experienced by real people out there, how uninteresting. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sun Feb 3 11:41:47 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 94A9F12D4EA; Sun, 3 Feb 2019 11:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4128YXybmswH; Sun, 3 Feb 2019 11:41:36 -0800 (PST) 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 395461277D2; Sun, 3 Feb 2019 11:41:36 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id b7so5745373pfi.8; Sun, 03 Feb 2019 11:41:36 -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=lYHH6JI1fM9hsvdkMG4igQvx7IyAnFUJR9lChxoaYgY=; b=f5rsQFn26T618pjceHcxFSS+B8TL4I6NGBQe3gC+Du1OReIJO6E+jstWPFnLcWSrhZ p7rwOeCeB3+GMdO+NYjd7WO4xjJUJv1tFFOZrOsNKNiLhMhMGN569X2VJtzJcegey7mN JwmYV6MSEuc5x/6m3TP+z58JurNUvrKkm1S0DO0ybmD9YG+BrZpmRYg5L3JgnYfE+xHP AsOijO0Jdr2JKhIY2wMIMDwQef6QT2tKz+fqGX+weBYLeiQzUycicxBhkLggA5ZcdBxg DxaqAATDi4JMIzsZj0aosxc0D6NDXXY5hBvt4BXdoKhYfef+UqfXbz66sEYCfs5QghSk 9l6w== 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=lYHH6JI1fM9hsvdkMG4igQvx7IyAnFUJR9lChxoaYgY=; b=hGDIcWLYbhhtyH0uyudADGlDhrXcs5D/TkI2RCcHgYJXzDa/o1gTHepCxKQUVJtdPs NOe7+pPbFCbQ31eJpcgyC+PiSOtheGGbNRDya28wSGLIGve+nJqVyBRBcVqVPx2DB85k lo28P7mn0wTL1MmMDaNqAOnqRslF6DuZ2iPbJtyCwWP8kTZPqtuFYh5xpdxAkOCMCd1B Oa67+TIcj1y8XnprYNwU5BkLBVCQnWOap/ASHT9jaQGqLB2I8KKF48GVzUj72xsSsdRI LDPj8d3tmcBvRa1UddUnaUPV7EWQBRN41TXs4tb+cvjcE5autBVjtDHyqeH1LOPayIcI 6SAw== X-Gm-Message-State: AHQUAuZoZnHTV25juME/2CqtSz2yf++Jc+FMMs34lhV1LO3SaTDFJJi0 ho7qZC6qeVURYXbrCPIGgTRE8S0q X-Google-Smtp-Source: AHgI3IZUjMX8j8xVKXUAjYNDIzZp193Q3WEF3jU0/esTM7/f2L+lM0XU9uVjxpF2qjb0kE3SE3tQkg== X-Received: by 2002:a63:330c:: with SMTP id z12mr9692108pgz.10.1549222895355; Sun, 03 Feb 2019 11:41:35 -0800 (PST) Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id g28sm19608394pfd.100.2019.02.03.11.41.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Feb 2019 11:41:34 -0800 (PST) To: JORDI PALET MARTINEZ , Fernando Gont , Ole Troan Cc: "v6ops@ietf.org WG" , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> From: Brian E Carpenter Message-ID: <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> Date: Mon, 4 Feb 2019 08:41:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 19:41:38 -0000 On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: > The RIPE document does not recommend it. In Germany, that's the expected > default. > > ----> This is not correct, in the context of another mailing list, a few day ago, some people (including people from Germany) confirmed that this is not true for Germany, neither there is any law or anything similar that requires dynamic prefixes. It doesn't matter. The objective fact is that getting a new prefix after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is common, and not just in Germany. Not that I've ever had any stale address problems as a result, even at a time when I was getting multiple ADSL disconnects per day due to a line fault. So with a FritzBox and Windows hosts, the "common problem" simply wasn't a problem. Brian From nobody Sun Feb 3 11:45: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 23D7212E036; Sun, 3 Feb 2019 11:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1BX0BCR6ZCoQ; Sun, 3 Feb 2019 11:45:55 -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 83FE5127598; Sun, 3 Feb 2019 11:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1549223152; x=1549827952; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=S69rl7h6AKT3Afyw01CyZAzlbQcURyMRxXXjEf1h8pE=; b=iXnN7/NuAnmkY eciGDEl1IpKr1nq/ZHCqwo9JTYlkW143F1sSL46IDhnnvmrwWUIfVjj/rNDimCSr n9Vg0VwhOCohqFWS0P10vi+iEXVTXf3FCd47EUz6IguGxb+JYlRo9pwXGpeH98Q6 O7xYQQXh9803SBzrQSa28oBEErIrtY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 03 Feb 2019 20:45:52 +0100 X-Spam-Processed: mail.consulintel.es, Sun, 03 Feb 2019 20:45:52 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006140166.msg; Sun, 03 Feb 2019 20:45:52 +0100 X-MDRemoteIP: 2001:470:1f09:495:ec7e:caa4:9d9e:92d6 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Sun, 03 Feb 2019 20:45:52 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=19377bc400=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.6.190114 Date: Sun, 03 Feb 2019 20:45:47 +0100 From: JORDI PALET MARTINEZ To: Brian E Carpenter CC: "v6ops@ietf.org WG" , 6man WG Message-ID: Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> In-Reply-To: <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 19:45:57 -0000 Agree. Just wanted to clarify that assertion, as I've heard it too many tim= es. AVM/Fritzbox, if I recall correctly is one of the very very very few vendor= s that write the prefix in the flash ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Brian E Carpenter Fecha: domingo, 3 de febrero de 2019, 20:41 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org WG" , 6man WG Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: > The RIPE document does not recommend it. In Germany, that's the e= xpected > default. > =20 > ----> This is not correct, in the context of another mailing list, a= few day ago, some people (including people from Germany) confirmed that th= is is not true for Germany, neither there is any law or anything similar th= at requires dynamic prefixes. =20 It doesn't matter. The objective fact is that getting a new prefix afte= r a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is = common, and not just in Germany. =20 Not that I've ever had any stale address problems as a result, even at = a time when I was getting multiple ADSL disconnects per day due to a line f= ault. So with a FritzBox and Windows hosts, the "common problem" simply was= n't a problem. =20 Brian =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 Sun Feb 3 12:02: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 79059127598; Sun, 3 Feb 2019 12:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCTLfne7Jis1; Sun, 3 Feb 2019 12:02:45 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BDD1277D2; Sun, 3 Feb 2019 12:02:45 -0800 (PST) Received: from [10.161.196.87] (77.18.52.87.tmi.telenormobil.no [77.18.52.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id BC797FECC093; Sun, 3 Feb 2019 20:02:44 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (16D39) In-Reply-To: Date: Sun, 3 Feb 2019 21:02:40 +0100 Cc: Brian E Carpenter , "v6ops@ietf.org WG" , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <5EC71546-5433-4A62-ABEF-C1181878B84B@employees.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> To: JORDI PALET MARTINEZ Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 20:02:48 -0000 > On 3 Feb 2019, at 20:45, JORDI PALET MARTINEZ wrote: >=20 > Agree. Just wanted to clarify that assertion, as I've heard it too many ti= mes. >=20 > AVM/Fritzbox, if I recall correctly is one of the very very very few vendo= rs that write the prefix in the flash ... And just to be clear. That=E2=80=99s of course not the only solution. Nor ne= cessarily the right solution.=20 Ole >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: Brian E Carpenter > Fecha: domingo, 3 de febrero de 2019, 20:41 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org WG" , 6man WG > Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios= >=20 >> On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: >> The RIPE document does not recommend it. In Germany, that's the expect= ed >> default. >>=20 >> ----> This is not correct, in the context of another mailing list, a few= day ago, some people (including people from Germany) confirmed that this is= not true for Germany, neither there is any law or anything similar that req= uires dynamic prefixes. >=20 > It doesn't matter. The objective fact is that getting a new prefix afte= r a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is c= ommon, and not just in Germany. >=20 > Not that I've ever had any stale address problems as a result, even at a= time when I was getting multiple ADSL disconnects per day due to a line fau= lt. So with a FritzBox and Windows hosts, the "common problem" simply wasn't= a problem. >=20 > Brian >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Feb 3 12:11: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 5CBEF1277D2 for ; Sun, 3 Feb 2019 12:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pIOd8bPWrKx for ; Sun, 3 Feb 2019 12:11:13 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2A3DC1286E7 for ; Sun, 3 Feb 2019 12:11:13 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx63.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gqO6e-00080R-OO for v6ops@ietf.org; Sun, 03 Feb 2019 21:11:11 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gqO6Y-0001MD-AX for v6ops@ietf.org; Sun, 03 Feb 2019 15:11:06 -0500 Received: (qmail 21799 invoked from network); 3 Feb 2019 20:10:55 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 Feb 2019 20:10:55 -0000 To: JORDI PALET MARTINEZ , Brian E Carpenter Cc: "v6ops@ietf.org WG" , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> Date: Sun, 3 Feb 2019 10:10:54 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.08) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5j3qR+ctGT+FqYVnEpVI0/V602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9AxXYwQvUdzYsUuSZZty9ePmVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5kOBMxD5VtLQHqGLqtq4lLk5EpHPznVavQp4h 1cyzxbRC4xvs/7iGgDKhZ45D5vihvZAdx4vjUFLh0kXGIOazxFpgLxqZUFZdwbOLffZB9SIbeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80DrsibCyBr x+YtCB8oetqRijWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SK/lIPtlUiBhTzlv5XU8Y E2iH1Wgh6RAenBR+licROGbTzrWUA+sbAUoZv9wXXmR3Pv2wFW7cRg5wGUVDFK6Y1rcd2g/OoHOl qirR5B5iR5pk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlsfj3cQFz5QBYZW/yDwrWuVZYSpQQtCkh8qZ SV0LCxteW/AsEVtqyiqAJdSHh5MTh1KLSMePB4ksgJ9VFNcB74Yhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK//KzSfzfwEldM3jWkCPmDu9UshveVgoiypAicYsWUtd9a2LHJVD1n7GG0fP 4s+aIo4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 20:11:17 -0000 If the source address is allocated from a deprecated prefix, or an unknown prefix, the router cannot forward the packet. The router should send an ICMPv6 message, but from my quick reading of the RFC I could not find a code that said "the destination is unreachable because you are using a source address allocated from a deprecated prefix." The closest would be "Code =3D 5, source address failed ingress/egress policy", but that feels like an approximation. An appropriate error code would help the source device might take some corrective action, like for example solicit an RA and configure an address with an up-to-date prefix. A specific connection might fail, but by the time little Johnny tries again a new source address would be available and the cat video will play fine. That seems a lot less frustrating than calling ISP support... -- Christian Huitema On 2/3/2019 9:45 AM, JORDI PALET MARTINEZ wrote: > Agree. Just wanted to clarify that assertion, as I've heard it too many= times. > > AVM/Fritzbox, if I recall correctly is one of the very very very few ve= ndors that write the prefix in the flash ... > > Regards, > Jordi > =20 > =20 > > =EF=BB=BF-----Mensaje original----- > De: Brian E Carpenter > Fecha: domingo, 3 de febrero de 2019, 20:41 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org WG" , 6man WG > Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenar= ios > > On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: > > The RIPE document does not recommend it. In Germany, that's t= he expected > > default. > > =20 > > ----> This is not correct, in the context of another mailing lis= t, a few day ago, some people (including people from Germany) confirmed t= hat this is not true for Germany, neither there is any law or anything si= milar that requires dynamic prefixes. > =20 > It doesn't matter. The objective fact is that getting a new prefix = after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hour= s, is common, and not just in Germany. > =20 > Not that I've ever had any stale address problems as a result, even= at a time when I was getting multiple ADSL disconnects per day due to a = line fault. So with a FritzBox and Windows hosts, the "common problem" si= mply wasn't a problem. > =20 > Brian > =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= confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disc= losure, 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 recipi= ent be aware that any disclosure, copying, distribution or use of the con= tents of this information, even if partially, including attached files, i= s strictly prohibited, will be considered a criminal offense, so you must= reply to the original sender to inform about this communication and dele= te it. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sun Feb 3 12:19: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 675241277CC; Sun, 3 Feb 2019 12:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQER2jFbGV13; Sun, 3 Feb 2019 12:19:18 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314801277D2; Sun, 3 Feb 2019 12:19:18 -0800 (PST) Received: from [10.161.196.87] (77.18.52.87.tmi.telenormobil.no [77.18.52.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 6308CFECBEBC; Sun, 3 Feb 2019 20:19:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (16D39) In-Reply-To: <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> Date: Sun, 3 Feb 2019 21:19:15 +0100 Cc: JORDI PALET MARTINEZ , Brian E Carpenter , "v6ops@ietf.org WG" , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> To: Christian Huitema Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 20:19:20 -0000 Christian, The router cannot in its RPF check determine the reason for the wrong source= address. If its spoofed or a previously valid address. Therefore code 5.=20= Ole > On 3 Feb 2019, at 21:10, Christian Huitema wrote: >=20 > If the source address is allocated from a deprecated prefix, or an > unknown prefix, the router cannot forward the packet. The router should > send an ICMPv6 message, but from my quick reading of the RFC I could not > find a code that said "the destination is unreachable because you are > using a source address allocated from a deprecated prefix." The closest > would be "Code =3D 5, source address failed ingress/egress policy", but > that feels like an approximation. >=20 > An appropriate error code would help the source device might take some > corrective action, like for example solicit an RA and configure an > address with an up-to-date prefix. A specific connection might fail, but > by the time little Johnny tries again a new source address would be > available and the cat video will play fine. That seems a lot less > frustrating than calling ISP support... >=20 > -- Christian Huitema >=20 >> On 2/3/2019 9:45 AM, JORDI PALET MARTINEZ wrote: >> Agree. Just wanted to clarify that assertion, as I've heard it too many t= imes. >>=20 >> AVM/Fritzbox, if I recall correctly is one of the very very very few vend= ors that write the prefix in the flash ... >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >> De: Brian E Carpenter >> Fecha: domingo, 3 de febrero de 2019, 20:41 >> Para: JORDI PALET MARTINEZ >> CC: "v6ops@ietf.org WG" , 6man WG >> Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenario= s >>=20 >>> On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: >>> The RIPE document does not recommend it. In Germany, that's the expec= ted >>> default. >>>=20 >>> ----> This is not correct, in the context of another mailing list, a fe= w day ago, some people (including people from Germany) confirmed that this i= s not true for Germany, neither there is any law or anything similar that re= quires dynamic prefixes. >>=20 >> It doesn't matter. The objective fact is that getting a new prefix aft= er a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is c= ommon, and not just in Germany. >>=20 >> Not that I've ever had any stale address problems as a result, even at= a time when I was getting multiple ADSL disconnects per day due to a line f= ault. So with a FritzBox and Windows hosts, the "common problem" simply wasn= 't a problem. >>=20 >> Brian >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Feb 3 12:38: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 C6583126C7E; Sun, 3 Feb 2019 12:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, 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 olvqlOxT_qVk; Sun, 3 Feb 2019 12:38:46 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AFB11228B7; Sun, 3 Feb 2019 12:38:46 -0800 (PST) Received: from dooku.sandelman.ca (unknown [209.226.201.241]) by relay.sandelman.ca (Postfix) with ESMTPS id 12C631F8BE; Sun, 3 Feb 2019 20:38:43 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2A2D0B82; Sun, 3 Feb 2019 15:38:17 -0500 (EST) From: Michael Richardson To: Nick Hilliard cc: "Joel M. Halpern" , v6ops list , 6man WG In-reply-to: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com> <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> Comments: In-reply-to Nick Hilliard message dated "Sun, 03 Feb 2019 18:53:38 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 03 Feb 2019 15:38:17 -0500 Message-ID: <5489.1549226297@dooku.sandelman.ca> Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 20:38:48 -0000 --=-=-= Content-Type: text/plain Nick Hilliard wrote: > Mikael pointed out a related problem that if the cpe is delegated a > prefix via dhcp6-pd and splits this across multiple home networks, it > needs to do this in a repeatable way so that even if the SP remembers > what prefix it previously delegated, the CPE will divvy that up the > same way it did before the reboot. openwrt gets this right. > For whatever sets of underlying reasons, this is a real world problem, > which indicates that between CPE vendors and provisioning system > vendors, there are problems which lead to end user loss of service. The > IETF may well be able to offer reasonable guidance here. I agree, and having a write up of the issues (as simple as you related them), would be good, as it would give ISPs something to point at when CPE vendors get it wrong. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlxXUTgACgkQlUzhVv38 QpBQzwgAql6r8Mphhe7/Nman5qGXZxx9hxJyCKgaCsZKufgrK1KWPqSiKL4DrR40 rWMBQBSa/qdWRy4jH2xKG+Ts7+UqnKr+bNMKHAhyVOus9OIgT5YBBGCt/5TtqAGi ig6Hl37kxf8xsihr3Rw8BNBE73/yUCh16MrT+Qq/Yun0J0Bcfez0uZz+AeyfLUJA CFHJj1rySAOkfQk0JVkZnjL0W21Em6203rz+i+6gs+57Hdwtd/c6b6HFcWwP5Q35 1RlOtlZTX2QVBWf8N30HL+0knhwGVLs9bPEejd4MrV3KqXWUpuakj9ahnnCVATfd KHZGuWts7XSu99Zvby8yQmLxaZ90fA== =z0Bz -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 3 12:56: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 82522126C7E; Sun, 3 Feb 2019 12:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, 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 zS47QylfxLhB; Sun, 3 Feb 2019 12:56:39 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA62127133; Sun, 3 Feb 2019 12:56:38 -0800 (PST) Received: from dooku.sandelman.ca (unknown [209.226.201.241]) by relay.sandelman.ca (Postfix) with ESMTPS id D3D2F1F8BE; Sun, 3 Feb 2019 20:56:36 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id B094CB82; Sun, 3 Feb 2019 15:56:09 -0500 (EST) From: Michael Richardson To: Ole Troan cc: Christian Huitema , "v6ops\@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ In-reply-to: <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> Comments: In-reply-to Ole Troan message dated "Sun, 03 Feb 2019 21:19:15 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 03 Feb 2019 15:56:09 -0500 Message-ID: <6440.1549227369@dooku.sandelman.ca> Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 20:56:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ole Troan wrote: > The router cannot in its RPF check determine the reason for the wrong > source address. If its spoofed or a previously valid address. Therefo= re > code 5. Right... if the router knew it was the previously valid address, then it would know what it was, and could have sent a lifetime=3D0 deprecate out... (did I follow you correctly?) > Ole >> On 3 Feb 2019, at 21:10, Christian Huitema >> wrote: >> >> If the source address is allocated from a deprecated prefix, or an >> unknown prefix, the router cannot forward the packet. The router >> should send an ICMPv6 message, but from my quick reading of the RFC I >> could not find a code that said "the destination is unreachable >> because you are using a source address allocated from a deprecated >> prefix." The closest would be "Code =3D 5, source address failed >> ingress/egress policy", but that feels like an approximation. >> >> An appropriate error code would help the source device might take so= me >> corrective action, like for example solicit an RA and configure an >> address with an up-to-date prefix. A specific connection might fail, >> but by the time little Johnny tries again a new source address would >> be available and the cat video will play fine. That seems a lot less >> frustrating than calling ISP support... >> >> -- Christian Huitema >> >>> On 2/3/2019 9:45 AM, JORDI PALET MARTINEZ wrote: Agree. Just wanted >>> to clarify that assertion, as I've heard it too many times. >>> >>> AVM/Fritzbox, if I recall correctly is one of the very very very few >>> vendors that write the prefix in the flash ... >>> >>> Regards, Jordi >>> >>> >>> >>> =EF=BB=BF-----Mensaje original----- De: Brian E Carpenter >>> Fecha: domingo, 3 de febrero de 2019, >>> 20:41 Para: JORDI PALET MARTINEZ CC: >>> "v6ops@ietf.org WG" , 6man WG Asunt= o: >>> Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios >>> >>>> On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: The RIPE document >>>> does not recommend it. In Germany, that's the expected default. >>>> ----> This is not correct, in the context of another mailing list, a few ----> day ago, some people (including people from Germany) confirmed th= at ----> this is not true for Germany, neither there is any law or anything ----> similar that requires dynamic prefixes. >>> >>> It doesn't matter. The objective fact is that getting a new prefix >>> after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 >>> hours, is common, and not just in Germany. >>> >>> Not that I've ever had any stale address problems as a result, even >>> at a time when I was getting multiple ADSL disconnects per day due = to >>> a line fault. So with a FritzBox and Windows hosts, the "common >>> problem" simply wasn't a problem. >>> >>> Brian >>> >>> >>> >>> >>> ********************************************** >>> 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 y= ou >>> are not the intended recipient be aware that any disclosure, copyin= g, >>> 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. >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlxXVWkACgkQlUzhVv38 QpDj6Qf/RiTu/Pab/qmV6jkyzVSEUF/N+C/kE28nUc3o8vOVVP/XtMOJGBqJ7HwL vqAOvTgUZpZwVHsoCldpsVngTR9PPcbUBsdTilzJGaaJrbZhuA3ND5K1A29XxyM6 RyLpYXaX9R+lD1AYYeoufEWg3r1jvtJkC8zYkO00oAV+eIVJLo/EM2jw2VNfjpo0 1hEDq/lw24ggK7I4et/L4cPAAJk6CggHYw0VC9oy9UHNn+2JaDJHms7Nyxv0DRup d8LhsYmNTUmdC3SIWtxc2PEgOsHE7RnCoPM1B0QaqI2a0DqVYv/s6mHcos96qVHP cacHFjV/p44Sx7bsa0W4SKDGPUfRcQ== =xMYE -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 3 13:43: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 B3A3C126C7E; Sun, 3 Feb 2019 13:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7j8n5BPteKz; Sun, 3 Feb 2019 13:43:51 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A687F128CF2; Sun, 3 Feb 2019 13:43:51 -0800 (PST) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id F1013FECC10E; Sun, 3 Feb 2019 21:43:50 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 7B710DF5AE4; Sun, 3 Feb 2019 22:43:47 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ole Troan In-Reply-To: <6440.1549227369@dooku.sandelman.ca> Date: Sun, 3 Feb 2019 22:43:46 +0100 Cc: Christian Huitema , "v6ops@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ Content-Transfer-Encoding: quoted-printable Message-Id: <85C3CE49-93CC-48E1-94FB-46A0203783A2@employees.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <6440.1549227369@dooku.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 21:43:55 -0000 >> The router cannot in its RPF check determine the reason for the wrong >> source address. If its spoofed or a previously valid address. = Therefore >> code 5. >=20 > Right... if the router knew it was the previously valid address, then = it > would know what it was, and could have sent a lifetime=3D0 deprecate = out... >=20 > (did I follow you correctly?) Yes. Of course it might do both. Cheers, Ole >=20 >>> On 3 Feb 2019, at 21:10, Christian Huitema >>> wrote: >>>=20 >>> If the source address is allocated from a deprecated prefix, or an >>> unknown prefix, the router cannot forward the packet. The router >>> should send an ICMPv6 message, but from my quick reading of the RFC = I >>> could not find a code that said "the destination is unreachable >>> because you are using a source address allocated from a deprecated >>> prefix." The closest would be "Code =3D 5, source address failed >>> ingress/egress policy", but that feels like an approximation. >>>=20 >>> An appropriate error code would help the source device might take = some >>> corrective action, like for example solicit an RA and configure an >>> address with an up-to-date prefix. A specific connection might fail, >>> but by the time little Johnny tries again a new source address would >>> be available and the cat video will play fine. That seems a lot less >>> frustrating than calling ISP support... >>>=20 >>> -- Christian Huitema >>>=20 >>>> On 2/3/2019 9:45 AM, JORDI PALET MARTINEZ wrote: Agree. Just wanted >>>> to clarify that assertion, as I've heard it too many times. >>>>=20 >>>> AVM/Fritzbox, if I recall correctly is one of the very very very = few >>>> vendors that write the prefix in the flash ... >>>>=20 >>>> Regards, Jordi >>>>=20 >>>>=20 >>>>=20 >>>> =EF=BB=BF-----Mensaje original----- De: Brian E Carpenter >>>> Fecha: domingo, 3 de febrero de 2019, >>>> 20:41 Para: JORDI PALET MARTINEZ CC: >>>> "v6ops@ietf.org WG" , 6man WG = Asunto: >>>> Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios >>>>=20 >>>>> On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: The RIPE document >>>>> does not recommend it. In Germany, that's the expected default. >>>>>=20 > ----> This is not correct, in the context of another mailing list, = a few > ----> day ago, some people (including people from Germany) = confirmed that > ----> this is not true for Germany, neither there is any law or = anything > ----> similar that requires dynamic prefixes. >>>>=20 >>>> It doesn't matter. The objective fact is that getting a new prefix >>>> after a CPE reboot, or after a DSL disconnect/reconnect, or every = 24 >>>> hours, is common, and not just in Germany. >>>>=20 >>>> Not that I've ever had any stale address problems as a result, even >>>> at a time when I was getting multiple ADSL disconnects per day due = to >>>> a line fault. So with a FritzBox and Windows hosts, the "common >>>> problem" simply wasn't a problem. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ********************************************** >>>> IPv4 is over Are you ready for the new Internet ? >>>> http://www.theipv6company.com The IPv6 Company >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>=20 >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Sun Feb 3 16:08: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 2244412F19D for ; Sun, 3 Feb 2019 16:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3Z8n7toHT6Z for ; Sun, 3 Feb 2019 16:08:04 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2DB98126F72 for ; Sun, 3 Feb 2019 16:08:04 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gqRnt-000gLb-Ru for v6ops@ietf.org; Mon, 04 Feb 2019 01:08:02 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gqRnn-00010J-D1 for v6ops@ietf.org; Sun, 03 Feb 2019 19:07:59 -0500 Received: (qmail 29438 invoked from network); 4 Feb 2019 00:07:52 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Feb 2019 00:07:52 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16C101) In-Reply-To: <85C3CE49-93CC-48E1-94FB-46A0203783A2@employees.org> Date: Sun, 3 Feb 2019 14:07:50 -1000 Cc: Michael Richardson , "v6ops@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ Content-Transfer-Encoding: quoted-printable Message-Id: <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <6440.1549227369@dooku.sandelman.ca> <85C3CE49-93CC -48E1-94FB-46A0203783A2@employees.org> To: Ole Troan X-Originating-IP: 168.144.250.215 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.04) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5oBhQfmFSfycR+1XThqEkQp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9AxdsPCrFYHXT6jA5t3Pwk+dFDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5+lC8ScYqqrIKKgZkuEMYGaXe0Of4jddu9xC8 8+iQ5nb7LoaTAX7mj3bIh4FDz/DsTWjvPyjQw0UjfF+Jrlh6iu5FWD3Fo0oXNNKNfWMJhMmBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQviUSfAdJk YJaAlfzQz6q7eKBmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsiW9oFktVPzI6hjS2b07n6nEnix/VaU47nUhRtloJq3YVpl15XLs+NN wqsEJsuDxs3FVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNuW3bv1nPfn3AWXq7M22DtZ0 Dg9K+vwGh2YhLXUzLTJYs7W549ydvqZDiFMXDyPJeJtfWUfKlmRxQlLE/MsS4KDozswVgmo2tH4W 8yU3FuMqsjQyQl5BLbVDtpxmW72Fk6RBNbNatc7DssJAYrVaZ9s8CVsONrMJuGzuoGnKTKcyyDl+ Iey4xwZiQVVdRpyDl2jeRXywq1EjZ4XBR1ffqAuf3MLbn7l3g+Lh7r9C5nLMRGxQZAxG+4f1XAVN zQl2yky2ZS50wJ+lQ+LaxBNJUp6t2ykfuEOAy+YBuZa3mFPXkVWClPVvbW5lVyQanRxw5p2JYH/6 BohvTRmOq56pXi2xVeaE7wHMAOKzNxZH1vP9C0T1BLTNamueI0y1oJZKcQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 00:08:07 -0000 On Feb 3, 2019, at 11:43 AM, Ole Troan wrote: >>> The router cannot in its RPF check determine the reason for the wrong >>> source address. If its spoofed or a previously valid address. Therefore >>> code 5. >>=20 >> Right... if the router knew it was the previously valid address, then it >> would know what it was, and could have sent a lifetime=3D0 deprecate out.= .. >>=20 >> (did I follow you correctly?) >=20 > Yes. Of course it might do both. OK. But then the host knows that it is not engaged in address spoofing, so i= t could decide to do something about it. That still would be better than cal= ling support. -- Christian Huitema=20= From nobody Sun Feb 3 16:27: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 779FD130DF1; Sun, 3 Feb 2019 16:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iduWvXrzonb4; Sun, 3 Feb 2019 16:27:00 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1BC130DEF; Sun, 3 Feb 2019 16:27:00 -0800 (PST) Received: from [192.168.10.191] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id A8209FECC093; Mon, 4 Feb 2019 00:26:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (16D39) In-Reply-To: <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net> Date: Mon, 4 Feb 2019 01:26:57 +0100 Cc: Michael Richardson , "v6ops@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ Content-Transfer-Encoding: quoted-printable Message-Id: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <6440.1549227369@dooku.sandelman.ca> <85C3CE49-93CC -48E1-94FB-46A0203783A2@employees.org> <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net> To: Christian Huitema Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 00:27:04 -0000 > On 4 Feb 2019, at 01:07, Christian Huitema wrote: >=20 >=20 > On Feb 3, 2019, at 11:43 AM, Ole Troan wrote: >=20 >>>> The router cannot in its RPF check determine the reason for the wrong >>>> source address. If its spoofed or a previously valid address. Therefore= >>>> code 5. >>>=20 >>> Right... if the router knew it was the previously valid address, then it= >>> would know what it was, and could have sent a lifetime=3D0 deprecate out= ... >>>=20 >>> (did I follow you correctly?) >>=20 >> Yes. Of course it might do both. >=20 > OK. But then the host knows that it is not engaged in address spoofing, so= it could decide to do something about it. That still would be better than c= alling support. Well, this is caused by the ISP, so perhaps the call should be the recommend= ed action. :-) Ole= From nobody Sun Feb 3 16:52: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 E647E130E00; Sun, 3 Feb 2019 16:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 QKiRU7jHlozt; Sun, 3 Feb 2019 16:52:11 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2D512008A; Sun, 3 Feb 2019 16:52:10 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id t204so10210500oie.7; Sun, 03 Feb 2019 16:52: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:content-transfer-encoding; bh=+344JPRjp84QU4/cZxE/sL/u7b/oCoY5sgRzoZ4Nw60=; b=A0kdSYely+8dxfNI2gVuWz9LxXADscbIDhfIiapcI2gWxlb2KkMGx86AOED7yTyJqB TcX4/kXca7uqUznOsFW8TziwDKoWHa/uszB/6WuqxNXYKj4OaKojObvx9vx2Ql3vFfFK i41sVlGtSgGigOWZZpvK3DjnWYbylZf31QdLdSiFXT17Q8CxkkLcJgYwUFCHMWgA8eIv LNkxSGzZnzQXlW8NhCBznx5E+h0rlyD2FLKOHQH1No/OPkopolv0Ug5hdRcGGoPN5g4t NewpshUYaUKWOSnVyIkkcaIZjxncyaXVqp9+gr3boqa1q7ZVF3iHMWZTOUM4hBB+Uzlk cZgw== 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:content-transfer-encoding; bh=+344JPRjp84QU4/cZxE/sL/u7b/oCoY5sgRzoZ4Nw60=; b=k1GFJfKVCruj53XEkvzc4+n3fza5UQVbtJq+mzu88oLuXU9W39nu8UFXUldfxSOZl2 EN4/R5GphP/uhyS72YKLLqX4e0CY46qol+KhcFnLhBqKBaIqvKo7paLFW5AIgfk3YKmI Rypx6ln9lkqaYFgOiK5flDG3CEpg/tx8gf5owUFZQnayQ2Q++gUO3eXjOZPMR1GZSb9g /fOwEqBBIzAT04LQcjkhu5QrsDcyxqZgaj/jsOpeRh9c4QgRZJbIXcaypEfWzUNKDy9W ydx8pLgkSV7ksqSZFDTJUYEnDPJKN+alJDR1fpJUcIFzX3JdMfqJ20GTqOMTqaOUpv83 tzuA== X-Gm-Message-State: AJcUukee4Oid15uIiIBw0jj5M1LY/woTUTBqcKqAb4cxEhvDzKAeViF1 C5/BqHxlNOd8XnKE/NIy/flIuqIRCA7C95i6VeM= X-Google-Smtp-Source: ALg8bN6XK6lI2ry/zKsgGve4VcO9NbNK9R0+4tz0T+p4qXStzxJyVWFOeCJVrHel9ikZjUdHlfXwYbSgMb6ZIGxen2Y= X-Received: by 2002:aca:f5ce:: with SMTP id t197mr23799748oih.311.1549241529467; Sun, 03 Feb 2019 16:52:09 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> In-Reply-To: From: Mark Smith Date: Mon, 4 Feb 2019 11:51:42 +1100 Message-ID: To: Fernando Gont Cc: Ole Troan , v6ops list , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 00:52:13 -0000 On Mon, 4 Feb 2019 at 04:40, Fernando Gont wrote: > > On 3/2/19 13:49, Mark Smith wrote: > [....] > >>> So a bug. > >>> What you are talking about is the case where the ISP breaks the contr= act. While it previously promised to delegate you a prefix until 20200301, = all trace of that has gone. > >> > >> The CPE is the middle-man between the ISP and the LAN. No matter what > >> you may *expect* the CPE to do, the CPE is currently not actually > >> required to e.g. clean after the contract that the ISP broke (if you > >> assume/think there's such a thing), or even adjust prefix timers > >> according to the DHCPv6 lease times -- talk about under-specification = of > >> the glue between e.g. DHCPv6-PD and SLAAC. > >> > >> Besides, the layer-8 contract between the user and the ISP may be that > >> you get dynamic prefixes. This means that whenever you request a lease= , > >> you get a different prefix. You might say that if you don't do another > >> DHCPv6-PD request, you should be able to use the same prefix. But if y= ou > >> do ask a new prefix, you might indeed get a new one -- and this is wha= t > >> normally happens after reboots. > > > > That's against the architecture and design of the Internet protocols. > > > > A router reboot, anywhere along the path between communicating > > end-points, is supposed to have no more effect than a transient period > > of packet loss. Recovery is supposed to be via transport layer > > retransmission within the existing established connections. > > If you change the addresses, all bets are off. Getting a different > prefix might mean, in theory, that you=C2=A1re attached to a different po= int > of the network topology. > > In any case, the debate here is how to improve things when such > scenarios do happen. > > So I think it is worth finding out exactly why ISPs are doing this, to then work out what the best solution or solutions are. Are they doing it 1. because they're used to giving residential IPv4 customers dynamic addresses by default, so they've carried that practice over to IPv6 without realising there are different and avoidable consequences? 2. their employer charges a premium for static address assignment in IPv4, and their employer assumes or expects, possibly implicitly, to do the same with IPv6? 3. because PD privacy e.g. German example? 4. to suit occasional flash renumbering? 5. ??? In some of these cases, education may be a better, easier and quicker solution in comparison to the years it'd take to deploy CPE behaviour changes. I put options in radvd that tried to mitigate this nearly 10 years ago (DeprecatePrefix, DecrementLifetimes), as radvd was popular in IPv6 CPE I was working with at the time. Assuming radvd is still popularly used, if those options haven't been widely enabled and are not well known, then that might indicate an education and expectations problem. Ultimately though, the residential ISP I worked for decided to give up the specialness and price premium of static addresses and gives all customers their own persistent stable PD prefix tied to PPPoE username. I've had the same one at home for 7 years. > > >> The CPE should -- if possible -- be faithful to its LAN hosts, and > >> advertise if previous contracts between the CPE and the LAN hosts are > >> void. i.e., if the CPE does not get leased the same prefix as before, > >> it shoudl notifiy its "clients". However, possibly for simplicity sake= , > >> CPEs don't record what > >> information was previously advertised on the LAN -- they are not > >> required, so.... when they reboot, they may not not be in a position t= o > >> notify hosts accordingly. > >> > >> That's the environment hosts operate in -- no matter whether you or me > >> like it. > >> > >> In that environment, hosts can and should be smarter. > > > > > > Multipath transport layer protocols for the win. They're splitting > > identifier semantics off from IP addresses. > > That's mostly irrelevant -- because the thing here is to get rid of the > invalid addresses which tends to be benefical for anything running on IP. > > I don't think it is. Invalid addresses become far less of an issue when a transport layer connection doesn't depend on a single address at each end and that it is valid all of the time. Regards, Mark. From nobody Sun Feb 3 17:14: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 17234130DE4; Sun, 3 Feb 2019 17:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 kcrol6000OSX; Sun, 3 Feb 2019 17:14:20 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6F712D4EC; Sun, 3 Feb 2019 17:14:20 -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 1C1103AB004; Mon, 4 Feb 2019 01:14:20 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D4845160054; Mon, 4 Feb 2019 01:14:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AEC5116006C; Mon, 4 Feb 2019 01:14:19 +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 rNDoLVN68oD1; Mon, 4 Feb 2019 01:14:19 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id AABC8160054; Mon, 4 Feb 2019 01:14:18 +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: Mon, 4 Feb 2019 12:14:15 +1100 Cc: Fernando Gont , 6man WG , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> To: Mark Smith X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:14:23 -0000 CPE=E2=80=99s need both stable prefixes and temporary prefixes. We = really should just describe how to achieve both with PD as currently specified as it = is possible. We also need to be able to tag prefixes as intentionally = temporary on the LAN side so node can preference those prefixes for temporary = address use over choosing a temporary address from an otherwise stable prefix. ISP=E2=80=99s should be expecting CPE=E2=80=99s to request multiple = prefixes with PD and should return them. The CPE keeps renewing the =E2=80=9Cstable=E2=80=9D = prefix, the temporary prefix gets rolled to a new prefix periodically by the CPE with overlap = between the old and new prefix. Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Feb 3 17:16: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 C8570126F72; Sun, 3 Feb 2019 17:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ishBuVzRBOg2; Sun, 3 Feb 2019 17:16:53 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04751126C7E; Sun, 3 Feb 2019 17:16:53 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id a77so10243601oii.5; Sun, 03 Feb 2019 17:16:52 -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=R+rjw0BWcP0AvZv4wBpFrbg6qDnqeBRBR/wUOSmiJwA=; b=lsdanqjZ70rq1TIgo4P358Kq3TqppQCGUYHL/YhfKWCPUoxDXAtbIGyciN82jk97gw WBV5c0D3Y1gDEKiJwWWheA7vv1afyhNIdcfKACa7FEyKOeymci44ClEdHc1RdqD2qL9M WMbJ5eyJ+hLucnp086EuUkDa/rBSofuD8Q6UhL9yYSKuMJkjw40l90CHshCpCvcJPF33 MglDHjUSmui536xCzDRdKEXhwRxemXVGMRxN7nMZDsAD/lWZr9nmjfci69l9Ro14ZG+1 iRcnFnbeROfoO8NeryWGA59Hfj7hZ6JzqyOpJNQHdEP7CRLtTlnPTqgvQOM7i8/Bbdbk YfSg== 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=R+rjw0BWcP0AvZv4wBpFrbg6qDnqeBRBR/wUOSmiJwA=; b=bS3BFhrG/72Sz6cE2oLR862ZjRdqkf05VEqFryQb7w5g6z8F7LjJc+/mAGmWkFoAJ0 m3ACnUcSYXF+G+Skzy3CRGBDYpoK5Qg+1jF6jdlbcm+BPOoO+X1DOTXOBL3lLNix3LwL hGh65w51BalCd/2hWOdlAwLDIbq74+GR2vO19LpR2yOLfwssp+u+wJdzdpmgyVseSY8a o81/9QEBIA+b2I4WYg71zT1MaJZzxqFnIkNUGBLM5+JVChNoyuVFSYSoV1KzRMe62qK0 jLBluw66owSXbR5oT7hezk65cM0yIWAAEcZnY3ArkTBkLyg2u/yWroTzHmg7CNzLF2OQ Elfg== X-Gm-Message-State: AHQUAuYf/TI60ADM1W7xKnINq1LOlgUFSPiaFZv3OWasUQGzQksP22TA ccjBiUwvXKNljowSV9+3RG+5q1JrzD21BZkWVVoMMg== X-Google-Smtp-Source: ALg8bN4HZFO6Z0tCC0/gPLuSCornpVyFiaNAP8IBjUFC/rJ+v7kzfjnm6FLlG0uZE/YM7kFO4e9r1CC0aeLYYs5HQys= X-Received: by 2002:aca:2807:: with SMTP id 7mr25559832oix.7.1549243012132; Sun, 03 Feb 2019 17:16:52 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> In-Reply-To: From: Mark Smith Date: Mon, 4 Feb 2019 12:16:25 +1100 Message-ID: To: Mikael Abrahamsson Cc: Fernando Gont , 6man WG , v6ops list Content-Type: multipart/alternative; boundary="00000000000068b5f50581073f82" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:16:55 -0000 --00000000000068b5f50581073f82 Content-Type: text/plain; charset="UTF-8" On Mon., 4 Feb. 2019, 04:14 Mikael Abrahamsson On Mon, 4 Feb 2019, Mark Smith wrote: > > > A first hop CPE rebooting and being given a different PD prefix is > > effectively changing a transient packet loss event into the movement of > > What about if it decides to choose a different /64 out of that /56? Do we > cover this in any documents? The result to end systems is the same > regardless if it's different /64 out of the /56 or if it's different /56. > Are there ones doing that? The effect would be the same. Hosts are effectively having their network location changed because the only valid available prefix(es) is/are new one(s). I'm doing a well overdue (on my part) review of rfc4941bis. Privacy addresses are in some regards effectively doing this too, because applications' transport layer connections cannot persist longer than the privacy addresses' valid lifetime. The difference is that privacy addresses are expected to have a minimum valid lifetime that is larger than the longest expected transport layer connection duration that uses a privacy address. Regards, Mark. > --00000000000068b5f50581073f82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon., 4 Feb. 2019, 04:14 Mikael Abrahamsson <swmike@sw= m.pp.se wrote:
On Mon, 4 Feb 20= 19, Mark Smith wrote:

> A first hop CPE rebooting and being given a different PD prefix is > effectively changing a transient packet loss event into the movement o= f

What about if it decides to choose a different /64 out of that /56? Do we <= br> cover this in any documents? The result to end systems is the same
regardless if it's different /64 out of the /56 or if it's differen= t /56.

Are the= re ones doing that? The effect would be the same. Hosts are effectively hav= ing their network location changed because the only valid available prefix(= es) is/are new one(s).

I= 'm doing a well overdue (on my part) review of rfc4941bis. Privacy addr= esses are in some regards effectively doing this too, because applications&= #39; transport layer connections cannot persist longer than the privacy add= resses' valid lifetime.

The diffe= rence is that privacy addresses are expected to have a minimum valid lifeti= me that is larger than the longest expected transport layer connection dura= tion that uses a privacy address.

Regards,
Mark.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
--00000000000068b5f50581073f82-- From nobody Sun Feb 3 19:12: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 A20A1130DC9; Sun, 3 Feb 2019 19:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brBA21BxwP1D; Sun, 3 Feb 2019 19:11:52 -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 975721294FA; Sun, 3 Feb 2019 19:11:50 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 1BFA98376E; Mon, 4 Feb 2019 04:11:45 +0100 (CET) To: "Joel M. Halpern" , Mikael Abrahamsson , Mark Smith Cc: v6ops list , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com> <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 3 Feb 2019 20:44:28 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 03:11:54 -0000 On 3/2/19 15:30, Joel M. Halpern wrote: > I have been trying to follow the discussion.  I think I have been able > to reconstruct the problem being discussed. > > If I understand correctly, we are talking about CPE behavior when the > CPE receives IPv6 prefixes via DHCP-PD, and then advertises prefixes for > hust using RA PIO.  The assumptions that I believe Fernando is making are: > > 1) The CPE Does not store its delegations across reboots. > 2) The CPE crashes > 3) The CPE requests a prefix from DHCP-PD > 4) The CPE receives a different prefix than it received before. Yes. Or any variation of this that leads to the same behaviour -- e.g., the CPE does not cap the prefix lifetime according to the DHCPv6 lease, and only sends one RA with PIO lifetime=0 at the time a new prefix is leased -- but that RA is lost and not received by some nodes. > An Fernando seems to be saying that this results in the CPE violating > its "contract" with the hosts from earlier PIO information. Well, the CPE cannot respect the contract in somehow it does not get leased the same prefix, and it failed to cap the prefix lifetimes accordingly, wither. > Given that if the CPE had stored the delegated prefix, it could have > continued to use it, one could equally (and arguably with more > justification) argue that the DHCP server violated its contract with the > CPE when it did not return the still-valid prefix (with a correct > lifetime).  After all, the server madea "contract" when it handed over > the address. As far as the DHCPv6 server is concerned, I guess the argument could be: you got a different prefix because you asked for a new leased. Had you not asked a new lease, you could have continued using the previous one -- but you just didn't know about it, because you didn't record it on stable storage. > Have I missed something in the "problem"?  Robustness is nice.  But > let's not bend over backwards trying to fix a problem of multiple failures. There are multiple reasons for which this may happen. THe interaction on the WAN side and LAN side is largely unaddressed. So while we could "expect" things from the CPEs that "would just make sense", we haven't helped the situation by the lack of advice on how automatic configuration on LAN and WAN sides are glued together. Some of those devices are part of the installed base, and are not going to go away anytime soon. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 3 19:12: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 95E89130E64; Sun, 3 Feb 2019 19:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVOIGnCGYal9; Sun, 3 Feb 2019 19:11: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 F01D01294FA; Sun, 3 Feb 2019 19:11:54 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 A4446843E6; Mon, 4 Feb 2019 04:11:50 +0100 (CET) To: Brian E Carpenter , JORDI PALET MARTINEZ , Ole Troan Cc: "v6ops@ietf.org WG" , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <70b415e1-9f59-6066-7ebb-604c5e3058ad@si6networks.com> Date: Sun, 3 Feb 2019 20:47:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 03:12:01 -0000 On 3/2/19 16:41, Brian E Carpenter wrote: > On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: >> The RIPE document does not recommend it. In Germany, that's the expected >> default. >> >> ----> This is not correct, in the context of another mailing list, a few day ago, some people (including people from Germany) confirmed that this is not true for Germany, neither there is any law or anything similar that requires dynamic prefixes. > > It doesn't matter. The objective fact is that getting a new prefix after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is common, and not just in Germany. Exactly. > Not that I've ever had any stale address problems as a result, even at a time when I was getting multiple ADSL disconnects per day due to a line fault. So with a FritzBox and Windows hosts, the "common problem" simply wasn't a problem. FritzBox used to generate RAs that would disable the outdated prefixes in response to packets with a source address that it didn't like. See: http://blog.si6networks.com/2016/02/quiz-weird-ipv6-traffic-on-local-network.html That may explain why you didn't have stale addresses :-) 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 Sun Feb 3 19:20: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 B6233130DC9; Sun, 3 Feb 2019 19:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe4xt2u9VXEk; Sun, 3 Feb 2019 19:20:21 -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 8D6EC1294FA; Sun, 3 Feb 2019 19:20:20 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 44117843F4; Mon, 4 Feb 2019 04:11:56 +0100 (CET) To: Ole Troan , Christian Huitema Cc: "v6ops@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <2d919f5d-672f-9319-2757-cfff86a0ff50@si6networks.com> Date: Sun, 3 Feb 2019 20:51:07 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 03:20:22 -0000 On 3/2/19 17:19, Ole Troan wrote: > Christian, > > The router cannot in its RPF check determine the reason for the wrong source address. If its spoofed or a previously valid address. Therefore code 5. Before anybody proposes reactions to code 5, please remember that GTSM is *not* enforced on ICMP errors, nor dor they ned to use any specific source address. i.e., they are trivial to spoof, and make an obvious attack vector unless simply considered "soft errors". -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 3 21:44: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 92E6D1294FA for ; Sun, 3 Feb 2019 21:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOIr1iHJ-yu2 for ; Sun, 3 Feb 2019 21:44:25 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 BA870130E09 for ; Sun, 3 Feb 2019 21:44:24 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gqX3O-0002nr-0O for v6ops@ietf.org; Mon, 04 Feb 2019 06:44:22 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gqX3J-0003ua-Kd for v6ops@ietf.org; Mon, 04 Feb 2019 00:44:20 -0500 Received: (qmail 3200 invoked from network); 4 Feb 2019 05:44:16 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Feb 2019 05:44:15 -0000 To: Fernando Gont , Ole Troan Cc: "v6ops@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <2d919f5d-672f-9319-2757-cfff86a0ff50@si6networks.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6e077b15-073a-3c55-1a77-6f49f8b3b648@huitema.net> Date: Sun, 3 Feb 2019 19:44:13 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <2d919f5d-672f-9319-2757-cfff86a0ff50@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.232 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vAfvG2/689f/hOQIwzqDzR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9Ax7HgQm9qm8gMJzTL7ePMEulDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j52/TRjU7znIc9NYfKkdzfqE5EpHPznVavQp4h 1cyzxbRC4xvs/7iGgDKhZ45D5vihvZAdx4vjUFLh0kXGIOazxFpgLxqZUFZdwbOLffZB9SIbeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80DrsibCyBr x+YtCB8oetqRijWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SK/lIPtlUiBhTzlv5XU8Y E2iH1Wgh6RAenBR+licROGbb9y5lhVnKiPvVFZv0JHJZKTljjPEP7+GUCRDYjFFovX9Y7/Iap/GD 4/Gc3zEaYc9qJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+elpXlXsYEKiOTsiESb6idaDg5/bq7ChmPMN Ycw1QSmR0N5CDPOnAGGFQCPJ6lg5HnnejzWYK11qYIJRi2Wj1Zdm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhiimxcJ9s1w9uxbJROTdpUdu+NTKQHNkjJg8xvPcdYB8X9H4DectLaqn7kLkt Zo9lq/27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 05:44:27 -0000 On 2/3/2019 1:51 PM, Fernando Gont wrote: > On 3/2/19 17:19, Ole Troan wrote: >> Christian, >> >> The router cannot in its RPF check determine the reason for the wrong = source address. If its spoofed or a previously valid address. Therefore c= ode 5.=20 > Before anybody proposes reactions to code 5, please remember that GTSM > is *not* enforced on ICMP errors, nor dor they ned to use any specific > source address. i.e., they are trivial to spoof, and make an obvious > attack vector unless simply considered "soft errors". Sure. But then, devices can the code 5 Dest Unreachable ICMP as a hint. They could for example solicit an RA, and check what prefixes are currently advertised. If they learn a new prefix, they might want to configure an additional address. -- Christian Huitema From nobody Sun Feb 3 22:59: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 1BA2B130DE4; Sun, 3 Feb 2019 22:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiPQqwu16kw0; Sun, 3 Feb 2019 22:58:02 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292DA126CC7; Sun, 3 Feb 2019 22:58:02 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id 81so11359868otj.2; Sun, 03 Feb 2019 22:58: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=MzDyh1S9t2tpeo8WWZtGjITCYsFLc4Q91qh+JmNkxFE=; b=RC8HY176WI+bc61uRQ14y77HXRFea1+UqEAMRfatg0kuBIPlaKG2RxBwVxqLsUswie pPkNXdogmOYkRagNxEvbO/Z8YlHBXcn4faO1jo1gJZqiQcIgUh4xdXdr45nH9F1dYHQr BbRu2Pd0DIiTSLLvtitDwajkuvvjAnp38YCC0B99NsSXoq9pHgsTJQ91zr4u9e9mxO0t jXkhlRYOLTFvcQMa3pCJmOgmeUS2C2rp9Pm//WB961pc9ebaion21EPj0R8cKN9FOfz3 +xx9QXmgPLIgKk4vCq+vNYdqK8OSuYr5POKhzF5clfnaXwrX0MtJ6TIpodQFDMBjONa1 ljwg== 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=MzDyh1S9t2tpeo8WWZtGjITCYsFLc4Q91qh+JmNkxFE=; b=oxp0117xyKTn8V8L+DDzBkrQh/Wjfs/zxMr7KCON7fHQ5tEtxCVENcXzSXoQ6N9+O7 vK8hRnUaXUdqZGEk2PFmm3WX/GGs3WV3Q7em93TrklRBIKvZ/3LvJNLdl9z6RrwOYnIJ cSRJQju+5i1o1Q5LIagBx4+sfrQLlKx0R2bhcQHOBNnjvy4J5nxe072PM0EveHhmX0AK +0Ep4WBIaGJD/dx+5tgjAuWUCXGRWM3L/kg37unTFE/59E+WT2D5VHnB4gYAVSwKBfk5 ripN35DNagmSWoC+WeA6KDsOaLTR+o1s5d+z0FJOkBfvFN6Zo97Wj0TkfpXWPgp5wMwR 315Q== X-Gm-Message-State: AHQUAuaPXe9JLyO+M6C2Fkj7Q4HcROarBc9sS6xXcB6Kb3J8LvUkBcqd lVUIYnGlXtn62fedanvPohmvncQFLvfPojnbo28BmQ== X-Google-Smtp-Source: ALg8bN7MmLPD0cKRbfRvAIy7KrN1pC4qLs8JEcNhp/GEN96QizdMznin/QSbdKG7xkJmIBta4wMnYtR0DpsvfV/CZtA= X-Received: by 2002:aca:2807:: with SMTP id 7mr26100155oix.7.1549263481205; Sun, 03 Feb 2019 22:58:01 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <2d919f5d-672f-9319-2757-cfff86a0ff50@si6networks.com> <6e077b15-073a-3c55-1a77-6f49f8b3b648@huitema.net> In-Reply-To: <6e077b15-073a-3c55-1a77-6f49f8b3b648@huitema.net> From: Mark Smith Date: Mon, 4 Feb 2019 17:57:49 +1100 Message-ID: To: Christian Huitema Cc: Fernando Gont , Ole Troan , "v6ops@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ Content-Type: multipart/alternative; boundary="00000000000075f88305810c0333" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 06:58:04 -0000 --00000000000075f88305810c0333 Content-Type: text/plain; charset="UTF-8" On Mon., 4 Feb. 2019, 16:44 Christian Huitema > On 2/3/2019 1:51 PM, Fernando Gont wrote: > > On 3/2/19 17:19, Ole Troan wrote: > >> Christian, > >> > >> The router cannot in its RPF check determine the reason for the wrong > source address. If its spoofed or a previously valid address. Therefore > code 5. > > Before anybody proposes reactions to code 5, please remember that GTSM > > is *not* enforced on ICMP errors, nor dor they ned to use any specific > > source address. i.e., they are trivial to spoof, and make an obvious > > attack vector unless simply considered "soft errors". > > Sure. But then, devices can the code 5 Dest Unreachable ICMP as a hint. > They could for example solicit an RA, and check what prefixes are > currently advertised. If they learn a new prefix, they might want to > configure an additional address. > Possibly a prefix deprecating RA could be sent in parallel to the ICMP message, rather than waiting for the host to solicit one. It could be unicast, or probably more usefully multicast, rate limited. The deprecated prefix length of the old prefix would need to be assumed, probably quite accurately to be the common prefix length of the newer prefixes on the interface, and likely /64. A unicast deprecating RA with a /128 PIO that matches the source address is an interesting idea, although probably wouldn't work, because I assume there is prefix length checking upon lifetime updating when receiving PIOs. Regards, Mark. > -- Christian Huitema > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000075f88305810c0333 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Mon., 4 Feb. 2019, 16:44 Christian Huitema <huitema@huitema.net wrote:

On 2/3/2019 1:51 PM, Fernando Gont wrote:
> On 3/2/19 17:19, Ole Troan wrote:
>> Christian,
>>
>> The router cannot in its RPF check determine the reason for the wr= ong source address. If its spoofed or a previously valid address. Therefore= code 5.
> Before anybody proposes reactions to code 5, please remember that GTSM=
> is *not* enforced on ICMP errors, nor dor they ned to use any specific=
> source address. i.e., they are trivial to spoof, and make an obvious > attack vector unless simply considered "soft errors".

Sure. But then, devices can the code 5 Dest Unreachable ICMP as a hint.
They could for example solicit an RA, and check what prefixes are
currently advertised. If they learn a new prefix, they might want to
configure an additional address.

Possibly a prefix deprecating RA could be s= ent in parallel to the ICMP message, rather than waiting for the host to so= licit one. It could be unicast, or probably more usefully multicast, rate l= imited.

The deprecated p= refix length of the old prefix would need to be assumed, probably quite acc= urately to be the common prefix length of the newer prefixes on the interfa= ce, and likely /64.

A un= icast deprecating RA with a /128 PIO that matches the source address is an = interesting idea, although probably wouldn't work, because I assume the= re is prefix length checking upon lifetime updating when receiving PIOs.


Regards,
Mark.


-- Christian Huitema


_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000075f88305810c0333-- From nobody Sun Feb 3 23:29: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 487731292F1; Sun, 3 Feb 2019 23:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBCShOMTOvmK; Sun, 3 Feb 2019 23:29:45 -0800 (PST) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9B7126CC7; Sun, 3 Feb 2019 23:29:45 -0800 (PST) Received: from [2a02:c0:2:90:443:6:0:1000] (port=52472 helo=sloth.fud.no) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1gqYhK-0007RQ-HK; Mon, 04 Feb 2019 08:29:42 +0100 To: Brian E Carpenter , JORDI PALET MARTINEZ , Fernando Gont , Ole Troan Cc: "v6ops@ietf.org WG" , 6man WG References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> From: Tore Anderson Message-ID: <822850f0-12b3-d29d-6fcc-7739f11897ec@fud.no> Date: Mon, 4 Feb 2019 08:29:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 07:29:47 -0000 * Brian E Carpenter > It doesn't matter. The objective fact is that getting a new prefix after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is common, and not just in Germany. > > Not that I've ever had any stale address problems as a result, even at a time when I was getting multiple ADSL disconnects per day due to a line fault. So with a FritzBox and Windows hosts, the "common problem" simply wasn't a problem. If I recall correctly, the FritzBox I used to own would immediately send a few RAs with PIO timers=0 after receiving a packet from the LAN with a source address from a unknown prefix. Thus it didn't have to worry about remembering the previous delegated prefixes across a crash+reboot, as it would be reminded about it and get the opportunity to invalidate it the second a host tried to use it. That approach didn't work very well in networks with multiple routers, of course... This was 7-8 years ago, things might have changed since then. Tore From nobody Mon Feb 4 20:15:29 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 15A3A129AB8; Mon, 4 Feb 2019 20:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRDyKtdDWbVG; Mon, 4 Feb 2019 20:15:25 -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 00235130FF5; Mon, 4 Feb 2019 20:15:24 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 590158749E; Tue, 5 Feb 2019 05:07:54 +0100 (CET) To: Christian Huitema , Ole Troan Cc: "v6ops@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <2d919f5d-672f-9319-2757-cfff86a0ff50@si6networks.com> <6e077b15-073a-3c55-1a77-6f49f8b3b648@huitema.net> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Tue, 5 Feb 2019 01:07:25 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <6e077b15-073a-3c55-1a77-6f49f8b3b648@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 04:15:27 -0000 On 4/2/19 02:44, Christian Huitema wrote: > > On 2/3/2019 1:51 PM, Fernando Gont wrote: >> On 3/2/19 17:19, Ole Troan wrote: >>> Christian, >>> >>> The router cannot in its RPF check determine the reason for the wrong source address. If its spoofed or a previously valid address. Therefore code 5. >> Before anybody proposes reactions to code 5, please remember that GTSM >> is *not* enforced on ICMP errors, nor dor they ned to use any specific >> source address. i.e., they are trivial to spoof, and make an obvious >> attack vector unless simply considered "soft errors". > > Sure. But then, devices can the code 5 Dest Unreachable ICMP as a hint. > They could for example solicit an RA, and check what prefixes are > currently advertised. If they learn a new prefix, they might want to > configure an additional address. Isn't this a more complicated way of doing what we're proposing in our document? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 6 14:28: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 7A665130EED for ; Wed, 6 Feb 2019 14:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 QaQzC4hIYIAq for ; Wed, 6 Feb 2019 14:28:31 -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 1A1ED130EE9 for ; Wed, 6 Feb 2019 14:28:31 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id e12so14921680otl.5 for ; Wed, 06 Feb 2019 14:28:31 -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=gnHt1cAxTQsk+mD5ky6V87JH7q57tp0RpVwXWzs50SU=; b=UP3IDd/+eBmzsRw5/xeoVH7zK90Xv9+aCTl3of0YvOkvCsAl/Qir2yfjtFdb7v0Q+s nS4O2LrVJ9NSD9OKrtgXr98HixnXyAx69thgnGs+f9JT2aCpAyz75DQ0+xnfX7DGMlTY 3GhXQi5oiorZoPT5kx388JaLJ5FvEfAFTJs1bCorSId3RX12P2D4f3Zfk37L7PZDtxqL BfMTYcLaDa4FMd95pbUTCwndjhP7Nf2ap1IJvVk8aqbdMyRugz47AsULa+7nExaQ2xBF OI1ccCbmedTL38cLzSI0DTH98oMYIyTYfXDbdnGyhcnT6dG1cdN5pfXvE964xIeuB91Z pxbQ== 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=gnHt1cAxTQsk+mD5ky6V87JH7q57tp0RpVwXWzs50SU=; b=uODkPrCsakFt6xGyrDhog7En8bUdo11I/x0iT+tieW3FIZCuSW1p61E1hg5TQWZcve z9Lhq2jbea06T0EaWdp6C8VgrCjoxSYppqmzB6ILosd417oVpFhLgZxIf+Wu3KiGnO6l 0/rzQ1oxisYVSHGsJJPWoAQmr3lT1VH2uDPyU4DCEXtif2zFAT7+PL1CgVw2lBCcwpZi tkT4kvQ8mxxnXQYFzgNqGMzckZwGcYPW2jcMxYI3o5oux+rbIXLJlyby+m41/bxBufl6 fX0t0EOrUMUciTa9hawB5/XnjsLIKVr440IRQTBwHuYdDVVv1sl1YKiXsfpD12DzIk6a FL2Q== X-Gm-Message-State: AHQUAuYQN9KJiw2Dksjdqj1cBl2zA/sPVK0YGk4K4ESp+tLfVckovr4H Gvbf4zVtH+15hTZcdy3qH7ry4/sv X-Google-Smtp-Source: AHgI3Ib7U3SUnL0xe1UIiKG0DOFacw9wJAGhKqeDoVA7togg7I2WHC95kcMb8qD7z9R5Aj5Ub51lgA== X-Received: by 2002:a9d:63cd:: with SMTP id e13mr7247212otl.319.1549492110263; Wed, 06 Feb 2019 14:28:30 -0800 (PST) Received: from ?IPv6:2600:8802:5600:164::1999? ([2600:8802:5600:164::1999]) by smtp.gmail.com with ESMTPSA id z15sm9783075oib.23.2019.02.06.14.28.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 14:28:29 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_9A56D753-49D3-4968-9489-24C71E35D22B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.1\)) Message-Id: <05C0ABCF-BE5A-4504-AB22-3A434573CDE1@gmail.com> Date: Wed, 6 Feb 2019 14:28:27 -0800 To: IPv6 Operations X-Mailer: Apple Mail (2.3445.104.1) Archived-At: Subject: [v6ops] FOSDEM 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, 06 Feb 2019 22:28:32 -0000 --Apple-Mail=_9A56D753-49D3-4968-9489-24C71E35D22B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Saw an interesting blog regarding FOSDEM - = https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-new-view-from-the-noc= . --Apple-Mail=_9A56D753-49D3-4968-9489-24C71E35D22B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlxbX4sACgkQEhdRnd2G P+DHfRAAnh/Mxfi/a9Jwgjyk2I3udN2qAlNJHbICqwnDG6pkaerMXCeZdGIGGYSD pV1BpaH8iEmyyiCoW3PzhBj0HB6d+ALHg9P8oGpJyaoEXV0PJLX5t+Sk4pLjwJtB YV84mlZrIsllCcQHqmUV10dBwXBeaWbxoi1191DxkN5vv8H9/MOEMwwhGbD/bMOa /DC73aTCcMurr03pp3FMwWoYdH6GIbRfbsLCO+5JuxMi4pr5B/KJQqDtfO9y1Ncu bP6UN/zOerUraL2vsyCsq/Jj83oREk9BkHHyBvcLuXZTZ6/6Pc4vYlBn5cBTaURO Q+WInQtIh+nLNM2Q7Xl48YTjFzIhBbL+vuqqRY9Z9QXWBpTIa5kqR65LbvQBZQ1+ 48tX9Bm24Ndtl0JKXeLl/kDPNHkoD/C1jJq2oJdn/1lf3TvDYz0W8wh1sZFhxPjI /0j+bgT5QJs5MtuBOXcPF4yrsNslTaRK8dXnDPZWiMBh37vqng3N9HlkT6VfeOzo 0s9L09VllK3hC3XcvSaSHrGMkfTvVbCXReE4kYoCYVhepNPPMvV2wMQ+k/tnj5Zq WU+WV+C9ykL/Ls1219PSlcyQtuzXe4nWGTpeGL/xhi9wNGFukU08dsljvRQDx4RK HZhgOqYh08jDB+Y98mmY18Ad9Edl7Epx1u3Bi3zB5cUfFQh3byw= =jAoc -----END PGP SIGNATURE----- --Apple-Mail=_9A56D753-49D3-4968-9489-24C71E35D22B-- From nobody Wed Feb 6 15:10: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 1B5C6130EE0 for ; Wed, 6 Feb 2019 15:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCUJxRP7MPPW for ; Wed, 6 Feb 2019 15:10:19 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450: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 58793130E25 for ; Wed, 6 Feb 2019 15:10:19 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id v16so7618972wrn.11 for ; Wed, 06 Feb 2019 15:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0QRf9eBy6+JPzqQUhk8rhmr58CAGYe5uWqcepKCaago=; b=Ev0agNx9dR5OHnDupktOTQJZZ2L1rOP2tDfsXfKgtSsDBDrw1Wlbq/KliYUoODr2p/ oGlEawo/1i2XZvhEpwhgMYf9IwWOGMiGAxN9adYj0qo5cnozzENuVeHhqXlonH6O7SSR kBfAcNcsXhuV0e8O0X8XidK2F19rcuE2eLd7Xr9/MXCY4yWxRb5dDuS0hCJgnWLGq55A ftU/+o+PWyaFuK4TlSfx0GPGiHO9035KOX2RAvsBvNySnwgSf5KV5h5YaZkdWWeiDOe9 FF/JMhdnzjcnQPrMpYhQI9fDiBGYBvoJQzVcTp7KkRcr1GnNNVxTn9+oSwsTKORmyleX 5mnA== 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=0QRf9eBy6+JPzqQUhk8rhmr58CAGYe5uWqcepKCaago=; b=CglkircdVwG7ENntSIM2bd9z79npsFlhvNfSULEmHZmumrY/ANF3JSSu/2JGg7n+c5 EoBqf8qr7v9XQmiabXzbesY194Vhg4nLn1TSrIrM8R7I1jufxs1x2N0ZnYwXjHz4oF4G 4wdLIDKz/Ok2IyIi28GDN/4mfOrRZl85+QvuVtOXcXo+V4Vba+imbG4yRqI7MaAJafvo ihcXSTeEPdJibmvNNXUN+r2vB19yFog0hGuidyNo8AYZZrw+rahxEjOHjPjPsc6pY6DG ZUazr36mcB49zLrFoXqo5wZrP+SxHiWSbZTXHWQsaAsOPtbxQU0ncgsZBdZKLnbirifL KWNQ== X-Gm-Message-State: AHQUAuaSkNN4aOFFhgTE+GzzyZfPsiBoK4NnopkdN+lxxq2CyL26+6PR ctGfkw587c7uy8RcWep6cWgAhHBGCk3jglyLqEXYFw== X-Google-Smtp-Source: AHgI3IYDkVgFpf/lvTnEadMjAUeYYywu7gFp7lgPBJ5IxDAq6qpsWPMx7+qXiANoidIPx5EHEk+7EciznhxBnKI5+yg= X-Received: by 2002:adf:f848:: with SMTP id d8mr10363459wrq.178.1549494617262; Wed, 06 Feb 2019 15:10:17 -0800 (PST) MIME-Version: 1.0 References: <05C0ABCF-BE5A-4504-AB22-3A434573CDE1@gmail.com> In-Reply-To: <05C0ABCF-BE5A-4504-AB22-3A434573CDE1@gmail.com> From: Warren Kumari Date: Wed, 6 Feb 2019 18:09:40 -0500 Message-ID: To: Fred Baker Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000003e6571058141d45d" Archived-At: Subject: Re: [v6ops] FOSDEM 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, 06 Feb 2019 23:10:22 -0000 --0000000000003e6571058141d45d Content-Type: text/plain; charset="UTF-8" On Wed, Feb 6, 2019 at 5:28 PM Fred Baker wrote: > Saw an interesting blog regarding FOSDEM - > https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-new-view-from-the-noc > .. > > Hah. I attended FOSDEM for the first time this year. I decided to walk over on Friday morning (FOSDEM itself is Saturday and Sunday) to both try avoid jetlag and also make sure I knew where the location was... I poked my head into the venue, mentioned that I'm one of the IETF NOC monkeys, and got conscripted into the FOSDEM NOC. The network is very different to the IETF network, but it was fun and exciting... W > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000003e6571058141d45d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 6, 2019 at 5:28 PM Fred = Baker <fredbaker.ietf@gmail.= com> wrote:
Saw an interesting blog regarding FOSDEM - https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-ne= w-view-from-the-noc..


Hah. I attended FOSDEM for the first time t= his year. I decided to walk over on Friday morning (FOSDEM itself is Saturd= ay and Sunday) to both try avoid jetlag and also make sure I knew where the= location was... I poked my head into the venue, mentioned that I'm one= of the IETF NOC monkeys, and got conscripted into the FOSDEM NOC.=C2=A0
Th= e network is very different to the IETF network, but it was fun and excitin= g...

W

=C2=A0

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


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--0000000000003e6571058141d45d-- From nobody Thu Feb 7 03:44: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 6A6C5131140 for ; Thu, 7 Feb 2019 03:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8s-XKTKkec7 for ; Thu, 7 Feb 2019 03:43:52 -0800 (PST) Received: from atl4mhob16.registeredsite.com (atl4mhob16.registeredsite.com [209.17.115.109]) by ietfa.amsl.com (Postfix) with ESMTP id 550FD131136 for ; Thu, 7 Feb 2019 03:43:52 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id x17BhnL2042009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 Feb 2019 06:43:49 -0500 Received: (qmail 9090 invoked by uid 0); 7 Feb 2019 11:43:49 -0000 X-TCPREMOTEIP: 68.100.71.215 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.135?) (lee@asgard.org@68.100.71.215) by 0 with ESMTPA; 7 Feb 2019 11:43:49 -0000 To: v6ops@ietf.org References: <05C0ABCF-BE5A-4504-AB22-3A434573CDE1@gmail.com> From: Lee Howard Message-ID: Date: Thu, 7 Feb 2019 06:43:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FA559F038157ED335616CCC3" Content-Language: en-US Archived-At: Subject: Re: [v6ops] FOSDEM 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 Feb 2019 11:44:03 -0000 This is a multi-part message in MIME format. --------------FA559F038157ED335616CCC3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/6/19 6:09 PM, Warren Kumari wrote: > > > On Wed, Feb 6, 2019 at 5:28 PM Fred Baker > wrote: > > Saw an interesting blog regarding FOSDEM - > https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-new-view-from-the-noc.. > > > Hah. I attended FOSDEM for the first time this year. I decided to walk > over on Friday morning (FOSDEM itself is Saturday and Sunday) to both > try avoid jetlag and also make sure I knew where the location was... I > poked my head into the venue, mentioned that I'm one of the IETF NOC > monkeys, and got conscripted into the FOSDEM NOC. > The network is very different to the IETF network, but it was fun and > exciting... Different in at least the respect that IPv6-only + NAT64 is their default SSID. Lee > > W > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >    ---maf > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------FA559F038157ED335616CCC3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/6/19 6:09 PM, Warren Kumari wrote:


On Wed, Feb 6, 2019 at 5:28 PM Fred Baker <fredbaker.ietf@gmail.com> wrote:
Saw an interesting blog regarding FOSDEM - https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-new-view-from-the-noc..


Hah. I attended FOSDEM for the first time this year. I decided to walk over on Friday morning (FOSDEM itself is Saturday and Sunday) to both try avoid jetlag and also make sure I knew where the location was... I poked my head into the venue, mentioned that I'm one of the IETF NOC monkeys, and got conscripted into the FOSDEM NOC. 
The network is very different to the IETF network, but it was fun and exciting...

Different in at least the respect that IPv6-only + NAT64 is their default SSID.

Lee


W

 

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


--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------FA559F038157ED335616CCC3-- From nobody Mon Feb 11 11:06:56 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 B1138131150; Mon, 11 Feb 2019 11:06:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Ron Bonica , draft-ietf-v6ops-transition-ipv4aas@ietf.org, The IESG , rbonica@juniper.net, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154991199471.29540.1057172386661003425.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2019 11:06:34 -0800 Archived-At: Subject: [v6ops] Document Action: 'Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service' to Informational RFC (draft-ietf-v6ops-transition-ipv4aas-15.txt) 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: Mon, 11 Feb 2019 19:06:42 -0000 The IESG has approved the following document: - 'Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service' (draft-ietf-v6ops-transition-ipv4aas-15.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Technical Summary This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or by vendors who sell through the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). Working Group Summary There was broad consensus behind this document and no controversy. Document Quality All of the mechanisms have been implemented by multiple vendors. The document shepherd (Ron Bonica) read every word of this document. Coincidentally, he is doing a similar comparison as part of his day job. Therefore, he is testing all but one of the transition mechanisms mentioned in this document in the lab (employer doesn't implement one of the mechanisms.) I worked closely with the authors to improve the readability, and they have been very responsive in addressing the directorate reviews. Personnel Ron Bonica is the Document Shepherd. Warren Kumari is the "Responsible" Area Director. From nobody Tue Feb 12 19:18: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 8B70E1295D8; Tue, 12 Feb 2019 19:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhuYWbraatH5; Tue, 12 Feb 2019 19:18:29 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09681277D2; Tue, 12 Feb 2019 19:18:28 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 D8064845B1; Wed, 13 Feb 2019 04:18:19 +0100 (CET) To: Ole Troan , Christian Huitema Cc: Michael Richardson , "v6ops@ietf.org WG" , 6man WG , JORDI PALET MARTINEZ References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <6440.1549227369@dooku.sandelman.ca> <85C3CE49-93CC -48E1-94FB-46A0203783A2@employees.org> <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <38eb8b47-6ae9-f256-81b4-3313c7f0a83f@si6networks.com> Date: Tue, 12 Feb 2019 23:37:12 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 03:18:31 -0000 On 3/2/19 21:26, Ole Troan wrote: > > >> On 4 Feb 2019, at 01:07, Christian Huitema wrote: >> >> >> On Feb 3, 2019, at 11:43 AM, Ole Troan wrote: >> >>>>> The router cannot in its RPF check determine the reason for the wrong >>>>> source address. If its spoofed or a previously valid address. Therefore >>>>> code 5. >>>> >>>> Right... if the router knew it was the previously valid address, then it >>>> would know what it was, and could have sent a lifetime=0 deprecate out... >>>> >>>> (did I follow you correctly?) >>> >>> Yes. Of course it might do both. >> >> OK. But then the host knows that it is not engaged in address spoofing, so it could decide to do something about it. That still would be better than calling support. > > Well, this is caused by the ISP, so perhaps the call should be the recommended action. :-) Not necessarily. There is no requirement that the ISP leases the same prefix if the client just asks a new prefix. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 14 12:18:55 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 3E9401200D7; Wed, 13 Feb 2019 07:28:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "=?utf-8?q?Ole_Tr=C3=B8an?=" , "Ron Bonica" , "Reshad Rahman" , "Bill Cerveny" , "Jeffrey Haas" , "Chris Bowers" , "Bob Hinden" , "Brian Trammell" , "Jeff Tantsura" , "Tommy Pauly" , "Fred Baker" Cc: Deborah Brungard , Bidirectional Forwarding Detection Discussion List , =?utf-8?q?Mirja_K=C3=BChlewind?= , Bob Hinden , Jeff Tantsura , Fred Baker , Ron Bonica , Ignas Bagdonas , Bill Cerveny , Warren Kumari , Martin Vigoureux , Brian Trammell , IPv6 Maintenance Discussion List , IPv6 Operations Discussion List , Terry Manderson , =?utf-8?q?Ole_Tr=C3=B8an?= , rraghu@ciena.com, Tommy Pauly , Raghu Ranganathan , Reshad Rahman , Jeffrey Haas , Chris Bowers , IP Performance Measurement Discussion List , Alvaro Retana , Spencer Dawkins , Routing Area Working Group Discussion List , Suresh Krishnan X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155007172917.9348.7524674738392964663.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2019 07:28:49 -0800 Archived-At: X-Mailman-Approved-At: Thu, 14 Feb 2019 12:18:49 -0800 Subject: [v6ops] New Liaison Statement, "Status of MEF IP Services Projects" 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: Wed, 13 Feb 2019 15:28:50 -0000 Title: Status of MEF IP Services Projects Submission Date: 2019-02-13 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1628/ From: Liaison Mef To: Jeffrey Haas ,Reshad Rahman ,Chris Bowers ,Jeff Tantsura ,Ron Bonica ,Fred Baker ,Brian Trammell ,Bill Cerveny ,Tommy Pauly ,Bob Hinden ,Ole Trøan Cc: Jeffrey Haas ,Bidirectional Forwarding Detection Discussion List ,Bob Hinden ,Deborah Brungard ,Jeff Tantsura ,Fred Baker ,Ron Bonica ,Terry Manderson ,Alvaro Retana ,Bill Cerveny ,Warren Kumari ,Martin Vigoureux ,Brian Trammell ,IPv6 Maintenance Discussion List ,IPv6 Operations Discussion List ,Ignas Bagdonas ,Tommy Pauly ,Raghu Ranganathan ,Reshad Rahman ,Ole Trøan ,Chris Bowers ,IP Performance Measurement Discussion List ,Mirja Kühlewind ,Spencer Dawkins ,Routing Area Working Group Discussion List ,Suresh Krishnan Response Contacts: rraghu@ciena.com Technical Contacts: Purpose: For information Body: Following the previous liaisons between our organizations, we would like to provide an update on the status of the active projects in MEF that relate to IP Services. There are four active projects: IP Service Attributes. This project is defining the generic Service Attributes that are agreed between the provider and user of an IP Service, to describe the service being provided. MEF 61, covering Service Attributes for Subscriber IP Services (for end users), was published in April 2018. We have since been working on a revision to this standard, to add support for wholesale IP Services between Operators. An Approved Draft of the revision was included in an earlier liaison, and a Letter Ballot (final approval) has now been initiated. Publication of the revision is expected in Q2 2019. IP Service Definitions. This project is defining a number of specific IP Services, based on the Service Attributes defined in MEF 61. The initial phase is focusing on two forms of Internet Access Service: Consumer-grade Internet Access, and Commercial-grade Internet Access. A later phase will also define one or more IP-VPN Services. A Letter Ballot (final approval) on the first phase is expected to be initiated in April 2019, with publication to follow in the Summer. Service OAM for IP Services. This project is defining how Fault Management and Performance Monitoring can be performed for IP Services (based on techniques and protocols defined in IETF). Fault Management is based on ping, traceroute, and BFD. Performance Monitoring is based on TWAMP, TWAMP-light and STAMP. The initial phase is focusing on Subscriber IP Services, and a Draft Standard release of this document is available on the MEF public web site (see below). We would welcome any comments you have on this Draft Standard. A Letter Ballot (final approval) is expected to be initiated in April 2019, therefore we would request that you send any comments by the end of March 2019. Service Activation Testing for IP Services. This project is defining a methodology for Service Activation Testing of IP Services. The initial phase again focuses on Subscriber IP Services, based on the Service Attributes in MEF 61. A later phase will cover IP Services between Operators. A Draft Standard for review is expected to be available in Spring 2019. Note that MEF has replaced our previous mechanism of "Approved Drafts", which were shared only with liaison partners and could be accessed using a username and password, with a mechanism of Draft Standards, which are published on the MEF web site. Current Draft Standards can be found at https://www.mef.net/draft-standards. Published MEF Standards can be found, as always, at https://www.mef.net/resources/technical-specifications. The forthcoming MEF meetings are: 29 April - 2 May, 2019 - Dubrovnik, Croatia 29 July - 1 August, 2019 - North America Attachments: No document has been attached From nobody Mon Feb 18 12:17:27 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 2634212D4EA; Mon, 18 Feb 2019 12:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPjPvtSTrrGI; Mon, 18 Feb 2019 12:17:24 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDAE12426E; Mon, 18 Feb 2019 12:17:24 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id y140so10718106qkb.9; Mon, 18 Feb 2019 12:17:24 -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=9kg45C7746bdFa44yU16mAAv+YDIOAg6BbXJ0qnnTXI=; b=hSPcTS3BR6/uy9EwNQUHkOvWAaX3CP9wVGjzm7OfN/heV4aDmWpsX3Gk7gXk7VTboT QrREYqOCCPtfLqp7sGL9HDM2bH6soTvSjKD5ukPAC1xcPdaJxIN2vuS7frYEzFDk7b5Y bWTN/4rEzHlX0Nfou6zEIvbi22AR32yB8UBtn+HdTKGWSjS37VR3T6I90MA2fcNm0yPK 1RTXmB3VeSPUqvXACHM9m1aR+PorkDpz09PI9eG+fm7ZEfzerfjBpx2Bp8fmQBEIJIy0 N7w0ttZUG+9frerx+JkyTS4xE38PTAHeQGdyktNYwIJxWdXeciLA17eRY1LUeVSFnkq9 kPTA== 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=9kg45C7746bdFa44yU16mAAv+YDIOAg6BbXJ0qnnTXI=; b=A2CH6kXt83WD5uzcA2v3DlkhpyWMkKkML/EiGRjwaDAG0CyYNAHlW3Ta0YUlPY5bLO ZgxpVdtkvteIOm/6XLK3eaPPAcuO8JJwaCGNdRWOGNffU4Dw/Jli7MZzSIZB9whB18oN tCb58WfJYmd4Et/scOo8onevsaAj1mnszmvCIozYOqIXTp8CkcSMse+Ehb8uQHipZ0Xc NTz6Kdi5PYbXAA6KMzlv5rwkmeNSvP1IpU5Iml51lvdcPbuRY17JKFNdm4chh8lffH5w 5btwagre/XIRAbGeBAkfx5TQ75tyjvthg/1TH7UTlFN+oUlqCRF/BjuOQTqz6uvGYdWY 0ssQ== X-Gm-Message-State: AHQUAuZx2/E4sv9KtzyiS9VAR2f7EwSfNi7VWlLZRVn8O+4IG4F66bAD uIW2uQHkikwrqSk66pU9hxr32c8LgkBkbyeH5ayqxFOs X-Google-Smtp-Source: AHgI3IalmwSbWyNTpxmyrZLsQZFJn6QO08QBLKPZZaLn/pkpoTwN0zicBk8DIrNmPreA9yd0ttdBJltnaM+m8QsAZUI= X-Received: by 2002:a05:620a:1333:: with SMTP id p19mr16422644qkj.165.1550521042839; Mon, 18 Feb 2019 12:17:22 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> In-Reply-To: <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> From: Jen Linkova Date: Tue, 19 Feb 2019 07:16:59 +1100 Message-ID: To: Fernando Gont Cc: Mikael Abrahamsson , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 20:17:26 -0000 On Thu, Jan 31, 2019 at 11:12 PM Fernando Gont wrote: > > When the new prefix is received it'll most likely have a higher > > preferred and valid lifetime, so hosts should use the new prefix just by > > means of them preferring the higher preferred lifetime of that PIO. So > > the problem is a bit less than you write in the draft. > > Nothing in the spec says preference is related to the "Preferred > Lifetime" timer. i.e., an address is preferred, or it is not... I tried to address this problem before (and there are more use cases than just CPE reboot): https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00 I might be biased here indeed but I think that using the "most recently updated" (however we define that) address would be the simpler solution than deprecating the whole prefix (and both solution requires hosts to keep the PIO <> advertising router mapping). -- SY, Jen Linkova aka Furry From nobody Mon Feb 18 15:41: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 212AF1288BD; Mon, 18 Feb 2019 15:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImZU5wdwYpV9; Mon, 18 Feb 2019 15:41:18 -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 52A31126F72; Mon, 18 Feb 2019 15:41:18 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 4CBB182C4D; Tue, 19 Feb 2019 00:41:11 +0100 (CET) To: Jen Linkova Cc: Mikael Abrahamsson , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Mon, 18 Feb 2019 19:24:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 23:41:21 -0000 Hello, Jen, On 18/2/19 17:16, Jen Linkova wrote: > On Thu, Jan 31, 2019 at 11:12 PM Fernando Gont wrote: >>> When the new prefix is received it'll most likely have a higher >>> preferred and valid lifetime, so hosts should use the new prefix just by >>> means of them preferring the higher preferred lifetime of that PIO. So >>> the problem is a bit less than you write in the draft. >> >> Nothing in the spec says preference is related to the "Preferred >> Lifetime" timer. i.e., an address is preferred, or it is not... > > I tried to address this problem before (and there are more use cases > than just CPE reboot): > https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00 > > I might be biased here indeed but I think that using the "most > recently updated" (however we define that) address would be the > simpler solution than > deprecating the whole prefix (and both solution requires hosts to keep > the PIO <> advertising router mapping). Say the Stale prefix is 2001:Db8:1::/64, for which you configured 2001:db8:1::1. Say that Prefix(2001:Db8:1::/64) has now become stale, and a new prefix 2001:db8:2::/64 is being announced, for which you have 2001:db8:2::1. Say you now need to send packets to 2001:db8:1::/64. You will use the new addresses (from 2001:db8:2::/64), but will send the packets assuming nodes are "on-link", instead of sending them to the default router. -- You do need to get rid of information, including routes, asap. Similarly, if you have multiple interfaces, Rule 5 might override your rule 8. Whether because you are sending to the stale prefix, or because your first default-router was the one the happened to crash-and-reboot. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 18 15:48: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 8BB8D1310B0; Mon, 18 Feb 2019 15:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kKY273PbKpA; Mon, 18 Feb 2019 15:48:22 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAF6126F72; Mon, 18 Feb 2019 15:48:21 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 32B3D82B7F; Tue, 19 Feb 2019 00:48:17 +0100 (CET) References: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== To: "6man@ietf.org" <6man@ietf.org> Cc: IPv6 Operations , "Jan Zorz @ go6.si" X-Forwarded-Message-Id: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 18 Feb 2019 20:48:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.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, 18 Feb 2019 23:48:25 -0000 Folks, We have posted a revision of our I-D, which expands a lot on the problem and possible solutions, based on the email discussion we had on this list. The revised I-D is available at: https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt Comments will be very welcome. Thanks! Fernando & Jan -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-6man-slaac-renum-01.txt Date: Mon, 18 Feb 2019 15:45:21 -0800 From: internet-drafts@ietf.org To: Fernando Gont , Jan Zorz A new version of I-D, draft-gont-6man-slaac-renum-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-6man-slaac-renum Revision: 01 Title: Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events Document date: 2019-02-18 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/ Htmlized: https://tools.ietf.org/html/draft-gont-6man-slaac-renum-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-01 Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and proposes workarounds to improve network robustness. This document updates RFC4861 and RFC4862 to allow for a more robust reaction to network configuration changes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Feb 18 17:18: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 F3CAB129BBF; Mon, 18 Feb 2019 17:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRtbC3nUWst1; Mon, 18 Feb 2019 17:18:42 -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 7CC381200D7; Mon, 18 Feb 2019 17:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550539118; x=1551143918; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=HaecmpCxBtk0XfAswpVjlzUknIMF63e2cvn24Qu3yYo=; b=fscTwdgkqk0Un 4euGUya7xGXYCGAniGrUEFbi7M2+ZdcBgqhM6aObtMhsLeTYPQmf4vOz/RBP6uHW jtwO7x00FyihHDSXBziLWQ0734SaF0KPARzzrn+m4AxPyNcd4+T9O/ENtFSgtpLt XErvodN2I0FT4JJbq8rt/TNw4TE5Wc= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 19 Feb 2019 02:18:38 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 19 Feb 2019 02:18:25 +0100 Received: from [10.10.10.160] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006159717.msg; Tue, 19 Feb 2019 02:18:25 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.10.10.160] X-MDArrival-Date: Tue, 19 Feb 2019 02:18:25 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1953e7be70=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Tue, 19 Feb 2019 10:18:14 +0900 From: JORDI PALET MARTINEZ To: Fernando Gont , "6man@ietf.org" <6man@ietf.org> CC: IPv6 Operations Message-ID: <105E9F49-A9E7-4C77-963D-0B37997FF7AE@consulintel.es> Thread-Topic: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt) References: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.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: Tue, 19 Feb 2019 01:18:44 -0000 As just said in another list in Spanish, the reference to GERMAN-DP is wron= g, in the sense that is not a law or anything similar. German folks can con= firm. At least that has been said a few weeks ago by Germans in another lis= t ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ipv6 en nombre de Fernando Gont Fecha: martes, 19 de febrero de 2019, 8:49 Para: "6man@ietf.org" <6man@ietf.org> CC: IPv6 Operations Asunto: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for = draft-gont-6man-slaac-renum-01.txt) Folks, =20 We have posted a revision of our I-D, which expands a lot on the proble= m and possible solutions, based on the email discussion we had on this li= st. =20 The revised I-D is available at: https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt =20 Comments will be very welcome. =20 Thanks! Fernando & Jan =20 =20 =20 =20 -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-6man-slaac-renum-01.tx= t Date: Mon, 18 Feb 2019 15:45:21 -0800 From: internet-drafts@ietf.org To: Fernando Gont , Jan Zorz =20 =20 A new version of I-D, draft-gont-6man-slaac-renum-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. =20 Name: draft-gont-6man-slaac-renum Revision: 01 Title: Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events Document date: 2019-02-18 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/ Htmlized: https://tools.ietf.org/html/draft-gont-6man-slaac-renum= -01 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-6man-slaac-renum-01 =20 Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network wil= l continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and proposes workarounds to improv= e network robustness. This document updates RFC4861 and RFC4862 to allow for a more robust reaction to network configuration changes. =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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =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 Feb 18 22:00: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 32B0F130E71; Mon, 18 Feb 2019 22:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45XWtB4uHQ3K; Mon, 18 Feb 2019 22:00:00 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72567124BF6; Mon, 18 Feb 2019 22:00:00 -0800 (PST) Received: from [192.168.10.189] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id BA968FECC155; Tue, 19 Feb 2019 05:59:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (16D39) In-Reply-To: Date: Tue, 19 Feb 2019 06:59:56 +0100 Cc: Jen Linkova , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <207AEC9F-BD52-437C-AAA2-AB974DA17AFC@employees.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> To: Fernando Gont Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 19 Feb 2019 06:00:04 -0000 > On 18 Feb 2019, at 23:24, Fernando Gont wrote: >=20 > Hello, Jen, >=20 >> On 18/2/19 17:16, Jen Linkova wrote: >> On Thu, Jan 31, 2019 at 11:12 PM Fernando Gont wr= ote: >>>> When the new prefix is received it'll most likely have a higher >>>> preferred and valid lifetime, so hosts should use the new prefix just b= y >>>> means of them preferring the higher preferred lifetime of that PIO. So >>>> the problem is a bit less than you write in the draft. >>>=20 >>> Nothing in the spec says preference is related to the "Preferred >>> Lifetime" timer. i.e., an address is preferred, or it is not... >>=20 >> I tried to address this problem before (and there are more use cases >> than just CPE reboot): >> https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-upd= ate-00 >>=20 >> I might be biased here indeed but I think that using the "most >> recently updated" (however we define that) address would be the >> simpler solution than >> deprecating the whole prefix (and both solution requires hosts to keep >> the PIO <> advertising router mapping). >=20 > Say the Stale prefix is 2001:Db8:1::/64, for which you configured > 2001:db8:1::1. >=20 > Say that Prefix(2001:Db8:1::/64) has now become stale, and a new prefix > 2001:db8:2::/64 is being announced, for which you have 2001:db8:2::1. >=20 > Say you now need to send packets to 2001:db8:1::/64. >=20 > You will use the new addresses (from 2001:db8:2::/64), but will send the > packets assuming nodes are "on-link", instead of sending them to the > default router. >=20 > -- You do need to get rid of information, including routes, asap. >=20 > Similarly, if you have multiple interfaces, Rule 5 might override your > rule 8. Whether because you are sending to the stale prefix, or because > your first default-router was the one the happened to crash-and-reboot. How is your case different from the multi-prefix multi-homed case where one p= ath is (temporary) out of service? Ole >=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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Feb 18 23:56:29 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 945D2124B0C; Mon, 18 Feb 2019 23:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yrjzhanS9YA; Mon, 18 Feb 2019 23:56:26 -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 DE95A1276D0; Mon, 18 Feb 2019 23:56:25 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id v10so22129692qtp.8; Mon, 18 Feb 2019 23:56:25 -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=RrwmF7C94oj/FLZqM/rlaEwljHlbe+bRuLb8tUcnK1c=; b=UPGv2QUS9fi4DgOB+IJhXdGKCDMBK+6+hZK1anq+LGGTX+zyF8vYiD1ZI6xYjoPyz6 4O5Sfsr1Uyw8XRQC7bUv384l6vYtAl248z5LE2NfgSKPEb2aIlWRDxCI3CSPkWv6/+P7 EqG2OXD0OFAqzJqoqWLiO2zWY1ntNhC5v014mhRvLw+DD6/uGAsEHC7aONTzbOCvTNtJ yWPxLoYZBgvbcrPYnQW3VytrvDjQsk4KSs3MP8Uet5dmg4+b76ZZJmlmyoRIjdKfrBXI dgmJpVhTxqRTDVJ5m3OpZ/AzW6pSvc90D0vEocmANTewxDCPKUjLYBnCC4Fqe84eCamY ASQw== 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=RrwmF7C94oj/FLZqM/rlaEwljHlbe+bRuLb8tUcnK1c=; b=JTafMVP1t8mWX3L1k+wKEc/As6BSlT8sv8VxsryFp5qgeszZtbm5WmbLXVnmEV1fQJ nqXd9paWpmRI6lfz+D/ETzRemGCOhwfhwxA44YY8L0dno6N33O4Wvru0YAmboAOyqOhl kDUV+HXDlUWE/pnUiKbiARxiMO1u4JrPnsmnoOSbYorBBOgz2ci4kKmGxhHYx2LkAhKc 2GsFN8GllDSKZJMfZhxIBVMFf4DxhglSxTLzPlH+ToXXjO+Yb+CLi+iFaQx6bf5ckUN0 beRb2PW8qSnTxAjBomcPFgyrKemjha9locPrXlOqGFhLPorSMGSSo0EROO+yirIJKojJ UbPw== X-Gm-Message-State: AHQUAuatjeRqFwD6328GgDiMApPxvdOTMrzgGdJrE0kBcv7q8XUdn7nV woa32ZrN4vQMHPnVGIV8BWpkqWCQS9Wj4a7oFjRC40OK X-Google-Smtp-Source: AHgI3Ib4Sm12g+4JxPuNGDex9I1DHWHiHYG8QEWSfrXBYWnk9rk4Uf/DmBV3WEg2MSGone7iHnFWTlSmQcv4Oemic2w= X-Received: by 2002:a0c:88ed:: with SMTP id 42mr19517378qvo.126.1550562984584; Mon, 18 Feb 2019 23:56:24 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> In-Reply-To: From: Jen Linkova Date: Tue, 19 Feb 2019 18:56:12 +1100 Message-ID: To: Fernando Gont Cc: Mikael Abrahamsson , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 19 Feb 2019 07:56:28 -0000 On Tue, Feb 19, 2019 at 10:41 AM Fernando Gont wrote: > > I might be biased here indeed but I think that using the "most > > recently updated" (however we define that) address would be the > > simpler solution than > > deprecating the whole prefix (and both solution requires hosts to keep > > the PIO <> advertising router mapping). > > Say the Stale prefix is 2001:Db8:1::/64, for which you configured > 2001:db8:1::1. > > Say that Prefix(2001:Db8:1::/64) has now become stale, and a new prefix > 2001:db8:2::/64 is being announced, for which you have 2001:db8:2::1. > > Say you now need to send packets to 2001:db8:1::/64. > > You will use the new addresses (from 2001:db8:2::/64), but will send the > packets assuming nodes are "on-link", instead of sending them to the > default router. True. I'm not convinced that this use case is worth solving by introducing the complexity (and impact on other scenarios) the draft is suggesting What I'm not a big fun of is assuming that absence of evidence is actually evidence of absence. When a router stops advertising a prefix it does not necessary mean that hosts shall stop using the addresses. It does indeed in the scenario the draft describes but the host can not know the topology/scenario. The proposed host changes would solve one particular case (DHCPv6-PD router crash/reboot) while multiprefix/multihomed networks. Lets say there are two routers (R1 and R2) on the LAN. R1 advertised 2001:db8:1::/64 and 2001:db8:3::/64 R2 advertised 2001:db8::2::/64 and 2001:db8:3::/64. Hosts have addresses from 3 prefixes. Now R2 stops advertising 2001:db8:3::/64. There is no reason for hosts to deprecate addresses in 2001:db8:3::/64. What's going to happen is every time an RA from R1 is received, hosts would get preferred addresses in 2001:db8:3::/64 and every RA from R2 would deprecate them. I do believe that the default preferred lifetime is a bit longer that it should be (and I have to tweak it all the time). So maybe we shall change that. > Similarly, if you have multiple interfaces, Rule 5 might override your > rule 8. Sorry, I must be very slow today. Could you please elaborate on this scenario? I'm having difficulties figuring it out.. The draft is talking about deprecating prefixes on *another* interface? I hope not.. Actually I've just realized that I could not find any clear definition of what 'the same router' means. The same address installed as 'next-hop'? The same combination of IPv6 address and L2 address? -- SY, Jen Linkova aka Furry From nobody Tue Feb 19 20:23: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 9AACA130F40; Tue, 19 Feb 2019 20:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwyOa84618F2; Tue, 19 Feb 2019 20:22:42 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC4412E036; Tue, 19 Feb 2019 20:22:42 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 B910E849F7; Wed, 20 Feb 2019 05:22:37 +0100 (CET) To: Jen Linkova Cc: Mikael Abrahamsson , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> Date: Wed, 20 Feb 2019 00:59:37 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 04:22:47 -0000 On 19/2/19 04:56, Jen Linkova wrote: > On Tue, Feb 19, 2019 at 10:41 AM Fernando Gont wrote: >>> I might be biased here indeed but I think that using the "most >>> recently updated" (however we define that) address would be the >>> simpler solution than >>> deprecating the whole prefix (and both solution requires hosts to keep >>> the PIO <> advertising router mapping). >> >> Say the Stale prefix is 2001:Db8:1::/64, for which you configured >> 2001:db8:1::1. >> >> Say that Prefix(2001:Db8:1::/64) has now become stale, and a new prefix >> 2001:db8:2::/64 is being announced, for which you have 2001:db8:2::1. >> >> Say you now need to send packets to 2001:db8:1::/64. >> >> You will use the new addresses (from 2001:db8:2::/64), but will send the >> packets assuming nodes are "on-link", instead of sending them to the >> default router. > > True. I'm not convinced that this use case is worth solving by > introducing the complexity (and impact on other scenarios) the draft > is suggesting Could you elaborate on what's the complexity you are referring to and what's the impact on other scenarios? Having multiples addresses from multiples prefixes is complex. > What I'm not a big fun of is assuming that absence of evidence is > actually evidence of absence. When a router stops advertising a prefix > it does not necessary mean > that hosts shall stop using the addresses. This is not the way the proposed algorithm work. I'd agree with you that if you stopped receiving RAs, *that* wouldn't necessarily warrant a prompt reaction. However, the proposed algorithm reacts to *RAs from the same router* (i.e. the router *is alive*) that do carry PIOs, but they happen to advertise PIOs for different prefixes. Once you receive four RAs with PIOs from the same router, all of them including PIOs, but failing to advertise the stale prefix, you remove the addresses. > It does indeed in the > scenario the draft describes but the host can not know the > topology/scenario. > The proposed host changes would solve one particular case (DHCPv6-PD > router crash/reboot) while multiprefix/multihomed networks. > > Lets say there are two routers (R1 and R2) on the LAN. > R1 advertised 2001:db8:1::/64 and 2001:db8:3::/64 > R2 advertised 2001:db8::2::/64 and 2001:db8:3::/64. > > Hosts have addresses from 3 prefixes. > Now R2 stops advertising 2001:db8:3::/64. > > There is no reason for hosts to deprecate addresses in 2001:db8:3::/64. > What's going to happen is every time an RA from R1 is received, hosts > would get preferred addresses in 2001:db8:3::/64 and every RA from R2 > would deprecate them. That's not correct. It takes two consecutive RAs for the prefixe to be unpreferred. And another two consecutive RAs for the prefix to be removed. In the scenario you describe, R1 would keep advertising the prefix, and hence it would never be unpreferred or removed. There's room for improvement and clarification, though: one may clarify that. You might think of this problem as havinf a reference count on the prefix. If there's only one router associated with the prefix, un-prefer and remove the prefix. Otherwise, just dis-associate the prefix with this particular router. > I do believe that the default preferred lifetime is a bit longer that > it should be (and I have to tweak it all the time). So maybe we shall > change that. Same applies to the Valid Lifetime. In the context of RFC8028 it doesn't make sense for the Valid Lifetime of a prefix to span past the Router Lifetime of a router. >> Similarly, if you have multiple interfaces, Rule 5 might override your >> rule 8. > > Sorry, I must be very slow today. Could you please elaborate on this > scenario? I'm having difficulties figuring it out.. Example: Say you have two network interfaces: If1 and If2. Say If1, is configured with 2001:db8:1::/64, and If2 with 2001:db8:2::/64 Say the first default router is that associated with If1. Say prefix 2001:db8:1::/64 stops being announced, or that you stop receiving RAs on If1, but RAs on If2 keep arriving fine. Based on the logic of your algorithm, one would expect that a new connection uses 2001:db8:2::/64/If2 (since that's the "more recently advertised information). However, Rule #5 would override that and make you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresses on the outgoing interface. So as long as you have stale routes, in many cases that will override any other rules for address selection. -- i.e., if your new rule for RFC6724 comes after rule 5, you better get rid of stale routes, or otherwise they will override you well-intended rule. > The draft is talking about deprecating prefixes on *another* > interface? I hope not.. Certainly not. > Actually I've just realized that I could not find any clear definition > of what 'the same router' means. The same address installed as > 'next-hop'? > The same combination of IPv6 address and L2 address? My mental model (as long as this algorithm is concerned) is that the router is uniquely identified by the (link-local) IPv6 address (the combination of IPv6 and L2 would work, too, but it seems unnecessary). We'll spell it out in the next rev. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 19 20:31: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 B2EAF12E036; Tue, 19 Feb 2019 20:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VOQWUKP1uPr; Tue, 19 Feb 2019 20:31:25 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 52A3E12DD85; Tue, 19 Feb 2019 20:31:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4444Rw5G73z1c0cg; Tue, 19 Feb 2019 20:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1550637084; bh=jQnQxcMB364HIkq7WSFhEhdb+HlnqHfBsNvPxE1x3oA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VsR8BACy37AceK7zOljYpk9D1qwmXnqbGBXRCWiK5mHQ4QrE1BWxBwLoevaeVnsU+ mp6G9uG8VOXnHkxlqILd2JAnQlPUAhxFvWkZjOLZqs3TFbZmWx6Ab/eRAoHtFe8H86 JJ9vmaOs5XTMW3L1HuRUMlPtc/ncSqnbAbAGanlI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4444Rv5tk0z1c02P; Tue, 19 Feb 2019 20:31:22 -0800 (PST) To: Fernando Gont Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 19 Feb 2019 23:31:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 04:31:27 -0000 I was trying to think through what breaks if you do the below. The one case I can see is if there is an open TCP connection using the prefix to be dropped. If that TCP connection appears to be working, then dropping the prefix would seem harmful. It would also seem that if the TCP connection is working that would be evidence that there is no need to drop the prefix. Yours, Joel On 2/19/19 10:59 PM, Fernando Gont wrote: ,,, > This is not the way the proposed algorithm work. > > I'd agree with you that if you stopped receiving RAs, *that* wouldn't > necessarily warrant a prompt reaction. > > However, the proposed algorithm reacts to *RAs from the same router* > (i.e. the router *is alive*) that do carry PIOs, but they happen to > advertise PIOs for different prefixes. > > Once you receive four RAs with PIOs from the same router, all of them > including PIOs, but failing to advertise the stale prefix, you remove > the addresses. ,,, From nobody Tue Feb 19 21:38: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 E07CB12D84D; Tue, 19 Feb 2019 21:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QefqgXJXpjS; Tue, 19 Feb 2019 21:38:20 -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 934D2129619; Tue, 19 Feb 2019 21:38:19 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 9C84382B83; Wed, 20 Feb 2019 06:38:14 +0100 (CET) To: "Joel M. Halpern" Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 20 Feb 2019 01:52:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 05:38:22 -0000 On 20/2/19 01:31, Joel M. Halpern wrote: > I was trying to think through what breaks if you do the below. > The one case I can see is if there is an open TCP connection using the > prefix to be dropped.  If that TCP connection appears to be working, > then dropping the prefix would seem harmful.  It would also seem that if > the TCP connection is working that would be evidence that there is no > need to drop the prefix. That's of course correct. Now: can you think of a scenario where that might occur? -- no routers are advertising the prefix anymore. Any new nodes joining the network will not consider the corresponding prefix to be on-link, will not configure prefixes for such address, etc. That said, the above might make the removal of the address debatable, but not the marking of the corresponding addresses as un-preferred, right? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 20 01:09: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 0B5601276D0; Wed, 20 Feb 2019 01:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdycGGRMQGxi; Wed, 20 Feb 2019 01:09:12 -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 7A4D4124B0C; Wed, 20 Feb 2019 01:09:12 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id o6so26356918qtk.6; Wed, 20 Feb 2019 01:09:12 -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=xYKH4MKZJacDAX8sjuS2dgArqUbwGfaBlJPrSI4yrTM=; b=QgRZNJpHkupfaY6jCJeFxjFaCnGDYz0ocq9fJoegEXI9EB6DlI3xm1pzpqQNe8DKHY ft4qmMwlPr14WXE/mwbsuLpdTSlhxdA0LK10m1hw1bx+mKnMa3Fv3FdaOFKaZSy+raGd pUMuSfDnCtiZoQ4LIgPIAKXxfT9P7hd7Au47903emzFhttWCDY4hQYkwTh223SZkL0us YgOpBJ3470Y1EuBHBtEFABss65zC2VZRBP17llx2AxqyERt+cqAjyiZwdHTI3c7BUazz LmaewaRbvKnb926gkfx3cvIWJqKm69995DdC5JgH/AKyqO2eLP7Au4IaXyj5MuisrxZ7 ywNA== 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=xYKH4MKZJacDAX8sjuS2dgArqUbwGfaBlJPrSI4yrTM=; b=Z7wQyXOk+qdOPp5//JOUrRlx1OJ/ma2aae2akI1Ogv0fyvCam5c4dqMp5xJ6PtpQio MEoLxKxrNPaIxwRZGAG6pLKDHJoueTfAX6bPKiC1Y+96133/gMCE24n2FFI36gr3DzBh a/W0WIZpsqyk7trovorGLaanuW1/QT0coeoPYlMxjeHlOIBuZZgUzC4OZ0yHOZIdFMd2 /4hsywr17QCMd4rGSW+7dveTV5Va7zMmc/UArlCGBpX2qCexbORRXtDRQtcid2yaTKwQ pMCRbdNTApw9UDNsNSz/EoIeYyj8oIRI0Zdp5JmXQTl3haitCr5L3CGzrwXrfXM+cytz CkGQ== X-Gm-Message-State: AHQUAuZqEwatr8SMiummy+rPin3rwRSlixfYergHZgLefgiZnLhx1ZVA 5olZ0QSPuR+cczc43gdXBQoOVyduT5mGBmthGafkvw== X-Google-Smtp-Source: AHgI3IYTZ3iq9eJmlO4de4QfAAUNcJV1bpiKJeqC21THmipYIxv4cxibgYK5kxyHxaZSeRloTW5Y8QAyQuBrM1IVj4A= X-Received: by 2002:ac8:3341:: with SMTP id u1mr25237516qta.58.1550653751425; Wed, 20 Feb 2019 01:09:11 -0800 (PST) MIME-Version: 1.0 References: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> In-Reply-To: From: Jen Linkova Date: Wed, 20 Feb 2019 20:08:59 +1100 Message-ID: To: Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , "Jan Zorz @ go6.si" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.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: Wed, 20 Feb 2019 09:09:14 -0000 Hi Fernando, On Tue, Feb 19, 2019 at 10:48 AM Fernando Gont wrote: > We have posted a revision of our I-D, which expands a lot on the problem > and possible solutions, based on the email discussion we had on this list. A few comments: - (sorry if I missed another thread on it - I'm catching up with emails slowly): any reason for setting Valid Lifetime to 0 as well? It looks to me that just deprecating the prefix would be enough..What would be a benefit of completely removing an address already deprecated? - "After normal processing of Router Advertisement messages, Router Advertisements that contain at least one PIO MUST be processed as follows" - I'd suggest you make it explicit that PIOs must of of the global scope. I did see CPEs including PIOs for fe80::/64 (and AFAIR such behavior is not explicitly prohibited); - the draft makes an assumption that "while network configuration information might be split into multiple RAs, PIOs will be spread among *at most* two RAs." - I'm not sure where this assumption is coming from - is there any requirements for routers saying it MUST/SHOULD do this? Adding any references to support such assumption would be very helpful. - as I've mentioned earlier, it would be nice not to break other scenarios while fixing DHCP-PD case. So what do you think about modifying the algorithm so the addresses are deprecated only if *all* routers the PIO has been received from stopped advertising it? Again, my point is that while proposed behavior *does* help in a single-homed residential case, it would be nice to keep in mind other cases and avoid breaking them; - the proposed changes say that PIOs MUST be processed as follows....and relies on hosts tracking prefix <> nexthop as per RFC8028...However RFC8028 (and RFC8504) uses 'SHOULD' ...so it seems to be inconsistency here..If a host does not implement RFC8029, all those MUST in the draft do not make much sense. > -------- Forwarded Message -------- > Subject: New Version Notification for draft-gont-6man-slaac-renum-01.txt > Date: Mon, 18 Feb 2019 15:45:21 -0800 > From: internet-drafts@ietf.org > To: Fernando Gont , Jan Zorz > > > A new version of I-D, draft-gont-6man-slaac-renum-01.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-6man-slaac-renum > Revision: 01 > Title: Reaction of Stateless Address Autoconfiguration (SLAAC) to > Renumbering Events > Document date: 2019-02-18 > Group: Individual Submission > Pages: 22 > URL: > https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/ > Htmlized: https://tools.ietf.org/html/draft-gont-6man-slaac-renum-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum > Diff: > https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-01 > > Abstract: > In scenarios where network configuration information related to IPv6 > prefixes becomes invalid without any explicit signaling of that > condition (such as when a CPE crashes and reboots without knowledge > of the previously-employed prefixes), nodes on the local network will > continue using stale prefixes for an unacceptably long period of > time, thus resulting in connectivity problems. This document > analyzes these problem scenarios, and proposes workarounds to improve > network robustness. This document updates RFC4861 and RFC4862 to > allow for a more robust reaction to network configuration changes. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- SY, Jen Linkova aka Furry From nobody Wed Feb 20 01:36: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 0CEC9130EFF; Wed, 20 Feb 2019 01:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XfPhuCWbKSa; Wed, 20 Feb 2019 01:36:36 -0800 (PST) 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 36A27130E9F; Wed, 20 Feb 2019 01:36:36 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id d18so16379620qtg.12; Wed, 20 Feb 2019 01:36:36 -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=RKjqsyzqQOp+rtVqoSebkhsOsz58aiec8GV+5Bnn/bE=; b=F+s13eopAOds5nS/LuCNrkSVNRBVxpfkV/DzTPbgedjIVKz0YuKAvvWnXTsX2jqNkz chBkmr4O6+RT3dJgLdBTlc6KAzj5YIB5+K+lDXob52nuhojXkrApKoj1N+JRrkbj3I0/ Ac4tqxrOAYTMryYsYo2FOr2Ax68LmTT1RJZiN8UB2qaTNLB0bDjdm9aifApp6lo4LxVh DwaqwoOMp42NXz48MNJKBmAXSN7yBt5Sz/ULW+d5OnHqNJiIlIDFz8ynhAoAFVN4BIHV uzdxkv4YLQFfn01HryIYarvWVCUW9NqCzVPEHpMgaFFyq+BJZq1TNmn5QcGOwUOSo8La HRcg== 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=RKjqsyzqQOp+rtVqoSebkhsOsz58aiec8GV+5Bnn/bE=; b=qKybliytV6GLy1PqhGvMeaCLuJPxWl7M72xO3fbkuziH6q3xtgA7pH0OWig1qOiUZZ UgML8WTZNcnmfEsOUin6kM6zrka/evei9QQE4gdD17smlC1hcc2xt1wti6HFKdvOiNe0 g+U6wFYHYGctpUFXElj76oULBUnFoS9z7ne3YDQtIzCfT7TASiLKSHYVWukWx7cwJ91L FrIEXs8oo9V86B0c8oyi6N459it00JziZd5hQTBW7oSgCVUVJgUtsxmqEuUQmooIqzVC tQ2jDYFg1WSQ9NOhBRg11RxL1Md8EHCWSP4B4xRvowSy4+IJfTvpiuFc+KBZ6TIxII/5 NZuQ== X-Gm-Message-State: AHQUAua2a7s4MXu4vSbAC/SRLi+RdIbvE/3hqV8XXlMgGcW5YIba8MpT S9eID0mME1otBq08rKGkrQRgH9CqPDYfpZYfaNLLAn7i X-Google-Smtp-Source: AHgI3IbR8I5exEuNJnxiZdkIgUHinC+IM0e28Qfu0qgQZ7D3jqJuc2Z4qMwwjFs/HLKGtYEYD47eOChVGvQ/QeWfpO4= X-Received: by 2002:aed:20a3:: with SMTP id 32mr26330687qtb.9.1550655395167; Wed, 20 Feb 2019 01:36:35 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> In-Reply-To: <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> From: Jen Linkova Date: Wed, 20 Feb 2019 20:36:22 +1100 Message-ID: To: Fernando Gont Cc: Mikael Abrahamsson , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 09:36:42 -0000 On Wed, Feb 20, 2019 at 3:22 PM Fernando Gont wrote: > There's room for improvement and clarification, though: one may clarify > that. You might think of this problem as havinf a reference count on the > prefix. If there's only one router associated with the prefix, un-prefer > and remove the prefix. Otherwise, just dis-associate the prefix with > this particular router. yeah, see another email I've just sent ;) > > I do believe that the default preferred lifetime is a bit longer that > > it should be (and I have to tweak it all the time). So maybe we shall > > change that. > > Same applies to the Valid Lifetime. In the context of RFC8028 it doesn't > make sense for the Valid Lifetime of a prefix to span past the Router > Lifetime of a router. Well, my ISP sent me a CPE which is configured to send RAs with router lifetime of 30 seconds or smth (I sent it back so can not verify anymore ;)) I would object if I can not listen to the music (which is stored at the machine in the network) because my Internet connection goes down (as it's been doing 5 times/day recently ;) > >> Similarly, if you have multiple interfaces, Rule 5 might override your > >> rule 8. > > > > Sorry, I must be very slow today. Could you please elaborate on this > > scenario? I'm having difficulties figuring it out.. > > Example: > > Say you have two network interfaces: If1 and If2. > Say If1, is configured with 2001:db8:1::/64, and If2 with 2001:db8:2::/64 > > Say the first default router is that associated with If1. > > Say prefix 2001:db8:1::/64 stops being announced, or that you stop > receiving RAs on If1, but RAs on If2 keep arriving fine. > > Based on the logic of your algorithm, one would expect that a new > connection uses 2001:db8:2::/64/If2 (since that's the "more recently > advertised information). However, Rule #5 would override that and make > you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresses on > the outgoing interface. I'm even more confused now, sorry ;(( Both your draft and my draft talk about cases when *the given interface* has addresses from the different prefixes and it would be nice to make sure the host selects the correct one. So in the case described above: Time t0: if1: has addresses from 2001:db8:1::/64, the default route -> if1 if2: has addresses from 2001:db8:2::/64 Time t1 an RA received on if1 containing PIO for 2001:db8:3::/64 (no PIO for 2001:db8:1::/64) Time t2 if1: has addresses from 2001:db8:1::/64, 2001:db8:3::/64 the default route -> if1. An RA received if2: has addresses from 2001:db8:2::/64 Time t3: the host is trying to send an IPv6 packet off-link. It selects if1 and now needs to select one of addresses on the outgoing interfaces. My algorithm suggests that address(es) from 2001:db8:3::/64 should be preferred as they are "freshest" ones. The same outcome as deprecating 2001:db8:1::/64 > So as long as you have stale routes, in many cases that will override > any other rules for address selection. -- i.e., if your new rule for > RFC6724 comes after rule 5, you better get rid of stale routes, or > otherwise they will override you well-intended rule. If the only routes are default routes it does not matter, right? > > The draft is talking about deprecating prefixes on *another* > > interface? I hope not.. > > Certainly not. It would be nice to make it clear IMHO... -- SY, Jen Linkova aka Furry From nobody Wed Feb 20 01:50: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 D4985124B0C; Wed, 20 Feb 2019 01:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7hB4feOmTah; Wed, 20 Feb 2019 01:49:51 -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 97AD5130DC9; Wed, 20 Feb 2019 01:49:50 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 33EE6847A3; Wed, 20 Feb 2019 10:49:43 +0100 (CET) To: Jen Linkova Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , "Jan Zorz @ go6.si" References: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 20 Feb 2019 06:49:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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] Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.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: Wed, 20 Feb 2019 09:49:54 -0000 Hello, Jen, On 20/2/19 06:08, Jen Linkova wrote: > Hi Fernando, > > On Tue, Feb 19, 2019 at 10:48 AM Fernando Gont wrote: >> We have posted a revision of our I-D, which expands a lot on the problem >> and possible solutions, based on the email discussion we had on this list. > > A few comments: > - (sorry if I missed another thread on it - I'm catching up with > emails slowly): any reason for setting Valid Lifetime to 0 as well? It > looks to me that just deprecating the prefix would be enough..What > would be a benefit of completely removing an address already > deprecated? You mean in the host-side algorithm specified in Section 5.1.3? The benefit would be garbage collection. -- another alternative would be, instead removing the addresses, reduce the current Valid Lifetime -- say to 10 minutes or whatever, so that the stale addresses do not stay around forever. (if SLAAC was using sensible timer values, you wouldn't need these... but you probably don't want stale addresses to stay around for one months, as per the default "Valid Lifetime"). > - "After normal processing of Router Advertisement messages, Router > Advertisements that contain at least one PIO MUST be processed as > follows" - I'd suggest you make it explicit that PIOs must of of > the global scope. I did see CPEs including PIOs for fe80::/64 (and > AFAIR such behavior is not explicitly prohibited); Item b) in Section 5.5.3 says: b) If the prefix is the link-local prefix, silently ignore the Prefix Information option. albeit not with normative language. But, anyway, if you've seen CPEs send them, we better make this explicit! > - the draft makes an assumption that "while network > configuration information might be split into multiple RAs, PIOs > will be spread among *at most* two RAs." - I'm not sure where > this assumption is coming from - is there any requirements for routers > saying it MUST/SHOULD do this? Adding any references to support such > assumption would be very helpful. I've never seen a scenario where information actually needs to be split among multiple RAs. I have a hard time thinking of filling up a whole RA. So the logic here was "Ok, all information is normally transmitted in a single RA. But for the sake of (rather insane :-) ) flexibility, let's assume that you send all the info is sent in as many RAs as you want, with PIOs split among two RAs". I believe it's quite unlikely that PIO information needs to be split into more than two RAs -- you'd need ~ (2*1280)/16 worth of prefixes) > - as I've mentioned earlier, it would be nice not to break other > scenarios while fixing DHCP-PD case. So what do you think about > modifying the algorithm so the addresses are deprecated only if *all* > routers the PIO has been received from stopped advertising it? Again, > my point is that while proposed behavior *does* help in a single-homed > residential case, it would be nice to keep in mind other cases and > avoid breaking them; Yes, we should update the algorithm as you suggest. Thinking our loud: best thing would probably be that, in the case the prefix has been advertised by multiple routers, it is dis-associated with the prefix that ceased advertising it. Otherwise, you might end up sending packets sourced from that prefix to the next-hop router that has ceased advertising it. That is, if multiple routers were advertising a prefix, and one has ceased advertising it, you want packets sourced from that prefix to use a next-hop router that keeps advertising the prefix. > - the proposed changes say that PIOs MUST be processed as > follows....and relies on hosts tracking prefix <> nexthop as per > RFC8028...However RFC8028 (and RFC8504) uses 'SHOULD' ...so it seems > to be inconsistency here..If a host does not implement RFC8029, all > those MUST in the draft do not make much sense. That's a good point. I wonder if we should change the "MUST" to "SHOULD", or whether we should stick to "MUST" with a rationale of "a host that implements this standard MUST implement RFC8028 and MUST process PIOs as follows..." Thoughts? Thinking out loud: I wonder if support for RFC8028 should have actually been a MUST in RFC8504 -- reality is that in many multiprefix/multihomed scenarios, if you don't do RFC8504 it's quite likely your packets will be dropped -- i.e., an interoperability issue that would have warranted a "MUST" for 8028. 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 Wed Feb 20 02:51: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 D7BE7128CF2 for ; Wed, 20 Feb 2019 02:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 r0xRvk_MtJs3 for ; Wed, 20 Feb 2019 02:51:24 -0800 (PST) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84C712DDA3 for ; Wed, 20 Feb 2019 02:51:24 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id f196so4538631yba.5 for ; Wed, 20 Feb 2019 02:51:24 -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=XrdckhZ6JrhvI4ilJJc/JGkQ+suZ2h5GgUYX9bvZpHg=; b=hKjvV6oenqZMFBJJyNC7dXPjSA6zxjYM1CAcEXvuAyYED4jtsUmi2pLelaVR4ds/3I mCDVzeQCmqgqynesBsCMXtX7L65sJzO2K04+JcHgN0gPybPGmUET/SBr8FPieNJ1fyx7 Jk6QohBbVa5E0V4daa69jXcOKvoezU0NYsoobl2nq0Jf3Ky6t3yzrvaa57afWEfnWOPD OhnIxs0v7AgZpvcf2lWb+poDxQro3uqM2aitJE3S7K8OGuHhSRH/5Zl8lOFlk6pLYIEJ VduMAC4jm/TqgGCvWRJg5LucckLQ6aj3W+2z4LRnxotBNbr7D4VXpOIpBfrhfhChcaFp qL5Q== 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=XrdckhZ6JrhvI4ilJJc/JGkQ+suZ2h5GgUYX9bvZpHg=; b=c16LRtS1ZTL2Jj/22VZ1n8gkKvkzpjtrdzyTkpCfWNEtofXQhadc4rvuINGb3UsYsF gH1d04D8CHTuR/vca8I/Jge7Zdcyb2ooIsWGBxJCZgEg63fk98/OnwqzLsVopjbR+9IJ W6jdrREg/V2lp8rCx1FlhJmYunlx/etmTkQJD+6yr1vemTMziMTzl8plKpKV+BSV4SpO Fy2kweeJofL278PpgYl2vTUVkG6CxTtkJjFbXBwB8U5tsZ3OY2BOD9g38t+i7Ta2uWVe 6K5CDarfzE04uzSP0/CyCHNWYERU0FQ68oYfgvltb4f/WX+ttw08MHPXfG5hfQpO6Vnc UgJA== X-Gm-Message-State: AHQUAuZsl6sv9NzNhNOe7odBRFcqP9CiqDkA6mtfJ4jTAQ5vHv7+hqx3 VrWG9cLxSwTujclC2mgW52yXu+YYLsw= X-Google-Smtp-Source: AHgI3IYjiKNYiIpw/i59fdmVmzY9HVmJff/Cg4HjWci/Mw0QWQgQ+CdAAIJhHeaTkBILbzXquGyLAA== X-Received: by 2002:a25:b3c2:: with SMTP id x2mr25481744ybf.40.1550659883780; Wed, 20 Feb 2019 02:51:23 -0800 (PST) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id f203sm7961825ywf.105.2019.02.20.02.51.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 02:51:22 -0800 (PST) Received: by mail-yb1-f175.google.com with SMTP id j189so9390356ybj.9; Wed, 20 Feb 2019 02:51:22 -0800 (PST) X-Received: by 2002:a25:c805:: with SMTP id y5mr28392026ybf.68.1550659882075; Wed, 20 Feb 2019 02:51:22 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> In-Reply-To: From: Richard Patterson Date: Wed, 20 Feb 2019 10:51:09 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Jen Linkova Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 10:51:28 -0000 On Wed, 20 Feb 2019 at 09:37, Jen Linkova wrote: > Well, my ISP sent me a CPE which is configured to send RAs with router > lifetime of 30 seconds or smth (I sent it back so can not verify > anymore ;)) > I would object if I can not listen to the music (which is stored at > the machine in the network) because my Internet connection goes down > (as it's been doing 5 times/day recently ;) That's what having a stable ULA prefix is useful for! From nobody Wed Feb 20 03:09: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 499C412DDA3; Wed, 20 Feb 2019 03:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7IdrRYv7D1L; Wed, 20 Feb 2019 03:08:56 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B339124B0C; Wed, 20 Feb 2019 03:08:55 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x1KB8q9s073355 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2019 11:08:52 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Richard Patterson Cc: Jen Linkova , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> From: Nick Hilliard Message-ID: <27cc7a26-1ce1-38cf-4fc8-35032cf757dc@foobar.org> Date: Wed, 20 Feb 2019 11:08:50 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.10 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 11:08:58 -0000 Richard Patterson wrote on 20/02/2019 10:51: > That's what having a stable ULA prefix is useful for! Add some NAT on the CPE and this entire problem goes away! Nick From nobody Wed Feb 20 03:21: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 911BB128CF2 for ; Wed, 20 Feb 2019 03:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 h6aKBJy0lJc9 for ; Wed, 20 Feb 2019 03:21:37 -0800 (PST) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7FB12D7F8 for ; Wed, 20 Feb 2019 03:21:37 -0800 (PST) Received: by mail-yw1-xc32.google.com with SMTP id u200so9041565ywu.10 for ; Wed, 20 Feb 2019 03:21:37 -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=tQPMKswkSnCYlPdLaynIVfKpjJEc8xQH2jlzxIFWwJc=; b=A9g9KpzxfEo5aDYB08TvIjnxWhefUKmUS+dRiNcs7c9yv+lL1i/JbyCbc6n21WM6Nu a9EbBQJcxTHI/08nLpvRKq2S89hgY5j9PCZD+rUSltDbELdnfWowG+3+e+RT13GiN6Ea qTr24NWCFTEGSWTA+clg0tQd+x3ulbTcsyutv7F0LfLaV0qaHrHgs0LhqORPjdwy/TQJ 6CPL54laqPjY3tSy151si9Es7SPa4nfqYqezHuWJjzQDByBYkZgwlYtWK9Sgqfmq1feK 74V2vjcef22rkRR/l6DzAr1reUmhmcNUdWAUBJEILW4+an3VypJMO5JVE1wmK43wohH0 LAXg== 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=tQPMKswkSnCYlPdLaynIVfKpjJEc8xQH2jlzxIFWwJc=; b=rw2ObhplN14yamizHB3rIrN7Om+TlPn4jD+1tt9QzGTmv8AGzzwZQx73+ioBPrajNK m3C2Cftc514FSa+qWPakHRsk/yULJoNiK70cKDipPhtxYZhi4xcIfyToGYC1OUFFUPlb V+y7/AYGpvbUwaxFxDgn1kQJSYYkHgjn3d1T8mUTfcsiLJbJdPEzt84hcoZ0e08PEntC xvyHVQDOdUiop+qjGrQukaetvK/7SOtUnzjGG8L73gbGdN2EDJgXXpumjaZQId9vfAqB wecAegP2DaJWnh2EBxDQdP6DnLEIYEB493ORdwzoZ3PpxssKR7AAndLrtesIVi+xuSK7 ZW0g== X-Gm-Message-State: AHQUAuZXuky7ZluGjSYv7WEC3M4IEqDFcNwMvCopmWhMzglSpUYk+vwA kSCluZ+hqHvuqnEpMfgxFj7RipD9Rvo= X-Google-Smtp-Source: AHgI3IZpdiqnpOyh+glKEDvJ0dW2Tg6Fi92FiTFHMvMoQheWrIWjhJ6yiGaBCHLp0vqHcNp5/9kYYw== X-Received: by 2002:a81:3508:: with SMTP id c8mr27369541ywa.497.1550661696150; Wed, 20 Feb 2019 03:21:36 -0800 (PST) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com. [209.85.219.169]) by smtp.gmail.com with ESMTPSA id x84sm7113157ywb.5.2019.02.20.03.21.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 03:21:35 -0800 (PST) Received: by mail-yb1-f169.google.com with SMTP id 18so7814194ybf.8; Wed, 20 Feb 2019 03:21:35 -0800 (PST) X-Received: by 2002:a25:4e05:: with SMTP id c5mr26332735ybb.389.1550661695217; Wed, 20 Feb 2019 03:21:35 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <27cc7a26-1ce1-38cf-4fc8-35032cf757dc@foobar.org> In-Reply-To: <27cc7a26-1ce1-38cf-4fc8-35032cf757dc@foobar.org> From: Richard Patterson Date: Wed, 20 Feb 2019 11:21:24 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Nick Hilliard Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 11:21:39 -0000 On Wed, 20 Feb 2019 at 11:08, Nick Hilliard wrote: > > Richard Patterson wrote on 20/02/2019 10:51: > > That's what having a stable ULA prefix is useful for! > > Add some NAT on the CPE and this entire problem goes away! Now why didn't I think of that? :) From nobody Wed Feb 20 03:23: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 9962E12D826 for ; Wed, 20 Feb 2019 03:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrDwX6d4qsuv for ; Wed, 20 Feb 2019 03:22:58 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC68012D7F8 for ; Wed, 20 Feb 2019 03:22:58 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7356441B93 for ; Wed, 20 Feb 2019 12:22:56 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 5DD5F41B57; Wed, 20 Feb 2019 12:22:56 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 4E5FFB5EB2; Wed, 20 Feb 2019 12:22:56 +0100 (CET) Date: Wed, 20 Feb 2019 12:22:56 +0100 From: Gert Doering To: Nick Hilliard Cc: Richard Patterson , Fernando Gont , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Message-ID: <20190220112256.GI71606@Space.Net> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <27cc7a26-1ce1-38cf-4fc8-35032cf757dc@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27cc7a26-1ce1-38cf-4fc8-35032cf757dc@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.11.2 (2019-01-07) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 11:23:00 -0000 Hi, On Wed, Feb 20, 2019 at 11:08:50AM +0000, Nick Hilliard wrote: > Add some NAT on the CPE and this entire problem goes away! NATs are good! (Seriously, given what a train wreck IPv6 seems to become, NPT and ULAs or IPv6 PI inside is increasingly looking more attractive...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Feb 20 03:25: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 6CF7812D826; Wed, 20 Feb 2019 03:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADAm7cs00o0y; Wed, 20 Feb 2019 03:25:05 -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 1302C128CF2; Wed, 20 Feb 2019 03:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550661903; x=1551266703; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=ZXH3m08NXx5GNZyWOqafKkF8zwxiO+fnAp2pZ6BmtOw=; b=K+e47Ud5VG1bK nZkKtxMAjRCxpV4O0lH2Yl3gDNb1zNA/ZJc0lgAsS1hLmnfm18UwWdLAZjdWk9/q uyDzMxsFV8K57Fgaby12Bb60yiMHxNyzEtH7yzeQ4c41Po9NF2Cnisn2qOs30ixA WIMcWmq1XJf/MCHmmI7x95QGkfJzsA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 20 Feb 2019 12:25:03 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 20 Feb 2019 12:25:02 +0100 Received: from [10.10.10.160] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006161528.msg; Wed, 20 Feb 2019 12:25:02 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.10.10.160] X-MDArrival-Date: Wed, 20 Feb 2019 12:25:02 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1954f3d980=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Wed, 20 Feb 2019 20:24:51 +0900 From: JORDI PALET MARTINEZ To: Gert Doering , Nick Hilliard CC: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <27cc7a26-1ce1-38cf-4fc8-35032cf757dc@foobar.org> <20190220112256.GI71606@Space.Net> In-Reply-To: <20190220112256.GI71606@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 11:25:08 -0000 What a sacrilege! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Gert Doering Fecha: mi=C3=A9rcoles, 20 de febrero de 2019, 20:23 Para: Nick Hilliard CC: Fernando Gont , IPv6 Operations = , "6man@ietf.org" <6man@ietf.org> Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios Hi, =20 On Wed, Feb 20, 2019 at 11:08:50AM +0000, Nick Hilliard wrote: > Add some NAT on the CPE and this entire problem goes away! =20 NATs are good! =20 (Seriously, given what a train wreck IPv6 seems to become, NPT and ULAs or IPv6 PI inside is increasingly looking more attractive...) =20 Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? =20 SpaceNet AG Vorstand: Sebastian v. Bomhard, Michae= l Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 =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 Wed Feb 20 03:26: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 4E15312D826; Wed, 20 Feb 2019 03:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOkttRBz8_ue; Wed, 20 Feb 2019 03:26:22 -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 AD18B128CF2; Wed, 20 Feb 2019 03:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550661979; x=1551266779; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=t/fJ7d3wv+7zFkAPRU3vxeoNnTYeOFitHBc5TZJIiIM=; b=TKyxY/tbRsLq7 g7thy2oqGnPldyCSuEZ3DEBOpR2KbiPCe+Q1/92thsLktPAL1HPi4+8quLlFgr0m Az7S8Uqw/ue0lbaCIcqBDb6idT5JBVrY4URsBRaLo1taypdW4L2VjbvuBC6b0hOE ZOm5ojVaZ5mNgoLi5VZa2m1HOhCSG4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 20 Feb 2019 12:26:19 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 20 Feb 2019 12:26:17 +0100 Received: from [10.10.10.160] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006161532.msg; Wed, 20 Feb 2019 12:26:17 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.10.10.160] X-MDArrival-Date: Wed, 20 Feb 2019 12:26:17 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1954f3d980=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Wed, 20 Feb 2019 20:26:08 +0900 From: JORDI PALET MARTINEZ To: Gert Doering , Nick Hilliard CC: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <27cc7a26-1ce1-38cf-4fc8-35032cf757dc@foobar.org> <20190220112256.GI71606@Space.Net> In-Reply-To: <20190220112256.GI71606@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 11:26:24 -0000 Ok, so let's go for IPv6 PI for every household, business, etc. ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ipv6 en nombre de Gert Doering Fecha: mi=C3=A9rcoles, 20 de febrero de 2019, 20:23 Para: Nick Hilliard CC: Fernando Gont , IPv6 Operations = , "6man@ietf.org" <6man@ietf.org> Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios Hi, =20 On Wed, Feb 20, 2019 at 11:08:50AM +0000, Nick Hilliard wrote: > Add some NAT on the CPE and this entire problem goes away! =20 NATs are good! =20 (Seriously, given what a train wreck IPv6 seems to become, NPT and ULAs or IPv6 PI inside is increasingly looking more attractive...) =20 Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? =20 SpaceNet AG Vorstand: Sebastian v. Bomhard, Michae= l Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =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 Wed Feb 20 03:36: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 01C2A128CF2 for ; Wed, 20 Feb 2019 03:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prlRWFluGRxG for ; Wed, 20 Feb 2019 03:36:05 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780FD12D826 for ; Wed, 20 Feb 2019 03:36:05 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 760B141CDB for ; Wed, 20 Feb 2019 12:36:03 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 6180A40082; Wed, 20 Feb 2019 12:36:03 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 5C7F0B5EFD; Wed, 20 Feb 2019 12:36:03 +0100 (CET) Date: Wed, 20 Feb 2019 12:36:03 +0100 From: Gert Doering To: JORDI PALET MARTINEZ Cc: Gert Doering , Nick Hilliard , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: <20190220113603.GK71606@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4sIpN43wh+0KCG0T" Content-Disposition: inline In-Reply-To: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> X-NCC-RegID: de.space User-Agent: Mutt/1.11.2 (2019-01-07) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 11:36:07 -0000 --4sIpN43wh+0KCG0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Feb 20, 2019 at 08:24:51PM +0900, JORDI PALET MARTINEZ wrote: > What a sacrilege! There's so much wrong with current IPv6 standards and implementations and processes that "just go with NPT" would save a lot of pain. I'm no longer holding by breath for *useful* SoHo implementations (like, full homenet multi-router / multi-homing support, with proper firewalling, etc.) or useful client application behaviour. > Ok, so let's go for IPv6 PI for every household, business, etc. ... The PI part was more about "guaranteed uniqueness", which is important for enterprise interconnections. ULA-C would have nicely solved this as well, but since we do not have it, ULA-L for "I have nothing in my home which someone wants to reach over VPN" and PI for "VPN access should be possible without address collisions". OTOH, many large-enterprise VPNs use NAT today to work around the duplicate-address problem, so whatever. Just add NAT there. (Quoting in the same style as everyone else does in this conversation would be just so slightly more polite than blowing out two one-line- full-quote mails in a properly quoted discussions. Just sayin) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --4sIpN43wh+0KCG0T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlxtO4sACgkQ31bAZeTO f8XUBw/9HJTMr79QU6pwEVg825h46KuMjfpAkuwl390oyDdDEBw04IsedZJarJU2 xLLPteyxKlWWmKcJQrQDECZfM7ZAWraqa25Ex7gFezhec30Sa7ceJxV8vW/ebW7/ 6F45biyHTLc9MHyX3S/Xktm/weYNnOaj0fvzqyNIxHTINrhZV1EWrcKZKi7hRUd1 CgOKnw7mzUtoWIKgcchyc0lShsrEpaGgRajaRReKpfPtSRG+08OVflQ8ah0XUbYJ H5wOHZbkPWk4SMtI+YnJboTQ1yC5VBQ1SVKrlfb1GRvuANzxgSyzdkcPXGNfxbRI S48fPVQGk7yu0rodCEC0HEIGyNm2L4RQB1R2Kf7U/Rd/iLXVv3+BJrjr+XteQJ07 Czq2Tdmo5us9I019Hkg5bcVFQRi90L8sWoDVK0aaJwM9Vqk8UA+kHE6EVxjMPxWX 31oOk43sLiLzyKC3EvCrY8nhezWjf+OzDjDbGB8H8k6QkpA5oLcgnBOpqF3x3Ibf ggxg8q8iT9gVyq/VddfSW+yI8TxfMA6O0NK6y9TI+5igBDwzkwm5PE6jrMIw4eHO vPPhXyeJLU4ghLC6dCdmdztSL3dLg7sL5ZsPfS31RIvUdKmI4rbkH8+B+YAPtrWZ utFnhtbNSjZEITd4A0JVl7vlaT/rJY7hiJOTCs2p609krmYUwJU= =8kSi -----END PGP SIGNATURE----- --4sIpN43wh+0KCG0T-- From nobody Wed Feb 20 04:03: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 917F512DDA3; Wed, 20 Feb 2019 04:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBGgKqaWHtMU; Wed, 20 Feb 2019 04:02:49 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4239A129284; Wed, 20 Feb 2019 04:02:49 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 02109E6079; Wed, 20 Feb 2019 13:02:45 +0100 (CET) Date: Wed, 20 Feb 2019 13:02:45 +0100 (CET) Message-Id: <20190220.130245.526931615.sthaug@nethelp.no> To: gert@space.net Cc: jordi.palet@consulintel.es, fgont@si6networks.com, v6ops@ietf.org, 6man@ietf.org From: sthaug@nethelp.no In-Reply-To: <20190220113603.GK71606@Space.Net> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> 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 common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 12:02:53 -0000 >> What a sacrilege! > > There's so much wrong with current IPv6 standards and implementations > and processes that "just go with NPT" would save a lot of pain. Would you be interesting in making a list of what you think is wrong? (I'm not disagreeing, I'm just curious...) Steinar Haug, AS2116 From nobody Wed Feb 20 06:42: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 8F678130E1C for ; Wed, 20 Feb 2019 06:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6VjnbsAmpEW for ; Wed, 20 Feb 2019 06:42:31 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09208127AC2 for ; Wed, 20 Feb 2019 06:42:26 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7602641C2A for ; Wed, 20 Feb 2019 15:42:22 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 5FFE741B56; Wed, 20 Feb 2019 15:42:22 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 51C42B6297; Wed, 20 Feb 2019 15:42:22 +0100 (CET) Date: Wed, 20 Feb 2019 15:42:22 +0100 From: Gert Doering To: sthaug@nethelp.no Cc: gert@space.net, jordi.palet@consulintel.es, fgont@si6networks.com, v6ops@ietf.org, 6man@ietf.org Message-ID: <20190220144222.GL71606@Space.Net> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <20190220.130245.526931615.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iWgke0titJZxhgDH" Content-Disposition: inline In-Reply-To: <20190220.130245.526931615.sthaug@nethelp.no> X-NCC-RegID: de.space User-Agent: Mutt/1.11.2 (2019-01-07) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 14:42:32 -0000 --iWgke0titJZxhgDH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Feb 20, 2019 at 01:02:45PM +0100, sthaug@nethelp.no wrote: > >> What a sacrilege! > >=20 > > There's so much wrong with current IPv6 standards and implementations > > and processes that "just go with NPT" would save a lot of pain. >=20 > Would you be interesting in making a list of what you think is wrong? > (I'm not disagreeing, I'm just curious...) Oh, that list will be long, so doing it in a useful way will take some time. Just a quick list of things that come to my mind right away There's "protocol inherent" issues that turn out to be amazingly stupid in retrospective - using IPv6 for ND/NA - "you cannot attack something from remote which is not IP" - usiing a mix of local and global addresses for ND/NA source/dest (so filtering "only accept those ND/NA packets that can correctly happen on *this link* and drop all else" is fairly tedious) - using multicast for core functionality - little benefit compared to broadcast in today's networks - lots of extra complexity in network drivers, switch forwarding planes, Wifi, ... -> lots of bugs and problems - replicating the ARP model of "neighbor solicitation when a packet comes in" instead of trying something akin to LANE, where you just register with "someone" who knows all the L2/L3 mappings for a given LAN segment on connection, and nobody has to probe -> "scan /64, exhaust ND" attacks totally defused - unbound chain of extention headers=20 - carrying link-local next-hop addresses in IPv6 BGP sessions that are connecting peers on the same LAN using their GUAs (so at least one major vendor installs a next-hop in the FIB that is different from=20 the BGP peer it is talking to - combine that with ND bugs galore, and you get blackholing due to LLA next-hop unreachability, while BGP thinks "all is good") Then, there's market and IETF process fails - homenet protocol suite - this is something that could have been=20 insanely great, with "just plug in a second ISP into your home network, all machines understand that they have two options for 'connect to the Internet' now, and users have full control" IETF process fail: stall this by haggling two years over "what sort of routing protocols should we have in the homenet protocol suite? we must have negotiations! options! flexibility!" market fail: CPEs have their implementations done. Nobody (but OpenWRT) seems to be working on homenet implementations. double market fail: ISPs have no interest in requesting this from=20 their vendors (so, IETF fail again, because that way it never made it into the CPE requirements list...) - because it would empower their customers to more easily switch ISPs, while they would have to pay the development costs. - source address *failover* in case a machine has multiple source=20 addresses and one of them is broken. We have happy eyeballs for=20 "multiple destinations", but as far as I'm aware (maybe I have=20 missed something) still no "we might want to probe multiple sources if the preferred best source seems to be non-working". =20 Actually this thread is fixing one of scenarios when this can happen (because your router went belly-up), but there's "you have two /64 from two ISPs on your LAN, with two routers happily announcing their RAs, but one of them just cannot reach your preferred destination due to external breakage" - in which case you want to try the other source. - the whole "multiple /48 multihoming" debacle - combined with homenet,=20 this is a really great idea for SoHo environments, especially if you combine it with application smartness, so you can tell your web browser "I want to surf via MyCableNet now!" while your torrent client is filling YourDSL.ISP link... Instead of having nice things, what we *do* get is RFCs that explain "if your primary ISP goes belly-up, withdraw primary RA, send RA for secondary ISP"... (sorry, Jen, but I think this is a bandaid for a much more fundamental flaw). - Firewalls on home routers - so, what do I need global IPv6 addresses in my home network if IETF keeps telling people "you better should not have these addresses reachable from the world!! because, security!!!"? Combined with "CPE market fails" I can now have native IPv6 at home (great), combined with a CPE that has severe limitations on what can be permitted in its ACL handling. Well, after some 5 years, AVM *did* manage to permit IPv6 traffic to DHCPv6-PD-delegated prefixes, but=20 this is still unsatisfactory. - did I mention CPEs? Like, AVM, which claims that there is no way to transport IPv4 over an IPv6-transported VPN, so their CPEs will not implement VPN over IPv6. Great combination if you're sitting behind a ds-lite ISP and have no public v4 address at all... (bashing AVM is actually somewhat unfair, since most other CPE vendors are 10 years behind) - did I mention VPNs? Like, Fortinet, who do support VPN over IPv6, and IPv6 over VPN. And VPN over IPv4, and IPv4 over VPN. But they do not support "IPv4 payload over IPv6 VPN", because, "where is the business case for that?" - like "I'm sitting behind a carrier-grade NAT IPv4=20 at home, but I have proper IPv6, and I want to reach my IPv4-only backend servers in the datacenter over your VPN"... - I *did* mention the dual-stack IPv6 socket API, did I, with lots of extra code paths everywhere and the amount of bugs this introduces? (in retrospective I can only applaud OpenBSD for refusing to implement it - I did not understand it back then, "because it is so much more convenient!", but I was wrong) - another market fail: 3GPP mandates IPv6 for UMTS. 3 out of 4 mobile ISPs in DE do not offer IPv6 at all... (nowadays it's no longer "3" since Telefonica bought E-Plus, but when 3G was rolled out, none of the 3 had any interest in v6...) - and of course, having to deploy IPv4 in 2019, because "The Internet" took over 20 years to not-deploy IPv6 widely enough that we could=20 finally start shutting down IPv4... instead we have haggling and arguments galore over the last scraps of IPv4... So, that was the unsorted "things that came to my mind" list - it might be factually not correct if I missed interesting new developments, and it might be unfair to people that had the best of intentions, but this is where we are: in an annoying mess of half-done half-working things. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --iWgke0titJZxhgDH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlxtZ0sACgkQ31bAZeTO f8UQEA/+L6AnT8QOMHnFut5la86/klN/Zy6bHwpKmcPQ5ruocR6Bje/jPBZXLi2s 3VOUi4lkXKYCkpngnX+6jPl5+FhnWGBKe4OQzOpC+CO0KTM0LKlBHA6YtXe/JItA WlevZclOMgloA7yhk5lHZY4iiVJ4j3bRglQ90YOMC/WtWYXq1woDNQtWAhRFlVWd jz2y56B6Fwb4RUGK+M2mxbjzk9DCZfKm/FHfQljaPVkFIqgiCh/sr9LwQwo3oc+o xFgXEZrsfFvqxrZw228+5UoQCKNihk6EuKafMWpEh0iPQ8kQ1h3nJ6yteUhexsYH GF3rf1js7dWLf9JyeBk6vppjstysf4BM18jN7ENyaAyR48ziZ1N7aNeyTGCOUaQv cf4qU+ewbWlCKkjnVCmPmSyXrVRubkjM74xxN8Rtmncw0XqrZSIn8oYEWT5Za80J dQOQqv7NWLJx/yrvsdbbMj8vUFz8fP1mPKTSk5JvoMRc11z4BqRO58Kmnc4BJvoe KuNAsGeNoDdIfCy3WTE15SX9fUwylNCjJfRO21N7LXwS6HMrJQA2OBWqIopU+OfX 4e/2ME7TXr1SyiEA2NGM42uaqK8T3ykYQDpQuheS99bFl3bn9lG3url2xhHeXgSc Hd/zX1nvI26LJY/I+8anKLu23WsZUET++ahCcv4WTBCzsLXn2lE= =rB5p -----END PGP SIGNATURE----- --iWgke0titJZxhgDH-- From nobody Wed Feb 20 07:03: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 9673C129741 for ; Wed, 20 Feb 2019 07:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfF1A65bnHLI for ; Wed, 20 Feb 2019 07:03:17 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A32130E2E for ; Wed, 20 Feb 2019 07:03:14 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DF13B41CDB for ; Wed, 20 Feb 2019 16:03:11 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C99C041B56; Wed, 20 Feb 2019 16:03:11 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id BB691B62FF; Wed, 20 Feb 2019 16:03:11 +0100 (CET) Date: Wed, 20 Feb 2019 16:03:11 +0100 From: Gert Doering To: sthaug@nethelp.no Cc: gert@space.net, jordi.palet@consulintel.es, fgont@si6networks.com, v6ops@ietf.org, 6man@ietf.org Message-ID: <20190220150311.GO71606@Space.Net> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <20190220.130245.526931615.sthaug@nethelp.no> <20190220144222.GL71606@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DeQ9GnsEQp3CI+P2" Content-Disposition: inline In-Reply-To: <20190220144222.GL71606@Space.Net> X-NCC-RegID: de.space User-Agent: Mutt/1.11.2 (2019-01-07) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 15:03:19 -0000 --DeQ9GnsEQp3CI+P2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Feb 20, 2019 at 03:42:22PM +0100, Gert Doering wrote: > Then, there's market and IETF process fails Ooooh, I totally forgot the "RA vs. DHCPv6" train wreck. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --DeQ9GnsEQp3CI+P2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlxtbC4ACgkQ31bAZeTO f8XUBQ//ejECWC/uGy3CFLgzNBR9rKsNXHvunw1mwK/xrZk4y72LknuoXQgla2aR ZOarBhIsDD1eTzzwsqs9esQ3IdME/DpLVgB1rJlRFtxeVqphJtUcGcN82D/N9XdM HSX4MOG7rEs2ETW10ceT8POIHxQ2cQSVp9fBiCZxs5W09TGc0fUHc9iBTTB5QZbE k/SwJ11wTczkF6zAw9B+BtARF0Dk/LlbFCyHnYJwls7GaLK1Vwgn8ygsISZe/FNG cBTzEQLwMgLdlPnjpO/9YH3A48DtEDu01U/NMOTwJdvke64sTLivaLm4xoSKxvyh UEy4cTweFim1n183Rd6BfkKKa65ZiWcel5RJ/KLFv5RGJXfQzifDy37Fql1YRVMY j/FCu9fl4fscD03f4BDXUUKN3S08acRYPEG1m/15vEv+iis3zMYbh9nRomry8GFf y5I/uda0gqx/xwvxyNwzhv+D9cV1NBw32xmLp+Yxqq/2ts1c4iR5YSDf3zrhqCTc rPgM+g+DYzxzQy0uTfikWWJZ9nGjbv3xzxfrs0+unBrKGdpOHlK2emdJXAaoKlWb yZtJLzqmgZUGmE/e4CLRl1+AKB8GiGvWNNWuuBQYDgvZEdcgvsgS04HuAO2Vk/Gl lDz3fu3zYOynV8aIO7QfOzcV/eFBH4X3jjdOTp8emyMmi5GfqfQ= =8AEJ -----END PGP SIGNATURE----- --DeQ9GnsEQp3CI+P2-- From nobody Wed Feb 20 09: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 528BA1277D2; Wed, 20 Feb 2019 09:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_XrwpNBW9ih; Wed, 20 Feb 2019 09:09:25 -0800 (PST) Received: from mail.conjury.org (prime.conjury.org [174.136.98.234]) by ietfa.amsl.com (Postfix) with ESMTP id D0EAC12870E; Wed, 20 Feb 2019 09:09:25 -0800 (PST) Received: from [192.168.1.67] (zoox-inc.wh.edge1.sanjose2.level3.net [4.28.172.66]) by mail.conjury.org (Postfix) with ESMTPSA id 2E9E4E6037; Wed, 20 Feb 2019 08:32:12 -0800 (PST) From: j h woodyatt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Feb 2019 09:09:24 -0800 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> To: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations In-Reply-To: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> Message-Id: <9D7D5944-FCC1-4237-B530-7C1DB1B61A56@conjury.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 17:09:29 -0000 On Jan 31, 2019, at 03:00, Fernando Gont wrote: >=20 > https://tools.ietf.org/html/draft-gont-6man-slaac-renum For the record, I agree with the authors that reducing the default = values for AdvPreferredLifetime and AdvValidLifetime is an idea with = merit. The other changes seem less obviously good, as they resemble previous = unsuccessful attempts to hammer the DHCPv6 and Router Discovery = protocols into resembling a proper routing protocol, which they are not, = and which I think we should admit they never will be. Having experienced = the futility in attempting to improve Router Discovery and/or DHCPv6 to = resemble a proper routing protocol, I would say I=E2=80=99ve seen better = and more elegant solutions to these problems, which unfortunately all = depend on host operating systems adopting the model that hosts sometimes = have cause to participate in the network routing protocol. As this idea = has never been taken seriously by the community, I think it=E2=80=99s = probably best to leave it behind. Shorter james: keep section 5.1.1 and drop sections 5.1.2, 5.1.3, 5.2 = and 5.3. --james woodyatt From nobody Wed Feb 20 12:20: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 EE8BC130E96; Wed, 20 Feb 2019 12:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQQ9Q2dV9N43; Wed, 20 Feb 2019 12:19:59 -0800 (PST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 C88ED130E9A; Wed, 20 Feb 2019 12:19:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1KKJtrq019438; Wed, 20 Feb 2019 15:19:55 -0500 Received: from XCH16-01-09.nos.boeing.com (xch16-01-09.nos.boeing.com [144.115.65.234]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1KKJmsp018370 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 20 Feb 2019 15:19:49 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-09.nos.boeing.com (144.115.65.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Wed, 20 Feb 2019 12:19:47 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Wed, 20 Feb 2019 12:19:47 -0800 From: "Manfredi (US), Albert E" To: Gert Doering CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUyRB17V+FnESOAEi8Djm3PcxDpKXpHwZQ Date: Wed, 20 Feb 2019 20:19:47 +0000 Message-ID: <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> In-Reply-To: <20190220113603.GK71606@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: 5CC738F2393790F25B78D1939AB2CF743C3AE181D140DBC0788078781482D5842000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 20:20:01 -0000 -----Original Message----- From: ipv6 On Behalf Of Gert Doering > There's so much wrong with current IPv6 standards and implementations and processes that "just go with NPT" would save a lot of pain. Wait, whether that's partially said in jest or not, NPT was invented primar= ily to add the 16-bit Port ID to the limited 32-bit address space of IPv4. = But with IPv6, a "basic NAT" would not need to also do port translation. Pl= enty of addresses available. And it would make addresses behind the NAT as = stable as anyone could want. Just a 1:1 mapping, with the WAN addresses. Doesn't that take away most of the pain, maybe all of the pain? And solve t= his problem? (Sometimes, to solve a vexing problem, you have to do a "paradigm shift.") Bert From nobody Wed Feb 20 12:30: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 18589130E91; Wed, 20 Feb 2019 12:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzJbIT5LgyPL; Wed, 20 Feb 2019 12:30:10 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF1F130E85; Wed, 20 Feb 2019 12:30:09 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x1KKU3Cn040177 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2019 20:30:03 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: "Manfredi (US), Albert E" Cc: Gert Doering , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> From: Nick Hilliard Message-ID: <7bf05276-9fb1-f2d3-83a6-ec329e5968ae@foobar.org> Date: Wed, 20 Feb 2019 20:30:02 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.10 MIME-Version: 1.0 In-Reply-To: <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 20:30:12 -0000 Manfredi (US), Albert E wrote on 20/02/2019 20:19: > Wait, whether that's partially said in jest or not, NPT was invented > primarily to add the 16-bit Port ID to the limited 32-bit address > space of IPv4. But with IPv6, a "basic NAT" would not need to also do > port translation. Plenty of addresses available. And it would make > addresses behind the NAT as stable as anyone could want. Just a 1:1 > mapping, with the WAN addresses. > > Doesn't that take away most of the pain, maybe all of the pain? And > solve this problem? it certainly does, at the cost of very little technical innovation and a quantity of pain that most people are already familiar with and are happy to accept - or even welcome in some situations due to the perception of security benefits. Nick From nobody Wed Feb 20 13:31:15 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 395EC12D4E7 for ; Wed, 20 Feb 2019 13:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU0OzGmiwqS8 for ; Wed, 20 Feb 2019 13:31:11 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BCF128CF3 for ; Wed, 20 Feb 2019 13:31:09 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CC38941B56 for ; Wed, 20 Feb 2019 22:31:07 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id B972141B51; Wed, 20 Feb 2019 22:31:07 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id AB347B69E9; Wed, 20 Feb 2019 22:31:07 +0100 (CET) Date: Wed, 20 Feb 2019 22:31:07 +0100 From: Gert Doering To: "Manfredi (US), Albert E" Cc: Gert Doering , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: <20190220213107.GS71606@Space.Net> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jXOm+/RfH/DUBEsl" Content-Disposition: inline In-Reply-To: <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.11.2 (2019-01-07) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 21:31:13 -0000 --jXOm+/RfH/DUBEsl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Feb 20, 2019 at 08:19:47PM +0000, Manfredi (US), Albert E wrote: > -----Original Message----- > From: ipv6 On Behalf Of Gert Doering >=20 > > There's so much wrong with current IPv6 standards and implementations > and processes that "just go with NPT" would save a lot of pain. >=20 > Wait, whether that's partially said in jest or not, NPT was invented prim= arily to add the 16-bit Port ID to the limited 32-bit address space of IPv4= =2E But with IPv6, a "basic NAT" would not need to also do port translation= =2E=20 My "NPT" was intended to be an acronym for "Network Prefix Translation", so yes, exactly this. Keep ports, keep host part (if desired), just translate prefix. We even have an RFC for that :-) But then, I'm not using IPv4 NAT @ home... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --jXOm+/RfH/DUBEsl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlxtxxkACgkQ31bAZeTO f8UxAA//bfWdmSPKYi9C25sJW6baPG2xdB0hVw/bRjWBMQUx2j/idmMF8jeejgW0 J9QAVurXKKQAdzJKwxipI3MzJe+ifXgzwvqMJYcRSyV/iuteGbnPmIaFT3tBY6Gz Cj8RZfhXVUgLjRFOImZw7eWE+vfNb9T1eugIo+4eqcPurKSqUyuu+Z1rukkqr868 vYmbAOEkQ/zk9FIXwd84sOlVK4y8PMTCSywRo/c5acK2Vtnl0sp2dflIk+8WJbOx FJyllPwz2xqiLVG2CZ5GrkbCmTsT7ez9MIYocv1BcFQOU5hD3qWNy1IXdNJOjTfH IMAVSrlPe6iNg8ciGsxE7BpHY486VPXGX2CvptvHzlWvh3zNeRsW2x5RbZxz/SuU otAhBF4HeuiiUvbuyoRq+9GOc9y8G43R0XxJL9nFaxzPtK+wZBEQHG9BEliaNXO+ HO9mnocuWnqPTQcYU39yZZjU2ThEJIFFDT+K88bvVVH8Xxs9hFb5BmAzGZ4+wzDF ZjRs1ls/H1PFBvl8razlkNvf8kNd0Tq5u88Kl1m5FkYBAxj0YmOYrZz4NKjVoG0q Rr13YfsqWWPCpk1t8cmonBs5nUjB1e35+DCJK67Qny1eLAANL7caiRDbw7LlDb6+ hrV++OWa+NU7Pbo93YiVtn8+ZvFkuGY+a1mgwWLSpJtYBibf1HI= =4yo/ -----END PGP SIGNATURE----- --jXOm+/RfH/DUBEsl-- From nobody Wed Feb 20 14:17: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 B2952129AA0; Wed, 20 Feb 2019 14:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agoqLXNDQWN3; Wed, 20 Feb 2019 14:16:47 -0800 (PST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 01FD5128701; Wed, 20 Feb 2019 14:16:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1KMGiqH001799; Wed, 20 Feb 2019 17:16:45 -0500 Received: from XCH16-01-09.nos.boeing.com (xch16-01-09.nos.boeing.com [144.115.65.234]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1KMGb3p032600 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 20 Feb 2019 17:16:37 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-09.nos.boeing.com (144.115.65.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Wed, 20 Feb 2019 14:16:36 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Wed, 20 Feb 2019 14:16:36 -0800 From: "Manfredi (US), Albert E" To: Gert Doering CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUyRB17V+FnESOAEi8Djm3PcxDpKXpHwZQgACcI4D//4RNUA== Date: Wed, 20 Feb 2019 22:16:36 +0000 Message-ID: <019c552eb1624d348641d6930829fd1f@boeing.com> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> In-Reply-To: <20190220213107.GS71606@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: 108F5043C15D8D455BC54FD4A5296282BD5F09A0B228FE87AF3D5C8E6A7AF6D42000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 22:16:49 -0000 -----Original Message----- From: Gert Doering =20 > My "NPT" was intended to be an acronym for "Network Prefix Translation", so yes, exactly this. Keep ports, keep host part (if desired), just translate prefix. We even have an RFC for that :-) Right. So, why shouldn't this NAT66 idea be taken more seriously? All of th= e advantages of the basic NAT come to bear, including the renumbering probl= em in enterprises, including no changes required to SLAAC timers, and sessi= ons easily survive a reboot of the edge router, and yet none of the port tr= anslation kludge that made NATs useful in IPv4. And the solution can be introduced gradually. For homenets, for example, yo= u let things default back to IPv4 as they seem to do today, until the user = acquires the CPE with NAT66, or ntil the ISP finishes updating all of the s= ubscriber households. From then on, "it just works." And IPv4 can be retire= d. Bert From nobody Wed Feb 20 15:18: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 0D9F1130E9C; Wed, 20 Feb 2019 15:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHYb2Q5mhff2; Wed, 20 Feb 2019 15:18:42 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8537E130E58; Wed, 20 Feb 2019 15:18:42 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id o6so13056695pls.13; Wed, 20 Feb 2019 15:18:42 -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=Q5R6KZGEGZsTDI+0JdjoFI1AS03198LpKTzo7l6qjl4=; b=Nn/jFOzhfeWRorZGTTOT24DVto3z7dFxCtl3km4O8VuI53x1ohVvxG43lYU/voOOEf GZucbU33dHqXhXK3CCy0R+5IhPr1QZdhDMPdXZxaR0CvMBy6jzXVeRaXc/UoFTzLHfzi Zo0f0+jYEbM1Lt4T5vCgu0tMq5L50UJ5W0+anh6VSRrgmnZnimJAopLqj3fwRGFwrMux 6wWuHM56LhouwKZJN0AR7fRyKru6ooyMQyZt4rL6rOfNlU9r8DObraM8qihiTk88Luf2 qZEFleNeWf2o1M23f2Qbzu0PQgI/Gy7bw/85z4OGU+HykvepeJRnYe9rQ+df+Ro7RliO g1zw== 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=Q5R6KZGEGZsTDI+0JdjoFI1AS03198LpKTzo7l6qjl4=; b=SfelCvPLwYjz4VCKl5LwKt1Mq/JU3OcYMAWWU1Lyb0EKZiNjQ9WKZ3kpU/UspPBVZw F2FKfs/IPLpwQKI1jKP638Y6w6Sd2UCLZlXoUvA5Vh/kbWKzNxpL6/uS/fLLLgBCOd28 S/JfniUVtzPo2wVrsauQ6GDCw4TDZ1gYUY1XdeYaSF8w7Yw2nFuj5fVYQn8up5Z/y5vq VNxVd0JeJ4lfF0hsSoC5bws2fzjCovP7TxnxFOZ21sDhuHl1eeFsiJJecV2EHdChWTj3 AkQblPi8q+At4J67ETaDUGU1dD02MOBqpepCMBrsBht6KzjsGTgR1PTyXFa4taHFv9Yz oMPw== X-Gm-Message-State: AHQUAuYS9MA843LHopI3WWQ3s985Xeeb748hAM4W1UKAosCDJENew9sP yBUTjAxdBhTXPxODuaU7d4bKIwzo X-Google-Smtp-Source: AHgI3IYiyXpPh3vURehPZCYJHXaNjuy8WsVwALt47V6BHlo90ZTMxbdqJBDXqNuxRahjBmgsBGIqKg== X-Received: by 2002:a17:902:6a4:: with SMTP id 33mr38493746plh.99.1550704721633; Wed, 20 Feb 2019 15:18:41 -0800 (PST) Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id y133sm27089193pfb.107.2019.02.20.15.18.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 15:18:40 -0800 (PST) To: "Manfredi (US), Albert E" , Gert Doering Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> From: Brian E Carpenter Message-ID: Date: Thu, 21 Feb 2019 12:18:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <019c552eb1624d348641d6930829fd1f@boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 23:18:45 -0000 On 2019-02-21 11:16, Manfredi (US), Albert E wrote: > -----Original Message----- > From: Gert Doering > >> My "NPT" was intended to be an acronym for "Network Prefix Translation", > so yes, exactly this. Keep ports, keep host part (if desired), just > translate prefix. We even have an RFC for that :-) > > Right. So, why shouldn't this NAT66 idea be taken more seriously? NPTv6 is not NAT66, as the NPTv6 *Experimental* RFC explains. > All of the advantages of the basic NAT come to bear, I'm not sure that that is true, but NPTv6 brings some, but not all, of the disadvantages of NAT too, as also explained in RFC6296. It isn't needed for enterprise renumbering, and it isn't needed for enterprise security. This is all very old news. I mean, 10 years old at least. NPTv6 as a work-around for a defect in SLAAC when there is an unplanned renumbering? That's a very large hammer applied to quite a small screw, IMNSHO. Fixing SLAAC seems like a more scientific approach. In the context of homenets and HNCP, NPTv6 is even more pointless. Brian > including the renumbering problem in enterprises, including no changes required to SLAAC timers, and sessions easily survive a reboot of the edge router, and yet none of the port translation kludge that made NATs useful in IPv4. > > And the solution can be introduced gradually. For homenets, for example, you let things default back to IPv4 as they seem to do today, until the user acquires the CPE with NAT66, or ntil the ISP finishes updating all of the subscriber households. From then on, "it just works." And IPv4 can be retired. > > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Feb 20 15:43: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 DFD1F130E58 for ; Wed, 20 Feb 2019 15:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fghRlnZGWMim for ; Wed, 20 Feb 2019 15:43:34 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F57212D7EA for ; Wed, 20 Feb 2019 15:43:34 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id x131so19743069itc.3 for ; Wed, 20 Feb 2019 15:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=89jIuysLQPQkJXmMqbkh0Gz7Jsd4Q9zSmqAZdMmc8k4=; b=K9oCdZc+Xp8BWXJ46yGulEpiGR9SvZhCEIVnburfE3BABZ4/Dx6AiiFjyPEpkGpUFk 58Do7HCww/gz1LGtdRa+CsJ1HXY+r1gDn96U7JJ6GkjStQ+lNfXeVh19jGXzFFDplcBg erMm/CyFLAK6d1nQkH7/1+hLYMfZpW5y6mOrCcNUJAYxTnBKV5nAe+bnEaboPcxAi1ha 86hoFDTuo6A5LYYYVmuQlp1dSUhj8OHe7VYGralfFKpYGsC+RYqYyVy8sJ48uJU0DUte RowPhyH7mzd+Rl1GB6qghohvyd5QYXSKsUfZOrappUU1O6EzX26bntG1P5CQNqeadYUY OOIw== 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=89jIuysLQPQkJXmMqbkh0Gz7Jsd4Q9zSmqAZdMmc8k4=; b=Ll6Rbnrd9BT6THTsklczsVl34uPBvcPYuqf3MaZ9a6/eN8eMuN0BUBQin6JbzAl6Nb Sk5hvVwo7qD6tF8qQ2egsonFVa5p/4SETFo7+BNs/c002YLs9z+NQLO+QBHCdHZR71L1 jIuXG6zZIRMHT1PyKPQQMIeplnmYNy0v0A6jy5ejtI+fQP+axfsqXyNfSsoy4QtVSERH OQF8q/LaFTEplnGjOz9Pf7loN86hXMFfdVliDWauLAKPOmne18S4kMpgXGMXmE/BOWfG CoaeuE5hKN84R5t4n8WgoCATst8LxpTF10mqrdVhyeAATtB04F7TRBFmlSy/oe31hAoT TLpA== X-Gm-Message-State: AHQUAubaJupFYRZJgzRc6WmxtwiztSibakk15vRI6l9tf+lQuJ8ia4C/ pGYkI3Dyg9EXlntAi5BPJ3cwZjT4jVGzdA29UmmhLA== X-Google-Smtp-Source: AHgI3IasoAX/WjUI26qZpqiRCQY9WuFQIdlBdeSL0q0HjPsIVw/yDY4EY7/qrCgQS4bdF2k6ikoDTRPpmZABTm3Ok+M= X-Received: by 2002:a24:4290:: with SMTP id i138mr6758613itb.24.1550706212732; Wed, 20 Feb 2019 15:43:32 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> In-Reply-To: <019c552eb1624d348641d6930829fd1f@boeing.com> From: Lorenzo Colitti Date: Thu, 21 Feb 2019 08:43:21 +0900 Message-ID: To: "Manfredi (US), Albert E" Cc: Gert Doering , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000f67ac305825becb7" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 20 Feb 2019 23:43:36 -0000 --000000000000f67ac305825becb7 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 21, 2019 at 7:17 AM Manfredi (US), Albert E < albert.e.manfredi@boeing.com> wrote: > Right. So, why shouldn't this NAT66 idea be taken more seriously? All of > the advantages of the basic NAT come to bear, including the renumbering > problem in enterprises, including no changes required to SLAAC timers, and > sessions easily survive a reboot of the edge router, and yet none of the > port translation kludge that made NATs useful in IPv4. > Because the advantages are for network operators have corresponding disadvantages for application developers and thus for users. Application complexity and brittleness due to NAT traversal. Battery impact of NAT keepalives. Higher-latency due to relaying and rendezvous. And so on. --000000000000f67ac305825becb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 21, 2019 at 7:17 AM Manfredi = (US), Albert E <albert.e= .manfredi@boeing.com> wrote:
Right. So, why shouldn't= this NAT66 idea be taken more seriously? All of the advantages of the basi= c NAT come to bear, including the renumbering problem in enterprises, inclu= ding no changes required to SLAAC timers, and sessions easily survive a reb= oot of the edge router, and yet none of the port translation kludge that ma= de NATs useful in IPv4.

Because the adv= antages are for network operators have corresponding disadvantages for appl= ication developers and thus for users. Application complexity and brittlene= ss due to NAT traversal. Battery impact of NAT keepalives. Higher-latency d= ue to relaying and rendezvous. And so on.
--000000000000f67ac305825becb7-- From nobody Wed Feb 20 17:06: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 3536C130F29; Wed, 20 Feb 2019 17:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx9bvTQ_jGBm; Wed, 20 Feb 2019 17:06:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CDD130F0E; Wed, 20 Feb 2019 17:06:37 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 4306581DE8; Thu, 21 Feb 2019 02:06:32 +0100 (CET) To: Jen Linkova Cc: Mikael Abrahamsson , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> Date: Wed, 20 Feb 2019 21:55:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:06:39 -0000 On 20/2/19 06:36, Jen Linkova wrote: [...] >> Example: >> >> Say you have two network interfaces: If1 and If2. >> Say If1, is configured with 2001:db8:1::/64, and If2 with 2001:db8:2::/64 >> >> Say the first default router is that associated with If1. >> >> Say prefix 2001:db8:1::/64 stops being announced, or that you stop >> receiving RAs on If1, but RAs on If2 keep arriving fine. >> >> Based on the logic of your algorithm, one would expect that a new >> connection uses 2001:db8:2::/64/If2 (since that's the "more recently >> advertised information). However, Rule #5 would override that and make >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresses on >> the outgoing interface. > > I'm even more confused now, sorry ;(( I was referring to the fact that some of the previous rules might prevent the evaluation of the rule about freshness. e.g.: * You have two network interfaces eth0 and eth1 (say each connected to a different ISP) * eth0 has stopped receiving RAs * eth1 receives RAs as usual (hence all info associated with this interface is "fresher" than than corresponding to eth0) * The default router employed by eth0 has precedence (whether because it had a higher preference value, because it was the first one that was learned, or whatever) * When you evaluate the rules in RFC6724, rule 5 will say that the outgoing interface will be eth0, and thus you should pick an address associated with it --- however, as noted above, the addresses on eth1 are fresher than those from eth1. Other cases might be if an interface has a stale ULA address one one interface, and a fresh one on another. You might end up using the stale ULA becase the rules about scope and "use addresses from the outgoing interface" take precedence over the rule about freshness. I do agree that these might be considered corner cases which might be unimportant for scenarios where we only deal with GUAs, or at least only GUAs become stale. Note (that I forgot to mention in a previous email): Many implementations limit the number of prefixes they may use for address configuration. I seem to recall that some implementations limit them to 16. If you don't do "garbage collection" for the stale addresses (remove stale addresses when there's some sort of indication that they are stale), then you might end up in a scenario where stale addresses take all the available "slots" for address configuration, and you don't have room for configuring addresses for the fresh prefixes. With the default Valid Lifetimes of 1 month, this is certainly a concern: if the prefix changes 16 times in a month, without explicit signaling to remove the stale addresses, you might be unable to configure addresses for the fresh prefixes. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 20 17:11: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 13E25126F72; Wed, 20 Feb 2019 17:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dEVrir13-SX; Wed, 20 Feb 2019 17:11:48 -0800 (PST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 44CC4130E25; Wed, 20 Feb 2019 17:11:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1L1Bk3L024011; Wed, 20 Feb 2019 20:11:46 -0500 Received: from XCH16-01-12.nos.boeing.com (xch16-01-12.nos.boeing.com [144.115.66.70]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1L1Bf8O023058 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 20 Feb 2019 20:11:41 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-12.nos.boeing.com (144.115.66.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Wed, 20 Feb 2019 17:11:40 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Wed, 20 Feb 2019 17:11:40 -0800 From: "Manfredi (US), Albert E" To: Brian E Carpenter CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUyRB17V+FnESOAEi8Djm3PcxDpKXpHwZQgACcI4D//4RNUIAAmbeA//+QzRA= Date: Thu, 21 Feb 2019 01:11:39 +0000 Message-ID: <6cc7e8ac9c7e4a898018f117aabf1a88@boeing.com> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: 59019201BDE28B5BF53EF6722E4F10EDD9343DF1102D42CE2E3D978B1C0BD20F2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:11:50 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IA0KDQo+IE5QVHY2IGlzIG5vdCBOQVQ2NiwgYXMgdGhl IE5QVHY2ICpFeHBlcmltZW50YWwqIFJGQyBleHBsYWlucy4NCg0KT2theSwgTlBUdjYuIE5vIHBv cnQgdHJhbnNsYXRpb25zLiBSRkMgNjI5Ni4NCg0KPj4gQWxsIG9mIHRoZSBhZHZhbnRhZ2VzIG9m IHRoZSBiYXNpYyBOQVQgY29tZSB0byBiZWFyLCANCj4NCj4gSSdtIG5vdCBzdXJlIHRoYXQgdGhh dCBpcyB0cnVlLCBidXQgTlBUdjYgYnJpbmdzIHNvbWUsIGJ1dCBub3QgYWxsLA0Kb2YgdGhlIGRp c2FkdmFudGFnZXMgb2YgTkFUIHRvbywgYXMgYWxzbyBleHBsYWluZWQgaW4gUkZDNjI5Ni4NCg0K RmV3IG9mIHRoZSBkaXNhZHZhbnRhZ2VzLCBJJ2Qgc2F5LiBGb3IgZXhhbXBsZSwgdXNlIG9mIElQ c2VjIEFIIGlzIGNvbXByb21pc2VkLiBCdXQgbWFueSBwZW9wbGUgb2JqZWN0ZWQgdG8gdGhlIG1h bmRhdG9yeSB1c2Ugb2YgSVBzZWMgaW4gSVB2NiBhbHJlYWR5LCBiZWNhdXNlIHRoZXJlIGFyZSBv dGhlciB3YXlzIG9mIHNlY3VyaW5nIGNvbnRlbnQgdGhhdCB0aGV5IHByZWZlciB0byBkZXBsb3ku IEkgdGhpbmsgdGhhdCB0aGUgd2lkZSBkZXBsb3ltZW50IG9mIE5BUFQgaW4gSVB2NCBoYXMgcmVk dWNlZCB0aGUgc2V2ZXJpdHkgb2YgdGhlIGRpc2FkdmFudGFnZXMgb2YgTlBULCBhcyBhcHBsaWNh dGlvbiBkZXNpZ25lcnMgaGF2ZSBsb25nIGhhZCB0byBhY2NvbW1vZGF0ZSB3b3JrYXJvdW5kcz8N Cg0KPiBOUFR2NiBhcyBhIHdvcmstYXJvdW5kIGZvciBhIGRlZmVjdCBpbiBTTEFBQyB3aGVuIHRo ZXJlIGlzIGFuDQp1bnBsYW5uZWQgcmVudW1iZXJpbmc/DQoNCkkgbWVudGlvbmVkIFNMQUFDIHRp bWVycyBhcyBhbiBleGFtcGxlLiBXaGF0IEkgc2hvdWxkIGhhdmUgc2FpZCBpcywgYXMgZmFyIGFz IEkgY2FuIHRlbGwsIGFsbCBvZiB0aGUgcHJvYmxlbXMgd2UgaGF2ZSBiZWVuIGRpc2N1c3Npbmcg aW4gdGhpcyB0aHJlYWQgd291bGQgYmUgc29sdmVkIHdpdGggTlBUdjYuIFByaXZhY3kgaW4gaG9t ZSBuZXRzLCByZW51bWJlcmluZywgcm91dGUgYWdncmVnYXRpb24sIFNMQUFDLCB3aGF0IGVsc2U/ IEkgY2FuJ3QgdGhpbmsgb2YgYW4gaXNzdWUgbWVudGlvbmVkIGhlcmUgdGhhdCBOUFR2NiB3b3Vs ZG7igJl0IHNvbHZlLg0KDQpJdCBzaG91bGQgbm90IGJlIGFsbCB0aGF0IHN1cnByaXNpbmcgdGhh dCB0aGUgYWR2YW50YWdlcyBvZiBhZGRyZXNzIGluZGVwZW5kZW5jZSBoYXZlIGJlY29tZSBlbnRy ZW5jaGVkIGluIElQIHRoaW5raW5nLCB0aGFua3MgdG8gSVB2NC4gU28gaXQgc2hvdWxkIG5vdCBi ZSBzdXJwcmlzaW5nIGlmIG1hbnkgaGF2ZSBjb21lIHRvIGRlcGVuZCBvbiB0aGVzZSBhZHZhbnRh Z2VzLCBhbmQgZG9u4oCZdCB3YW50IHRvIGdpdmUgdGhlbSB1cC4NCg0KQmVydA0KDQo= From nobody Wed Feb 20 17:12: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 9330F130FCD for ; Wed, 20 Feb 2019 17:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 828cKvD44OOt for ; Wed, 20 Feb 2019 17:12:16 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9921130FB2 for ; Wed, 20 Feb 2019 17:12:15 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id v10so98364iop.4 for ; Wed, 20 Feb 2019 17:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=p8CnfzeiY0T/0xXOFamyrpVAl9hPS+c3FTdjjJ2vXDE=; b=HEemp2ILpjZdCBgH0WIvZKzCk/AkxxD7Vx0w0+EOL74Ne8pMdfS6qNg/UTcfVZwej8 wCi5BXZpcGix9K9ru4Guy0yHN1BO2rjzPp4l6V5AMS8S3+/+X8BZRXHaOCYxwjN2f7t5 vqUE8/y1T75i0COxrPwkYGuYx8AHFTOjpEaKk= 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:reply-to :from:date:message-id:subject:to:cc; bh=p8CnfzeiY0T/0xXOFamyrpVAl9hPS+c3FTdjjJ2vXDE=; b=RYWb0cfd/Kfq4jsB5DvN6/q96SyBlUCNDbogivo8Eq9+nA6G0fBBqiQzRzlLRZb3y8 OZ5SfJ/sEcnq4YkdEjqSwmF1D9b1C0reUfraolSB/gXqEQZgrBgC/iqceozE0RBUqFZD PGzdWfLjIOnoDSHxcu9LoF8oQ4kXGyHZMh962vGugqazk6NFT5Pf8MsYBVJuU7NTsHi3 4L4TtjZI+4r163wpHtYpWe+82SMqhIfaKSzpWJH5wkhRKy/jf0MkCYsTM/W2LFEt9s40 bH/gV7UDf0RM1HjWQiZcirWQyGzfQ2qvxp38otWo1N1Tk1lgp5XwVkoqZAPT9rz4MfMr 9eEQ== X-Gm-Message-State: AHQUAuYZ6Cf+bf55bBIso7ahNFpRp4kw0U+UFd9oPx4OYhhnAgl2dxcC wz8jJ+jy+zaLo0P3xXCuDzbTNsl9/u2a44unmGBA+w== X-Google-Smtp-Source: AHgI3IZ5arPg2Gv9ULz8yMpBiZgbJnWwQhGKcYAALwDTVb3reaprDeLmgL3enrtLTR55k3y/mj6FDuOKz3CAtGADHH0= X-Received: by 2002:a6b:5913:: with SMTP id n19mr23543202iob.62.1550711534277; Wed, 20 Feb 2019 17:12:14 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> In-Reply-To: <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> Reply-To: ek@loon.co From: Erik Kline Date: Wed, 20 Feb 2019 17:12:01 -0800 Message-ID: To: Fernando Gont Cc: Jen Linkova , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000026c34705825d2a79" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:12:23 -0000 --00000000000026c34705825d2a79 Content-Type: text/plain; charset="UTF-8" On Wed, 20 Feb 2019 at 17:07, Fernando Gont wrote: > On 20/2/19 06:36, Jen Linkova wrote: > [...] > >> Example: > >> > >> Say you have two network interfaces: If1 and If2. > >> Say If1, is configured with 2001:db8:1::/64, and If2 with > 2001:db8:2::/64 > >> > >> Say the first default router is that associated with If1. > >> > >> Say prefix 2001:db8:1::/64 stops being announced, or that you stop > >> receiving RAs on If1, but RAs on If2 keep arriving fine. > >> > >> Based on the logic of your algorithm, one would expect that a new > >> connection uses 2001:db8:2::/64/If2 (since that's the "more recently > >> advertised information). However, Rule #5 would override that and make > >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresses on > >> the outgoing interface. > > > > I'm even more confused now, sorry ;(( > > I was referring to the fact that some of the previous rules might > prevent the evaluation of the rule about freshness. e.g.: > > * You have two network interfaces eth0 and eth1 (say each connected to a > different ISP) > * eth0 has stopped receiving RAs > * eth1 receives RAs as usual (hence all info associated with this > interface is "fresher" than than corresponding to eth0) > * The default router employed by eth0 has precedence (whether because it > had a higher preference value, because it was the first one that was > learned, or whatever) > * When you evaluate the rules in RFC6724, rule 5 will say that the > outgoing interface will be eth0, and thus you should pick an address > associated with it --- however, as noted above, the addresses on eth1 > are fresher than those from eth1. > Not receiving multicast RAs is not a condition you can really take any action on. PIO/RIO/default route/... timers expiring? Of course. ND is_router goes from 1 to 0? Absolutely. NUD says the router is gone? Most definitely. Some kind of repeatedly beating on the router with unicast RSes... maybe... Other cases might be if an interface has a stale ULA address one one > interface, and a fresh one on another. You might end up using the stale > ULA becase the rules about scope and "use addresses from the outgoing > interface" take precedence over the rule about freshness. > > I do agree that these might be considered corner cases which might be > unimportant for scenarios where we only deal with GUAs, or at least only > GUAs become stale. > > > Note (that I forgot to mention in a previous email): Many > implementations limit the number of prefixes they may use for address > configuration. I seem to recall that some implementations limit them to > 16. If you don't do "garbage collection" for the stale addresses (remove > stale addresses when there's some sort of indication that they are > stale), then you might end up in a scenario where stale addresses take > all the available "slots" for address configuration, and you don't have > room for configuring addresses for the fresh prefixes. With the default > Valid Lifetimes of 1 month, this is certainly a concern: if the prefix > changes 16 times in a month, without explicit signaling to remove the > stale addresses, you might be unable to configure addresses for the > fresh prefixes. > > 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 > --00000000000026c34705825d2a79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 20 Feb 2019 at 17:07, Fernand= o Gont <fgont@si6networks.com> wrote:
On= 20/2/19 06:36, Jen Linkova wrote:
[...]
>> Example:
>>
>> Say you have two network interfaces: If1 and If2.
>> Say If1, is configured with 2001:db8:1::/64, and If2 with 2001:db8= :2::/64
>>
>> Say the first default router is that associated with If1.
>>
>> Say prefix 2001:db8:1::/64 stops being announced, or that you stop=
>> receiving RAs on If1, but RAs on If2 keep arriving fine.
>>
>> Based on the logic of your algorithm, one would expect that a new<= br> >> connection uses 2001:db8:2::/64/If2 (since that's the "mo= re recently
>> advertised information). However, Rule #5 would override that and = make
>> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresse= s on
>> the outgoing interface.
>
> I'm even more confused now, sorry ;((

I was referring to the fact that some of the previous rules might
prevent the evaluation of the rule about freshness. e.g.:

* You have two network interfaces eth0 and eth1 (say each connected to a different ISP)
* eth0 has stopped receiving RAs
* eth1 receives RAs as usual (hence all info associated with this
=C2=A0 interface is "fresher" than than corresponding to eth0) * The default router employed by eth0 has precedence (whether because it =C2=A0 had a higher preference value, because it was the first one that was=
=C2=A0 learned, or whatever)
* When you evaluate the rules in RFC6724, rule 5 will say that the
=C2=A0 outgoing interface will be eth0, and thus you should pick an address=
=C2=A0 associated with it --- however, as noted above, the addresses on eth= 1
=C2=A0 are fresher than those from eth1.

Not receiving multicast RAs is not a condition you can really take any ac= tion on.





Other cases might be if an interface has a stale ULA address one one
interface, and a fresh one on another. You might end up using the stale
ULA becase the rules about scope and "use addresses from the outgoing<= br> interface" take precedence over the rule about freshness.

I do agree that these might be considered corner cases which might be
unimportant for scenarios where we only deal with GUAs, or at least only GUAs become stale.


Note (that I forgot to mention in a previous email): Many
implementations limit the number of prefixes they may use for address
configuration. I seem to recall that some implementations limit them to
16. If you don't do "garbage collection" for the stale addres= ses (remove
stale addresses when there's some sort of indication that they are
stale), then you might end up in a scenario where stale addresses take
all the available "slots" for address configuration, and you don&= #39;t have
room for configuring addresses for the fresh prefixes. With the default
Valid Lifetimes of 1 month, this is certainly a concern: if the prefix
changes 16 times in a month, without explicit signaling to remove the
stale addresses, you might be unable to configure addresses for the
fresh prefixes.

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




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000026c34705825d2a79-- From nobody Wed Feb 20 17:17: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 4F5AE130F0E for ; Wed, 20 Feb 2019 17:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx8CxxDgsxeZ for ; Wed, 20 Feb 2019 17:17:40 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CC9130E25 for ; Wed, 20 Feb 2019 17:17:40 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id x3so107474ior.6 for ; Wed, 20 Feb 2019 17:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=+Jz4elpDt78QYPTgTHydZ44Z6BarODUJeWMt/jYfgb0=; b=CFJkShv7C8GqVP8eDaFEJ5jHnTFLeN5+PjN7Gexz45tyFFhy5AFnnYa6hcpGG+t8Jq 6l1ZfZMAs5ps5bVYpB65BvqbwFaHIpz9LVeu4k94Nql//RIYVk1MZDGkH+CD77ElqZmI rOlHTFHGnePTK+UB7U41XLQAmNdTfY3P3QnFk= 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:reply-to :from:date:message-id:subject:to:cc; bh=+Jz4elpDt78QYPTgTHydZ44Z6BarODUJeWMt/jYfgb0=; b=qWF43xC6aWkVZbImBsYUkrGebgMBr2KFZtHYodn/JSvGWnMZpmlqQqjkZrkg2zFIRn U1dZzDeCe2g0J3+QHJ0O9kkIvHWf/R7oWJHqT0qoMo5+Q9/sAm8sQSot/wsGFS/hWSoN mJ/3AFXNsM+0WLAYK8DLqQ7dN0gMwtUOK+Qeq0dVMuB7kRXTUVKDwigzBW9FEZyyuJiT VWXsNtwB2z1bKEpv102XUtm/kiiAwoVNPViu8f8HifzmiJoA0Z5lIKX4pRPyYAdtgCSm khKhTmHkOo6qTJdXHWwP1WvN2AVwx97mo5tOr5F7yrNflvrkuLQS6+lD4eQNtrAXzyv6 oCyw== X-Gm-Message-State: AHQUAuZ6gQ7iQpl3stIAp8MBsAbRKUynMId3h9gccFbWK9aCPVZB6g6/ MMhmD+o6jj88XYxrYBpOOcbXRsW7Mpq9YC3b9uPyEw== X-Google-Smtp-Source: AHgI3IZ/ID1Pg1HEv7Rai16qQjFkNMUM3p2j77xu4xlzhAmmiE3qmvyq9PJgRWOQ9TdJC/Pj1yca/fP6W7JOIrSDVYY= X-Received: by 2002:a6b:5913:: with SMTP id n19mr23554618iob.62.1550711858754; Wed, 20 Feb 2019 17:17:38 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <6cc7e8ac9c7e4a898018f117aabf1a88@boeing.com> In-Reply-To: <6cc7e8ac9c7e4a898018f117aabf1a88@boeing.com> Reply-To: ek@loon.co From: Erik Kline Date: Wed, 20 Feb 2019 17:17:27 -0800 Message-ID: To: "Manfredi (US), Albert E" Cc: Brian E Carpenter , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000007de09405825d3d0e" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:17:42 -0000 --0000000000007de09405825d3d0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 20 Feb 2019 at 17:12, Manfredi (US), Albert E < albert.e.manfredi@boeing.com> wrote: > -----Original Message----- > From: Brian E Carpenter > > > NPTv6 is not NAT66, as the NPTv6 *Experimental* RFC explains. > > Okay, NPTv6. No port translations. RFC 6296. > > >> All of the advantages of the basic NAT come to bear, > > > > I'm not sure that that is true, but NPTv6 brings some, but not all, > of the disadvantages of NAT too, as also explained in RFC6296. > > Few of the disadvantages, I'd say. For example, use of IPsec AH is > compromised. But many people objected to the mandatory use of IPsec in IP= v6 > already, because there are other ways of securing content that they prefe= r > to deploy. I think that the wide deployment of NAPT in IPv4 has reduced t= he > severity of the disadvantages of NPT, as application designers have long > had to accommodate workarounds? > > > NPTv6 as a work-around for a defect in SLAAC when there is an > unplanned renumbering? > > I mentioned SLAAC timers as an example. What I should have said is, as fa= r > as I can tell, all of the problems we have been discussing in this thread > would be solved with NPTv6. Privacy in home nets, renumbering, route > aggregation, SLAAC, what else? I can't think of an issue mentioned here > that NPTv6 wouldn=E2=80=99t solve. > > It should not be all that surprising that the advantages of address > independence have become entrenched in IP thinking, thanks to IPv4. So it > should not be surprising if many have come to depend on these advantages, > and don=E2=80=99t want to give them up. > As Lorenzo said, it "solves" some operational pain by pushing that pain onto those that are not represented in the decision making process to deploy any variety of NAT (i.e. apps, OSes, ...) We've been here before , of course. --0000000000007de09405825d3d0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 20 Feb 2019 at 17:12, Manfred= i (US), Albert E <albert= .e.manfredi@boeing.com> wrote:
-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com>

> NPTv6 is not NAT66, as the NPTv6 *Experimental* RFC explains.

Okay, NPTv6. No port translations. RFC 6296.

>> All of the advantages of the basic NAT come to bear,
>
> I'm not sure that that is true, but NPTv6 brings some, but not all= ,
of the disadvantages of NAT too, as also explained in RFC6296.

Few of the disadvantages, I'd say. For example, use of IPsec AH is comp= romised. But many people objected to the mandatory use of IPsec in IPv6 alr= eady, because there are other ways of securing content that they prefer to = deploy. I think that the wide deployment of NAPT in IPv4 has reduced the se= verity of the disadvantages of NPT, as application designers have long had = to accommodate workarounds?

> NPTv6 as a work-around for a defect in SLAAC when there is an
unplanned renumbering?

I mentioned SLAAC timers as an example. What I should have said is, as far = as I can tell, all of the problems we have been discussing in this thread w= ould be solved with NPTv6. Privacy in home nets, renumbering, route aggrega= tion, SLAAC, what else? I can't think of an issue mentioned here that N= PTv6 wouldn=E2=80=99t solve.

It should not be all that surprising that the advantages of address indepen= dence have become entrenched in IP thinking, thanks to IPv4. So it should n= ot be surprising if many have come to depend on these advantages, and don= =E2=80=99t want to give them up.

As Lor= enzo said, it "solves" some operational pain by pushing that pain= onto those that are not represented in the decision making process to depl= oy any variety of NAT (i.e. apps, OSes, ...)

We= 9;ve been here bef= ore, of course.
--0000000000007de09405825d3d0e-- From nobody Wed Feb 20 17:35: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 146A5130F30; Wed, 20 Feb 2019 17:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eLgAEgswDtD; Wed, 20 Feb 2019 17:35:00 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509CD130F3E; Wed, 20 Feb 2019 17:35:00 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 AE68D84920; Thu, 21 Feb 2019 02:34:55 +0100 (CET) To: Lorenzo Colitti , "Manfredi (US), Albert E" Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 20 Feb 2019 22:13:28 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:35:02 -0000 On 20/2/19 20:43, Lorenzo Colitti wrote: > On Thu, Feb 21, 2019 at 7:17 AM Manfredi (US), Albert E > > wrote: > > Right. So, why shouldn't this NAT66 idea be taken more seriously? > All of the advantages of the basic NAT come to bear, including the > renumbering problem in enterprises, including no changes required to > SLAAC timers, and sessions easily survive a reboot of the edge > router, and yet none of the port translation kludge that made NATs > useful in IPv4. > > > Because the advantages are for network operators have corresponding > disadvantages for application developers and thus for users. Application > complexity and brittleness due to NAT traversal. Battery impact of NAT > keepalives. Higher-latency due to relaying and rendezvous. And so on. Given that RFC6092 recommends "only allow outgoing connections", and that many IPv6 CPEs fail to implement UPnP for IPv6, I'm wondering that what extent what you mention is actually true. (yes, we'd wish that was the case... unfortunately, in many cases it isn't) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 20 17:49: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 95DCA130F63; Wed, 20 Feb 2019 17:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp8S_726Uc56; Wed, 20 Feb 2019 17:49:01 -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 8988F130F56; Wed, 20 Feb 2019 17:49:01 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 B4871837F0; Thu, 21 Feb 2019 02:48:52 +0100 (CET) To: j h woodyatt , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <9D7D5944-FCC1-4237-B530-7C1DB1B61A56@conjury.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 20 Feb 2019 22:40:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <9D7D5944-FCC1-4237-B530-7C1DB1B61A56@conjury.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:49:04 -0000 Hi, James, Thanks for thre great feedback! Comments in-line... On 20/2/19 14:09, j h woodyatt wrote: > On Jan 31, 2019, at 03:00, Fernando Gont > wrote: >> >> https://tools.ietf.org/html/draft-gont-6man-slaac-renum > > For the record, I agree with the authors that reducing the default > values for AdvPreferredLifetime and AdvValidLifetime is an idea with > merit. > > The other changes seem less obviously good, as they resemble previous > unsuccessful attempts to hammer the DHCPv6 and Router Discovery > protocols into resembling a proper routing protocol, which they are > not, and which I think we should admit they never will be. Having > experienced the futility in attempting to improve Router Discovery > and/or DHCPv6 to resemble a proper routing protocol, I would say I’ve > seen better and more elegant solutions to these problems, which > unfortunately all depend on host operating systems adopting the model > that hosts sometimes have cause to participate in the network routing > protocol. As this idea has never been taken seriously by the > community, I think it’s probably best to leave it behind. Note: 5.1.3 allows for more timely recovery from the aforementioned problem. (otherwise you'd have to wait longer, or reduce timers more agressively) 5.1.2, 5.2, and 5.3 aims at network devices behaving nicely, possibly allowing for timely recovery of hosts that don't implement 5.1.3. > > Shorter james: keep section 5.1.1 and drop sections 5.1.2, 5.1.3, 5.2 > and 5.3. Seems folks wanted these bits about "how devices should play nice"... 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 Wed Feb 20 17:49: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 190ED130F94; Wed, 20 Feb 2019 17:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTCmXgmGKVbs; Wed, 20 Feb 2019 17:49:06 -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 94F25130F67; Wed, 20 Feb 2019 17:49:05 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 73DF88491D; Thu, 21 Feb 2019 02:48:57 +0100 (CET) To: ek@loon.co Cc: Jen Linkova , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 20 Feb 2019 22:44:12 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 01:49:12 -0000 Hi, Eric, On 20/2/19 22:12, Erik Kline wrote: > > > On Wed, 20 Feb 2019 at 17:07, Fernando Gont > wrote: > > On 20/2/19 06:36, Jen Linkova wrote: > [...] > >> Example: > >> > >> Say you have two network interfaces: If1 and If2. > >> Say If1, is configured with 2001:db8:1::/64, and If2 with > 2001:db8:2::/64 > >> > >> Say the first default router is that associated with If1. > >> > >> Say prefix 2001:db8:1::/64 stops being announced, or that you stop > >> receiving RAs on If1, but RAs on If2 keep arriving fine. > >> > >> Based on the logic of your algorithm, one would expect that a new > >> connection uses 2001:db8:2::/64/If2 (since that's the "more recently > >> advertised information). However, Rule #5 would override that and > make > >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes > addresses on > >> the outgoing interface. > > > > I'm even more confused now, sorry ;(( > > I was referring to the fact that some of the previous rules might > prevent the evaluation of the rule about freshness. e.g.: > > * You have two network interfaces eth0 and eth1 (say each connected to a > different ISP) > * eth0 has stopped receiving RAs > * eth1 receives RAs as usual (hence all info associated with this >   interface is "fresher" than than corresponding to eth0) > * The default router employed by eth0 has precedence (whether because it >   had a higher preference value, because it was the first one that was >   learned, or whatever) > * When you evaluate the rules in RFC6724, rule 5 will say that the >   outgoing interface will be eth0, and thus you should pick an address >   associated with it --- however, as noted above, the addresses on eth1 >   are fresher than those from eth1. > > > Not receiving multicast RAs is not a condition you can really take any > action on. Agreed. The main issue I see with incorporating an explicit rule in RFC6724 about "freshness" is that in multi-prefix scenarios, it's guaranteed that the default SA will oscillate among the different prefixes, and that if you only implement this workaround, you wouldn't be able to communicate with hosts actively employing your stale prefix. 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 Wed Feb 20 18:01:44 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 73677130F81 for ; Wed, 20 Feb 2019 18:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln0cDAWZT-i5 for ; Wed, 20 Feb 2019 18:01:29 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB07130F83 for ; Wed, 20 Feb 2019 18:01:29 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id e186so172162ioa.0 for ; Wed, 20 Feb 2019 18:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=gAMmTjMOUMUxu/yIrwTW2jgDgZbPHjFszwxR7/EaLK4=; b=UunVIL2wqexpImzkRd6nKbAczK1eNbVgmW5PmOdq8O5TV2B44Umzxij0wL7F8tWPIP RLphhQtuN5ui6rwcx7GtCZp0pLUG3aNcx2KWu6+NWN1JqvehOtTb6Djl8pChRN4MKpf/ rjPpzKRJjEdtORpPl+i5xV8rpcnWBziWSYTBA= 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:reply-to :from:date:message-id:subject:to:cc; bh=gAMmTjMOUMUxu/yIrwTW2jgDgZbPHjFszwxR7/EaLK4=; b=ryT4wPixQwP1t7yHqg8gIQsRQ0FvbgOzCSUKZM2wZobw0RHFNo9lywxgRoxmxHHcK8 ofkTF5/GtVL6yyu9fKl0WEMoGg5k7uu9dK5mBCEVWnn1iEtTCx4ys1j1LosGJ+ml+NRU nofA8yOOjJtezBtep+G0DbN0XIrc8GLRWe2SIt9FjmIU2c/HWDMbxGynTmEdxT/+Vuru 1s3TZGDNZu4jIGe82PsOWa6HHypjc/AnLstiCYSt2rZcgLASRS55+Jj3W4RUB/4uPijZ 8/fCvxXBOsdSM2l7/0JsZOu729l0KlBBSZcIdrff9ZdrRV9u6DCd0j4uqS88SdjKy6vO qZqA== X-Gm-Message-State: AHQUAuaFQGtvOeJYoztRgi7potEC7bDDyGqyoOjODNQoR49AA4JpCx7j Zk0Pg2jYiZ1VU0Q+NHisneHSmo26YK6gM3vMJd3sUQ== X-Google-Smtp-Source: AHgI3IYCB2yRaoNz+3KkIY9dbFLWyN7qZgocHU08uBUjUx1zF+G+VQKlt9mCLTJ7iQlQSEl7T8wRLvWXBITe5jOkbBs= X-Received: by 2002:a5d:824e:: with SMTP id n14mr21346225ioo.16.1550714487750; Wed, 20 Feb 2019 18:01:27 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> In-Reply-To: Reply-To: ek@loon.co From: Erik Kline Date: Wed, 20 Feb 2019 18:01:14 -0800 Message-ID: To: Fernando Gont Cc: Jen Linkova , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000312c5305825dda0f" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 02:01:32 -0000 --000000000000312c5305825dda0f Content-Type: text/plain; charset="UTF-8" On Wed, 20 Feb 2019 at 17:49, Fernando Gont wrote: > Hi, Eric, > > On 20/2/19 22:12, Erik Kline wrote: > > > > > > On Wed, 20 Feb 2019 at 17:07, Fernando Gont > > wrote: > > > > On 20/2/19 06:36, Jen Linkova wrote: > > [...] > > >> Example: > > >> > > >> Say you have two network interfaces: If1 and If2. > > >> Say If1, is configured with 2001:db8:1::/64, and If2 with > > 2001:db8:2::/64 > > >> > > >> Say the first default router is that associated with If1. > > >> > > >> Say prefix 2001:db8:1::/64 stops being announced, or that you stop > > >> receiving RAs on If1, but RAs on If2 keep arriving fine. > > >> > > >> Based on the logic of your algorithm, one would expect that a new > > >> connection uses 2001:db8:2::/64/If2 (since that's the "more > recently > > >> advertised information). However, Rule #5 would override that and > > make > > >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes > > addresses on > > >> the outgoing interface. > > > > > > I'm even more confused now, sorry ;(( > > > > I was referring to the fact that some of the previous rules might > > prevent the evaluation of the rule about freshness. e.g.: > > > > * You have two network interfaces eth0 and eth1 (say each connected > to a > > different ISP) > > * eth0 has stopped receiving RAs > > * eth1 receives RAs as usual (hence all info associated with this > > interface is "fresher" than than corresponding to eth0) > > * The default router employed by eth0 has precedence (whether > because it > > had a higher preference value, because it was the first one that > was > > learned, or whatever) > > * When you evaluate the rules in RFC6724, rule 5 will say that the > > outgoing interface will be eth0, and thus you should pick an > address > > associated with it --- however, as noted above, the addresses on > eth1 > > are fresher than those from eth1. > > > > > > Not receiving multicast RAs is not a condition you can really take any > > action on. > > Agreed. > > The main issue I see with incorporating an explicit rule in RFC6724 > about "freshness" is that in multi-prefix scenarios, it's guaranteed > that the default SA will oscillate among the different prefixes, and > that if you only implement this workaround, you wouldn't be able to > communicate with hosts actively employing your stale prefix. > that's where rule 5.5 would help (wherever it is actually implemented; alas...) --000000000000312c5305825dda0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 20 Feb 2019 at 17:49, Fernand= o Gont <fgont@si6networks.com> wrote:
Hi= , Eric,

On 20/2/19 22:12, Erik Kline wrote:
>
>
> On Wed, 20 Feb 2019 at 17:07, Fernando Gont <fgont@si6networks.com
> <mailto:= fgont@si6networks.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 20/2/19 06:36, Jen Linkova wrote:
>=C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0>> Example:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Say you have two network interfaces: If1 a= nd If2.
>=C2=A0 =C2=A0 =C2=A0>> Say If1, is configured with 2001:db8:1::/6= 4, and If2 with
>=C2=A0 =C2=A0 =C2=A02001:db8:2::/64
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Say the first default router is that assoc= iated with If1.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Say prefix 2001:db8:1::/64 stops being ann= ounced, or that you stop
>=C2=A0 =C2=A0 =C2=A0>> receiving RAs on If1, but RAs on If2 keep = arriving fine.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Based on the logic of your algorithm, one = would expect that a new
>=C2=A0 =C2=A0 =C2=A0>> connection uses 2001:db8:2::/64/If2 (since= that's the "more recently
>=C2=A0 =C2=A0 =C2=A0>> advertised information). However, Rule #5 = would override that and
>=C2=A0 =C2=A0 =C2=A0make
>=C2=A0 =C2=A0 =C2=A0>> you employ 2001:db8:1::/64/If1, since Rule= #5 prioritizes
>=C2=A0 =C2=A0 =C2=A0addresses on
>=C2=A0 =C2=A0 =C2=A0>> the outgoing interface.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I'm even more confused now, sorry ;((
>
>=C2=A0 =C2=A0 =C2=A0I was referring to the fact that some of the previo= us rules might
>=C2=A0 =C2=A0 =C2=A0prevent the evaluation of the rule about freshness.= e.g.:
>
>=C2=A0 =C2=A0 =C2=A0* You have two network interfaces eth0 and eth1 (sa= y each connected to a
>=C2=A0 =C2=A0 =C2=A0different ISP)
>=C2=A0 =C2=A0 =C2=A0* eth0 has stopped receiving RAs
>=C2=A0 =C2=A0 =C2=A0* eth1 receives RAs as usual (hence all info associ= ated with this
>=C2=A0 =C2=A0 =C2=A0=C2=A0 interface is "fresher" than than c= orresponding to eth0)
>=C2=A0 =C2=A0 =C2=A0* The default router employed by eth0 has precedenc= e (whether because it
>=C2=A0 =C2=A0 =C2=A0=C2=A0 had a higher preference value, because it wa= s the first one that was
>=C2=A0 =C2=A0 =C2=A0=C2=A0 learned, or whatever)
>=C2=A0 =C2=A0 =C2=A0* When you evaluate the rules in RFC6724, rule 5 wi= ll say that the
>=C2=A0 =C2=A0 =C2=A0=C2=A0 outgoing interface will be eth0, and thus yo= u should pick an address
>=C2=A0 =C2=A0 =C2=A0=C2=A0 associated with it --- however, as noted abo= ve, the addresses on eth1
>=C2=A0 =C2=A0 =C2=A0=C2=A0 are fresher than those from eth1.
>
>
> Not receiving multicast RAs is not a condition you can really take any=
> action on.

Agreed.

The main issue I see with incorporating an explicit rule in RFC6724
about "freshness" is that in multi-prefix scenarios, it's gua= ranteed
that the default SA will oscillate among the different prefixes, and
that if you only implement this workaround, you wouldn't be able to
communicate with hosts actively employing your stale prefix.

that's where rule 5.5 would help (wherever it is = actually implemented; alas...)
--000000000000312c5305825dda0f-- From nobody Wed Feb 20 18:22:29 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 25D60130F5C; Wed, 20 Feb 2019 18:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQsrLXwG9s4x; Wed, 20 Feb 2019 18:22:15 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE511275F3; Wed, 20 Feb 2019 18:22:14 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id y5so7743483plk.8; Wed, 20 Feb 2019 18:22:14 -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=HR4Xc8XKIc5bWprP6Nxp0cR90BR/Oi5/Qf9+jWhM8fM=; b=gSuaLkE4wja9cnMKNGE6ZQaZVKrASYXsdel0Jx2R1T64kfIOf3xl2UdtHCZN3FJOaM ZoaIrfth5p8dIYMitWwmT9gvsksMqesf7QBqoj0MKDkL+xR4UHm9TRfPmFuZCskq6P/3 oWTeXuhXDlsrV3L+lUMVlPx3OcW4jdfbXpZv7Fuxlo5Cuw35LfZ4aFtP8ZZz8mpX2+XQ DZTQ5UeVOR1SbJa3tPQUQOOMdEv3o92mz7tkF1i4EL4ab/1eY6wkiT9/sOv00QG0eEgy N6iE9QG6Z5OPPOYT+lEx43uXyHE/flBN70muYG4E+QbslLUUcdMl8z89TQ6UAtW1aZyu tfTg== 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=HR4Xc8XKIc5bWprP6Nxp0cR90BR/Oi5/Qf9+jWhM8fM=; b=ot4dQhmGE3YYThVCTB/rf0bhTFeTPhK2vRafjUn89CdaLRKV5s4Xjw44h5v3Memhxy 50f+nm+hnIMa/Gzxy0rXq4aVVPkoYhz2WfTvUVD+qNgF4lzrM5HDyeWqcEtkNkYKse3x lvwHhvg7/D6rhf9KtGG/Hblnot/pwbfgSw7/MgxwxJ/hdxXhJRL8oW//U8T8yP6+hZKy JOIZNNvMcPXy6oIZboY4zTMdY3StpGngHKeTCe1uGHKibOhGHjXdqzcKYUXQ0gtNIfZQ 4ktcOnUQKbtD0XcBHU9MEf5XJyT1yeNI5ZMz/IqJxswvzm3XUpPStDVwDk5V4lAj30tE Gu9Q== X-Gm-Message-State: AHQUAubyi3h3qS8c4P6dzsQqSoX/5MC+Gc860G75oT8t2XPj5DJ9kVW2 2z5y5+b54A2Ev3WzL4ucwSIvaYCl X-Google-Smtp-Source: AHgI3IbuaNNiEHdWa5kvRE1h+S5KcsZ1uStVO7bb0V5Mp3bd7/JfYcvwbbeMK7vLhg11PJBG0p27IQ== X-Received: by 2002:a17:902:584:: with SMTP id f4mr41016879plf.28.1550715733789; Wed, 20 Feb 2019 18:22:13 -0800 (PST) Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id y6sm33311964pfd.104.2019.02.20.18.22.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 18:22:12 -0800 (PST) To: ek@loon.co, Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> From: Brian E Carpenter Message-ID: <26df53ce-e6d5-9dcb-a7d0-9ceb133f003c@gmail.com> Date: Thu, 21 Feb 2019 15:22:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.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] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 02:22:17 -0000 On 2019-02-21 15:01, Erik Kline wrote: >=20 >=20 > On Wed, 20 Feb 2019 at 17:49, Fernando Gont > wrote: >=20 > Hi, Eric, >=20 > On 20/2/19 22:12, Erik Kline wrote: > > > > > > On Wed, 20 Feb 2019 at 17:07, Fernando Gont > > >> wr= ote: > > > >=C2=A0 =C2=A0 =C2=A0On 20/2/19 06:36, Jen Linkova wrote: > >=C2=A0 =C2=A0 =C2=A0[...] > >=C2=A0 =C2=A0 =C2=A0>> Example: > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>> Say you have two network interfaces: If1 an= d If2. > >=C2=A0 =C2=A0 =C2=A0>> Say If1, is configured with 2001:db8:1::/64= , and If2 with > >=C2=A0 =C2=A0 =C2=A02001:db8:2::/64 > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>> Say the first default router is that associ= ated with If1. > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>> Say prefix 2001:db8:1::/64 stops being anno= unced, or that you stop > >=C2=A0 =C2=A0 =C2=A0>> receiving RAs on If1, but RAs on If2 keep a= rriving fine. > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>> Based on the logic of your algorithm, one w= ould expect that a new > >=C2=A0 =C2=A0 =C2=A0>> connection uses 2001:db8:2::/64/If2 (since = that's the "more recently > >=C2=A0 =C2=A0 =C2=A0>> advertised information). However, Rule #5 w= ould override that and > >=C2=A0 =C2=A0 =C2=A0make > >=C2=A0 =C2=A0 =C2=A0>> you employ 2001:db8:1::/64/If1, since Rule = #5 prioritizes > >=C2=A0 =C2=A0 =C2=A0addresses on > >=C2=A0 =C2=A0 =C2=A0>> the outgoing interface. > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> I'm even more confused now, sorry ;(( > > > >=C2=A0 =C2=A0 =C2=A0I was referring to the fact that some of the p= revious rules might > >=C2=A0 =C2=A0 =C2=A0prevent the evaluation of the rule about fresh= ness. e.g.: > > > >=C2=A0 =C2=A0 =C2=A0* You have two network interfaces eth0 and eth= 1 (say each connected to a > >=C2=A0 =C2=A0 =C2=A0different ISP) > >=C2=A0 =C2=A0 =C2=A0* eth0 has stopped receiving RAs > >=C2=A0 =C2=A0 =C2=A0* eth1 receives RAs as usual (hence all info a= ssociated with this > >=C2=A0 =C2=A0 =C2=A0=C2=A0 interface is "fresher" than than corres= ponding to eth0) > >=C2=A0 =C2=A0 =C2=A0* The default router employed by eth0 has prec= edence (whether because it > >=C2=A0 =C2=A0 =C2=A0=C2=A0 had a higher preference value, because = it was the first one that was > >=C2=A0 =C2=A0 =C2=A0=C2=A0 learned, or whatever) > >=C2=A0 =C2=A0 =C2=A0* When you evaluate the rules in RFC6724, rule= 5 will say that the > >=C2=A0 =C2=A0 =C2=A0=C2=A0 outgoing interface will be eth0, and th= us you should pick an address > >=C2=A0 =C2=A0 =C2=A0=C2=A0 associated with it --- however, as note= d above, the addresses on eth1 > >=C2=A0 =C2=A0 =C2=A0=C2=A0 are fresher than those from eth1. > > > > > > Not receiving multicast RAs is not a condition you can really tak= e any > > action on. >=20 > Agreed. >=20 > The main issue I see with incorporating an explicit rule in RFC6724= > about "freshness" is that in multi-prefix scenarios, it's guarantee= d > that the default SA will oscillate among the different prefixes, an= d > that if you only implement this workaround, you wouldn't be able to= > communicate with hosts actively employing your stale prefix. >=20 >=20 > that's where rule 5.5 would help (wherever it is actually implemented; = alas...) That's also why we made rule 5.5 a SHOULD in RFC 8028. Brian From nobody Wed Feb 20 18:28: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 70BC9130F81; Wed, 20 Feb 2019 18:28:31 -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, HTML_MESSAGE=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 b7Wu1e88nWUc; Wed, 20 Feb 2019 18:28:29 -0800 (PST) Received: from mail.conjury.org (prime.conjury.org [174.136.98.234]) by ietfa.amsl.com (Postfix) with ESMTP id 713C1130F5C; Wed, 20 Feb 2019 18:28:29 -0800 (PST) Received: from [IPv6:2607:f598:b0b2:cf00:d4fb:b027:be5d:c37d] (unknown [IPv6:2607:f598:b0b2:cf00:d4fb:b027:be5d:c37d]) by mail.conjury.org (Postfix) with ESMTPSA id BC5B7E6011; Wed, 20 Feb 2019 17:51:15 -0800 (PST) From: j h woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_433CA7B3-AB2C-47C5-AFCB-E81469EDFE57" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Feb 2019 18:28:27 -0800 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> To: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations In-Reply-To: Message-Id: <2EEFFB58-C665-48BF-B09E-5AF5A7CA91E6@conjury.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 02:28:31 -0000 --Apple-Mail=_433CA7B3-AB2C-47C5-AFCB-E81469EDFE57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 20, 2019, at 17:13, Fernando Gont wrote: >=20 > Given that RFC6092 recommends "only allow outgoing connections=E2=80=9D.= .. I certainly don=E2=80=99t remember writing that, and I just = double-checked the text, and I=E2=80=99m pretty sure that recommendation = is not in RFC 6092. The relevant portion is Section 3.4 Passive = Listeners, I think, and it only goes so far as to say this: REC-49: Internet gateways with IPv6 simple security capabilities MUST provide an easily selected configuration option that permits a "transparent mode" of operation that forwards all unsolicited flows regardless of forwarding direction, i.e., not to use the IPv6 simple security capabilities of the gateway. The transparent mode of operation MAY be the default configuration. The recommendation to deny inbound flows to passive listeners by = default, I believe, comes from RFC 4864, which says this on page 15: These should provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets (sometimes known as reflective session state). The reason this is important: RFC 6092 includes all that special = requirements language despite being Informational category because IPv6 = Ready and various other groups were asking for guidance by which they = could write their own standards for IPv6 Simple Security requirements, = and IETF wanted to give them that guidance. And so, RFC 6092 was written = with that aim in mind. RFC 4864 is just an Informational document that = offers some opinionated assertions on the topic, and I would say it=E2=80=99= s worth what you paid for it. As far as I know, IETF has not yet actually written a Standards Track = RFC that says Internet gateways SHOULD (note well: requirements = language) block inbound flows to passive listeners. I=E2=80=99d be = interested to know if I=E2=80=99ve missed that news. In any case, my = recollection is that it wasn=E2=80=99t the case when RFC 6092 was = published. Shorter james: don=E2=80=99t blame me for this. I didn=E2=80=99t do it. --james woodyatt --Apple-Mail=_433CA7B3-AB2C-47C5-AFCB-E81469EDFE57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 20, 2019, at 17:13, Fernando Gont <fgont@si6networks.com> wrote:

Given that RFC6092 recommends "only allow outgoing = connections=E2=80=9D...

I = certainly don=E2=80=99t remember writing that, and I just double-checked = the text, and I=E2=80=99m pretty sure that recommendation is not in RFC = 6092. The relevant portion is Section 3.4 Passive Listeners, I think, = and it only goes so far as to say this:

   REC-49: Internet gateways with IPv6 simple security =
capabilities MUST
   provide an easily selected configuration option that permits a
   "transparent mode" of operation that forwards all unsolicited flows
   regardless of forwarding direction, i.e., not to use the IPv6 simple
   security capabilities of the gateway.  The transparent mode of
   operation MAY be the default configuration.

The recommendation to = deny inbound flows to passive listeners by default, I believe, comes = from RFC 4864, which says this on page 15:

   These should provide a =
default configuration where incoming traffic
   is limited to return traffic =
resulting from outgoing packets
   (sometimes known as =
reflective session state).

The reason this is important: RFC 6092 includes all that = special requirements language despite being Informational category = because IPv6 Ready and various other groups were asking for guidance by = which they could write their own standards for IPv6 Simple Security = requirements, and IETF wanted to give them that guidance. And so, RFC = 6092 was written with that aim in mind. RFC 4864 is just an = Informational document that offers some opinionated assertions on the = topic, and I would say it=E2=80=99s worth what you paid for = it.

As far as = I know, IETF has not yet actually written a Standards Track RFC that = says Internet gateways SHOULD (note well: requirements language) block = inbound flows to passive listeners. I=E2=80=99d be interested to know if = I=E2=80=99ve missed that news. In any case, my recollection is that it = wasn=E2=80=99t the case when RFC 6092 was published.

Shorter = james: don=E2=80=99t blame me for this. I didn=E2=80=99t do = it.

--james woodyatt = <jhw@conjury.org>




= --Apple-Mail=_433CA7B3-AB2C-47C5-AFCB-E81469EDFE57-- From nobody Wed Feb 20 18:28: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 84544130FD7; Wed, 20 Feb 2019 18:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJFtLd7qnPiF; Wed, 20 Feb 2019 18:28:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C6A131010; Wed, 20 Feb 2019 18:28:37 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 79B7384A20; Thu, 21 Feb 2019 03:28:30 +0100 (CET) To: ek@loon.co Cc: Jen Linkova , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 20 Feb 2019 23:26:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 02:28:44 -0000 On 20/2/19 23:01, Erik Kline wrote: [....] > > > > > > Not receiving multicast RAs is not a condition you can really take any > > action on. > > Agreed. > > The main issue I see with incorporating an explicit rule in RFC6724 > about "freshness" is that in multi-prefix scenarios, it's guaranteed > that the default SA will oscillate among the different prefixes, and > that if you only implement this workaround, you wouldn't be able to > communicate with hosts actively employing your stale prefix. > > > that's where rule 5.5 would help (wherever it is actually implemented; > alas...) Not sure what you mean. How would rule 5.5. prevent SA oscillation or allow communication with the new "owner" of the stale prefix? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 20 18:42: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 2F1A2129532; Wed, 20 Feb 2019 18:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ILHuS_-4ruJ; Wed, 20 Feb 2019 18:42:08 -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 8921612894E; Wed, 20 Feb 2019 18:42:07 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 6322A83726; Thu, 21 Feb 2019 03:42:03 +0100 (CET) To: j h woodyatt , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <2EEFFB58-C665-48BF-B09E-5AF5A7CA91E6@conjury.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 20 Feb 2019 23:41:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <2EEFFB58-C665-48BF-B09E-5AF5A7CA91E6@conjury.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 02:42:11 -0000 On 20/2/19 23:28, j h woodyatt wrote: > On Feb 20, 2019, at 17:13, Fernando Gont > wrote: >> >> Given that RFC6092 recommends "only allow outgoing connections”... > > I certainly don’t remember writing that, and I just double-checked the > text, and I’m pretty sure that recommendation is not in RFC 6092. I quickly grep'ed RFC6092. Found this: If an inbound SYN packet is filtered, either because a corresponding state record does not exist or because of the filter's normal behavior, a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMPv6 messages allows the sender to detect that the SYN did not reach the intended destination. Discarding the packet, on the other hand, allows applications to perform simultaneous-open more reliably. A more detailed discussion of this issue can be found in [RFC5382], but the basic outcome of it is that filters need to wait on signaling errors until simultaneous-open will not be impaired. REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) to any unsolicited inbound SYN packet after waiting at least 6 seconds without first forwarding the associated outbound SYN or SYN/ACK from the interior peer. FWIW, I do agree with the advice. > As far as I know, IETF has not yet actually written a Standards Track > RFC that says Internet gateways SHOULD (note well: requirements > language) block inbound flows to passive listeners. I’d be interested to > know if I’ve missed that news. In any case, my recollection is that it > wasn’t the case when RFC 6092 was published. > > Shorter james: don’t blame me for this. I didn’t do it. Actually, I'm in favor of such advice ;-) I do think that CPEs should support UPnP for IPv6, such that apps can punch holes in the fw, as they do for the IPv4 case. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Feb 20 18:52: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 84F4E12894E for ; Wed, 20 Feb 2019 18:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcl4DGGb94LN for ; Wed, 20 Feb 2019 18:52:15 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3711200ED for ; Wed, 20 Feb 2019 18:52:15 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id z124so20698439itc.2 for ; Wed, 20 Feb 2019 18:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=f4gTl2Jb1TwW+Ghzb+pD1gBcxPDzWcrepWbVQZf0sXU=; b=qXW3rW/ZPoT/PhfS/sb95nIlfmY/cnDFr9dgkzKTu2gAubCAkRg3S44HEegGeKB/J6 ZEr+oCQ0R1Yku90oaPEMbSLutIQyKyrIbD5a4yMiybjO+s8znRfZMdEcyLRIGosXEUUl lgppJspa9i05be4v7oHR3OCOLz1WTnndnMVOI= 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:reply-to :from:date:message-id:subject:to:cc; bh=f4gTl2Jb1TwW+Ghzb+pD1gBcxPDzWcrepWbVQZf0sXU=; b=pyXx/eXz6VXrtywQ4+ebA5XOCw8GanNvgeokNZDGWAT7A4iNYONPd9zDDJEcO6EwvL 0tukdAG18HrK7+fTgY6QPpNnaUeomsjN7uF/P4MVOX8KhQOAQ/yhp0zqbStFqMAbPd30 JUKbK5wHzmdmCZzfKCjbb8sTlBVGiN2HJMSR5p+z9uAAMxbP33EnNmYvPW795PmoN7a1 lK05draMbcWqntw2iFT/1BS7PXx4N+iKprAqG88cZbOTdEx5UTCyNVdxar2kbz6OXTSI YjHJIvPZcC6hrn92fwcsi9qYGEdpzNybnzQDBQqX7M/dBj/FHK9p2at6wTo0ar3JNd1Y DQFA== X-Gm-Message-State: AHQUAuZch77qHNmmKi1azgchcdIK5yy+SJYnIaWcKaFOMcGmiJOiWdQK ITDyLIryLKo5fDU6lKZeKib6Ju8EDTjQndBzaiXdpg== X-Google-Smtp-Source: AHgI3Ia52YTDjlxmSWWIf1TAMoN3pB2f0hK86LM8zyIFWAjr716nsD9iffB5EfLpvAQm4OIx148hVOD3B0seT+bVV2I= X-Received: by 2002:a02:7e87:: with SMTP id g7mr20033461jae.92.1550717534195; Wed, 20 Feb 2019 18:52:14 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> In-Reply-To: Reply-To: ek@loon.co From: Erik Kline Date: Wed, 20 Feb 2019 18:52:01 -0800 Message-ID: To: Fernando Gont Cc: Jen Linkova , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000c6405805825e8f50" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 02:52:19 -0000 --000000000000c6405805825e8f50 Content-Type: text/plain; charset="UTF-8" On Wed, 20 Feb 2019 at 18:28, Fernando Gont wrote: > On 20/2/19 23:01, Erik Kline wrote: > [....] > > > > > > > > > Not receiving multicast RAs is not a condition you can really take > any > > > action on. > > > > Agreed. > > > > The main issue I see with incorporating an explicit rule in RFC6724 > > about "freshness" is that in multi-prefix scenarios, it's guaranteed > > that the default SA will oscillate among the different prefixes, and > > that if you only implement this workaround, you wouldn't be able to > > communicate with hosts actively employing your stale prefix. > > > > > > that's where rule 5.5 would help (wherever it is actually implemented; > > alas...) > > Not sure what you mean. How would rule 5.5. prevent SA oscillation or > allow communication with the new "owner" of the stale prefix? > I don't know about "stale", but looking at it again now I think 5.5 doesn't appear complete. I think an implementation would need to go further than just select a srcaddr based on the next hop advertiser, but it would need to remember to keep using that next hop for traffic originated with that srcaddr until a router failure could be detected (NUD failure, is_router flag flip, lifetime expiration, ...). Non-trivial, actually. --000000000000c6405805825e8f50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 20 Feb 2019 at 18:28, Fernand= o Gont <fgont@si6networks.com> wrote:
On= 20/2/19 23:01, Erik Kline wrote:
[....]
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Not receiving multicast RAs is not a condition= you can really take any
>=C2=A0 =C2=A0 =C2=A0> action on.
>
>=C2=A0 =C2=A0 =C2=A0Agreed.
>
>=C2=A0 =C2=A0 =C2=A0The main issue I see with incorporating an explicit= rule in RFC6724
>=C2=A0 =C2=A0 =C2=A0about "freshness" is that in multi-prefix= scenarios, it's guaranteed
>=C2=A0 =C2=A0 =C2=A0that the default SA will oscillate among the differ= ent prefixes, and
>=C2=A0 =C2=A0 =C2=A0that if you only implement this workaround, you wou= ldn't be able to
>=C2=A0 =C2=A0 =C2=A0communicate with hosts actively employing your stal= e prefix.
>
>
> that's where rule 5.5 would help (wherever it is actually implemen= ted;
> alas...)

Not sure what you mean. How would rule 5.5. prevent SA oscillation or
allow communication with the new "owner" of the stale prefix?
=


--000000000000c6405805825e8f50-- From nobody Wed Feb 20 19:03: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 731921286D8; Wed, 20 Feb 2019 19:03:24 -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, HTML_MESSAGE=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 0pLj93Nk01Ty; Wed, 20 Feb 2019 19:03:21 -0800 (PST) Received: from mail.conjury.org (prime.conjury.org [174.136.98.234]) by ietfa.amsl.com (Postfix) with ESMTP id BFB38126D00; Wed, 20 Feb 2019 19:03:20 -0800 (PST) Received: from [IPv6:2607:f598:b0b2:cf00:d4fb:b027:be5d:c37d] (unknown [IPv6:2607:f598:b0b2:cf00:d4fb:b027:be5d:c37d]) by mail.conjury.org (Postfix) with ESMTPSA id D9D3BE600D; Wed, 20 Feb 2019 18:26:06 -0800 (PST) From: j h woodyatt Message-Id: <0B67644D-7A35-4884-9D0D-1DEE4E80A2B6@conjury.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_832DA5C2-97F1-4D6F-9408-A2ADEEB084E9" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Feb 2019 19:03:18 -0800 In-Reply-To: Cc: Fernando Gont To: 6man@ietf.org, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org> <433607c1-dbc6-a42e-cb17-dc209e33bdaa@si6networks.com> <12EA4FAE-BE3D-4CFE-9837-DF052F79A998@employees.org> <5bc3eaf0-3ef0-d954-b228-00a7faac7f4c@si6networks.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 03:03:25 -0000 --Apple-Mail=_832DA5C2-97F1-4D6F-9408-A2ADEEB084E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Fernando, It matters a lot what =E2=80=9Cunsolicited=E2=80=9D means, c.f. the = final prepositional phrase in this explanation from Section 2.3: The general operating principle is that transport layer traffic is not forwarded into the interior network of a residential IPv6 gateway unless it has been solicited explicitly by interior transport endpoints, e.g., by matching the reverse path for previously forwarded outbound traffic, or by matching configured exceptions set by the network administrator. The use of a PCP server or the selection of the =E2=80=9Ctransparent = mode=E2=80=9D configuration option *is* a solicitation of inbound flows = to passive listeners. There is no recommendation for the default = configuration of either a PCP server or the transparent mode. Under a = strict interpretation of only RFC 6092 (without attempting to reference = RFC 4864 normatively as one hopes external bodies would not do), it MAY = be the case that inbound flows to passive listeners are solicited by = DEFAULT until explicitly configured otherwise. It=E2=80=99s RFC 4864 that recommends denying all inbound flows to = passive listeners, and RFC 6092 was carefully written to remain neutral = on that point. Precisely because we expected RFC 6092 to be input to = external standards, and we expected that some bodies would require = transparent mode by default. --james woodyatt > On Feb 20, 2019, at 01:59, Fernando Gont = wrote: >=20 > On 20/2/19 06:32, Mark Smith wrote: > [....] >>>> - As Ole implied, TCP uses addresses as identifiers, so TCP expects >>>> that the address will persist for the entire duration of the TCP >>>> connection, regardless of how long that duration is. >>>=20 >>> Your are turning a kludge into a design principle. >>=20 >> It's been a design assumption and expectation rather than a = principle, >> and an expectation TCP has had since 1974 (see RFC675, 2.2 "Sockets >> and Addressing" (That's TCPv1, before IP was split off)). >>=20 >> >>=20 >>>=20 >>> Clearly, with your model of TCP connections surviving interface = up/downs >>> and the default lifetimes, you really have a host that is unusable, >>> except in very specific network conditions -- such as: the host = never >>> moves (quite unlikely these days) >>=20 >> A 2013 presentation that makes that observation and some others. >>=20 >> "The Rapid Rise of the Mobile Multihomed Host, and What It Might Mean >> to the Network" >> = http://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20= P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf >>=20 >>=20 >>> and nothing (including the CPE) fails >>> (quite unlikely). >>>=20 >>=20 >> I'm not saying these behaviours and expectations are necessarily = correct today. >=20 > Besides "mobile" nodes, we have had RFC4941 for quite a long time now. > Temporary addresses are preferred over stable addresses in RFC6724. -- > so short-lived addresses are more the norm than the exception for = IPv6, > I'd say. >=20 >=20 >=20 >> What I am saying is that they are and have been foundation design and >> implementation assumptions that have been in place for multiple >> decades. I think the longer a foundation assumption has been in = place, >> the more care and consideration you need to give to changing it, >> because there can be unexpected impacts. Given those impacts, it may >> be better to preserve them and design around them, compared to trying >> to change them ("boiling the ocean"). The Mobile IP people, for >> example, took this approach. >=20 > Based on the deployment level of Mobile IP, I'm not sure we want to > follow that road ;-) >=20 >=20 >=20 >> People have said moving to multi-path transport layer protocols is >> trying to boil the ocean. >>=20 >> Compared to providing stable PD prefixes within the BNG >> infrastructure, I consider upgrading CPE to be boiling the ocean - >> waiting on a CPE vendor to develop that firmware (depending on their >> development priorities you may be waiting 3 to 6 months or possibly >> longer), testing, and then deploying 100s of 1000s of CPE software >> upgrades during many middles' of the night, with a risk of a >> percentage of upgrades failing. >=20 > Note: me, I think that many CPEs will never store prefixes on stable > storage. So, as far as *I* am concerned, the CPE advice is "this is = what > you should do if you want to be nice". >=20 > As noted before, a host cannot rely on the ISP to do stable prefixes, > nor on CPEs to be nice. So if you want to be robust, the best place to > improve such robustness is at the host. >=20 >=20 >=20 >> That's if you have managed CPE. If you >> support BYO CPE (very common in Australia), then the time frame for >> CPE functionality changes through upgrades is in the order of 5 years >> or more, because people don't replace BYO CPE unless it stops = working, >> and they don't upgrade firmware either if it subjectively seems to >> them to be working. >=20 > I agree with you in this respect. That's why I said you cannot rely on > the CPE doing "the right thing" to get this problem solved. >=20 >=20 >=20 >> Upgrading ISP network infrastructure and back-end systems isn't easy >> either, however it is within house so runs to your schedule and >> resource availability, and all customers using that >> infrastructure/system gain the benefit without having any changes = made >> to their equipment or configuration. >=20 > An ISP may have its own reasons for doing dynamic prefixes. A poll = made > by Jordi indicates that 37% of surveyed ISPs employ dynamic prefixes. > That's a significant percentage... and you want host to be robust in > such scenarios, too. >=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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_832DA5C2-97F1-4D6F-9408-A2ADEEB084E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Fernando,

It matters a lot what =E2=80=9Cunsolicited=E2=80=9D means, = c.f. the final prepositional phrase in this explanation from Section = 2.3:

   The general operating =
principle is that transport layer traffic is
   not forwarded into the interior network of a residential IPv6 gateway
   unless it has been solicited explicitly by interior transport
   endpoints, e.g., by matching the reverse path for previously
   forwarded outbound traffic, or by matching configured exceptions set
   by the network administrator.

The use of a PCP server or the = selection of the =E2=80=9Ctransparent mode=E2=80=9D configuration option = *is* a solicitation of inbound flows to passive listeners. There is no = recommendation for the default configuration of either a PCP server or = the transparent mode. Under a strict interpretation of only RFC 6092 = (without attempting to reference RFC 4864 normatively as one hopes = external bodies would not do), it MAY be the case that inbound flows to = passive listeners are solicited by DEFAULT until explicitly configured = otherwise.

It=E2=80=99s RFC 4864 that recommends denying all inbound = flows to passive listeners, and RFC 6092 was carefully written to remain = neutral on that point. Precisely because we expected RFC 6092 to be = input to external standards, and we expected that some bodies would = require transparent mode by default.




On Feb 20, 2019, at 01:59, Fernando Gont <fgont@si6networks.com> wrote:

On = 20/2/19 06:32, Mark Smith wrote:
[....]
- As Ole implied, TCP = uses addresses as identifiers, so TCP expects
that the = address will persist for the entire duration of the TCP
connection, regardless of how long that duration is.

Your are turning a kludge into a = design principle.

It's been a = design assumption and expectation rather than a principle,
and an expectation TCP has had since 1974 (see RFC675, 2.2 =  "Sockets
and Addressing"  (That's TCPv1, before = IP was split off)).

<snip>


Clearly, with your model of TCP connections surviving = interface up/downs
and the default lifetimes, you really = have a host that is unusable,
except in very specific = network conditions -- such as: the host never
moves (quite = unlikely these days)

A 2013 = presentation that makes that observation and some others.

"The Rapid Rise of the Mobile Multihomed Host, = and What It Might Mean
to the Network"
http://www.ausnog.net/sites/default/files/ausnog-2013/presentat= ions/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.= pdf


and nothing (including the CPE) fails
(quite unlikely).

I'm not saying these behaviours and expectations are = necessarily correct today.

Besides "mobile" nodes, we have had RFC4941 for quite a long = time now.
Temporary addresses are preferred over stable = addresses in RFC6724. --
so short-lived addresses are more = the norm than the exception for IPv6,
I'd say.



What I am saying is that they are and have been = foundation design and
implementation assumptions that have = been in place for multiple
decades. I think the longer a = foundation assumption has been in place,
the more care and = consideration you need to give to changing it,
because = there can be unexpected impacts. Given those impacts, it may
be better to preserve them and design around them, compared = to trying
to change them ("boiling the ocean"). The Mobile = IP people, for
example, took this approach.

Based on the deployment level of = Mobile IP, I'm not sure we want to
follow that road ;-)



People have said moving to multi-path transport = layer protocols is
trying to boil the ocean.

Compared to providing stable PD prefixes = within the BNG
infrastructure, I consider upgrading CPE to = be boiling the ocean -
waiting on a CPE vendor to develop = that firmware (depending on their
development priorities = you may be waiting 3 to 6 months or possibly
longer), = testing, and then deploying 100s of 1000s of CPE software
upgrades during many middles' of the night, with a risk of = a
percentage of upgrades failing.

Note: me, I think that many CPEs = will never store prefixes on stable
storage. So, as far as = *I* am concerned, the CPE advice is "this is what
you = should do if you want to be nice".

As noted = before, a host cannot rely on the ISP to do stable prefixes,
nor on CPEs to be nice. So if you want to be robust, the best = place to
improve such robustness is at the host.



That's if you have managed CPE. If you
support BYO CPE (very common in Australia), then the time = frame for
CPE functionality changes through upgrades is in = the order of 5 years
or more, because people don't replace = BYO CPE unless it stops working,
and they don't upgrade = firmware either if it subjectively seems to
them to be = working.

I agree with you in = this respect. That's why I said you cannot rely on
the CPE = doing "the right thing" to get this problem solved.



Upgrading ISP network infrastructure and back-end systems = isn't easy
either, however it is within house so runs to = your schedule and
resource availability, and all customers = using that
infrastructure/system gain the benefit without = having any changes made
to their equipment or = configuration.

An ISP may have = its own reasons for doing dynamic prefixes. A poll made
by = Jordi indicates that 37% of surveyed ISPs employ dynamic prefixes.
That's a significant percentage... and you want host to be = robust in
such scenarios, too.


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




---------------------------------------------------------------= -----
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6
---------------------------------------------------------------= -----

= --Apple-Mail=_832DA5C2-97F1-4D6F-9408-A2ADEEB084E9-- From nobody Wed Feb 20 20:25: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 3C35C129441; Wed, 20 Feb 2019 20:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj5FhUqmVywL; Wed, 20 Feb 2019 20:25:21 -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 39ECD129532; Wed, 20 Feb 2019 20:25:21 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id z25so8321689qti.13; Wed, 20 Feb 2019 20:25:21 -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=PAanPXFCTZFy5iwk2bSihXyjlhQLYE7x/qw4AvhNIAU=; b=hjGm3S7Dg8B0J76cNLMy1/HZ12Nw5t0S+MaT3/h1TCFfKpNraFWlAhFwSr5JPgDGsa x14rCDCRqTM0O6vOb7RKK0b6pQziSukU5V3jDCyezcy1TjBUfMXzw0gd9TmYGm09K1Yo Gc+FE1CtOItyQz3ZSmDZPaoZm+e4tnacMfkha1yyM/1yeBfzG0xPDknS0V6MPdGoW67B FV275SpFBADDX8fV1LBWGYrSDpY52HHX0rIdHWzFilTDjn//1hL3JuGB45yyx3rTGXU7 PBkGjpt5dr6LZaSfeq0lKPqALZDfRnFURRU7CiF5St9vgfiuI9uLEZGtvKZ/S/g/5zVr 8yOg== 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=PAanPXFCTZFy5iwk2bSihXyjlhQLYE7x/qw4AvhNIAU=; b=PtuyihlmgauMANNmYc/+QTRrDUHulSHMuzDlMy/bd6yhmzx0LZinfTev/xNOoBhmV/ gMt2jFftAWDzrJZkbjRUrC8b1cTdAXgL7Olilv+5UPZTnSDOb0oyQjStizg+WlwjwT+m fr1UBe3m/oElGNE3uyEJLTfwj6+ThUjslQvdmYcFwnkMcOwP5vEXgyPxOUkoI1ZgyxuI cMWN9DuwI7hLxQeKxquNv+NCdObEBcUC3ES7t1irnHk6ELq24D7fxcx+L+5dJKkoTHxv U9FYr5rrB6qOrcd+/jej4orlJotU52LYNCkLZ/dWYo59t2vuIxSFU4b6zSLyU5g4aZCc tC8Q== X-Gm-Message-State: AHQUAuZ5gA1aR40/ATg8+IDCDNeYUXCo95wuZLz1bohS9hC5jFFQ7Rsy 4UvhYQ/M8mABob3AlHBdJL0nVkzT0och8le63wAw1OX+ X-Google-Smtp-Source: AHgI3Ib1I0pgKYiuTVnoNAHRjGRIn3+joT5x4XMyzSIJZSKe5xHqBJpcoQcaUMYL0k6JuHhJL0KaNII60zlN5TZATW8= X-Received: by 2002:ac8:3802:: with SMTP id q2mr23163185qtb.325.1550723119894; Wed, 20 Feb 2019 20:25:19 -0800 (PST) MIME-Version: 1.0 References: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> In-Reply-To: From: Jen Linkova Date: Thu, 21 Feb 2019 15:25:08 +1100 Message-ID: To: Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , "Jan Zorz @ go6.si" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.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: Thu, 21 Feb 2019 04:25:23 -0000 On Wed, Feb 20, 2019 at 8:49 PM Fernando Gont wrote: > > - (sorry if I missed another thread on it - I'm catching up with > > emails slowly): any reason for setting Valid Lifetime to 0 as well? It > > looks to me that just deprecating the prefix would be enough..What > > would be a benefit of completely removing an address already > > deprecated? > > You mean in the host-side algorithm specified in Section 5.1.3? The > benefit would be garbage collection. -- another alternative would be, > instead removing the addresses, reduce the current Valid Lifetime -- say > to 10 minutes or whatever, so that the stale addresses do not stay > around forever. (if SLAAC was using sensible timer values, you wouldn't > need these... but you probably don't want stale addresses to stay around > for one months, as per the default "Valid Lifetime"). Do we have any data on how much pain this is causing? I mean those addresses are not staying forever, just one month in the worst case scenario. So they will disappear eventually. On the other hand if I have an tcp session opened - why do we need to kill it in 10 mins? I agree that default times should be more reasonable, so I agree that defaults should be changed and depend on the AdvDefaultLifetime. Speaking of exact numbers - how did you come up with values? Just curious if the is any background for choosing them... > > - "After normal processing of Router Advertisement messages, Router > > Advertisements that contain at least one PIO MUST be processed as > > follows" - I'd suggest you make it explicit that PIOs must of of > > the global scope. I did see CPEs including PIOs for fe80::/64 (and > > AFAIR such behavior is not explicitly prohibited); > > Item b) in Section 5.5.3 says: > b) If the prefix is the link-local prefix, silently ignore the > Prefix Information option. > > albeit not with normative language. But, anyway, if you've seen CPEs > send them, we better make this explicit! I must be blind, I can not see that sentence in the draft ;( > I've never seen a scenario where information actually needs to be split > among multiple RAs. I have a hard time thinking of filling up a whole RA. Let's wait for the new shiny world of mPVD to come... > > - as I've mentioned earlier, it would be nice not to break other > > scenarios while fixing DHCP-PD case. So what do you think about > > modifying the algorithm so the addresses are deprecated only if *all* > > routers the PIO has been received from stopped advertising it? Again, > > my point is that while proposed behavior *does* help in a single-homed > > residential case, it would be nice to keep in mind other cases and > > avoid breaking them; > > Yes, we should update the algorithm as you suggest. > > Thinking our loud: best thing would probably be that, in the case the > prefix has been advertised by multiple routers, it is dis-associated > with the prefix that ceased advertising it. Otherwise, you might end up > sending packets sourced from that prefix to the next-hop router that has > ceased advertising it. That is, if multiple routers were advertising a > prefix, and one has ceased advertising it, you want packets sourced from > that prefix to use a next-hop router that keeps advertising the prefix. So...it looks to me that the only change should be: - if a host supports prefix <> advertizing router mapping and supports the Rule 5.5: -- deassociate prefix - next-hop if the given router stops advertizing it; -- deprecate the prefix if there is no routers advertizing it; Then the default address selection takes care of selecting the right source address. No need for complex algorithm described in the draft (and potential implementation bugs). If the host does not support Rule 5.5 + prefix<>next-hop mapping, this draft (PIO processing part) would not work for them anyway. Combined with reduced default timers it should help significantly (at least for hosts and routers implementing this..) > > - the proposed changes say that PIOs MUST be processed as > > follows....and relies on hosts tracking prefix <> nexthop as per > > RFC8028...However RFC8028 (and RFC8504) uses 'SHOULD' ...so it seems > > to be inconsistency here..If a host does not implement RFC8029, all > > those MUST in the draft do not make much sense. > > That's a good point. I wonder if we should change the "MUST" to > "SHOULD", or whether we should stick to "MUST" with a rationale of "a > host that implements this standard MUST implement RFC8028 and MUST > process PIOs as follows..." See above. All we need to do in terms of PIO processing by a host is to say 'host SHOULD refresh prefix-next-hop mapping while processing RAs' (which would mean 'remove all mappings for that next-hop if they are not in that RA you are processing') and 'host SHOULD deprecate addresses with no next-hops'. Even if you say 'MUST' here (and explicitly state 'MUST implement RFC8028') it would only mean 'hosts MUST support a standard which says they SHOULD do smth' => effectively that requirement means 'SHOULD'. > Thinking out loud: I wonder if support for RFC8028 should have actually > been a MUST in RFC8504 -- reality is that in many multiprefix/multihomed > scenarios, if you don't do RFC8504 it's quite likely your packets will > be dropped -- i.e., an interoperability issue that would have warranted > a "MUST" for 8028. See above. Then 8028 should have said 'MUST support rule 5.5 -- SY, Jen Linkova aka Furry From nobody Wed Feb 20 21:58: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 DB82512EB11; Wed, 20 Feb 2019 21:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 TyCQuD7wsjcR; Wed, 20 Feb 2019 21:58:56 -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 8219012008F; Wed, 20 Feb 2019 21:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550728732; x=1551333532; 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=MCNpxHmzKQkzfwYg+6Due fqytVOchEQUB4WmkrGP2y0=; b=G3RoZHxCrPy1Lyao4CBs778KH9AANI/qSvrBY 8K7fnV0zLCpZWhDHMSYiAnWscoaHl51ELshkgQafHrFWN/3noTucT4n6CYdKnIqB rL15WGehQqPOg5jL/qSirdDljPe3KutJMNFibRMIgG7eDH4o7myfrOAIk/PBKgZX uVptqw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 21 Feb 2019 06:58:52 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 21 Feb 2019 06:58:52 +0100 Received: from [10.10.10.160] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006162679.msg; Thu, 21 Feb 2019 06:58:51 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.10.10.160] X-MDArrival-Date: Thu, 21 Feb 2019 06:58:51 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1955780031=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Thu, 21 Feb 2019 14:58:36 +0900 From: JORDI PALET MARTINEZ To: IPv6 Operations , dnsop Message-ID: <40C16CF8-8EE8-468D-8248-A2873CC7EAB6@consulintel.es> Thread-Topic: inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment 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 Feb 2019 05:58:58 -0000 Hi all, (dnsop copied because DNS64) I'm working in a new version of this document. Link to the document: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ It will be great if we can get some new inputs. Thanks! Regards, Jordi ********************************************** 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 nobody Wed Feb 20 23:22: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 4F711126C01; Wed, 20 Feb 2019 23:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvyLUayroEhi; Wed, 20 Feb 2019 23:22:10 -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 39550124C04; Wed, 20 Feb 2019 23:22:09 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 6D4D7843B8; Thu, 21 Feb 2019 08:22:05 +0100 (CET) To: Jen Linkova Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , "Jan Zorz @ go6.si" References: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 21 Feb 2019 04:21:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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] Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.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: Thu, 21 Feb 2019 07:22:14 -0000 On 21/2/19 01:25, Jen Linkova wrote: > On Wed, Feb 20, 2019 at 8:49 PM Fernando Gont wrote: >>> - (sorry if I missed another thread on it - I'm catching up with >>> emails slowly): any reason for setting Valid Lifetime to 0 as well? It >>> looks to me that just deprecating the prefix would be enough..What >>> would be a benefit of completely removing an address already >>> deprecated? >> >> You mean in the host-side algorithm specified in Section 5.1.3? The >> benefit would be garbage collection. -- another alternative would be, >> instead removing the addresses, reduce the current Valid Lifetime -- say >> to 10 minutes or whatever, so that the stale addresses do not stay >> around forever. (if SLAAC was using sensible timer values, you wouldn't >> need these... but you probably don't want stale addresses to stay around >> for one months, as per the default "Valid Lifetime"). > > Do we have any data on how much pain this is causing? Not that I know of. Problem is: you still have v4, and if v6 fails, HE makes it work over v4. > I mean those > addresses are not staying forever, > just one month in the worst case scenario. So they will disappear eventually. Many stacks limit the number of prefixes they will use for address configuration. Some limit such number to 16. That means that if you experience crash-and-reboot 16 during the same month, your host may fail to configure addresses for the fresh prefix. > On the other hand if I have an tcp session opened - why do we need to > kill it in 10 mins? Not sure what you mean.... > I agree that default times should be more reasonable, so I agree that > defaults should be changed and depend on the > AdvDefaultLifetime. > > Speaking of exact numbers - how did you come up with values? Just > curious if the is any background for choosing them... The only one you really choose is MaxRtrAdvInterval. The rest are set as a function of it. For the most part, I picked MaxRtrAdvInterval such that there were more ferquent RAs, but in the worst-case scenario, never more than 1 every 1.5-2 minutes. (trade-off beween responsiveness and not bothering the network a lot, unnecessarily) > >>> - "After normal processing of Router Advertisement messages, Router >>> Advertisements that contain at least one PIO MUST be processed as >>> follows" - I'd suggest you make it explicit that PIOs must of of >>> the global scope. I did see CPEs including PIOs for fe80::/64 (and >>> AFAIR such behavior is not explicitly prohibited); >> >> Item b) in Section 5.5.3 says: >> b) If the prefix is the link-local prefix, silently ignore the >> Prefix Information option. >> >> albeit not with normative language. But, anyway, if you've seen CPEs >> send them, we better make this explicit! > > I must be blind, I can not see that sentence in the draft ;( Sorry, that section is not in the draft, but in rfc4862. Same text appears in Section 6.3.4 of RFC4861. >> I've never seen a scenario where information actually needs to be split >> among multiple RAs. I have a hard time thinking of filling up a whole RA. > > Let's wait for the new shiny world of mPVD to come... Same router, PIOs split over more than three RAs? >>> - as I've mentioned earlier, it would be nice not to break other >>> scenarios while fixing DHCP-PD case. So what do you think about >>> modifying the algorithm so the addresses are deprecated only if *all* >>> routers the PIO has been received from stopped advertising it? Again, >>> my point is that while proposed behavior *does* help in a single-homed >>> residential case, it would be nice to keep in mind other cases and >>> avoid breaking them; >> >> Yes, we should update the algorithm as you suggest. >> >> Thinking our loud: best thing would probably be that, in the case the >> prefix has been advertised by multiple routers, it is dis-associated >> with the prefix that ceased advertising it. Otherwise, you might end up >> sending packets sourced from that prefix to the next-hop router that has >> ceased advertising it. That is, if multiple routers were advertising a >> prefix, and one has ceased advertising it, you want packets sourced from >> that prefix to use a next-hop router that keeps advertising the prefix. > > So...it looks to me that the only change should be: > - if a host supports prefix <> advertizing router mapping and supports > the Rule 5.5: > -- deassociate prefix - next-hop if the given router stops advertizing it; > -- deprecate the prefix if there is no routers advertizing it; In response to what? I was thinking this would be an action by algorithm from 5.1.3 once the prefix has been un-preferred. If not, what would be the event that would trigger such dis-association? > Then the default address selection takes care of selecting the right > source address. > No need for complex algorithm described in the draft (and potential > implementation bugs). > > If the host does not support Rule 5.5 + prefix<>next-hop mapping, this > draft (PIO processing part) would not work for them anyway. > > Combined with reduced default timers it should help significantly (at > least for hosts and routers implementing this..) With appropriate timers + modification to SAS you get the problem solved. However, if you have multiple prefixes, and the source address will flap among them. -- I'd try, to the extent that is possible, to avoid that.... > >>> - the proposed changes say that PIOs MUST be processed as >>> follows....and relies on hosts tracking prefix <> nexthop as per >>> RFC8028...However RFC8028 (and RFC8504) uses 'SHOULD' ...so it seems >>> to be inconsistency here..If a host does not implement RFC8029, all >>> those MUST in the draft do not make much sense. >> >> That's a good point. I wonder if we should change the "MUST" to >> "SHOULD", or whether we should stick to "MUST" with a rationale of "a >> host that implements this standard MUST implement RFC8028 and MUST >> process PIOs as follows..." > > See above. All we need to do in terms of PIO processing by a host is > to say 'host SHOULD refresh prefix-next-hop mapping while processing > RAs' (which would mean 'remove all mappings for that next-hop if they > are not in that RA you are processing') and 'host SHOULD deprecate > addresses with no next-hops'. This enforces a more strict requirement on RAs. i.e., PIOs can only be sent in one RA. I'm not saying that's necessarily bad, but the reasons for the algorithm in Section 5.1.3 is to allow PIOs to be split in at most two RAs. > Even if you say 'MUST' here (and explicitly state 'MUST implement > RFC8028') it would only mean 'hosts MUST support a standard which says > they SHOULD do smth' => effectively that requirement means 'SHOULD'. Agreed. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 20 23:35: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 90149126C15 for ; Wed, 20 Feb 2019 23:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYn1XnL_cB4Y for ; Wed, 20 Feb 2019 23:35:33 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27790126C01 for ; Wed, 20 Feb 2019 23:35:32 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 145BD41CDB for ; Thu, 21 Feb 2019 08:35:31 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id F3F3E41B57; Thu, 21 Feb 2019 08:35:30 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id E610EB740D; Thu, 21 Feb 2019 08:35:30 +0100 (CET) Date: Thu, 21 Feb 2019 08:35:30 +0100 From: Gert Doering To: Lorenzo Colitti Cc: "Manfredi (US), Albert E" , Gert Doering , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: <20190221073530.GT71606@Space.Net> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q3LtICoXRyWKz3HA" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.11.2 (2019-01-07) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 07:35:36 -0000 --Q3LtICoXRyWKz3HA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Feb 21, 2019 at 08:43:21AM +0900, Lorenzo Colitti wrote: > Because the advantages are for network operators have corresponding > disadvantages for application developers and thus for users. Application > complexity and brittleness due to NAT traversal. Battery impact of NAT > keepalives. Higher-latency due to relaying and rendezvous. And so on. NPTv6 does not need state, so no keepalives and battery impact. Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to learn how to deal with NAPT. New protocols that embed IP addresses are=20 killed by IPv4 NAPT anyway, so that ship has sailed - and everything that doesn't care about embedded IP addresses will nicely work throug NPTv6. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Q3LtICoXRyWKz3HA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlxuVMAACgkQ31bAZeTO f8VDUA//X2f1nqNEw64it/wjvy7sHs86QCZ3iAe9FtTcDUVCH21rwyWU4LIGNu5l FoLv7LB+NI460I40WeHKAykA+te+1zwRVnR08Zc2gP4ECHVpJdiPWHKM0j81eVNQ ImbrnptE9fq1ZsR8WnoVkOwd1wKg/Cp3ZhBy9cjtITmPPaWVfppRaQuO7DT5xc1j GSFQlamwhtvedQu2Hk8l6ke+HPVegUfkgGPSO9R0Zcs7owlg6dXO4wUt6bRWOjeQ +C9/p4/d3AME7lT4sf8cVPm8LIkmP80kVozi/OlNtggN1i/tlLtEezxdtr7txK5D unFB6IhXGL6MHzOGgu7hRknOw02aQeFP5PjQmbPxp8n4q8QJ6qNpRcN2ysWGt1fx U328lpbaCu8OCPSb36UFNezSs+hL5XYsnxOFZzrJ0XnFd58UsiQQ9WEzhKCy44wS aOWifxdj7MBCnybLUZuzLvjuNtKOt1JSi1ysdv9/SvGiezJ3+vcOu1PkuDwcJ0cE JexZUaLgaFpil4gojejlEYCYn2UGOXUjUV0eDUgaBgYfxLjsNuURIzYUC+t3xX8z RMoWiBvJeGNd2SRyUy9qJPIW6uXw0RhJHHRTUIqlYo2oQdsuhJDrzSDAJrs0KxN/ lo4fy9pcbw5Wro4J4Fl9v1hoYkCvyorNmlE5SyoCNK6y72D3q/I= =oD0O -----END PGP SIGNATURE----- --Q3LtICoXRyWKz3HA-- From nobody Thu Feb 21 02:42: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 350AE130DD6 for ; Thu, 21 Feb 2019 02:42:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc_npqpicy57 for ; Thu, 21 Feb 2019 02:41:56 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24ACE1276D0 for ; Thu, 21 Feb 2019 02:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1550745714; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uDM/SIyahBrmXl5/xxTqOy/Pj8dT6dUwiZ1jG/7gncQ=; b=IfwYKhSE6+56KsamNw3XMjw2zB/IJBfAVEX13KQzPhFbHkonclYR3LEa6enb5xeno1GX8m6AAAEYLEWnMznVE3FFwJTMuuCC9hiFXZM3K0ZEy+WkWFjG1ZcCr/vNYaJrRuD2ZywGAP7DBvjUZvyqxajLLv4PNDfsW/CGeMKT+ac= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp2058.outbound.protection.outlook.com [104.47.4.58]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-88-rK9RXcX1Pk6dA3ZC0g78lQ-2; Thu, 21 Feb 2019 10:41:50 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.54.140) by AM0PR07MB4292.eurprd07.prod.outlook.com (52.133.61.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.6; Thu, 21 Feb 2019 10:41:47 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb%4]) with mapi id 15.20.1665.006; Thu, 21 Feb 2019 10:41:47 +0000 From: Tim Chown To: "ek@loon.co" CC: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUyNCyRyfkiR0M6E+jXGYmGdTvsaXobdkAgAEAugCAAASxgIAACP4AgAAEwgCAAJFvAA== Date: Thu, 21 Feb 2019 10:41:47 +0000 Message-ID: <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-originating-ip: [2001:a88:d510:1101:c0d1:a0e8:70b4:49f1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 245beef6-4c67-4ea9-4b4f-08d697e92de9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4292; x-ms-traffictypediagnostic: AM0PR07MB4292: x-microsoft-exchange-diagnostics: 1; AM0PR07MB4292; 20:0XvNaTJ6RlEWVTrBdNujUjARjLsiMICzmrsLPVy4DI/8x53GnOrD+pzXuX695ZBO2P2qfPR0FAMdE9rO1Ej/apnmLMtgK697nXtIHPaMETR1QuHTUiWBv2AbQc4O3mvtNpxZ4pc8OO6lgsuYkA3w6Uf2i7Q6giY8OhCf28Zi3PQ= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39850400004)(136003)(346002)(376002)(199004)(189003)(2351001)(229853002)(5640700003)(186003)(99286004)(6436002)(36756003)(68736007)(5660300002)(54896002)(236005)(4326008)(105586002)(6512007)(46003)(102836004)(33656002)(53546011)(478600001)(6246003)(6506007)(53936002)(25786009)(72206003)(476003)(93886005)(14454004)(106356001)(74482002)(446003)(2616005)(11346002)(54906003)(7736002)(786003)(316002)(1730700003)(486006)(66574012)(50226002)(2906002)(86362001)(82746002)(71190400001)(6486002)(71200400001)(2501003)(83716004)(256004)(76176011)(57306001)(6916009)(6116002)(8936002)(81156014)(97736004)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4292; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: XnfAyuPxfPUyT+BunETczM4hDRnMGwBUIDTRojGyF/HSXqPNDWRlOYS5Srq7nCFnlsoYBfwcUwIycvIY+Ozt3i7NULWdSSCAe2EKPV6757Ny8oheTUFyq1+AXGHbJX7whfNRXGxcV4cSFoVZ2pWv4EQS07cTeJluliDixjdtEOOLHU0zt3d/XeXEVlz5sKqTy8WgOb+2p7vSgvWe18CusfYIYJBPsnuBznU4a0xqpqTp8CaNO3RRnVDflVohgpQDetHpCnAJyCOUWLTazgYJxY1I3ZQpjZHCzqVddq8vTJQCCcwI7kLyRGsP632E+62jt14vlQeT3fBSBfAs0Q8MzTFpwu8WZh19GL2HGVxm4jKjLFlJE1xcx/PNfvWtOlpFDZ8uSLGsCfHXXdoP0HVQuCp0t2r7h3/KuhH/0jlK2AM= MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 245beef6-4c67-4ea9-4b4f-08d697e92de9 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 10:41:47.1801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4292 X-MC-Unique: rK9RXcX1Pk6dA3ZC0g78lQ-2 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_0DDB453862F8442AA12CD3C176540884jiscacuk_" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:42:00 -0000 --_000_0DDB453862F8442AA12CD3C176540884jiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 21 Feb 2019, at 02:01, Erik Kline > wrote: On Wed, 20 Feb 2019 at 17:49, Fernando Gont > wrote: Hi, Eric, On 20/2/19 22:12, Erik Kline wrote: > > > On Wed, 20 Feb 2019 at 17:07, Fernando Gont > >> wrote: > > On 20/2/19 06:36, Jen Linkova wrote: > [...] > >> Example: > >> > >> Say you have two network interfaces: If1 and If2. > >> Say If1, is configured with 2001:db8:1::/64, and If2 with > 2001:db8:2::/64 > >> > >> Say the first default router is that associated with If1. > >> > >> Say prefix 2001:db8:1::/64 stops being announced, or that you stop > >> receiving RAs on If1, but RAs on If2 keep arriving fine. > >> > >> Based on the logic of your algorithm, one would expect that a new > >> connection uses 2001:db8:2::/64/If2 (since that's the "more recent= ly > >> advertised information). However, Rule #5 would override that and > make > >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes > addresses on > >> the outgoing interface. > > > > I'm even more confused now, sorry ;(( > > I was referring to the fact that some of the previous rules might > prevent the evaluation of the rule about freshness. e.g.: > > * You have two network interfaces eth0 and eth1 (say each connected t= o a > different ISP) > * eth0 has stopped receiving RAs > * eth1 receives RAs as usual (hence all info associated with this > interface is "fresher" than than corresponding to eth0) > * The default router employed by eth0 has precedence (whether because= it > had a higher preference value, because it was the first one that wa= s > learned, or whatever) > * When you evaluate the rules in RFC6724, rule 5 will say that the > outgoing interface will be eth0, and thus you should pick an addres= s > associated with it --- however, as noted above, the addresses on et= h1 > are fresher than those from eth1. > > > Not receiving multicast RAs is not a condition you can really take any > action on. Agreed. The main issue I see with incorporating an explicit rule in RFC6724 about "freshness" is that in multi-prefix scenarios, it's guaranteed that the default SA will oscillate among the different prefixes, and that if you only implement this workaround, you wouldn't be able to communicate with hosts actively employing your stale prefix. that's where rule 5.5 would help (wherever it is actually implemented; alas= ...) Yeah.... we did add an explicit pointer to this in the Nodes Requirements -= bis, fwiw (noting RFC 8028). Tim --_000_0DDB453862F8442AA12CD3C176540884jiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: <146CEFBB3F52664398838054311FC164@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On 21 Feb 2019, at 02:01, Erik Kline <ek@loon.co> wrote:

On Wed, 20 Feb 2019 at 17:49, Fernand= o Gont <fgont@si6net= works.com> wrote:
Hi, Eric,

On 20/2/19 22:12, Erik Kline wrote:
>
>
> On Wed, 20 Feb 2019 at 17:07, Fernando Gont <fgont@si6networks.com > <mailto:fgont@si6networks.com>> wrote:
>
>     On 20/2/19 06:36, Jen Linkova wrote:
>     [...]
>     >> Example:
>     >>
>     >> Say you have two network interfaces: If1 a= nd If2.
>     >> Say If1, is configured with 2001:db8:1::/6= 4, and If2 with
>     2001:db8:2::/64
>     >>
>     >> Say the first default router is that assoc= iated with If1.
>     >>
>     >> Say prefix 2001:db8:1::/64 stops being ann= ounced, or that you stop
>     >> receiving RAs on If1, but RAs on If2 keep = arriving fine.
>     >>
>     >> Based on the logic of your algorithm, one = would expect that a new
>     >> connection uses 2001:db8:2::/64/If2 (since= that's the "more recently
>     >> advertised information). However, Rule #5 = would override that and
>     make
>     >> you employ 2001:db8:1::/64/If1, since Rule= #5 prioritizes
>     addresses on
>     >> the outgoing interface.
>     >
>     > I'm even more confused now, sorry ;((
>
>     I was referring to the fact that some of the previo= us rules might
>     prevent the evaluation of the rule about freshness.= e.g.:
>
>     * You have two network interfaces eth0 and eth1 (sa= y each connected to a
>     different ISP)
>     * eth0 has stopped receiving RAs
>     * eth1 receives RAs as usual (hence all info associ= ated with this
>       interface is "fresher" than than c= orresponding to eth0)
>     * The default router employed by eth0 has precedenc= e (whether because it
>       had a higher preference value, because it wa= s the first one that was
>       learned, or whatever)
>     * When you evaluate the rules in RFC6724, rule 5 wi= ll say that the
>       outgoing interface will be eth0, and thus yo= u should pick an address
>       associated with it --- however, as noted abo= ve, the addresses on eth1
>       are fresher than those from eth1.
>
>
> Not receiving multicast RAs is not a condition you can really take any=
> action on.

Agreed.

The main issue I see with incorporating an explicit rule in RFC6724
about "freshness" is that in multi-prefix scenarios, it's guarant= eed
that the default SA will oscillate among the different prefixes, and
that if you only implement this workaround, you wouldn't be able to
communicate with hosts actively employing your stale prefix.

that's where rule 5.5 would help (wherever it is actually i= mplemented; alas...)

Yeah.... we did add an explicit pointer to this in the Nodes Requireme= nts -bis, fwiw (noting RFC 8028).

Tim

--_000_0DDB453862F8442AA12CD3C176540884jiscacuk_-- From nobody Thu Feb 21 08:12: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 419C2131050; Thu, 21 Feb 2019 08:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aoC_gsqCr6PJ; Thu, 21 Feb 2019 08:11:56 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C011286E7; Thu, 21 Feb 2019 08:11:56 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 AA96F8458E; Thu, 21 Feb 2019 17:11:52 +0100 (CET) To: Tim Chown , "ek@loon.co" Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 21 Feb 2019 13:11:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 16:12:02 -0000 On 21/2/19 07:41, Tim Chown wrote: >> On 21 Feb 2019, at 02:01, Erik Kline > >> wrote: >> >> On Wed, 20 Feb 2019 at 17:49, Fernando Gont > > wrote: >> >> Hi, Eric, >> >> On 20/2/19 22:12, Erik Kline wrote: >> > >> > >> > On Wed, 20 Feb 2019 at 17:07, Fernando Gont >> >> > >> >> wrote: >> > >> > On 20/2/19 06:36, Jen Linkova wrote: >> > [...] >> > >> Example: >> > >> >> > >> Say you have two network interfaces: If1 and If2. >> > >> Say If1, is configured with 2001:db8:1::/64, and If2 with >> > 2001:db8:2::/64 >> > >> >> > >> Say the first default router is that associated with If1. >> > >> >> > >> Say prefix 2001:db8:1::/64 stops being announced, or that >> you stop >> > >> receiving RAs on If1, but RAs on If2 keep arriving fine. >> > >> >> > >> Based on the logic of your algorithm, one would expect >> that a new >> > >> connection uses 2001:db8:2::/64/If2 (since that's the >> "more recently >> > >> advertised information). However, Rule #5 would override >> that and >> > make >> > >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes >> > addresses on >> > >> the outgoing interface. >> > > >> > > I'm even more confused now, sorry ;(( >> > >> > I was referring to the fact that some of the previous rules >> might >> > prevent the evaluation of the rule about freshness. e.g.: >> > >> > * You have two network interfaces eth0 and eth1 (say each >> connected to a >> > different ISP) >> > * eth0 has stopped receiving RAs >> > * eth1 receives RAs as usual (hence all info associated with >> this >> > interface is "fresher" than than corresponding to eth0) >> > * The default router employed by eth0 has precedence >> (whether because it >> > had a higher preference value, because it was the first >> one that was >> > learned, or whatever) >> > * When you evaluate the rules in RFC6724, rule 5 will say >> that the >> > outgoing interface will be eth0, and thus you should pick >> an address >> > associated with it --- however, as noted above, the >> addresses on eth1 >> > are fresher than those from eth1. >> > >> > >> > Not receiving multicast RAs is not a condition you can really >> take any >> > action on. >> >> Agreed. >> >> The main issue I see with incorporating an explicit rule in RFC6724 >> about "freshness" is that in multi-prefix scenarios, it's guaranteed >> that the default SA will oscillate among the different prefixes, and >> that if you only implement this workaround, you wouldn't be able to >> communicate with hosts actively employing your stale prefix. >> >> >> that's where rule 5.5 would help (wherever it is actually implemented; >> alas...) > > Yeah.... we did add an explicit pointer to this in the Nodes > Requirements -bis, fwiw (noting RFC 8028). Probably an irrelevant question to ask now :-), but, anyway: any clues why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to me you cannot really do multi-prefix without RFC8028... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 21 08:14: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 B3FFF130F96 for ; Thu, 21 Feb 2019 08:14:53 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK9ttk-SCtTt for ; Thu, 21 Feb 2019 08:14:50 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA216130ED9 for ; Thu, 21 Feb 2019 08:14:49 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id e74so9543175wmg.3 for ; Thu, 21 Feb 2019 08:14:49 -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=BgDJeX4akctREx4c714fsdD0i7Dz6ajgM5qh66SH4NA=; b=AbEel7n0JNVnZn+hABrUDhMHV9UiIetaBJS1JfXzmVwgoPzNQn3tGEhXgDPvsfpQsN olKko4eoivQuqmVKGJOV9S+rYmMWuOaG57s/2kHPHOhUenYxP720rchDQJfMLBfsEqYY qmBBNgWC7Lz+zXnFk5ggsSKzfN+xf0dZr2HO8= 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=BgDJeX4akctREx4c714fsdD0i7Dz6ajgM5qh66SH4NA=; b=gpG6E9PL6ucIme8wAL+Lz0J03n3YjipfKFWzUgMTraE3nO+jvtm16OACvmnb+7poJL ob5UyT1YH9/CR+erMClQ4fBRFZgUckZFUBk1/HJMJuYQOtaKmpK+vMAcZjhUYr7xefo/ uVpEsPtEKUxBNal97LqeP/Qy5RVSaoZi6DRdnZm5yvjksU+zRg/Y9SIQ5mmG9KTfV90u mRhJ0joRP16XHWYyHmjIeHNrCLNqEwpWtp9QWVKaPoLU7TyXOYdcP3ZUJXWAHdg9AEdz ZqN3fXWQzqD8fCUzLPuCRQOXFCik2RIKFvUugc6qy48wTgQoIwm9Fx4B3teS3/TpGRPR KU1A== X-Gm-Message-State: AHQUAuY6QTe5Ypc/mbXGm4cC2EfA2060Y6jHtOiCXXiHsE7GBk6RV4TD lpKG+/cMuG+Pt2Z4IVqCsZyjFWTrJr2KYPUuERnhvg== X-Google-Smtp-Source: AHgI3IanWuKqNwLqRNBuPN0kurLGAV8lKQJGjJMCILtPzCJpRBfb7RR/nGZxpSFvu4agPtTWBmZmmCZbfT1miNKHa8Y= X-Received: by 2002:a1c:48f:: with SMTP id 137mr10402850wme.21.1550765687748; Thu, 21 Feb 2019 08:14:47 -0800 (PST) MIME-Version: 1.0 References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> In-Reply-To: From: Timothy Winters Date: Thu, 21 Feb 2019 11:14:32 -0500 Message-ID: To: Fernando Gont Cc: Tim Chown , "ek@loon.co" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000f2e0b3058269c57e" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 16:14:54 -0000 --000000000000f2e0b3058269c57e Content-Type: text/plain; charset="UTF-8" On Thu, Feb 21, 2019 at 11:12 AM Fernando Gont wrote: > On 21/2/19 07:41, Tim Chown wrote: > >> On 21 Feb 2019, at 02:01, Erik Kline > > >> wrote: > >> > >> On Wed, 20 Feb 2019 at 17:49, Fernando Gont >> > wrote: > >> > >> Hi, Eric, > >> > >> On 20/2/19 22:12, Erik Kline wrote: > >> > > >> > > >> > On Wed, 20 Feb 2019 at 17:07, Fernando Gont > >> > >> > >> > >> wrote: > >> > > >> > On 20/2/19 06:36, Jen Linkova wrote: > >> > [...] > >> > >> Example: > >> > >> > >> > >> Say you have two network interfaces: If1 and If2. > >> > >> Say If1, is configured with 2001:db8:1::/64, and If2 with > >> > 2001:db8:2::/64 > >> > >> > >> > >> Say the first default router is that associated with If1. > >> > >> > >> > >> Say prefix 2001:db8:1::/64 stops being announced, or that > >> you stop > >> > >> receiving RAs on If1, but RAs on If2 keep arriving fine. > >> > >> > >> > >> Based on the logic of your algorithm, one would expect > >> that a new > >> > >> connection uses 2001:db8:2::/64/If2 (since that's the > >> "more recently > >> > >> advertised information). However, Rule #5 would override > >> that and > >> > make > >> > >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes > >> > addresses on > >> > >> the outgoing interface. > >> > > > >> > > I'm even more confused now, sorry ;(( > >> > > >> > I was referring to the fact that some of the previous rules > >> might > >> > prevent the evaluation of the rule about freshness. e.g.: > >> > > >> > * You have two network interfaces eth0 and eth1 (say each > >> connected to a > >> > different ISP) > >> > * eth0 has stopped receiving RAs > >> > * eth1 receives RAs as usual (hence all info associated with > >> this > >> > interface is "fresher" than than corresponding to eth0) > >> > * The default router employed by eth0 has precedence > >> (whether because it > >> > had a higher preference value, because it was the first > >> one that was > >> > learned, or whatever) > >> > * When you evaluate the rules in RFC6724, rule 5 will say > >> that the > >> > outgoing interface will be eth0, and thus you should pick > >> an address > >> > associated with it --- however, as noted above, the > >> addresses on eth1 > >> > are fresher than those from eth1. > >> > > >> > > >> > Not receiving multicast RAs is not a condition you can really > >> take any > >> > action on. > >> > >> Agreed. > >> > >> The main issue I see with incorporating an explicit rule in RFC6724 > >> about "freshness" is that in multi-prefix scenarios, it's guaranteed > >> that the default SA will oscillate among the different prefixes, and > >> that if you only implement this workaround, you wouldn't be able to > >> communicate with hosts actively employing your stale prefix. > >> > >> > >> that's where rule 5.5 would help (wherever it is actually implemented; > >> alas...) > > > > Yeah.... we did add an explicit pointer to this in the Nodes > > Requirements -bis, fwiw (noting RFC 8028). > > Probably an irrelevant question to ask now :-), but, anyway: any clues > why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to me you > cannot really do multi-prefix without RFC8028... > My memory of this was the working group wasn't convinced that every node needed to support it. > > -- > 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 > --000000000000f2e0b3058269c57e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 21, 2019 at 11:12 AM Fern= ando Gont <fgont@si6networks.co= m> wrote:
On 21/2/19 07:41, Tim Chown wrote:
>> On 21 Feb 2019, at 02:01, Erik Kline <ek@loon.co <mailto:ek@loon.co>>
>> wrote:
>>
>> On Wed, 20 Feb 2019 at 17:49, Fernando Gont <fgont@si6networks.com
>> <mailto:fgont@si6networks.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Hi, Eric,
>>
>>=C2=A0 =C2=A0 =C2=A0On 20/2/19 22:12, Erik Kline wrote:
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> On Wed, 20 Feb 2019 at 17:07, Fernando Gon= t
>>=C2=A0 =C2=A0 =C2=A0<fgont@si6networks.com <mailto:fgont@si6networks.com>
>>=C2=A0 =C2=A0 =C2=A0> <mailto:fgont@si6networks.com <mailto:fgont@si6networks.com&= gt;>>
>>=C2=A0 =C2=A0 =C2=A0wrote:
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On 20/2/19 06:36, Jen L= inkova wrote:
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[...]
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Example:
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Say you have t= wo network interfaces: If1 and If2.
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Say If1, is co= nfigured with 2001:db8:1::/64, and If2 with
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A02001:db8:2::/64
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Say the first = default router is that associated with If1.
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Say prefix 200= 1:db8:1::/64 stops being announced, or that
>>=C2=A0 =C2=A0 =C2=A0you stop
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> receiving RAs = on If1, but RAs on If2 keep arriving fine.
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Based on the l= ogic of your algorithm, one would expect
>>=C2=A0 =C2=A0 =C2=A0that a new
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> connection use= s 2001:db8:2::/64/If2 (since that's the
>>=C2=A0 =C2=A0 =C2=A0"more recently
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> advertised inf= ormation). However, Rule #5 would override
>>=C2=A0 =C2=A0 =C2=A0that and
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0make
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> you employ 200= 1:db8:1::/64/If1, since Rule #5 prioritizes
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0addresses on
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> the outgoing i= nterface.
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> I'm even more = confused now, sorry ;((
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I was referring to the = fact that some of the previous rules
>>=C2=A0 =C2=A0 =C2=A0might
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0prevent the evaluation = of the rule about freshness. e.g.:
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* You have two network = interfaces eth0 and eth1 (say each
>>=C2=A0 =C2=A0 =C2=A0connected to a
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0different ISP)
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* eth0 has stopped rece= iving RAs
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* eth1 receives RAs as = usual (hence all info associated with
>>=C2=A0 =C2=A0 =C2=A0this
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 interface is &qu= ot;fresher" than than corresponding to eth0)
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* The default router em= ployed by eth0 has precedence
>>=C2=A0 =C2=A0 =C2=A0(whether because it
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 had a higher pre= ference value, because it was the first
>>=C2=A0 =C2=A0 =C2=A0one that was
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 learned, or what= ever)
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* When you evaluate the= rules in RFC6724, rule 5 will say
>>=C2=A0 =C2=A0 =C2=A0that the
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 outgoing interfa= ce will be eth0, and thus you should pick
>>=C2=A0 =C2=A0 =C2=A0an address
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 associated with = it --- however, as noted above, the
>>=C2=A0 =C2=A0 =C2=A0addresses on eth1
>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 are fresher than= those from eth1.
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> Not receiving multicast RAs is not a condi= tion you can really
>>=C2=A0 =C2=A0 =C2=A0take any
>>=C2=A0 =C2=A0 =C2=A0> action on.
>>
>>=C2=A0 =C2=A0 =C2=A0Agreed.
>>
>>=C2=A0 =C2=A0 =C2=A0The main issue I see with incorporating an expl= icit rule in RFC6724
>>=C2=A0 =C2=A0 =C2=A0about "freshness" is that in multi-pr= efix scenarios, it's guaranteed
>>=C2=A0 =C2=A0 =C2=A0that the default SA will oscillate among the di= fferent prefixes, and
>>=C2=A0 =C2=A0 =C2=A0that if you only implement this workaround, you= wouldn't be able to
>>=C2=A0 =C2=A0 =C2=A0communicate with hosts actively employing your = stale prefix.
>>
>>
>> that's where rule 5.5 would help (wherever it is actually impl= emented;
>> alas...)
>
> Yeah.... we did add an explicit pointer to this in the Nodes
> Requirements -bis, fwiw (noting RFC 8028).

Probably an irrelevant question to ask now :-), but, anyway: any clues
why RFC8028 is a "SHOULD" rather than "MUST"? -- It wou= ld seem to me you
cannot really do multi-prefix without RFC8028...
My me= mory of this was the working group wasn't convinced that every node nee= ded to support it.=C2=A0 =C2=A0=C2=A0

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




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000f2e0b3058269c57e-- From nobody Thu Feb 21 08:25: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 C4CEF130F96; Thu, 21 Feb 2019 08:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUGa7_QEDgEs; Thu, 21 Feb 2019 08:25:07 -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 3931B130E2E; Thu, 21 Feb 2019 08:25:07 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 DC766848C9; Thu, 21 Feb 2019 17:25:02 +0100 (CET) To: Timothy Winters Cc: Tim Chown , "ek@loon.co" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 21 Feb 2019 13:23:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 16:25:09 -0000 On 21/2/19 13:14, Timothy Winters wrote: [...] > > Probably an irrelevant question to ask now :-), but, anyway: any clues > why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to me you > cannot really do multi-prefix without RFC8028... > > My memory of this was the working group wasn't convinced that every node > needed to support it.    If you support multiple prefixes (all nodes do), then you really need RFC8028. Otherwise it is quite likely that you will be egress-filtered. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 21 12:00: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 4AD84130E57; Thu, 21 Feb 2019 11:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VELXd_jMJS4d; Thu, 21 Feb 2019 11:59:57 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3AE129A87; Thu, 21 Feb 2019 11:59:57 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id l11so2755945pgq.10; Thu, 21 Feb 2019 11:59:57 -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=Jsp9x15MgCtIklmdHiYhrYXtCuHGWAhNqGytTu7YCEs=; b=u5qwc6IRYzKT6cuSjV447aGMBgLaWAOjvAQJmw1lWda9q+CY7QGzDYbGhX8kw2y+qU p3me15VfVZJDWaKdibLcsKf36aYhOiIjinJ3+RCMRZu5EfqbGNLiqtUeznRdRCIkLlbG XhmuyYiwClMJZV6Ar9cNt9gcu4Yq2OmviT2P/g3a+NoJi/7q+LXyt0RKzDzdlWP5G01g Rhe8cb/chNXYpqswZZe4ZETBjRxnRnUeFcz8XrynoZcTh+saoIqarEqLzVKNnbJlD3eS F0CG6zLR2NrKQNLTf2RCdncw5M0cBh4usdNlIbSkRPIOA/n0Kf3JRkzh1O8+pcTNa9JI PJ2A== 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=Jsp9x15MgCtIklmdHiYhrYXtCuHGWAhNqGytTu7YCEs=; b=fuVEmBKa6U9FpMwLenTjOTEIqH6HAnKxqGCjNhm7vzVCFEsDrskGp8w+/RxzOVNMGN 4THQtvSrNDgllwa2stlwT3N2jyxNNm8ga2R6Xqu83PwGCh8NTtHhuuvouZ+//pOogm4T x56O34QSBRDAQniqK3uZD+z2etpVNTSaKBbx8fSa136qZK4H5/b9Nj99PrpyXaqtYo7D msD4YC+seXk4G3KQKzCiO9GGTFwlSU33+YcGd3UUKqMie9y76lS3n10R6ajoWDMh8lih LrHUSBVPPq2vxJYJwIdGp2u13Su4GaHigMhy5dLzNSbXua04ML/Utl503SEqN6+pgnU2 jI6Q== X-Gm-Message-State: AHQUAuZftQZgdbTPsxhvhIom8wgsdyJdj+a6VlKbSPBl+Fey3vyYQeWe mimq4Tn1UakJswTalU27ZGY= X-Google-Smtp-Source: AHgI3Ibpe8EBca7uZ8qxSQ9NWvWI8aN7q+TqK7jGBs1hRXYiTbPDoaNEQVTsNRAJAPkOdMZqpzvlIA== X-Received: by 2002:a62:5249:: with SMTP id g70mr236400pfb.115.1550779196457; Thu, 21 Feb 2019 11:59:56 -0800 (PST) Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id y70sm3301115pgd.6.2019.02.21.11.59.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 11:59:55 -0800 (PST) To: Timothy Winters , Fernando Gont Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "ek@loon.co" References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> From: Brian E Carpenter Message-ID: <0e3a8985-6aa6-e24d-dc83-82f7b5012cc6@gmail.com> Date: Fri, 22 Feb 2019 08:59:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 19:59:59 -0000 On 2019-02-22 05:14, Timothy Winters wrote: > On Thu, Feb 21, 2019 at 11:12 AM Fernando Gont > wrote: > >> On 21/2/19 07:41, Tim Chown wrote: >>>> On 21 Feb 2019, at 02:01, Erik Kline > >>>> wrote: >>>> >>>> On Wed, 20 Feb 2019 at 17:49, Fernando Gont >>> > wrote: >>>> >>>> Hi, Eric, >>>> >>>> On 20/2/19 22:12, Erik Kline wrote: >>>> > >>>> > >>>> > On Wed, 20 Feb 2019 at 17:07, Fernando Gont >>>> >>>> > >> >>>> wrote: >>>> > >>>> > On 20/2/19 06:36, Jen Linkova wrote: >>>> > [...] >>>> > >> Example: >>>> > >> >>>> > >> Say you have two network interfaces: If1 and If2. >>>> > >> Say If1, is configured with 2001:db8:1::/64, and If2 with >>>> > 2001:db8:2::/64 >>>> > >> >>>> > >> Say the first default router is that associated with If1. >>>> > >> >>>> > >> Say prefix 2001:db8:1::/64 stops being announced, or that >>>> you stop >>>> > >> receiving RAs on If1, but RAs on If2 keep arriving fine. >>>> > >> >>>> > >> Based on the logic of your algorithm, one would expect >>>> that a new >>>> > >> connection uses 2001:db8:2::/64/If2 (since that's the >>>> "more recently >>>> > >> advertised information). However, Rule #5 would override >>>> that and >>>> > make >>>> > >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes >>>> > addresses on >>>> > >> the outgoing interface. >>>> > > >>>> > > I'm even more confused now, sorry ;(( >>>> > >>>> > I was referring to the fact that some of the previous rules >>>> might >>>> > prevent the evaluation of the rule about freshness. e.g.: >>>> > >>>> > * You have two network interfaces eth0 and eth1 (say each >>>> connected to a >>>> > different ISP) >>>> > * eth0 has stopped receiving RAs >>>> > * eth1 receives RAs as usual (hence all info associated with >>>> this >>>> > interface is "fresher" than than corresponding to eth0) >>>> > * The default router employed by eth0 has precedence >>>> (whether because it >>>> > had a higher preference value, because it was the first >>>> one that was >>>> > learned, or whatever) >>>> > * When you evaluate the rules in RFC6724, rule 5 will say >>>> that the >>>> > outgoing interface will be eth0, and thus you should pick >>>> an address >>>> > associated with it --- however, as noted above, the >>>> addresses on eth1 >>>> > are fresher than those from eth1. >>>> > >>>> > >>>> > Not receiving multicast RAs is not a condition you can really >>>> take any >>>> > action on. >>>> >>>> Agreed. >>>> >>>> The main issue I see with incorporating an explicit rule in RFC6724 >>>> about "freshness" is that in multi-prefix scenarios, it's guaranteed >>>> that the default SA will oscillate among the different prefixes, and >>>> that if you only implement this workaround, you wouldn't be able to >>>> communicate with hosts actively employing your stale prefix. >>>> >>>> >>>> that's where rule 5.5 would help (wherever it is actually implemented; >>>> alas...) >>> >>> Yeah.... we did add an explicit pointer to this in the Nodes >>> Requirements -bis, fwiw (noting RFC 8028). >> >> Probably an irrelevant question to ask now :-), but, anyway: any clues >> why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to me you >> cannot really do multi-prefix without RFC8028... >> > My memory of this was the working group wasn't convinced that every node > needed to support it. fwiw the text changed from "would therefore be applicable" to "SHOULD" after IESG review of draft-ietf-6man-multi-homed-host-07, and specifically following a comment from Alvaro Retana. I didn't find anything to indicate that we discussed MUST at all. But indeed, nodes that don't support rule 5.5 are at risk from egress filtering. Brian >> >> -- >> 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 > From nobody Thu Feb 21 13:10:44 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 53E991311D1; Thu, 21 Feb 2019 13:10:42 -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 9GuRYNnFWRjg; Thu, 21 Feb 2019 13:10:40 -0800 (PST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 6AFF9130E6E; Thu, 21 Feb 2019 13:10:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1LLAc70008654; Thu, 21 Feb 2019 16:10:38 -0500 Received: from XCH16-01-12.nos.boeing.com (xch16-01-12.nos.boeing.com [144.115.66.70]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1LLAW2m008020 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 21 Feb 2019 16:10:32 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-12.nos.boeing.com (144.115.66.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Thu, 21 Feb 2019 13:10:30 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Thu, 21 Feb 2019 13:10:30 -0800 From: "Manfredi (US), Albert E" To: Gert Doering CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUyRB17V+FnESOAEi8Djm3PcxDpKXpHwZQgACcI4D//4RNUIAAoKWAgACD6gCAAFvVIA== Date: Thu, 21 Feb 2019 21:10:30 +0000 Message-ID: <66d78b87461744128d83eaf09e0b460b@boeing.com> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: <20190221073530.GT71606@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: 6CF9DC8BC226351F56A11AB361627CF9A98EF36588F793A1626BF6B5B6856B4F2000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 21:10:42 -0000 -----Original Message----- From: Gert Doering =20 > NPTv6 does not need state, so no keepalives and battery impact. > > Applications today seem to be all "HTTP(S)" or "QUIC", and they all had t= o learn how to deal with NAPT. New protocols that embed IP addresses are=20 killed by IPv4 NAPT anyway, so that ship has sailed - and everything that doesn't care about embedded IP addresses will nicely work throug NPTv6. That's my feeling about this too. NAPT in IPv4 has solved a lot of the appl= ication issues, and even more than necessary for NPTv6. Plus, we, I mean me= , related to work, have dealt with very many IPv4 "basic" NAT firewalls, fo= r years now, and they are really quite trouble-free. I think that the probl= ems Fernando is concerned about should be manageable with NPTv6. More to the point, I'm not sure how feasible it is, long term, to NOT have = this level of address independence. From my point of view, it has sort of b= ecome part of the culture. Bert From nobody Thu Feb 21 13:14: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 34824130E6E; Thu, 21 Feb 2019 13:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ietzn4oo4iGS; Thu, 21 Feb 2019 13:14:50 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EB01311D4; Thu, 21 Feb 2019 13:14:47 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id s198so34347pgs.2; Thu, 21 Feb 2019 13:14:47 -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=qWUPL2jSVT1qmvq8K6EdMKDnH2odCZuJfc2bFh/cZqM=; b=Ed81vzHHOHT3Pk1iLviTwvP7J5V0P+00wHq9kqJu58ORwT+1M3GYu+uHdvTG2mwvyJ /3CPHC6AThzVXflg3Yfu1PwaLdHy7lHZ6kR5ocb3stdiYCPlq9BRx/Ua5vSQrUnnhoQF HMmEGgIp859gUC1IlEhVWC0ot/68hWqRgRq7NtLlU8lZtVs4A4ua5OThuQp6Ti4Hr+Ar fyeXTO3rBeLQfaiRWcbWui6rnvjvIqnutZ87ND567x7xiomePJfds8bnd1XClpXEm0Uw 1/Cj3AWzHxCLBT88Rq6Dj7I4OyxKl0IhsMw+1g0lNjPskeSK6rrHYGG6wwMjNlEeWFud nHaQ== 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=qWUPL2jSVT1qmvq8K6EdMKDnH2odCZuJfc2bFh/cZqM=; b=rmnEW7gDPnibDb7OsmWcHWgYwOm4jLJVJCY8Kfb8HyoXW1lAiZfws4z+kBY5Slztk2 Vykhx+vREsDwNfs3AEssGRYZ0q+RYz1NTh3cqEtTV7TT1uBm5kZ+LfTtp0Q80zl+EDS3 haC6AF3jJEN5ongkxLLafn8JCBAgLFCThkHkJkehaVgX9yvvO3zplx3+FUNJjA33u3u6 r5fvkmdnrnk08oKRz2ZtyyUv69sLFXMkcJEy9K/JU6LW5C0tQD5vLwdnTu6fCM6jnHWS 8FKeU/JXOJzzaXsphrM2mkMwbEPcO79Czxan89Le6zGnq09+06ZphI5BAVH7pbYQPuac 7Rxw== X-Gm-Message-State: AHQUAuajbzLRkMrx5ErnV4CPGuJE+NBwGgTEOAj3aRyTXSnXpSZ/1Z9y QuoyfDoGbTtahRornGYsNiY= X-Google-Smtp-Source: AHgI3IYV5bZ9cswNx1B0RQoqaA1yJzmvpnKIylePei/plnEuvFs9xNRWaK4Khz8y6KnQYXCX5nWABg== X-Received: by 2002:a63:c503:: with SMTP id f3mr470763pgd.431.1550783686970; Thu, 21 Feb 2019 13:14:46 -0800 (PST) Received: from [130.216.36.44] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.44]) by smtp.gmail.com with ESMTPSA id j8sm31085990pfe.130.2019.02.21.13.14.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 13:14:46 -0800 (PST) To: Fernando Gont , Timothy Winters Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "ek@loon.co" References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> From: Brian E Carpenter Message-ID: <90dd7fee-77cc-3411-7079-60a6edf488d9@gmail.com> Date: Fri, 22 Feb 2019 10:14:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.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] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 21:14:53 -0000 On 2019-02-22 05:23, Fernando Gont wrote: > On 21/2/19 13:14, Timothy Winters wrote: > [...] >> >> Probably an irrelevant question to ask now :-), but, anyway: any c= lues >> why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to = me you >> cannot really do multi-prefix without RFC8028... >> >> My memory of this was the working group wasn't convinced that every no= de >> needed to support it.=C2=A0 =C2=A0=20 >=20 > If you support multiple prefixes (all nodes do), then you really need > RFC8028. Otherwise it is quite likely that you will be egress-filtered.= But as I pointed out, RFC8028 only makes rule 5.5 a SHOULD. It's SHOULDs all the way down. Of course, SHOULD means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed...". In other words, do RFC8028 and Rule 5.5 unless there's a good reason not to. Brian From nobody Thu Feb 21 13:22: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 7D506130EC0; Thu, 21 Feb 2019 13:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUkvjRDlyUXp; Thu, 21 Feb 2019 13:22:53 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86075129B88; Thu, 21 Feb 2019 13:22:53 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id q3so34671pll.4; Thu, 21 Feb 2019 13:22:53 -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=oK+49gRrsCutgwH4VxKdDbTMKwzqK0z9x7j2yLNQz88=; b=B/ayzzt08+iTj5MoWnHWQ2PWUJfrjWhcLVnYkGNubQ57XLmpwpw4bz/qGMOkjfZC2N 7rpsVpNY+OIJIkXYNCC5X+MeOz3AqEQk0y2/+qlTV71SOi028oXJMu2CI/IJiDNQSRfA +HQhn5Tz+7cGNXxNF3n2E5AFfl1SNTazm+/aMmhUy6l4Tj2PqL+MbxGgXkXv+/tP7r2U 3Cw2BWPRtuGnjW2oK9XU+4VC9TriCoI2fhAd6ecwe9z+7Ks4NNqBLFcAu7/QWY2/Qng/ z8U8yoksuY42fwCcUVP0n5OSSKbNEwfZHPv6zmnOGZJJsaoH96jd7NQrSx/fZGlwEcGn b5aQ== 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=oK+49gRrsCutgwH4VxKdDbTMKwzqK0z9x7j2yLNQz88=; b=m3axXoi3oLqejpqhFzqTGsGimoy9bIrvaht08GQCCkj1cJiuTiAcp5XmmeGs6Ei3jV 8hPB7Cnepd/4BJU7yp+BZygc7+/nXPWaYJ2/p2H31QvvaOZ3C3Mc26dbsr3SskxrQOj7 bZB0k+mz5NSFxhj1pqhkiazZtUsRYBrKZKIE0X3hgJ56QUoWjYfDKTe55sRkrE06DJ07 KrlAW0RGmPR/JLaohoMEyM4ERM0nuRUyOgRgsIcW9tLjdmJ4rMBRCoN1xG+amPaIz3G0 Jxs+gntsG8gr7pqx3p6hAGWuczm9vsL27vwRWzgetoE1D3Mz5F8cCQGy9xf61Apxhmeq K5fQ== X-Gm-Message-State: AHQUAuYiPRwHBZIppUJhrxQSBbX4ja+1u4dqz5lIYzrjL9P0OGwuTxl8 gDsqT8y4yZDAX57JCrjaEyZbfMmO X-Google-Smtp-Source: AHgI3IaAxkWXn06cyuDYNQBd4AG0rGInstabFsA0ZhK4wavtFbxJ9u4GkW/HhgjJmF6fj7rbLdRkrA== X-Received: by 2002:a17:902:8d97:: with SMTP id v23mr599458plo.274.1550784172662; Thu, 21 Feb 2019 13:22:52 -0800 (PST) Received: from [130.216.36.44] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.44]) by smtp.gmail.com with ESMTPSA id f3sm1453815pfn.100.2019.02.21.13.22.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 13:22:51 -0800 (PST) To: "Manfredi (US), Albert E" , Gert Doering Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <66d78b87461744128d83eaf09e0b460b@boeing.com> From: Brian E Carpenter Message-ID: <458d39d6-e971-59b4-022c-def58e061343@gmail.com> Date: Fri, 22 Feb 2019 10:22:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <66d78b87461744128d83eaf09e0b460b@boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 21:22:56 -0000 On 2019-02-22 10:10, Manfredi (US), Albert E wrote: > -----Original Message----- > From: Gert Doering > >> NPTv6 does not need state, so no keepalives and battery impact. >> >> Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to > learn how to deal with NAPT. New protocols that embed IP addresses are > killed by IPv4 NAPT anyway, so that ship has sailed - and everything that > doesn't care about embedded IP addresses will nicely work throug NPTv6. > > That's my feeling about this too. NAPT in IPv4 has solved a lot of the application issues, and even more than necessary for NPTv6. Plus, we, I mean me, related to work, have dealt with very many IPv4 "basic" NAT firewalls, for years now, and they are really quite trouble-free. I think that the problems Fernando is concerned about should be manageable with NPTv6. > > More to the point, I'm not sure how feasible it is, long term, to NOT have this level of address independence. From my point of view, it has sort of become part of the culture. Applications that recover smoothly from unexpected transport failures, including unexpected address failures or even unexpected changes between IPv6 and IPv4, have also become part of the culture. Masking NAPT glitches is only one of the things they do. In fact, they conceal NAPT glitches in most cases: we just have the odd RESTful transaction that fails from time to time with no explanation. Brian From nobody Thu Feb 21 13:40: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 3DCA7131234; Thu, 21 Feb 2019 13:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn50XIVolzc0; Thu, 21 Feb 2019 13:40:37 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C23131233; Thu, 21 Feb 2019 13:40:37 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id i5so86421oto.9; Thu, 21 Feb 2019 13:40:37 -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=HXBZ+Ym3uauIdzOkh+5/+UuurFKIYsOXlf7ys7Xmeio=; b=G6zmiLedu1R98xH/VqwrWMZeQmGe2rwVeZVocd7pqq8OuywLg0TptCfA1T/GeNhTD8 ErLVgRY7/GyHvjnCzTSD/Q1s7hE3O9f7sRigPbO9IuUvzS4H8YqcpllbmE/MEoxbYeIl ZYNl1RQfSNtQKs48qTcco8ryhTwmf5THak81/ih8bo4HSCm4fbp9XkYvkXNVaDnd10U2 K0HbsvXDzrAgdXHcA5LkoMN18UucMhzKWqGuCLOYWUf4kIrk0G+9SNyQs83mGgLv2Ds4 g5NJ5ZSgYYXkhA6SHB/b1Yk0wr8YJi2wxfnkYhZlNV35l2eTVdA2ovsrBqKrIeRBPZPF y0zw== 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=HXBZ+Ym3uauIdzOkh+5/+UuurFKIYsOXlf7ys7Xmeio=; b=VK+37FfzU830u42iZNBcIT+R0Zk7RbX/3OsfjKgnynpx5tGe+JQYuzA7fk7eb6Ez28 MPBXti7H89pzoAQRZZxCpV5I46ObWFUoCDrcMgdOcbgvIHHM0SgcBbh5QIMfnzNMNRaf d60Vk84w4ZXAPnJYFbDe183cPs1vy+apz/gc1P1fuKro7mlqDOGW7mMTqy1+6Q79HBNC u1qVCHqeg1yFsLxWHk6Frsq30Rm+LGIhfp2y4xQ8hpw7HgNiROH63FSAovbivL2yJLJ6 yoPI3s3yLt0SY8Bbp+IrZmSbPLkOo1o0PnHXqdmyXlPYr22oJadfLRAZuQVF3XEY5kDt q84g== X-Gm-Message-State: AHQUAuYmyBIlosYhnJxR2WFERTRK4oEFYFYuIshBTMcHhMXUW87U7GkN /bpzC8HYf0NVWzMY2xi7JNMzjNhU/Xfp9oxaKqg= X-Google-Smtp-Source: AHgI3IZrwk+EnzYfYK75h5MIqqmA1/6EeXdFRXQxNZQIXgTWAQ1ZFGnfNBeFS0hwf1B50N/lAaOBScRZl21dQcV0VVE= X-Received: by 2002:a9d:6394:: with SMTP id w20mr551234otk.72.1550785236493; Thu, 21 Feb 2019 13:40:36 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: <20190221073530.GT71606@Space.Net> From: Mark Smith Date: Fri, 22 Feb 2019 08:40:24 +1100 Message-ID: To: Gert Doering Cc: Lorenzo Colitti , "Manfredi, Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000024eaa505826e53cd" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 21:40:39 -0000 --00000000000024eaa505826e53cd Content-Type: text/plain; charset="UTF-8" On Thu., 21 Feb. 2019, 18:36 Gert Doering, wrote: > Hi, > > On Thu, Feb 21, 2019 at 08:43:21AM +0900, Lorenzo Colitti wrote: > > Because the advantages are for network operators have corresponding > > disadvantages for application developers and thus for users. Application > > complexity and brittleness due to NAT traversal. Battery impact of NAT > > keepalives. Higher-latency due to relaying and rendezvous. And so on. > > NPTv6 does not need state, so no keepalives and battery impact. > > Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to > learn how to deal with NAPT. New protocols that embed IP addresses are > killed by IPv4 NAPT anyway, so that ship has sailed - Getting it back in IPv6 is one of the things I hope we can get. That's because applications that would be best performing, most robust and more secure with a peer-to-peer communications model are forced to adopt an absolute client-server model (where the server is a much more likely performance bottleneck, the server becomes a SPOF for all clients using it at the time, and the server is a natural interception point for a malicious server operator). Being forced to use a client-server communications model is like going to a birthday party and having everybody have to conduct all of their conversations via the birthday girl or boy, rather than directly with any of the other attendees. Another analogy to show the significance is that with NAT in the telephone network, it wouldn't be possible for me to give you this phone's number to call me. Would any of us accept that constraint on the usability of our phones? Regards, Mark. and everything that > doesn't care about embedded IP addresses will nicely work throug NPTv6. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000024eaa505826e53cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu., 21 Feb. 2019, 18:36 Gert Doering, <gert@space.net> wrote:
Hi,

On Thu, Feb 21, 2019 at 08:43:21AM +0900, Lorenzo Colitti wrote:
> Because the advantages are for network operators have corresponding > disadvantages for application developers and thus for users. Applicati= on
> complexity and brittleness due to NAT traversal. Battery impact of NAT=
> keepalives. Higher-latency due to relaying and rendezvous. And so on.<= br>
NPTv6 does not need state, so no keepalives and battery impact.

Applications today seem to be all "HTTP(S)" or "QUIC", = and they all had to
learn how to deal with NAPT.=C2=A0 New protocols that embed IP addresses ar= e
killed by IPv4 NAPT anyway, so that ship has sailed -


Getting it back in IPv6 is one of the things I hope we can get.

That's because applications t= hat would be best performing, most robust and more secure with a peer-to-pe= er communications model are forced to adopt an absolute client-server model= (where the server is a much more likely performance bottleneck, the server= becomes a SPOF for all clients using it at the time, and the server is a n= atural interception point for a malicious server operator).

Being forced to use a client-server c= ommunications model is like going to a birthday party and having everybody = have to conduct all of their conversations via the birthday girl or boy, ra= ther than directly with any of the other attendees.
=
Another analogy to show the significance is tha= t with NAT in the telephone network, it wouldn't be possible for me to = give you this phone's number to call me. Would any of us accept that co= nstraint on the usability of our phones?=C2=A0

<= /div>
Regards,
Mark.


and everything that
doesn't care about embedded IP addresses will nicely work throug NPTv6.=

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvors.: A.= Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: DE8131= 85279
_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000024eaa505826e53cd-- From nobody Thu Feb 21 13:53: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 6114B13125D for ; Thu, 21 Feb 2019 13:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOlfUB875PGB for ; Thu, 21 Feb 2019 13:53:05 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0C6131238 for ; Thu, 21 Feb 2019 13:53:05 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 258B540AD6 for ; Thu, 21 Feb 2019 22:53:03 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 040FF40084; Thu, 21 Feb 2019 22:53:03 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id DDE14B85B4; Thu, 21 Feb 2019 22:53:02 +0100 (CET) Date: Thu, 21 Feb 2019 22:53:02 +0100 From: Gert Doering To: Mark Smith Cc: Gert Doering , Lorenzo Colitti , "Manfredi, Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: <20190221215302.GU71606@Space.Net> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vOedOGAU6TSXepIO" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.11.2 (2019-01-07) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 21:53:14 -0000 --vOedOGAU6TSXepIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Feb 22, 2019 at 08:40:24AM +1100, Mark Smith wrote: > > Applications today seem to be all "HTTP(S)" or "QUIC", and they all had= to > > learn how to deal with NAPT. New protocols that embed IP addresses are > > killed by IPv4 NAPT anyway, so that ship has sailed - >=20 > Getting it back in IPv6 is one of the things I hope we can get. >=20 > That's because applications that would be best performing, most robust and > more secure with a peer-to-peer communications model are forced to adopt = an > absolute client-server model (where the server is a much more likely > performance bottleneck, the server becomes a SPOF for all clients using it > at the time, and the server is a natural interception point for a malicio= us > server operator). Have you looked out there recently? None of the big actors in the market seem to have any particular interest in moving away from a "we are the clou= d=20 content players, you are just visiting clients" model. (The gaming industry has, to some extent, but that doesn't seem to be a really strong driver) [..] > Another analogy to show the significance is that with NAT in the telephone > network, it wouldn't be possible for me to give you this phone's number to > call me. Would any of us accept that constraint on the usability of our > phones? When did you do the last phone call on your mobile tablet-like computer=20 thingie? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --vOedOGAU6TSXepIO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlxvHbwACgkQ31bAZeTO f8UawA//eqWz9+LrhGcBGyPBLEpe3HeCK9PzBB+Dghsyyoe6aHNtVjcm3lKHC4DS stg07tt1LaG9PSBPmm2tsmr4ZbbeGVQn0Y+JckE7hZUgy9Nrm+1Y8nTW759vd3OU gFbpF+4XV1CQ7B0EofOzPmXOACOLqy+008/T+WPjOvnHnlp4bChrSCDti/hkUGiv qPNZK3RrKtt+PeIpdVfgqqraJ6s2QRvdG0BTj2PIS8xdJJPHgealTNoG+bJkOvSQ cSWEPP/0xUF5g7gNdfiskMQIHVcFPUceVnQg2m82zQziqOibHESD4n2HidesNXrB TAkNxxmaBzqp9E3OcuHaviMOclGaz3WTkYrUBC+imEBYVEGPo6VJ9ZcigU7K880X JWifc5VMtZzz1n0pLY8EzuJrOcfArenhfjIsLSNbKp1/yDqcO1ZGMS/ncdmmi/iV qGXbg3jsUXlQ1ovTwQg5EHhmaczEfDUj/HP3CgGt8nqYBQlXKI6LKaigosAsiaDX kDhXSb22lCmy7i+/nzMIyeb4WQujW8f/325Meltxnh+en2L9m3pije038jFMtB+g DFzBC+ZJyppxqsd6kD4LnlnBSGSNopL+tXCJjgCWldQAf8fO34LqUPit4t7fm3WV +L3kqB6Mv2uKzi5R3L29U6zm/pah/1c+4l1EQFaBrZaVAgzu7Pg= =aMpb -----END PGP SIGNATURE----- --vOedOGAU6TSXepIO-- From nobody Thu Feb 21 13:54: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 CF243131288; Thu, 21 Feb 2019 13:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byRRVw3gVnel; Thu, 21 Feb 2019 13:53:51 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 B5887131271; Thu, 21 Feb 2019 13:53:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1LLrn04000836; Thu, 21 Feb 2019 16:53:49 -0500 Received: from XCH16-01-10.nos.boeing.com (xch16-01-10.nos.boeing.com [144.115.66.5]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1LLrcZn031665 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 21 Feb 2019 16:53:38 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-10.nos.boeing.com (144.115.66.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Thu, 21 Feb 2019 13:53:37 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Thu, 21 Feb 2019 13:53:37 -0800 From: "Manfredi (US), Albert E" To: Mark Smith CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUyRB17V+FnESOAEi8Djm3PcxDpKXpHwZQgACcI4D//4RNUIAAoKWAgACD6gCAAOwQAP//fLQw Date: Thu, 21 Feb 2019 21:53:37 +0000 Message-ID: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: EB9BDEB75AF89DC6719C652833DF542621F9A6A51592034E08CF686329790DB02000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 21:53:59 -0000 RnJvbTogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT4gDQoNCj4gVGhhdCdzIGJl Y2F1c2UgYXBwbGljYXRpb25zIHRoYXQgd291bGQgYmUgYmVzdCBwZXJmb3JtaW5nLCBtb3N0IHJv YnVzdCBhbmQgbW9yZSBzZWN1cmUgd2l0aCBhIHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9ucyBt b2RlbCBhcmUgZm9yY2VkIHRvIGFkb3B0IGFuIGFic29sdXRlIGNsaWVudC1zZXJ2ZXIgbW9kZWwg KHdoZXJlIHRoZSBzZXJ2ZXIgaXMgYSBtdWNoIG1vcmUgbGlrZWx5IHBlcmZvcm1hbmNlIGJvdHRs ZW5lY2ssIHRoZSBzZXJ2ZXIgYmVjb21lcyBhIFNQT0YgZm9yIGFsbCBjbGllbnRzIHVzaW5nIGl0 IGF0IHRoZSB0aW1lLCBhbmQgdGhlIHNlcnZlciBpcyBhIG5hdHVyYWwgaW50ZXJjZXB0aW9uIHBv aW50IGZvciBhIG1hbGljaW91cyBzZXJ2ZXIgb3BlcmF0b3IpLg0KDQpFdmVuIGlmIGl0J3Mgb25s eSB0aGUgcHJlZml4IHRoYXQgY2hhbmdlcz8gSSBkb27igJl0IGdldCB0aGF0LiBQZWVyIHRvIHBl ZXIgY2FuIGJlIG1hZGUgdG8gd29yayB0aGVyZSB0b28uIEkgYWdyZWUgaWYgeW91J3JlIHRhbGtp bmcgYWJvdXQgTkFQVCwgdGhvdWdoLiBUaG9zZSBiYXNpYyBOQVQgZmlyZXdhbGxzIEkgYWxsdWRl ZCB0byBwcmV2aW91c2x5IHN1cHBvcnQgcGVlci1wZWVyIHF1aXRlIG5pY2VseS4NCg0KQmVydA0K From nobody Thu Feb 21 14:46: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 D7882130E68; Thu, 21 Feb 2019 14:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAt7reX8iDwA; Thu, 21 Feb 2019 14:46:31 -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 3CAE0129C6A; Thu, 21 Feb 2019 14:46:31 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id v20so249338otk.7; Thu, 21 Feb 2019 14:46:31 -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:content-transfer-encoding; bh=wYjo3Zm0XG2nzxHWBGVrjRQ2TKZeBO+OIHTsxTOxZCo=; b=n/OBIn6VfHeH+baC8DizNbaE9SsExuWvyfWUykCUlIsPPpDmSi+zrwMF9sNsXjx88N 47E39gS0h4YfHnO1dxzzNbbZ1Q89FhWKUYYX0NYXra2eG7Gxvhh3BdapcP2BaSLTFZ/n ewEjgZZIoEEHydIFefa0KjZmo6Y8fS9+/k9xb9x7FSffs48JFUyOcWLOi24K7T2V7ZoH IJIJFvo4tl9TXDCCzSY+J5HuJi1Qwx9qj6OAMoQP3VEb1AbYc5Dr89C34VU3x7dINODk CYoGwWJD+2K7SO1lGAIaZx349weYCugyl5PQkOBwP9D99lOljKaqqEGFotdp20n0tdsh XerA== 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:content-transfer-encoding; bh=wYjo3Zm0XG2nzxHWBGVrjRQ2TKZeBO+OIHTsxTOxZCo=; b=Ixwse4F/PiP0pvCw6IbSt2PqstKXoyexd/wfQiB/FfqEWQCPjZqVB0Wxd3ZcQ/Ioll WaCMFU8btFy8CYDscDeCqnaXgwZ1Ntakzt+gL8WHJ/VTs0Zq+5PfKQxZuj92p//YpXwz qNwuPJcADl8Hh9PeJHUXIZxe4phYHlfQ0+HzasWyOF/F0zfsFXrGvoagA+Zixz27JbRL Eu0jjU0Xbi9NuMmJQ5D/Jp5xASazibGN0uzuBiQFsL6A2oWeRnv5xQD3UncoJbQ/9lcP Q1oMrPXiTOPzLGazndc/Xs8vx+YKHakCwwif8t/Z9XxDz+bhJwnbWBKcwZ0LkGGu937f cXsg== X-Gm-Message-State: AHQUAuaRz/YhHbmPbshYE8BMcW6qPUs9cAkd4k4hI0huYxISmKzOyb6f AgtPASzZukHQJurmYYT0VEm/KtdwswNNGxPwsDQ= X-Google-Smtp-Source: AHgI3IaKOEpLXRGRF+lj3FNe6G2nXPbJMfE1qqIHzrxco1C+atMS3DrK7iQYWFIVboCE4KK+Q1hMwNLK8Oe5nJEdb+E= X-Received: by 2002:a9d:6d0c:: with SMTP id o12mr697714otp.256.1550789190272; Thu, 21 Feb 2019 14:46:30 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Mark Smith Date: Fri, 22 Feb 2019 09:46:03 +1100 Message-ID: To: "Manfredi (US), Albert E" Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 22:46:33 -0000 On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E wrote: > > From: Mark Smith > > > That's because applications that would be best performing, most robust = and more secure with a peer-to-peer communications model are forced to adop= t an absolute client-server model (where the server is a much more likely p= erformance bottleneck, the server becomes a SPOF for all clients using it a= t the time, and the server is a natural interception point for a malicious = server operator). > > Even if it's only the prefix that changes? I don=E2=80=99t get that. Peer= to peer can be made to work there too. "made to work" implies work arounds. The IP layer has a peer to peer nature - any node should be able to directly send to any other node, just by having the other node's address. If a device has to send it's packets through a third party to reach the actual party it wishes to communicate with, it isn't a peer of the latter party. It is now a client of the middle relay party. This isn't the place to rehash the NAT discussion (because IPv6 + NAT doesn't provide any benefits over IPv4 + NAT, and that makes IPv6 pretty much pointless.) Have a look at the following presentation on NAT from a few years ago, where I think I did something different to other NAT presentations - I compared NAT to what I describe as a network operator's "Network Critical Success Factors". Any questions/comments, we can discuss off-list. "The Trouble with NAT (Or why I care about IPv6)" https://www.ausnog.net/sites/default/files/ausnog-2016/presentations/1.2_Ma= rk_Smith_AusNOG2016.pdf (APNIC asked me to write up a few blog articles on it if you want a longer read - https://blog.apnic.net/author/mark-smith/) > I agree if you're talking about NAPT, though. Those basic NAT firewalls I= alluded to previously support peer-peer quite nicely. > So I think there's commonly a big different between works and works well. NAT may work, however compared to stateless IPv6 (and IPv4) forwarding, it doesn't work anywhere as near as well. Regards, Mark. > Bert From nobody Thu Feb 21 15:04: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 6112F128701 for ; Thu, 21 Feb 2019 15:04:41 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 RumeGgQcsaSH for ; Thu, 21 Feb 2019 15:04:38 -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 B1C25129AA0 for ; Thu, 21 Feb 2019 15:04:38 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id w4so450464qtc.1 for ; Thu, 21 Feb 2019 15:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2CsenjAgXktK2dLwLpzCDv3w0ldn8pu8mK3DNPvDEBQ=; b=rfvA/Y32kg/MnMF0kVP4OLZraOjJC9aE1OP/R5Dmuh9dag7gjNVNlW11Tqccoq5OVd pXksiyKU/zx3krBcbhyS2XVDMnaqjhjs+/D+fr5GMpwwu6WbpiyZPcfNcogKtXRyoeUI k4YHVYBYlfVePaKzbXTLjjvTy2+Wve+YMsZZoK2+K6VHPDU1TaLrxJ6vCmEWjJ/UCOJm xZjYggc5QA687EOyJnzrLfnY/LesrsiZC5nRmdpk5hMsW4+UWEiQsO2p2iZf36RSmEx9 MO6D+Rbds0j1+9oXMAz9+uu97LBUYkCUbaVw1ThNb1lrgtt0RQ/5CC0BF6visJsPL8IK n54w== 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:content-transfer-encoding; bh=2CsenjAgXktK2dLwLpzCDv3w0ldn8pu8mK3DNPvDEBQ=; b=A97R3+DOHrzGLILkXfBsJCbHDcnPFuzRO5C0VXmdOqWD44OL7pFqFQN5bAdjUq1yqp 7qzB2FLzpLt9ueoVz8KRbbtImtk6YbFcLJAWwdvpNPxOQRJQ1H+JQAp2vo4KTgJWZ6nf mrAN2c/mFe0oqKp7opjYaROKJw8Q/dUSpQT/fDUPbI0yzZBAyBMYsS/2wjAEb86tyCHT /h0TyeldUL1zeY7+8WL5cIfN+bFi8q2FbS6pFQlx0DoLpYRuw4RA1AsxHwK8fWpSMaPP IFpNFFoA7a6XCTeLVz4ZB9ORUm5l0UFXg2bLd7ycmmgnUeEAjH5xlUnmNszKDNlJkv2+ hFmw== X-Gm-Message-State: AHQUAuYJLQ8VR93MHZll0CZkezgArH86qiQ74NwV/v3Kvisek5csvw3n JTBXesKbKsWivcqFYOA38kovezUYqx3ICv7SwZWoSw== X-Google-Smtp-Source: AHgI3IbyaAxvcLDj8GLeSQSwvd71mAbqvPHgAIfPmvQK3sraEEBMj7vTPt9GFfpWjefNTQyX2P/baK1mWX+3041NyWs= X-Received: by 2002:a37:7885:: with SMTP id t127mr766167qkc.323.1550790277460; Thu, 21 Feb 2019 15:04:37 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Tom Herbert Date: Thu, 21 Feb 2019 15:04:26 -0800 Message-ID: To: Mark Smith Cc: "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 23:04:41 -0000 On Thu, Feb 21, 2019 at 2:46 PM Mark Smith wrote: > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E > wrote: > > > > From: Mark Smith > > > > > That's because applications that would be best performing, most robus= t and more secure with a peer-to-peer communications model are forced to ad= opt an absolute client-server model (where the server is a much more likely= performance bottleneck, the server becomes a SPOF for all clients using it= at the time, and the server is a natural interception point for a maliciou= s server operator). > > > > Even if it's only the prefix that changes? I don=E2=80=99t get that. Pe= er to peer can be made to work there too. > > "made to work" implies work arounds. The IP layer has a peer to peer > nature - any node should be able to directly send to any other node, > just by having the other node's address. If a device has to send it's > packets through a third party to reach the actual party it wishes to > communicate with, it isn't a peer of the latter party. It is now a > client of the middle relay party. > > This isn't the place to rehash the NAT discussion (because IPv6 + NAT > doesn't provide any benefits over IPv4 + NAT, and that makes IPv6 > pretty much pointless.) > > Have a look at the following presentation on NAT from a few years ago, > where I think I did something different to other NAT presentations - I > compared NAT to what I describe as a network operator's "Network > Critical Success Factors". Any questions/comments, we can discuss > off-list. > > "The Trouble with NAT (Or why I care about IPv6)" > https://www.ausnog.net/sites/default/files/ausnog-2016/presentations/1.2_= Mark_Smith_AusNOG2016.pdf > > (APNIC asked me to write up a few blog articles on it if you want a > longer read - https://blog.apnic.net/author/mark-smith/) > > > > I agree if you're talking about NAPT, though. Those basic NAT firewalls= I alluded to previously support peer-peer quite nicely. > > > > So I think there's commonly a big different between works and works > well. NAT may work, however compared to stateless IPv6 (and IPv4) > forwarding, it doesn't work anywhere as near as well. > Mark, I agreee with that with one exception. I believe that NAT/IPv4 can offer better privacy in addressing than IPv6 given current addess allocation methods. Tom > Regards, > Mark. > > > > > Bert > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 21 15:22: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 8DFF11312BF; Thu, 21 Feb 2019 15:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWeXmJrM1NuF; Thu, 21 Feb 2019 15:22:26 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C271312A0; Thu, 21 Feb 2019 15:22:26 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id w66so312198oia.4; Thu, 21 Feb 2019 15:22:26 -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:content-transfer-encoding; bh=ChN/gHDVJEGm/TymHMIFv609NfvHnFRBBdxGX65VUzU=; b=fcQ3H2YScQjg90uS0pP2o5uhrnYkhIBdTXtoGAZvgvYh7WgLRKCGwd2uiMsmbmp0Kx vuHfr75QP+i7naLOLMGBPDEv56oooBbGiR4/zIlMyRl+n+rWad2sXtFjSJSNzhCUc/PJ rFaS9QFELc9LXC+HItozpMSi9YEPV5IVv7Vt0ukczr0rWnm01Wbb14NZgDLM8LDMzHan GK2xF4tPC0a1DJQvappOG8FxEdsrL9HRP6T/zDTpk5NmHG3JVWh5ZSZrc8WwMjkjS3/j jn9Qspu2ploEgUyBlHp24LsLW2nfTvZ4N452GbMJckfbE9qW2rCLAU6hu8Mm1eQsVOaP nSqw== 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:content-transfer-encoding; bh=ChN/gHDVJEGm/TymHMIFv609NfvHnFRBBdxGX65VUzU=; b=kZ0pB+A5ScbM7Zvuew+Fk2JdIczX4uW1ELd7ORtgXJ2+bdtwQ21ybLrqDQGlMA17fr u4y8agJqVytzTRYBA6CPH6rZF+gc9aeSOsSDlVeRiNKYXgcdOcf9n37gVdFWjJhtf+fH gdoAUyWZBR60O+cFOxgZ14LPDz3qHHH7+uY/k7EKQbkNoFkdu1qSrCio8vmqaqqXcx9j 7+KmkYZHQtK0jj+MszmTZ0cAo5/QG0lKz1VGVHcHW9Ma57fBLINnIHbgTqDOrxNDaWaq dvhP7RnnqQDAdY8J+T6WIAUAAfWc6AMxFV95/l3Yd0r/X8KcIyBimXnFxmPLCdNIP6Gr 4qrA== X-Gm-Message-State: AHQUAubcbUmrjwCaDHYF4ZdEm24Kw9oklVEPPfIN7y0PzT4BmRYO3w3r mHed7ILixqwJwGQK2R3Mqfj214K1zFPkWTIxrDo= X-Google-Smtp-Source: AHgI3IaEMPHrGqwi7pT+6F1aRMnzcKE3Rmjeuyhc+oL6II2Rt6fNWFUUunfyuwXV6zGCvrOEJqJaQyBoLRBxwXahFTo= X-Received: by 2002:aca:ed06:: with SMTP id l6mr695987oih.7.1550791345209; Thu, 21 Feb 2019 15:22:25 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <20190221215302.GU71606@Space.Net> In-Reply-To: <20190221215302.GU71606@Space.Net> From: Mark Smith Date: Fri, 22 Feb 2019 10:21:58 +1100 Message-ID: To: Gert Doering Cc: Lorenzo Colitti , "Manfredi, Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 23:22:32 -0000 On Fri, 22 Feb 2019 at 08:53, Gert Doering wrote: > > Hi, > > On Fri, Feb 22, 2019 at 08:40:24AM +1100, Mark Smith wrote: > > > Applications today seem to be all "HTTP(S)" or "QUIC", and they all h= ad to > > > learn how to deal with NAPT. New protocols that embed IP addresses a= re > > > killed by IPv4 NAPT anyway, so that ship has sailed - > > > > Getting it back in IPv6 is one of the things I hope we can get. > > > > That's because applications that would be best performing, most robust = and > > more secure with a peer-to-peer communications model are forced to adop= t an > > absolute client-server model (where the server is a much more likely > > performance bottleneck, the server becomes a SPOF for all clients using= it > > at the time, and the server is a natural interception point for a malic= ious > > server operator). > > Have you looked out there recently? None of the big actors in the market > seem to have any particular interest in moving away from a "we are the cl= oud > content players, you are just visiting clients" model. > Generally it's in their business interests not to. However, just like everybody else, they don't have a choice anyway, even if they wanted to with IPv4 because of NAT. Still, there are lots of little actors, and a peer-to-peer model can allow them to scale their application without having to spend massive amounts on server infrastructure (physical or virtual.) > (The gaming industry has, to some extent, but that doesn't seem to be > a really strong driver) > Something significant happened in that regard recently. "IPv6 on Xbox One" https://support.xbox.com/en-US/xbox-one/networking/ipv6-on-xbox-one "And=E2=80=94most useful for Xbox=E2=80=94the expansion removes the need fo= r Network Address Translation (NAT), which can interfere with multiplayer gaming and chat over IPv4 networks." "..., for the best possible experience, we recommend enabling IPv6 on your network." > [..] > > Another analogy to show the significance is that with NAT in the teleph= one > > network, it wouldn't be possible for me to give you this phone's number= to > > call me. Would any of us accept that constraint on the usability of our > > phones? > > When did you do the last phone call on your mobile tablet-like computer > thingie? Sunday (and I need to get back to my Uncle since). Previous weeks a number of them organising a trip and updating expired credit card number details. I'll observe that you've still got your phone number in your email signature below, so being able to convey your globally unique phone number and receive calls to it isn't yet obsolete. Regards, Mark. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael = Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Feb 21 15:44: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 98CD3130EA0; Thu, 21 Feb 2019 15:44:52 -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_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 lQTXJy56xeIm; Thu, 21 Feb 2019 15:44:49 -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 C5233130E8B; Thu, 21 Feb 2019 15:44:49 -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 0B3B03AB043; Thu, 21 Feb 2019 23:44:49 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EA07E160050; Thu, 21 Feb 2019 23:44:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D2DD9160073; Thu, 21 Feb 2019 23:44:48 +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 re0Drz9UhfyW; Thu, 21 Feb 2019 23:44:48 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 8CB90160050; Thu, 21 Feb 2019 23:44:47 +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: Fri, 22 Feb 2019 10:44:45 +1100 Cc: Gert Doering , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <20190221215302.GU71606@Space.Net> To: Mark Smith X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 23:44:53 -0000 > On 22 Feb 2019, at 10:21 am, Mark Smith = wrote: >=20 > On Fri, 22 Feb 2019 at 08:53, Gert Doering wrote: >>=20 >> Hi, >>=20 >> On Fri, Feb 22, 2019 at 08:40:24AM +1100, Mark Smith wrote: >>>> Applications today seem to be all "HTTP(S)" or "QUIC", and they all = had to >>>> learn how to deal with NAPT. New protocols that embed IP addresses = are >>>> killed by IPv4 NAPT anyway, so that ship has sailed - >>>=20 >>> Getting it back in IPv6 is one of the things I hope we can get. >>>=20 >>> That's because applications that would be best performing, most = robust and >>> more secure with a peer-to-peer communications model are forced to = adopt an >>> absolute client-server model (where the server is a much more likely >>> performance bottleneck, the server becomes a SPOF for all clients = using it >>> at the time, and the server is a natural interception point for a = malicious >>> server operator). >>=20 >> Have you looked out there recently? None of the big actors in the = market >> seem to have any particular interest in moving away from a "we are = the cloud >> content players, you are just visiting clients" model. >>=20 >=20 > Generally it's in their business interests not to. >=20 > However, just like everybody else, they don't have a choice anyway, > even if they wanted to with IPv4 because of NAT. >=20 > Still, there are lots of little actors, and a peer-to-peer model can > allow them to scale their application without having to spend massive > amounts on server infrastructure (physical or virtual.) >=20 >> (The gaming industry has, to some extent, but that doesn't seem to be >> a really strong driver) >>=20 >=20 > Something significant happened in that regard recently. >=20 > "IPv6 on Xbox One" > https://support.xbox.com/en-US/xbox-one/networking/ipv6-on-xbox-one >=20 > "And=E2=80=94most useful for Xbox=E2=80=94the expansion removes the = need for Network > Address Translation (NAT), which can interfere with multiplayer gaming > and chat over IPv4 networks." >=20 > "..., for the best possible experience, we recommend enabling IPv6 on > your network." >=20 >> [..] >>> Another analogy to show the significance is that with NAT in the = telephone >>> network, it wouldn't be possible for me to give you this phone's = number to >>> call me. Would any of us accept that constraint on the usability of = our >>> phones? >>=20 >> When did you do the last phone call on your mobile tablet-like = computer >> thingie? >=20 > Sunday (and I need to get back to my Uncle since). Previous weeks a > number of them organising a trip and updating expired credit card > number details. >=20 > I'll observe that you've still got your phone number in your email > signature below, so being able to convey your globally unique phone > number and receive calls to it isn't yet obsolete. Actually he doesn=E2=80=99t. He has something that approximates a = globally unique phone number. The (0) should not be there. There is a standard for writing phone numbers that start with + and it isn=E2=80=99t being = used. > Regards, > Mark. >=20 >>=20 >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >>=20 >> SpaceNet AG Vorstand: Sebastian v. Bomhard, = Michael Emmer >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 21 15:49: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 2DF1E1312BA; Thu, 21 Feb 2019 15:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 2BF53TvvvRPy; Thu, 21 Feb 2019 15:49:35 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEE11312B7; Thu, 21 Feb 2019 15:49:35 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [192.159.10.5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x1LNnRNg026018 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Feb 2019 15:49:27 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x1LNnRNg026018 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1550792968; bh=8Ik+Mu0WIc+R7yf3oLjW1S1D9Jc0ZOKJxo9eDmbCQcs=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=cy1k2SJ+lk8VwKCh0GstFap/C5ESHfma5yAAn0jKqyXnlmpO4YwdBXKL3czLr3DrF dovK4MQN+CtAZ4VGaYZwZADFxjlpNgBa9P3qD3BZ7ZysDivLZRMxyXg/U3NR4jd35B dWcrba5CMdMXUfLTz/irrxnofNXCZk0oTOsnPv6g= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5D887866-A7C3-49DE-B394-7C2307AB4271" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 21 Feb 2019 15:49:27 -0800 In-Reply-To: Cc: Mark Smith , "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> To: Tom Herbert References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Thu, 21 Feb 2019 15:49:28 -0800 (PST) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 23:49:38 -0000 --Apple-Mail=_5D887866-A7C3-49DE-B394-7C2307AB4271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Mark, >=20 > I agreee with that with one exception. I believe that NAT/IPv4 can > offer better privacy in addressing than IPv6 given current addess > allocation methods. Huh? Random 64 bit numbers are less private than semi-opaque translation = of 32 bit numbers? In today=E2=80=99s world (where CGN is fortunately still mostly the = exception rather than the rule), the 32 bit public number (mostly) identifies the household on a transient = basis. In IPv6, the 64 bit prefix (or 60 or 56 or ideally 48) similarly = identifies the household, though it might be somewhat less transient than the IPv4 32 bit number. I=E2=80=99ve= been using the same cable company for transport of my GRE tunnels that provide my real = connectivity for about 10 years now. In that time, I=E2=80=99ve had roughly 4 address changes. Now, the rate of change there isn=E2=80=99t particularly relevant to my = privacy (mostly it=E2=80=99s just a rare nuisance), but I think it probably isn=E2=80=99t an uncommon indicator = of IPv4 address stability for people remaining on the same network. I=E2=80=99d say there=E2=80=99s not much privacy in a 32 bit space that = remains persistent for more than a year. I=E2=80=99d argue that even if it takes 10 years to cycle an IPv6 prefix = on a subscriber, you=E2=80=99ve still got roughly the same privacy model there at the household prefix level. On the host level, assuming that the hosts are using RFC4941, RFC7217, = or RFC7943 (which most hosts use by default these days), then I think that the host = portion in IPv6 is significantly more private than anything one gains from IPv4 NAT even = though one does not need to sacrifice the peer-to-peer nature of the internet in order = to use them (as is the case with IPv4 NAT). Owen --Apple-Mail=_5D887866-A7C3-49DE-B394-7C2307AB4271 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Mark,
I agreee with that with one = exception. I believe that NAT/IPv4 can
offer better privacy in addressing than IPv6 given current = addess
allocation = methods.

Huh? = Random 64 bit numbers are less private than semi-opaque translation of = 32 bit numbers?

In today=E2=80=99s = world (where CGN is fortunately still mostly the exception rather than = the rule), the
32 bit public number (mostly) identifies the = household on a transient basis.

In = IPv6, the 64 bit prefix (or 60 or 56 or ideally 48) similarly identifies = the household, though it
might be somewhat less transient than = the IPv4 32 bit number. I=E2=80=99ve been using the same = cable
company for transport of my GRE tunnels that provide my = real connectivity for about 10 years
now. In that time, I=E2=80=99= ve had roughly 4 address changes.

Now,= the rate of change there isn=E2=80=99t particularly relevant to my = privacy (mostly it=E2=80=99s just a rare
nuisance), but I = think it probably isn=E2=80=99t an uncommon indicator of IPv4 address = stability for
people remaining on the same = network.

I=E2=80=99d say there=E2=80=99= s not much privacy in a 32 bit space that remains persistent for more = than a year.
I=E2=80=99d argue that even if it takes 10 years = to cycle an IPv6 prefix on a subscriber, you=E2=80=99ve still = got
roughly the same privacy model there at the household = prefix level.

On the host level, = assuming that the hosts are using RFC4941, RFC7217, or = RFC7943
(which most hosts use by default these days), then I = think that the host portion in IPv6
is significantly more = private than anything one gains from IPv4 NAT even though one = does
not need to sacrifice the peer-to-peer nature of the = internet in order to use them (as is the
case with IPv4 = NAT).

Owen

= --Apple-Mail=_5D887866-A7C3-49DE-B394-7C2307AB4271-- From nobody Thu Feb 21 15:55: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 20467130E0A for ; Thu, 21 Feb 2019 15:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSITDciTpYPq for ; Thu, 21 Feb 2019 15:55:06 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C899D1312BA for ; Thu, 21 Feb 2019 15:55:04 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id y13so333034iop.11 for ; Thu, 21 Feb 2019 15:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A3TmlL5ornOSugvsKCuzDNK+EZ9Sis/zk1UESWHFfGQ=; b=EUwnq0RHbXcLSOMuBeFKeQ7v2a9gIcGsWW2NBmLYCiwe7QL3F5hnzm/pVL9oSR/Kpv xwXDDFN6yx1mJFLWHpbdWw7KnVmjsi7Zx7X9BXOeU37FhkWFsiNP0NJbcG3vjqqRykgc U4ho02lLwONxTDnaL2dM18kwmCfn2TW6lfS+qJeaGFMICcsmECxugUr8Ppqwnetk1FJI C35TjJ+T9jLlAuPy58YkHl3tKQA7aL7JyPibu7BC2Ty+bnkN6pksEIs2a9vJd2tvR0ml 3yOwy4Nj+b/E2sMgJxlo44aRiN3Y/WHSRkZ5uafCuzHvvQ7AMqmv+IB0Cpy8jSECKprN huyw== 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=A3TmlL5ornOSugvsKCuzDNK+EZ9Sis/zk1UESWHFfGQ=; b=L6t/A5G5UwXFt3pl9t7oM1NArAvxBN46WRDLXg2yw802soJxxkWA68djncNRxRbRGy V+ushotJb4MW1fhNreXd5CrR99uOoZ18QnciZO/tAc/styVuAFT+YhoDJ9dSxEILs/KB xolz2bkk9JSWk7y2BboKECro/SS5o1Lvco3AQYHh3alkva8DdKZSBMYFWhGZ60kCrWhn wP89Eu6ol2GNVGAb48cdhQo0acrWyaUi49JdoP5zUC0nu5h5cUJW1Wi8aVh4EodcwCa1 qXc0udFWlO6MA1i+byQVo6NusfQRyWiOlKRHCjRmsRYBjdJMzmiAUc4fzLTMWvlEmWnz IkgQ== X-Gm-Message-State: AHQUAuYxxWnwLqIQ1D88zfPDk1JGDYEmNL/73rEfFdKH55wZVoY+NKmU WkROtNNU3cXdzKD9HhS31pf5ZlapLn8f/j6ckSN29M3b X-Google-Smtp-Source: AHgI3Ibsk4aLBvK1WsSm8CGYygZTH+VvOiDfFY+Gma0RFyggwaYJ381ukFn+jPlpajXLQkrxbW6779fQUM/Dsr1WXOc= X-Received: by 2002:a5e:9912:: with SMTP id t18mr768064ioj.14.1550793303672; Thu, 21 Feb 2019 15:55:03 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> In-Reply-To: From: Lorenzo Colitti Date: Fri, 22 Feb 2019 08:54:49 +0900 Message-ID: To: Fernando Gont Cc: "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000fcbcc505827033aa" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 23:55:07 -0000 --000000000000fcbcc505827033aa Content-Type: text/plain; charset="UTF-8" On Thu, Feb 21, 2019 at 10:35 AM Fernando Gont wrote: > Given that RFC6092 recommends "only allow outgoing connections", RFC 6092 recommends no such thing. --000000000000fcbcc505827033aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000fcbcc505827033aa-- From nobody Thu Feb 21 15:58: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 52BC1130E0A for ; Thu, 21 Feb 2019 15:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCfWmZ5c4B1e for ; Thu, 21 Feb 2019 15:58:10 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B455128BCC for ; Thu, 21 Feb 2019 15:58:10 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id z131so610973itf.5 for ; Thu, 21 Feb 2019 15:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4G7ihUd3CU3OrW4/JRE1IxM9hDmlqQSMq3hE/HVUg60=; b=YYsy9tErL0eCn/oAOxUvZu2yhJIc54WxRBopAMgoMQfwTbiXwu31Er1ejDmc31yXtH XhRv2nf5718SPJv0X972aVHp4++3LHSfhK51rhQ67uR+LJw5Wv3Zxmeh2ETDuQgAzh0o Luxpi58rNqtENsvn/MDK/Yos7ILKn5b7mgklvMFgA+B8Dt4d7I4l/aTPqAGCD2ZWTP4F LwS97ejfH73fhfSgvWtJnJKxFBEYi0E8SKX/s5gVhKuMMnd61/bCfMYH6yGxX7xM7yDd TrPV7wQ0Obf01dGxqbi1OvG4G3YsYo+b2lkrbps4u0uNfRxQRK26nBNDiTfPTIKfmNrw T26g== 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=4G7ihUd3CU3OrW4/JRE1IxM9hDmlqQSMq3hE/HVUg60=; b=rcknLgQTOPAcAoYDPiGWC/pOIIXgcLkVTrv+39eJ/rooqxU0GkM7VUSFUKX6Y/LwL7 lTdoZP+UirOehWWnCuNvrcW23S7ZMm388GAbBDoio6fpaZBIzLyyxdZpvxN4D+jxgmpZ +ebgV2XESqMqQ+qx7xLcnKupMyS1Yhz0GbjEWt+vZEzz4M3fUgzc1QyD+LPxXUI2wHNF 9/sdvbXCE9IbVKI5+iCQi8PZl8GrHTtFBNuOHsBCTINRxAtRJ13Cj1ClUcgVhdgNkJxE hltylfrt9TXQpM5k228befOvVsYBFmJUF+clwqk/hAcEMZScnQgs6fwt964Qonot6HRa z/0w== X-Gm-Message-State: AHQUAub2GhdpIvdZY8Zr9Mzba9Ats2nEBv5U+rTBlZ20eqg0P4oUnjNZ EAL6/N79Oqc9LFHuLWOTd+0HL+Q0mcPyC3Oe6yqccg== X-Google-Smtp-Source: AHgI3IZKnRRSdH6JSL0qQ3EEAI0wCSec3epdxcNn1vlCQNIQNBvfDKiz2BkLbxTYKm+QD6hAjqhUFF836kCMm0Jzcbs= X-Received: by 2002:a24:4290:: with SMTP id i138mr806929itb.24.1550793488968; Thu, 21 Feb 2019 15:58:08 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: <20190221073530.GT71606@Space.Net> From: Lorenzo Colitti Date: Fri, 22 Feb 2019 08:57:57 +0900 Message-ID: To: Gert Doering Cc: "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000000826200582703f7b" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 23:58:13 -0000 --0000000000000826200582703f7b Content-Type: text/plain; charset="UTF-8" On Thu, Feb 21, 2019 at 4:35 PM Gert Doering wrote: > Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to > learn how to deal with NAPT. New protocols that embed IP addresses are > killed by IPv4 NAPT anyway, so that ship has sailed - and everything that > doesn't care about embedded IP addresses will nicely work throug NPTv6. > It has only sailed if we as an industry deploy NAT for IPv6 in a pervasive way. If we do not, and NAT66 remains an uncommon configuration, then the application breakage resulting from NAT66-only deployments will cause those deployments to roll back to IPv4 and/or global IPv6. --0000000000000826200582703f7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Applications today seem to be all "HTTP(S)" or "QUIC= ", and they all had to
learn how to deal with NAPT.=C2=A0 New protocols that embed IP addresses ar= e
killed by IPv4 NAPT anyway, so that ship has sailed - and everything that doesn't care about embedded IP addresses will nicely work throug NPTv6.=

It has only sailed if we as an industr= y deploy NAT for IPv6 in a pervasive way. If we do not, and NAT66 remains a= n uncommon configuration, then the application breakage resulting from NAT6= 6-only deployments will cause those deployments to roll back to IPv4 and/or= global IPv6.
--0000000000000826200582703f7b-- From nobody Thu Feb 21 16:19: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 7C9E1130EE2 for ; Thu, 21 Feb 2019 16:19:09 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 LwSXc7BfuUbS for ; Thu, 21 Feb 2019 16:19:07 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA83130E0A for ; Thu, 21 Feb 2019 16:19:07 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id x6so181261qki.6 for ; Thu, 21 Feb 2019 16:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0FDTlPVQy2wACCRouuF2wP6EhpFKaceVd+hCL5frmQM=; b=v2/BNW8K3AZ/zPc67MUwYQKJQATIroSKTd6zn5rDy0gqYZyNqtfkI5FD/h9ThjD0Yu Ks5tTcOqByjXIwBLz6RYsEwZ/F0tMSj+08AxyfxI+xxswDqAqoVxYUqFEW9sVIQn9Vez UPhFnPf+5EAFPGLbHNVEJ5c8/5YRxQYQ4vMyWgb0XgLtYp6+SPIzRUjrAGHUT+Ma5XB2 lS1LVGBBuU+EqOPFMsKImwmwjTUColxQKA177HJFad9HxiTsiJZGHkxUMX0XNErGgi58 o9FZqWuMnBafxdJfp8n6xgBcZaL/NCRkWpyufv+b5y5ZpJMyHjiSUpHwT2WIT3PWIGra Tjpg== 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:content-transfer-encoding; bh=0FDTlPVQy2wACCRouuF2wP6EhpFKaceVd+hCL5frmQM=; b=U+MtD4+TGS5XCFP3pRIHz3FGuucN9C55Uq2K4DM+V0tt0HkiGxSB1YOQzs66bFJgR3 4i4gBnSGPtMMnHZvefCABEbU7uKvflwLO7GST7ujzdUh80EHyVY3W/KgsRzSIRvcYUbg ZByKxoONetcmGg2exIAHY4+xCecepoAGO0AOAgaUE1m2i5psOWkVMyJibcBxnui7n1TI N251PcXXX1U8F4UhK7x8+agcyeLQIt8Xn9LMQzJds2f1a/Ge39qYgv2pcTWwTgWdjlyL oPrjCzrQ0Kww42iRlQwE5W9uSvBteMQePIAXTF/iSRC8OdWcpN1vzmDbNfr5TlERahQy oMew== X-Gm-Message-State: AHQUAuaHwRzGKwklhTx5Sj5gvpUPYRrmg0nql95HjzPPK0QHA6oOqPcM Y0oeNfVGEPASWtnGU1vyvty8zShb4fObgPp3VO10ww== X-Google-Smtp-Source: AHgI3IZJuvdMCjiKyrFcW/xGhh36q8MxL0PIQAHiL6FAEDoCPfwhQaIkYI2ws4vVMiI7Kfy50BxRUjIoZ3AT9fkHCCU= X-Received: by 2002:a37:a147:: with SMTP id k68mr997982qke.190.1550794746616; Thu, 21 Feb 2019 16:19:06 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Tom Herbert Date: Thu, 21 Feb 2019 16:18:55 -0800 Message-ID: To: Owen DeLong Cc: Mark Smith , "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 00:19:09 -0000 On Thu, Feb 21, 2019 at 3:49 PM Owen DeLong wrote: > > > Mark, > > I agreee with that with one exception. I believe that NAT/IPv4 can > offer better privacy in addressing than IPv6 given current addess > allocation methods. > > > Huh? Random 64 bit numbers are less private than semi-opaque translation = of 32 bit numbers? > > In today=E2=80=99s world (where CGN is fortunately still mostly the excep= tion rather than the rule), the > 32 bit public number (mostly) identifies the household on a transient bas= is. > Owen, Privacy in CGN effectively if the device lives behind a NAT with thousands of user. So if the an external external third party observes two different flows that share the same NAT address, then the observer can not infer that the two flows are sourced form the same device or user. Tom > In IPv6, the 64 bit prefix (or 60 or 56 or ideally 48) similarly identifi= es the household, though it > might be somewhat less transient than the IPv4 32 bit number. I=E2=80=99v= e been using the same cable > company for transport of my GRE tunnels that provide my real connectivity= for about 10 years > now. In that time, I=E2=80=99ve had roughly 4 address changes. > > Now, the rate of change there isn=E2=80=99t particularly relevant to my p= rivacy (mostly it=E2=80=99s just a rare > nuisance), but I think it probably isn=E2=80=99t an uncommon indicator of= IPv4 address stability for > people remaining on the same network. > > I=E2=80=99d say there=E2=80=99s not much privacy in a 32 bit space that r= emains persistent for more than a year. > I=E2=80=99d argue that even if it takes 10 years to cycle an IPv6 prefix = on a subscriber, you=E2=80=99ve still got > roughly the same privacy model there at the household prefix level. > > On the host level, assuming that the hosts are using RFC4941, RFC7217, or= RFC7943 > (which most hosts use by default these days), then I think that the host = portion in IPv6 > is significantly more private than anything one gains from IPv4 NAT even = though one does > not need to sacrifice the peer-to-peer nature of the internet in order to= use them (as is the > case with IPv4 NAT). > > Owen > From nobody Thu Feb 21 17:04: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 E8518129AA0; Thu, 21 Feb 2019 17:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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] 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 Z9MJxtMPtLd6; Thu, 21 Feb 2019 17:04:42 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C1F67130E7E; Thu, 21 Feb 2019 17:04:40 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [192.159.10.5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x1M14aWe019017 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Feb 2019 17:04:37 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x1M14aWe019017 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1550797477; bh=rUzKDbCpidMpLBo6HXNzYj5PU7qLxZefZCmBeYqL7vs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=eYX815VDBImwe9wLHzYTJz1EwSoUGx9CxRry3mchu2bPh/kfaWquLTkx3JdzpNMKY +/YlzeOfC1/YE026AtQXqJW3m0ZPPU+fAijY+slWeehVz+MtdqEa/Wht/G0YkFgxfZ TrJAW+2e5nXY9y0aZMBbr/PwD0kLpJlby/arg6hM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Owen DeLong In-Reply-To: Date: Thu, 21 Feb 2019 17:04:36 -0800 Cc: Mark Smith , "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> To: Tom Herbert X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Thu, 21 Feb 2019 17:04:37 -0800 (PST) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 01:04:46 -0000 > On Feb 21, 2019, at 16:18 , Tom Herbert wrote: >=20 > On Thu, Feb 21, 2019 at 3:49 PM Owen DeLong wrote: >>=20 >>=20 >> Mark, >>=20 >> I agreee with that with one exception. I believe that NAT/IPv4 can >> offer better privacy in addressing than IPv6 given current addess >> allocation methods. >>=20 >>=20 >> Huh? Random 64 bit numbers are less private than semi-opaque = translation of 32 bit numbers? >>=20 >> In today=E2=80=99s world (where CGN is fortunately still mostly the = exception rather than the rule), the >> 32 bit public number (mostly) identifies the household on a transient = basis. >>=20 > Owen, >=20 > Privacy in CGN effectively if the device lives behind a NAT with > thousands of user. So if the an external external third party observes > two different flows that share the same NAT address, then the observer > can not infer that the two flows are sourced form the same device or > user. >=20 Sure, but today, CGN is the exception, not the rule=E2=80=A6 Hopefully = it will remain that way for the foreseeable future as CGN is really an awful awful thing for the end = user. Also, due to CALEA constraints, most CGN implementations are going to = quasi-static port reservations per household, so it=E2=80=99s not as private as you think = it is. It will raise the bar slightly, forcing the third party to track an extra 32 bits per flow = (2xport number), but that=E2=80=99s about it. Owen From nobody Thu Feb 21 17:13: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 2D83712D4EF for ; Thu, 21 Feb 2019 17:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 RjNxEkmYuUyq for ; Thu, 21 Feb 2019 17:13:27 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BE8130E2F for ; Thu, 21 Feb 2019 17:13:25 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id a15so267451qkc.1 for ; Thu, 21 Feb 2019 17:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oyanN724oBkuyAULkKpri2Cd2PUKsuam/ZwQAr7+HmA=; b=Pkua0gt+YcmZjcs6lkKWtIZgMKCS29Gs5WNfK6qEHKVtnwH/xn8zZnglsVJrQmYkis 6REQkc7XArup/Yete/81h9GgGNSFbS1Aj9yXQ1nSr4EfytPPU4Utu3JG1Ll8hOUScctf 5UMMKporw7EbP2E//f7D2lHqFy7edC1KIDreRkcg+uly+e145pKaP+loVzUmsiwi6LUR Nhox0cd9lfU18irR701yWdkjz9VKG1QO4DHdS8VdaaC0DPaSQAkLtsp1Q1Fw0Du01UAc 1TwuvDM8USsRmcluRx8zwOAxEVDjHpmQ2BK8Gu65jQfRQzJO4ACMZehaO1wHKGerxfh9 Ob1g== 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:content-transfer-encoding; bh=oyanN724oBkuyAULkKpri2Cd2PUKsuam/ZwQAr7+HmA=; b=b9UHQ2Mvuf6gZiRpTWECNcG7bzMCq3iE3LawoyNE71dXKNYySSsDc6ZBIDzqvSlNLO DpUrYTNvu67BxElR+5FIyrAc4IhyIO+Bqo9u+9B8W2Aho5vFEldj38BaFqAbqaDkNc1i odGntXAmKKnNRCxTtspzjn2jta8elWqYkxsxF7/kLZHw4q0B+y/zRGeBNINKdn5ghh8i rtl68/8kHAdzhmyhMnfZGy4Gtqy5FrM9Jg9zyQ8sSI8ENcFHkjXSLdVVlL8lAHKHzVLg 2KQXw3VQYBF0rxy8wfPIVr2Tr5+dnocXpYusGXp0QmS3IuRUJILPgA72D72uD6EvNfl9 QfsA== X-Gm-Message-State: AHQUAuaUGI4+l2iGxsLw/sbk78NF7EHzXmzN1fo9182DHRJC/i6xEEL7 ZzsQCflnVjMvDnvdtiQtxZwAMPmmmDNtb+RKNVfAdA== X-Google-Smtp-Source: AHgI3IZb3+sPAgmTIolQ6KUy4o6T3AEpOVcLOhvKnYVfgMda1fHX0YbWe3Glg+gIhboM0bpwgmaRXk46lr9V6G/sRN0= X-Received: by 2002:a37:a147:: with SMTP id k68mr1135619qke.190.1550798004432; Thu, 21 Feb 2019 17:13:24 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Tom Herbert Date: Thu, 21 Feb 2019 17:13:13 -0800 Message-ID: To: Owen DeLong Cc: Mark Smith , "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 01:13:28 -0000 On Thu, Feb 21, 2019 at 5:04 PM Owen DeLong wrote: > > > > > On Feb 21, 2019, at 16:18 , Tom Herbert wrote: > > > > On Thu, Feb 21, 2019 at 3:49 PM Owen DeLong wrote: > >> > >> > >> Mark, > >> > >> I agreee with that with one exception. I believe that NAT/IPv4 can > >> offer better privacy in addressing than IPv6 given current addess > >> allocation methods. > >> > >> > >> Huh? Random 64 bit numbers are less private than semi-opaque translati= on of 32 bit numbers? > >> > >> In today=E2=80=99s world (where CGN is fortunately still mostly the ex= ception rather than the rule), the > >> 32 bit public number (mostly) identifies the household on a transient = basis. > >> > > Owen, > > > > Privacy in CGN effectively if the device lives behind a NAT with > > thousands of user. So if the an external external third party observes > > two different flows that share the same NAT address, then the observer > > can not infer that the two flows are sourced form the same device or > > user. > > > > Sure, but today, CGN is the exception, not the rule=E2=80=A6 Hopefully it= will remain that way for the > foreseeable future as CGN is really an awful awful thing for the end user= . > > Also, due to CALEA constraints, most CGN implementations are going to qua= si-static port > reservations per household, so it=E2=80=99s not as private as you think i= t is. It will raise the bar > slightly, forcing the third party to track an extra 32 bits per flow (2xp= ort number), but that=E2=80=99s > about it. > Owen, To be clear, I was not advocating NAT. I was only pointing out that it has some privacy properties to the extent that even law enforcement has even expressed concerns about it. For those users for which privacy is vital, I don't believe it's an adequate solution. If privacy is essential then I believe we really want single use untrackable addresses (see draft-herbert-ipv6-prefix-address-privacy-00). Tom > > Owen > From nobody Thu Feb 21 17:58: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 78813130E2F; Thu, 21 Feb 2019 17:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 dnP-7sMw20Li; Thu, 21 Feb 2019 17:58:40 -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 61E8212D7EA; Thu, 21 Feb 2019 17:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550800716; x=1551405516; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=E4RaoXf2O+Dck6Ob5v+pTZtR2K4mZP76a7Jn4rUKWuo=; b=g5Qu8f9n+YC8a Gaso32S/4k4WSCoM4cqAgXdJgrRjLl+Y+Yb5UcV4QFfFNv+ss6PbIiNFnd/Z0/ux YWcYMYdm8RJmQT1KdcKfJM6dNkX/JHO6Obuvye0s4tHa9vsod7i990wX0pYVFLMM Qdolsi0OkQZRZewCgTon3u9wHR6k6M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 22 Feb 2019 02:58:36 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 22 Feb 2019 02:58:36 +0100 Received: from [10.10.10.160] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006163789.msg; Fri, 22 Feb 2019 02:58:32 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.10.10.160] X-MDArrival-Date: Fri, 22 Feb 2019 02:58:32 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1956a66f16=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Fri, 22 Feb 2019 10:58:14 +0900 From: JORDI PALET MARTINEZ To: Tom Herbert , Mark Smith CC: "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Message-ID: <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 01:58:41 -0000 I agreee with that with one exception. I believe that NAT/IPv4 can offer better privacy in addressing than IPv6 given current addess allocation methods. I'm for as much privacy as possible, however, not at the cost of things such as: - Unnecessary complexity increase - Moving from peer-to-peer to client-server for everything - Single point of failure - Increasing the attacks chances by reducing the surface to the servers - Increase the complexity of app development - Complexity to host services in "clients" - Complexity to use "freely" and "efficient" DNS - etc So, using the "privacy" in the extreme as a repellent to simple peer-to-peer is like if we say "knives need to be forbidden because they can be used to kill people". If protocols or tools are badly used, law should take care of that. We should make protocols able to support privacy as much as possible, but never at the cost of an extreme complexity and losing or degrading all the other features. Regards, Jordi ********************************************** 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 nobody Thu Feb 21 18:07: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 E0EF2130E58; Thu, 21 Feb 2019 18:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtLf_u7kslTs; Thu, 21 Feb 2019 18:07:02 -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 EA495130E25; Thu, 21 Feb 2019 18:07:01 -0800 (PST) Received: from [192.168.4.76] (unknown [190.179.111.85]) (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 8C8C48447F; Fri, 22 Feb 2019 03:06:56 +0100 (CET) To: Brian E Carpenter , Timothy Winters Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "ek@loon.co" References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> <90dd7fee-77cc-3411-7079-60a6edf488d9@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <383d51c4-e53a-7fc3-3530-22cc2c7312ea@si6networks.com> Date: Thu, 21 Feb 2019 22:09:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <90dd7fee-77cc-3411-7079-60a6edf488d9@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 02:07:06 -0000 On 21/2/19 18:14, Brian E Carpenter wrote: > On 2019-02-22 05:23, Fernando Gont wrote: >> On 21/2/19 13:14, Timothy Winters wrote: >> [...] >>> >>> Probably an irrelevant question to ask now :-), but, anyway: any clues >>> why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to me you >>> cannot really do multi-prefix without RFC8028... >>> >>> My memory of this was the working group wasn't convinced that every node >>> needed to support it.    >> >> If you support multiple prefixes (all nodes do), then you really need >> RFC8028. Otherwise it is quite likely that you will be egress-filtered. > > But as I pointed out, RFC8028 only makes rule 5.5 a SHOULD. It's > SHOULDs all the way down. > > Of course, SHOULD means "that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed...". In other words, do RFC8028 and Rule 5.5 > unless there's a good reason not to. So... what would be the good reason? :-) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 21 18:07: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 6DC48130E25; Thu, 21 Feb 2019 18:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHeVvVqfqtN0; Thu, 21 Feb 2019 18:07:05 -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 D9F90130E90; Thu, 21 Feb 2019 18:07:04 -0800 (PST) Received: from [192.168.4.76] (unknown [190.179.111.85]) (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 DA71B846D9; Fri, 22 Feb 2019 03:07:01 +0100 (CET) To: j h woodyatt , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <2EEFFB58-C665-48BF-B09E-5AF5A7CA91E6@conjury.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <41ac74c3-51e7-c29f-7430-cbc88d218037@si6networks.com> Date: Thu, 21 Feb 2019 22:21:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <2EEFFB58-C665-48BF-B09E-5AF5A7CA91E6@conjury.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 02:07:07 -0000 On 20/2/19 23:28, j h woodyatt wrote: > On Feb 20, 2019, at 17:13, Fernando Gont > wrote: >> >> Given that RFC6092 recommends "only allow outgoing connections”... > > I certainly don’t remember writing that, and I just double-checked the > text, and I’m pretty sure that recommendation is not in RFC 6092. The > relevant portion is Section 3.4 Passive Listeners, I think, and it only > goes so far as to say this: > > REC-49: Internet gateways with IPv6 simple security capabilities MUST > provide an easily selected configuration option that permits a > "transparent mode" of operation that forwards all unsolicited flows > regardless of forwarding direction, i.e., not to use the IPv6 simple > security capabilities of the gateway. The transparent mode of > operation MAY be the default configuration. So it may default to "on" or "off"? (i.e., default value left unspecified?) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 21 18:07: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 1C1CE130F25; Thu, 21 Feb 2019 18:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFbGOnpl6Ste; Thu, 21 Feb 2019 18:07:10 -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 6CACD130EFE; Thu, 21 Feb 2019 18:07:10 -0800 (PST) Received: from [192.168.4.76] (unknown [190.179.111.85]) (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 8311F84967; Fri, 22 Feb 2019 03:07:06 +0100 (CET) To: Lorenzo Colitti Cc: "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <47c0cbae-b0e6-7fd6-eced-b6a5a8463788@si6networks.com> Date: Thu, 21 Feb 2019 22:27:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 02:07:16 -0000 On 21/2/19 20:54, Lorenzo Colitti wrote: > On Thu, Feb 21, 2019 at 10:35 AM Fernando Gont > wrote: > > Given that RFC6092 recommends "only allow outgoing connections", > > RFC 6092 recommends no such thing. Yep, that seems to be the case, sorry. That said, that seems to be the way many ISPs are rolling IPv6. I understand that's how Comcast does it in the USA, and the last to IPv6 deployments I tested in my city also "only allowed outgoing communications". It was fine for me, until I realized there was no UPnP support for IPv6. That meant that in scenarios where I couldn't change the CPE configuration, I did need a rendezvouz point for IPv6 -- where with IPv4, dynamic DNS plus UPnP to punch holes in the NAT did the trick. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 21 18:13: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 D272F12F295; Thu, 21 Feb 2019 18:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA7ePItN2dsf; Thu, 21 Feb 2019 18:13:25 -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 0B617126F72; Thu, 21 Feb 2019 18:13:25 -0800 (PST) Received: from [192.168.4.76] (unknown [190.179.111.85]) (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 E18F584994; Fri, 22 Feb 2019 03:13:20 +0100 (CET) To: JORDI PALET MARTINEZ , Tom Herbert , Mark Smith Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> Date: Thu, 21 Feb 2019 23:13:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 02:13:27 -0000 On 21/2/19 22:58, JORDI PALET MARTINEZ wrote: > > I agreee with that with one exception. I believe that NAT/IPv4 can > offer better privacy in addressing than IPv6 given current addess > allocation methods. > > I'm for as much privacy as possible, however, not at the cost of things such as: > - Unnecessary complexity increase > - Moving from peer-to-peer to client-server for everything > - Single point of failure > - Increasing the attacks chances by reducing the surface to the servers > - Increase the complexity of app development > - Complexity to host services in "clients" > - Complexity to use "freely" and "efficient" DNS > - etc There are two protocols associated with NATs: 1) Apps that incorporate IP addresses and ports in the app protocol require an ALG 2) Because of of the "only allow outgoing connections" side-effect of NATs, you need UPnP to open holes in the NAT, or some NAT traversal technique. "1)" goes away when you remove the NAT. "2)" does not if you replace the NAT with a stateful firewall that only allows outgoing connections. -- the majority of the IPv6 deployments I've seen use this policy/model. And, of course, this is also a single point of failure, will also increase application complexity, etc., etc., etc. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 21 18:24: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 6D670128B01 for ; Thu, 21 Feb 2019 18:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 spnpr0ZRnlXe for ; Thu, 21 Feb 2019 18:23:53 -0800 (PST) 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 8FF14128B33 for ; Thu, 21 Feb 2019 18:23:51 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id h28so316621qkk.7 for ; Thu, 21 Feb 2019 18:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lTX0mJUXMHw3tc1h66sxCmMJoifODTCWM1son90o6G0=; b=MYs8rhG5WiWT+cO0C3Vb8rHkbCDBBqleEHC4YmJJAQlnC1eX7YpZbnH3BD4YZIW54I 2xsk/+LokPkGDM84JMOWaE/e6TlBi4dE1OUorjeTFZabgBTBtROEczyCd7zBCPAyCkxD qrTdhXsTgUP7rmMktKfdB+duuN0EkpaIx+akkcvz0P8O0Sz1vHOzdxqCjH0QbucGGC56 +YM/ok/39ZfkR2x955b/jHaR3VD0b4qbRUlgsaWFQF4892xcSq+J4SMRxhL8xyhPzrdw PvhmiualSo9mtPtW02X07BzcV6EZ8whcd74pmQA6aX46wT8TtNpVU2YBsyzxNLBDc9FF 9EdA== 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=lTX0mJUXMHw3tc1h66sxCmMJoifODTCWM1son90o6G0=; b=fZ53PSogK6POQw5BsIinBQinNwX5QHbkQYSsPm8KXvXO6Ihtbd8hhuiTsvx4lJ8NAE Bu9pln6BIHQVZm0UOkzF+NZJVDvfsZFLsVLX8KJ2H6E3f+emShsayAzldNdMABSClF7R myL+lxIkHCGCXMXj4JTQVxlWwmhcv5Z/LyDXtnrX2tjRLCv+T3ZivgThKUyLmUHTcKQb 7rcB64m3Cg+3Yhm74X1wdGjl8/krJI8wSnbqG5YL0716z7Vz+3SWXzhPACA+0Wn1HIdh BLc8wlCtmsZML5bczynJ2VgOwYeN3DuXhV7Xbv1Sp5nJVqglDMOBrsh5xiWsFkC4B7Rc X2Ag== X-Gm-Message-State: AHQUAuabiqg1tUly30SPn/ZqywYdFCGgG86AoYa43gc/B77FhBchHgPq Fh/CCXwl/vIzN2aJEyJteqnI/as+BHjU8/xoZhRZSg== X-Google-Smtp-Source: AHgI3IYqGxMx1Ozls4BRw02sKebvWuqsLUttpXzjlyfXc7782qRlcEURKYyfrJNs7bO39y8TYfN76a67FnGZSEnP5qY= X-Received: by 2002:a37:b482:: with SMTP id d124mr1336548qkf.168.1550802230469; Thu, 21 Feb 2019 18:23:50 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> In-Reply-To: <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> From: Tom Herbert Date: Thu, 21 Feb 2019 18:23:38 -0800 Message-ID: To: Fernando Gont Cc: JORDI PALET MARTINEZ , Mark Smith , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 02:23:54 -0000 On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont wrote: > > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote: > > > > I agreee with that with one exception. I believe that NAT/IPv4 can > > offer better privacy in addressing than IPv6 given current addess > > allocation methods. > > > > I'm for as much privacy as possible, however, not at the cost of things such as: > > - Unnecessary complexity increase > > - Moving from peer-to-peer to client-server for everything > > - Single point of failure > > - Increasing the attacks chances by reducing the surface to the servers > > - Increase the complexity of app development > > - Complexity to host services in "clients" > > - Complexity to use "freely" and "efficient" DNS > > - etc > > There are two protocols associated with NATs: > 1) Apps that incorporate IP addresses and ports in the app protocol > require an ALG > 2) Because of of the "only allow outgoing connections" side-effect of > NATs, you need UPnP to open holes in the NAT, or some NAT traversal > technique. > > > "1)" goes away when you remove the NAT. > > "2)" does not if you replace the NAT with a stateful firewall that only > allows outgoing connections. -- the majority of the IPv6 deployments > I've seen use this policy/model. And, of course, this is also a single > point of failure, will also increase application complexity, etc., etc., > etc. So we need to eliminate stateful firewalls as well as NAT... Tom > > > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Thu Feb 21 18:25: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 C6FD912F295; Thu, 21 Feb 2019 18:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt4YrQJDb6zT; Thu, 21 Feb 2019 18:25:47 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007010.outbound.protection.outlook.com [40.92.7.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED43B126F72; Thu, 21 Feb 2019 18:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lpbGZZ0TfRvlFXsJEi4jJhdhk87LbaohgrUxE7D4HDg=; b=vAJbkKgc/xXw3Jv88xk1clHvjYhYkWPwFl6DIGmrVHL069qlEmQ+6H7dPvRmJID1JjmXOV8lC07QjUWKWV1x6RE3KfJfIphr9d1yfhcfwgd6Zby+74N3Bf8VLv+wbxibiMbCUuXN9Wa7iSu6Oj3C3yJ26gcz9/f1ASShyEEGtjZTu/XM7nUDPLg6uWRbNk+9RN93D+jdXE60XF3cRPU8FKWYHX/CS2/gOGBWED9pOQp6nJuDyuc4Cs6BqjNvFdEIjGEPa+Jzf20LJHO8l5fpSdWIPlzho/eqnvaUJDjAONtTMBEXiDAWF3ohqUOfFv+paZORVslsoYsux0CdX4JmFQ== Received: from DM3NAM03FT031.eop-NAM03.prod.protection.outlook.com (10.152.82.53) by DM3NAM03HT192.eop-NAM03.prod.protection.outlook.com (10.152.83.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13; Fri, 22 Feb 2019 02:25:46 +0000 Received: from DM6PR04MB4009.namprd04.prod.outlook.com (10.152.82.54) by DM3NAM03FT031.mail.protection.outlook.com (10.152.82.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Fri, 22 Feb 2019 02:25:46 +0000 Received: from DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968]) by DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968%5]) with mapi id 15.20.1643.016; Fri, 22 Feb 2019 02:25:45 +0000 From: Kristian McColm To: Fernando Gont , Tom Herbert CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "JORDI PALET MARTINEZ" Thread-Topic: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) Thread-Index: AQHUylQ7xClo1pMmD0qbB4iWLKyk0aXrFpQAgAAAlH0= Date: Fri, 22 Feb 2019 02:25:45 +0000 Message-ID: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com>, In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:FD7DCC5DF52469A18CF134B9E76309A1BF6A4FC5062AE388FA0FA432E3186F9C; UpperCasedChecksum:5BD7FEC2A1F88B61F4F147C15F1FD3799375ED61863D8B96DEF0DA8B539E688E; SizeAsReceived:7851; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [rLvYIw2QqMYWUewb8ipSIoSeuKMnqeIC] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(20181119070)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031324274)(2017031323274)(1601125500)(1603101475)(1701031045); SRVR:DM3NAM03HT192; x-ms-traffictypediagnostic: DM3NAM03HT192: x-microsoft-antispam-message-info: ZAP9qzdFJGpUcL0ENfulOJJY8rBLinZsQB9bnwEgphwUjFm/8xvWSNN3WvBMrgyh Content-Type: multipart/alternative; boundary="_000_DM6PR04MB4009E6096E8CF525931D46A5DD7F0DM6PR04MB4009namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 0746e09b-7d67-4841-1f81-08d6986d0d19 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 02:25:45.7570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT192 Archived-At: Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 02:25:49 -0000 --_000_DM6PR04MB4009E6096E8CF525931D46A5DD7F0DM6PR04MB4009namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Amen to that. Make the end user devices responsible for their own security. ________________________________ From: v6ops on behalf of Tom Herbert Sent: Thursday, February 21, 2019 9:23:38 PM To: Fernando Gont Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumb= ering" scenarios) On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont wrote= : > > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote: > > > > I agreee with that with one exception. I believe that NAT/IPv4 can > > offer better privacy in addressing than IPv6 given current addess > > allocation methods. > > > > I'm for as much privacy as possible, however, not at the cost of things= such as: > > - Unnecessary complexity increase > > - Moving from peer-to-peer to client-server for everything > > - Single point of failure > > - Increasing the attacks chances by reducing the surface to the servers > > - Increase the complexity of app development > > - Complexity to host services in "clients" > > - Complexity to use "freely" and "efficient" DNS > > - etc > > There are two protocols associated with NATs: > 1) Apps that incorporate IP addresses and ports in the app protocol > require an ALG > 2) Because of of the "only allow outgoing connections" side-effect of > NATs, you need UPnP to open holes in the NAT, or some NAT traversal > technique. > > > "1)" goes away when you remove the NAT. > > "2)" does not if you replace the NAT with a stateful firewall that only > allows outgoing connections. -- the majority of the IPv6 deployments > I've seen use this policy/model. And, of course, this is also a single > point of failure, will also increase application complexity, etc., etc., > etc. So we need to eliminate stateful firewalls as well as NAT... Tom > > > > -- > 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 --_000_DM6PR04MB4009E6096E8CF525931D46A5DD7F0DM6PR04MB4009namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Amen to that. Make the end user devices responsible for their own security.=
From: v6ops <v6ops-bou= nces@ietf.org> on behalf of Tom Herbert <tom@herbertland.com>
Sent: Thursday, February 21, 2019 9:23:38 PM
To: Fernando Gont
Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in = "renumbering" scenarios)
 
On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont <= fgont@si6networks.com> wrote:
>
> On 21/2/19 22:58, JORDI PALET MARTINEZ wrote:
> >
> >     I agreee with that with one exception. I = believe that NAT/IPv4 can
> >     offer better privacy in addressing than I= Pv6 given current addess
> >     allocation methods.
> >
> > I'm for as much privacy as possible, however, not at the cost of = things such as:
> > - Unnecessary complexity increase
> > - Moving from peer-to-peer to client-server for everything
> > - Single point of failure
> > - Increasing the attacks chances by reducing the surface to the s= ervers
> > - Increase the complexity of app development
> > - Complexity to host services in "clients"
> > - Complexity to use "freely" and "efficient" = DNS
> > - etc
>
> There are two protocols associated with NATs:
> 1) Apps that incorporate IP addresses and ports in the app protocol > require an ALG
> 2) Because of of the "only allow outgoing connections" side-= effect of
> NATs, you need UPnP to open holes in the NAT, or some NAT traversal > technique.
>
>
> "1)" goes away when you remove the NAT.
>
> "2)" does not if you replace the NAT with a stateful firewal= l that only
> allows outgoing connections. -- the majority of the IPv6 deployments > I've seen use this policy/model. And, of course, this is also a single=
> point of failure, will also increase application complexity, etc., etc= .,
> etc.

So we need to eliminate stateful firewalls as well as NAT...

Tom

>
>
>
> --
> 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.or= g/mailman/listinfo/v6ops
 --_000_DM6PR04MB4009E6096E8CF525931D46A5DD7F0DM6PR04MB4009namp_-- From nobody Thu Feb 21 18:54: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 2B12012F295 for ; Thu, 21 Feb 2019 18:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 thuwxgfPO8OL for ; Thu, 21 Feb 2019 18:54:03 -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 DB0581288BD for ; Thu, 21 Feb 2019 18:54:02 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id j36so974823qta.7 for ; Thu, 21 Feb 2019 18:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aiBJv+9bXiIlG7COd5yckx+fFOmZJc2QFNXBII13a5U=; b=a8KVruEix3jVyEnZqw045oH5FECRTunoiitFFV/TLbUPjKpR7p8lrDKY5YorqxeLam 8Vgk9otX2Yk+GZg3FxLH3FRM5VYUjdA1ytxFprfhqYgYRJG9f9IljDaDwRRajIgux8V4 OWxlFQh7TfjE8KeqM1BxGMCYJetL+5FMyBrUJJkjg+Iwaii2BuSCrqKCSam/4qqMPaGH S9arU7VTr/fHV2PjRmPx07yhBPZPDvfJicBob6rqssLB1/bCh+hmPxqeSmonRKs1TEkO Kt7lUEsF+dcGwI35xf2ch26lnId2YslT8wlHFj8ryUsw9Jx3lJn5y8Uc7UDKVRInJ88f lw8A== 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=aiBJv+9bXiIlG7COd5yckx+fFOmZJc2QFNXBII13a5U=; b=sIBSCclb8eZ3MigDn7i+qHz+9STfWohvrGdzBvdbrAoIJ7NP9tnzNx5PuKmp/Vh6/9 FdMB2TXDYaf/NYhtqPt3Z8aRJ3gSANKwjEq7BUMcnUcqUe+qZNZ2q8GmqNjj86txM+uo 93ow7mqTqiQcaDeydAyMzy9LjnphNHsUGTqKLgnAPPL++pfRG9y+KwMgoh5Q2PrzYVto Scaq5pnzSUqybTxt8NB90ffF1r+9Au4BmS3H59bSr4GbFzIQfttaXmy8dMcv5JiyDolX hajsyyEtYotwq2oOmceZBbFb9swbGg4FrDzbsMosTZXTDQuMhENvTaBbzvEah5SeX7Qi sGxg== X-Gm-Message-State: AHQUAuaAt8rfj5/BPJ8TQmDuh70QaUcwaGXqagEilEQFK3hypcbNGb8J gnavz/xDDAr45gxSJiM97atSpatf7xF2WkhH7Umi/Q== X-Google-Smtp-Source: AHgI3IbvLv3Ts7LPpFUMsFAaxxhBeFVUn1FHOa61SbR52zHfTOUcBn6lERWO7NwBWSAEw4e1400HNMXZlUFqclfZy64= X-Received: by 2002:a0c:8dc2:: with SMTP id u2mr1439652qvb.168.1550804041656; Thu, 21 Feb 2019 18:54:01 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> In-Reply-To: From: Tom Herbert Date: Thu, 21 Feb 2019 18:53:50 -0800 Message-ID: To: Kristian McColm Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 02:54:05 -0000 On Thu, Feb 21, 2019 at 6:25 PM Kristian McColm wrote: > > Amen to that. Make the end user devices responsible for their own security. > Kristian, Devices and applications are already responsible for their own security. No serious application or OS would ever rely on the presence of an external firewall for its security. However, there is still some benefit of stateful firewalls to protect network resources from attack. So we want the functionality of a stateful firewall in stateless solution without any of the annoying limitations of stateful devices (like they only work with certain protocols, force flows to traverse specific intermediate nodes, are single points of failure, etc). FAST ( draft-herbert-fast-00) is one proposal for this. Tom _______________________________ > From: v6ops on behalf of Tom Herbert > Sent: Thursday, February 21, 2019 9:23:38 PM > To: Fernando Gont > Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ > Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) > > On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont wrote: > > > > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote: > > > > > > I agreee with that with one exception. I believe that NAT/IPv4 can > > > offer better privacy in addressing than IPv6 given current addess > > > allocation methods. > > > > > > I'm for as much privacy as possible, however, not at the cost of things such as: > > > - Unnecessary complexity increase > > > - Moving from peer-to-peer to client-server for everything > > > - Single point of failure > > > - Increasing the attacks chances by reducing the surface to the servers > > > - Increase the complexity of app development > > > - Complexity to host services in "clients" > > > - Complexity to use "freely" and "efficient" DNS > > > - etc > > > > There are two protocols associated with NATs: > > 1) Apps that incorporate IP addresses and ports in the app protocol > > require an ALG > > 2) Because of of the "only allow outgoing connections" side-effect of > > NATs, you need UPnP to open holes in the NAT, or some NAT traversal > > technique. > > > > > > "1)" goes away when you remove the NAT. > > > > "2)" does not if you replace the NAT with a stateful firewall that only > > allows outgoing connections. -- the majority of the IPv6 deployments > > I've seen use this policy/model. And, of course, this is also a single > > point of failure, will also increase application complexity, etc., etc., > > etc. > > So we need to eliminate stateful firewalls as well as NAT... > > Tom > > > > > > > > > -- > > Fernando Gont > > SI6 Networks > > e-mail: fgont@si6networks.com > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 21 19:31: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 C0956130E11; Thu, 21 Feb 2019 19:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fpF7l_u4SVH; Thu, 21 Feb 2019 19:31:24 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002088.outbound.protection.outlook.com [40.92.2.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6DB128B33; Thu, 21 Feb 2019 19:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zFzr+egheE1OI3b0QJOy3fcP6DSHMGYxEWWpkLVUZ4M=; b=p+3pDgzMQCaS0RNHFGV39DpOcKYzjz+v7FfWHUHem/nIIkoURmPjBA+3D4c9ldxnaSEB9y3b54k0wM5RqRlXCY01YEcBebMvQcDyvhqr0gkhreqUMI2JzN1qZmXqJL1fBr3h8p2jjpUyiZoFjb8G3VL2WIBDb1eh1Wp0U+7s1Diixjfxr96WUuev2OV37tyfALPxsJNXv4CBC9xsFQhpnxH6K9VfNUlsRWGUuDDWe4OBRAezTEUQ56rVHVCpeLP5YIEPpLJtuKn0/OhmY45D1XLENWxu8KOjRr4KI9hNVEVBGvbIoW016F3c7JpylMCJz7RbF+A/Qa1d2tLuYRVPTA== Received: from SN1NAM01FT044.eop-nam01.prod.protection.outlook.com (10.152.64.60) by SN1NAM01HT167.eop-nam01.prod.protection.outlook.com (10.152.65.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Fri, 22 Feb 2019 03:31:23 +0000 Received: from DM6PR04MB4009.namprd04.prod.outlook.com (10.152.64.54) by SN1NAM01FT044.mail.protection.outlook.com (10.152.65.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11 via Frontend Transport; Fri, 22 Feb 2019 03:31:23 +0000 Received: from DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968]) by DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968%5]) with mapi id 15.20.1643.016; Fri, 22 Feb 2019 03:31:23 +0000 From: Kristian McColm To: Tom Herbert CC: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ Thread-Topic: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) Thread-Index: AQHUylQ7xClo1pMmD0qbB4iWLKyk0aXrFpQAgAAAlH2AAAfcAIAACn2D Date: Fri, 22 Feb 2019 03:31:23 +0000 Message-ID: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:5E372F61856D06B4BC176C745AE1596DE00C80E2D35AEF44ADCFED59870030C3; UpperCasedChecksum:7AF867D7BC31208C3CA78B2923DE9B85B6D0B38C4781AB1EF94802FA60E81DB7; SizeAsReceived:8020; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [4Ar1q2mnjL9MiW7ETtB7w2sSdLT7BvCg] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031324274)(2017031323274)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM01HT167; x-ms-traffictypediagnostic: SN1NAM01HT167: x-microsoft-antispam-message-info: MTjV4jAHOxG7DVJZ7YDEl/sQvHgv2NyvCz9/OaANAdHIZGFt7SduThDkmQi12Krr Content-Type: multipart/alternative; boundary="_000_DM6PR04MB40096241EB14D0526F7131CDDD7F0DM6PR04MB4009namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 1c6d992c-c519-4912-ac44-08d69876381e X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 03:31:23.3450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT167 Archived-At: Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 03:31:27 -0000 --_000_DM6PR04MB40096241EB14D0526F7131CDDD7F0DM6PR04MB4009namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Then by that same token, can the end user devices, network services and net= work devices not provide their own packet filtering and other security mech= anisms rather than forcing all network traffic to traverse centralized secu= rity devices? It won't be a popular opinion with network security folks and security appl= iance vendors, but I am a believer that the endpoint device is the right pl= ace to implement network security. Intermediary network devices should not,= in my opinion be doing anything other than forwarding packets to their des= tination. ________________________________ From: Tom Herbert Sent: Thursday, February 21, 2019 9:53:50 PM To: Kristian McColm Cc: Fernando Gont; IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumb= ering" scenarios) On Thu, Feb 21, 2019 at 6:25 PM Kristian McColm wrote: > > Amen to that. Make the end user devices responsible for their own securit= y. > Kristian, Devices and applications are already responsible for their own security. No serious application or OS would ever rely on the presence of an external firewall for its security. However, there is still some benefit of stateful firewalls to protect network resources from attack. So we want the functionality of a stateful firewall in stateless solution without any of the annoying limitations of stateful devices (like they only work with certain protocols, force flows to traverse specific intermediate nodes, are single points of failure, etc). FAST ( draft-herbert-fast-00) is one proposal for this. Tom _______________________________ > From: v6ops on behalf of Tom Herbert > Sent: Thursday, February 21, 2019 9:23:38 PM > To: Fernando Gont > Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ > Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renu= mbering" scenarios) > > On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont wro= te: > > > > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote: > > > > > > I agreee with that with one exception. I believe that NAT/IPv4 ca= n > > > offer better privacy in addressing than IPv6 given current addess > > > allocation methods. > > > > > > I'm for as much privacy as possible, however, not at the cost of thin= gs such as: > > > - Unnecessary complexity increase > > > - Moving from peer-to-peer to client-server for everything > > > - Single point of failure > > > - Increasing the attacks chances by reducing the surface to the serve= rs > > > - Increase the complexity of app development > > > - Complexity to host services in "clients" > > > - Complexity to use "freely" and "efficient" DNS > > > - etc > > > > There are two protocols associated with NATs: > > 1) Apps that incorporate IP addresses and ports in the app protocol > > require an ALG > > 2) Because of of the "only allow outgoing connections" side-effect of > > NATs, you need UPnP to open holes in the NAT, or some NAT traversal > > technique. > > > > > > "1)" goes away when you remove the NAT. > > > > "2)" does not if you replace the NAT with a stateful firewall that only > > allows outgoing connections. -- the majority of the IPv6 deployments > > I've seen use this policy/model. And, of course, this is also a single > > point of failure, will also increase application complexity, etc., etc.= , > > etc. > > So we need to eliminate stateful firewalls as well as NAT... > > Tom > > > > > > > > > -- > > 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 --_000_DM6PR04MB40096241EB14D0526F7131CDDD7F0DM6PR04MB4009namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Then by that same token, can the end user devices, network services and net= work devices not provide their own packet filtering and other security mech= anisms rather than forcing all network traffic to traverse centralized secu= rity devices?

It won't be a popular opinion with network security folks and security appl= iance vendors, but I am a believer that the endpoint device is the right pl= ace to implement network security. Intermediary network devices should not,= in my opinion be doing anything other than forwarding packets to their destination.
From: Tom Herbert <tom= @herbertland.com>
Sent: Thursday, February 21, 2019 9:53:50 PM
To: Kristian McColm
Cc: Fernando Gont; IPv6 Operations; 6man@ietf.org; JORDI PALET MARTI= NEZ
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in = "renumbering" scenarios)
 
On Thu, Feb 21, 2019 at 6:25 PM Kristian McColm <kristianmccolm@hotmail.com> wrote:
>
> Amen to that. Make the end user devices responsible for their own secu= rity.
>
Kristian,

Devices and applications are already responsible for their own
security. No serious application or OS would ever rely on the presence
of an external firewall for its security.

However, there is still some benefit of stateful firewalls to protect
network resources from attack. So we want the functionality of a
stateful firewall in stateless solution without any of the annoying
limitations of stateful devices (like they only work with certain
protocols, force flows to traverse specific intermediate nodes, are
single points of failure, etc). FAST ( draft-herbert-fast-00) is one
proposal for this.

Tom

_______________________________
> From: v6ops <v6ops-bounces@ietf.org> on behalf of Tom Herbert &l= t;tom@herbertland.com>
> Sent: Thursday, February 21, 2019 9:23:38 PM
> To: Fernando Gont
> Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ
> Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in &q= uot;renumbering" scenarios)
>
> On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont <fgont@si6networks.co= m> wrote:
> >
> > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote:
> > >
> > >     I agreee with that with one exceptio= n. I believe that NAT/IPv4 can
> > >     offer better privacy in addressing t= han IPv6 given current addess
> > >     allocation methods.
> > >
> > > I'm for as much privacy as possible, however, not at the cos= t of things such as:
> > > - Unnecessary complexity increase
> > > - Moving from peer-to-peer to client-server for everything > > > - Single point of failure
> > > - Increasing the attacks chances by reducing the surface to = the servers
> > > - Increase the complexity of app development
> > > - Complexity to host services in "clients"
> > > - Complexity to use "freely" and "efficient&q= uot; DNS
> > > - etc
> >
> > There are two protocols associated with NATs:
> > 1) Apps that incorporate IP addresses and ports in the app protoc= ol
> > require an ALG
> > 2) Because of of the "only allow outgoing connections" = side-effect of
> > NATs, you need UPnP to open holes in the NAT, or some NAT travers= al
> > technique.
> >
> >
> > "1)" goes away when you remove the NAT.
> >
> > "2)" does not if you replace the NAT with a stateful fi= rewall that only
> > allows outgoing connections. -- the majority of the IPv6 deployme= nts
> > I've seen use this policy/model. And, of course, this is also a s= ingle
> > point of failure, will also increase application complexity, etc.= , etc.,
> > etc.
>
> So we need to eliminate stateful firewalls as well as NAT...
>
> Tom
>
> >
> >
> >
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: fgont@si6networks.com
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 749= 2
> >
> >
> >
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
 --_000_DM6PR04MB40096241EB14D0526F7131CDDD7F0DM6PR04MB4009namp_-- From nobody Thu Feb 21 20:08:29 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 15135130E7E; Thu, 21 Feb 2019 20:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5_1Av4LrEfL; Thu, 21 Feb 2019 20:08:14 -0800 (PST) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554FB130E25; Thu, 21 Feb 2019 20:08:14 -0800 (PST) Received: by mail-yw1-xc35.google.com with SMTP id x21so338428ywx.11; Thu, 21 Feb 2019 20:08:14 -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=kyVg+Y1TxL4QAzMAxd8oNrWylp5rqJRQiirxBU7mxcM=; b=Rqsyq2WwSvdU73L87UNUFkAuQoIKeZuyp3UaYBKFTWf0SdprLP9FLxZIzOTTnwy1B/ XgDsQ+MCiHVu8RxT/EutxeFJUS3mjr6bjYa0BEiF+baNWeFQI8ceUtwfr9WD5MdYV7OT r9ZxZX+wU1ywasewE/zAlQdsn99l18P6NkSBd36wmnAPM/AXXOE57dWCtKzSj8G4Zw2X I0tsjoyOC8o405NjA9FO83gztBhNMqcXIJWzpUY9y2nEjdA8uky6LgWfYrXO5yHnlvCK u4eZepd+FQlqFccJryOe4lp/tpeceayHtYcBcwzSbmn0ZCCxYeH3bk6SjKMWLZxALn/X WN/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=kyVg+Y1TxL4QAzMAxd8oNrWylp5rqJRQiirxBU7mxcM=; b=WFwWzw3J8TfzltMY3Zz9OFoqqobT6zAjbTSMmsySiZm/uSnkWxsjaSosNt/24mfVbz 62Klgp2kjltf74ps07PKnst8e6/Pp8jhigRXMAdfkngAoT44g8z32DgDvtbYOI0ekavI 6v9oOYrwkttuqFKoVZmWC+GwcO07c1YtbN4i4ygsveufeE4VuIoeVPtwfKcezoXZwh86 zUvdo/zhM6KiKK9ExbFjeaQWladMwm95xeZ2KYqqJ80KPy5mM3u3luJo7HNDu93CI2E4 PQg2Vru1Iq5eA8grJyMZ1TpolXRH8qfdzbPGz02suYGESNPb8GFla1V6U1cBlqMKHYb0 eolw== X-Gm-Message-State: AHQUAuYftihjiHogVB3q5AOWY6ZUq/bw8iPbw/YsHF7qMkLSKnjIawF+ EETKwfxAzsKBLSwCiyE/WFu5XRMxopQAO5XwbHzmBA== X-Google-Smtp-Source: AHgI3IZHOhCWRilfmzP29nHl9UvyZHNwNaQ+s7g/n7GuOuM+5CfmFmIIQRubESSz4OCS6rIhPqNjR/riubby1B4anVY= X-Received: by 2002:a0d:e2ce:: with SMTP id l197mr1672517ywe.226.1550808492783; Thu, 21 Feb 2019 20:08:12 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> In-Reply-To: From: Ca By Date: Thu, 21 Feb 2019 21:08:01 -0700 Message-ID: To: Kristian McColm Cc: "6man@ietf.org" <6man@ietf.org>, Fernando Gont , IPv6 Operations , JORDI PALET MARTINEZ , Tom Herbert Content-Type: multipart/alternative; boundary="00000000000053c016058273bd41" Archived-At: Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 04:08:17 -0000 --00000000000053c016058273bd41 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 21, 2019 at 8:31 PM Kristian McColm wrote: > Then by that same token, can the end user devices, network services and > network devices not provide their own packet filtering and other security > mechanisms rather than forcing all network traffic to traverse centralized > security devices? > > It won't be a popular opinion with network security folks and security > appliance vendors, but I am a believer that the endpoint device is the > right place to implement network security. Intermediary network devices > should not, in my opinion be doing anything other than forwarding packets > to their destination. > +1, i have had a good experience removing stateful devices for the majority of flows from a large mobile network over the last 5 years as we transitioned for 464xlat. No downsides. And, with larger ipv6 space and random iid, discoverability risk is very low for 3rd parties / scans / botnets CB > ------------------------------ > *From:* Tom Herbert > *Sent:* Thursday, February 21, 2019 9:53:50 PM > *To:* Kristian McColm > *Cc:* Fernando Gont; IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ > > *Subject:* Re: [v6ops] NAT debate (Re: A common problem with SLAAC in > "renumbering" scenarios) > > On Thu, Feb 21, 2019 at 6:25 PM Kristian McColm > wrote: > > > > Amen to that. Make the end user devices responsible for their own > security. > > > Kristian, > > Devices and applications are already responsible for their own > security. No serious application or OS would ever rely on the presence > of an external firewall for its security. > > However, there is still some benefit of stateful firewalls to protect > network resources from attack. So we want the functionality of a > stateful firewall in stateless solution without any of the annoying > limitations of stateful devices (like they only work with certain > protocols, force flows to traverse specific intermediate nodes, are > single points of failure, etc). FAST ( draft-herbert-fast-00) is one > proposal for this. > > Tom > > _______________________________ > > From: v6ops on behalf of Tom Herbert < > tom@herbertland.com> > > Sent: Thursday, February 21, 2019 9:23:38 PM > > To: Fernando Gont > > Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ > > Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in > "renumbering" scenarios) > > > > On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont > wrote: > > > > > > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote: > > > > > > > > I agreee with that with one exception. I believe that NAT/IPv4 > can > > > > offer better privacy in addressing than IPv6 given current addess > > > > allocation methods. > > > > > > > > I'm for as much privacy as possible, however, not at the cost of > things such as: > > > > - Unnecessary complexity increase > > > > - Moving from peer-to-peer to client-server for everything > > > > - Single point of failure > > > > - Increasing the attacks chances by reducing the surface to the > servers > > > > - Increase the complexity of app development > > > > - Complexity to host services in "clients" > > > > - Complexity to use "freely" and "efficient" DNS > > > > - etc > > > > > > There are two protocols associated with NATs: > > > 1) Apps that incorporate IP addresses and ports in the app protocol > > > require an ALG > > > 2) Because of of the "only allow outgoing connections" side-effect of > > > NATs, you need UPnP to open holes in the NAT, or some NAT traversal > > > technique. > > > > > > > > > "1)" goes away when you remove the NAT. > > > > > > "2)" does not if you replace the NAT with a stateful firewall that only > > > allows outgoing connections. -- the majority of the IPv6 deployments > > > I've seen use this policy/model. And, of course, this is also a single > > > point of failure, will also increase application complexity, etc., > etc., > > > etc. > > > > So we need to eliminate stateful firewalls as well as NAT... > > > > Tom > > > > > > > > > > > > > > -- > > > 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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00000000000053c016058273bd41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 21, 2019 at 8:31 PM Kristian McColm <kristianmccolm@hotmail.com> w= rote:
Then by that same token, can the end user devices, network services and net= work devices not provide their own packet filtering and other security mech= anisms rather than forcing all network traffic to traverse centralized secu= rity devices?

It won't be a popular opinion with network security folks and security = appliance vendors, but I am a believer that the endpoint device is the righ= t place to implement network security. Intermediary network devices should = not, in my opinion be doing anything other than forwarding packets to their destination.

+1, i have had a good= experience removing stateful devices for the majority of flows from a larg= e mobile network over the last 5 years as we transitioned for 464xlat. =C2= =A0 No downsides.=C2=A0

= And, with larger ipv6 space and random iid, discoverability risk is very lo= w for 3rd parties / scans / botnets=C2=A0

=
CB
From: Tom Herbert <= tom@herbertland.com>
Sent: Thursday, February 21, 2019 9:53:50 PM
To: Kristian McColm
Cc: Fernando Gont; IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ

Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in = "renumbering" scenarios)
=C2=A0
On Thu, Feb 21, 2019 at 6:25 = PM Kristian McColm
<kristia= nmccolm@hotmail.com> wrote:
>
> Amen to that. Make the end user devices responsible for their own secu= rity.
>
Kristian,

Devices and applications are already responsible for their own
security. No serious application or OS would ever rely on the presence
of an external firewall for its security.

However, there is still some benefit of stateful firewalls to protect
network resources from attack. So we want the functionality of a
stateful firewall in stateless solution without any of the annoying
limitations of stateful devices (like they only work with certain
protocols, force flows to traverse specific intermediate nodes, are
single points of failure, etc). FAST ( draft-herbert-fast-00) is one
proposal for this.

Tom

_______________________________
> From: v6ops <v6ops-bounces@ietf.org> on behalf of Tom Herbert <tom@herbertland.com&g= t;
> Sent: Thursday, February 21, 2019 9:23:38 PM
> To: Fernando Gont
> Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ
> Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in &q= uot;renumbering" scenarios)
>
> On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont <fgont@si6networks.com> wrote:=
> >
> > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote:
> > >
> > >=C2=A0=C2=A0=C2=A0=C2=A0 I agreee with that with one exceptio= n. I believe that NAT/IPv4 can
> > >=C2=A0=C2=A0=C2=A0=C2=A0 offer better privacy in addressing t= han IPv6 given current addess
> > >=C2=A0=C2=A0=C2=A0=C2=A0 allocation methods.
> > >
> > > I'm for as much privacy as possible, however, not at the= cost of things such as:
> > > - Unnecessary complexity increase
> > > - Moving from peer-to-peer to client-server for everything > > > - Single point of failure
> > > - Increasing the attacks chances by reducing the surface to = the servers
> > > - Increase the complexity of app development
> > > - Complexity to host services in "clients"
> > > - Complexity to use "freely" and "efficient&q= uot; DNS
> > > - etc
> >
> > There are two protocols associated with NATs:
> > 1) Apps that incorporate IP addresses and ports in the app protoc= ol
> > require an ALG
> > 2) Because of of the "only allow outgoing connections" = side-effect of
> > NATs, you need UPnP to open holes in the NAT, or some NAT travers= al
> > technique.
> >
> >
> > "1)" goes away when you remove the NAT.
> >
> > "2)" does not if you replace the NAT with a stateful fi= rewall that only
> > allows outgoing connections. -- the majority of the IPv6 deployme= nts
> > I've seen use this policy/model. And, of course, this is also= a single
> > point of failure, will also increase application complexity, etc.= , etc.,
> > etc.
>
> So we need to eliminate stateful firewalls as well as NAT...
>
> Tom
>
> >
> >
> >
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: fgont@si6networks.com
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 749= 2
> >
> >
> >
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--00000000000053c016058273bd41-- From nobody Thu Feb 21 20:54: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 EA2BA130EA2; Thu, 21 Feb 2019 20:54: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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy9-iJ_k4HHW; Thu, 21 Feb 2019 20:54:10 -0800 (PST) Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) (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 D593B130E90; Thu, 21 Feb 2019 20:54:09 -0800 (PST) X-One-Unified-MailScanner-Watermark: 1551416040.18827@tw0HXBLUDGuPm2mms1UG2g X-One-Unified-MailScanner-From: ray@oneunified.net X-One-Unified-MailScanner: Not scanned: postmaster@oneunified.net X-One-Unified-MailScanner-ID: x1M4rs61005474 X-OneUnified-MailScanner-Information: Please contact the ISP for more information Received: from [10.55.40.131] (h96-45-2-121-eidnet.org.2.45.96.in-addr.arpa [96.45.2.121] (may be forged)) (authenticated bits=0) by mail1.oneunified.net (8.14.4/8.14.4/Debian-4) with ESMTP id x1M4rs61005474 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2019 04:53:56 GMT To: Kristian McColm , Tom Herbert Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> From: Raymond Burkholder Organization: One Unified Net Limited Message-ID: Date: Thu, 21 Feb 2019 21:53:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E01D869EA1E47D918FE031AE" Content-Language: en-US Archived-At: Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 04:54:11 -0000 This is a multi-part message in MIME format. --------------E01D869EA1E47D918FE031AE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 2019-02-21 8:31 p.m., Kristian McColm wrote: > Then by that same token, can the end user devices, network services > and network devices not provide their own packet filtering and other > security mechanisms rather than forcing all network traffic to > traverse centralized security devices? > > It won't be a popular opinion with network security folks and security > appliance vendors, but I am a believer that the endpoint device is the > right place to implement network security. Intermediary network > devices should not, in my opinion be doing anything other than > forwarding packets to their destination. There is a grey area here, from my experience. With virtualization and containers, hosts are becoming routers, with the host thus being an intermediary device. And there is tooling available which allows the host to apply protection policies as well as segregation policies to the virtualized functions it hosts. In other configurations, in a traditional vein, 'switches' connect hosts of various sorts, and in that same traditional vein, are intermediary devices and just forward packets. But there are security flavours out 'there' where the switch is no longer just a switch. For those end-points which are unable or are unwilling to handle their own security, there is a form of network topology where the 'switch' becomes more intelligent and can perform security functions on ingress/egress at the port level. This provides a form of distributed nonSPOF style protection mechanisms. In combining the concepts of the virtualization host I mentioned initially, and this edge 'protection switch', they are both sharing the concept of distributed nonSPOF security functionality (which I suppose is part of what Network Function Virtualization does). As one specific example, I'll mention Cillium, which is highly IPv6 aware, and excels at providing this distributed routing/security/forwarding function in a distributed fashion. So I think there is a happy medium: some end points devices just can't do their own security, and for paranoid network operators, you can't trust that they can, as well as from an endpoint developer perspective (think microservices), you don't want them to. Providing those services at the connecting port level is the next best thing for the consistent, distributed and reliable application of protection rules? --------------E01D869EA1E47D918FE031AE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 2019-02-21 8:31 p.m., Kristian McColm wrote:
Then by that same token, can the end user devices, network services and network devices not provide their own packet filtering and other security mechanisms rather than forcing all network traffic to traverse centralized security devices?

It won't be a popular opinion with network security folks and security appliance vendors, but I am a believer that the endpoint device is the right place to implement network security. Intermediary network devices should not, in my opinion be doing anything other than forwarding packets to their destination.

There is a grey area here, from my experience. With virtualization and containers, hosts are becoming routers, with the host thus being an intermediary device. And there is tooling available which allows the host to apply protection policies as well as segregation policies to the virtualized functions it hosts.

In other configurations, in a traditional vein, 'switches' connect hosts of various sorts, and in that same traditional vein, are intermediary devices and just forward packets.

But there are security flavours out 'there' where the switch is no longer just a switch. For those end-points which are unable or are unwilling to handle their own security, there is a form of network topology where the 'switch' becomes more intelligent and can perform security functions on ingress/egress at the port level. This provides a form of distributed nonSPOF style protection mechanisms.

In combining the concepts of the virtualization host I mentioned initially, and this edge 'protection switch', they are both sharing the concept of distributed nonSPOF security functionality (which I suppose is part of what Network Function Virtualization does). As one specific example, I'll mention Cillium, which is highly IPv6 aware, and excels at providing this distributed routing/security/forwarding function in a distributed fashion.

So I think there is a happy medium: some end points devices just can't do their own security, and for paranoid network operators, you can't trust that they can, as well as from an endpoint developer perspective (think microservices), you don't want them to. Providing those services at the connecting port level is the next best thing for the consistent, distributed and reliable application of protection rules?
--------------E01D869EA1E47D918FE031AE-- From nobody Thu Feb 21 21: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 9649F12E04D; Thu, 21 Feb 2019 21:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5pZzlA2IvU3; Thu, 21 Feb 2019 21:15:56 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-oln040092000055.outbound.protection.outlook.com [40.92.0.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD9C129532; Thu, 21 Feb 2019 21:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vQY4kfaDoDBNgxAa+kOsptZUpSdI+o4wp7T/cTeJaL0=; b=nmMOf/ehNHLG1PxHedOz11r+PJRe5eTWfux9YUwcWzlJtjp7NONs/ZVgTGAf8Gr71b25z3hMaMq0Lai0Kie7dA7siH0BZ5bvuQhXdrteWVuqVWdeMdaz0i2a246XVVAmNzJVvMTDsHPPTio9Y9CmEIvaw7ZeDeZqHRZsk/q85imEzEEXLTA8wKDmXpSv0uGu5MjxtqKsy3rCRi7VM4p/WMZKq+rIeepwbfsSeja7zcUlBJeyTJMTlsuzUfrrwCA0MHeDvUWHTxueSzCMuXI28cL7MjX95GJlMcPSg95Y2OT38TQROJ0UMm4i9QBCIY1wnMDw+Wt1JwYe51sQJNDKFg== Received: from SN1NAM01FT008.eop-nam01.prod.protection.outlook.com (10.152.64.59) by SN1NAM01HT178.eop-nam01.prod.protection.outlook.com (10.152.65.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.11; Fri, 22 Feb 2019 05:15:54 +0000 Received: from DM6PR04MB4009.namprd04.prod.outlook.com (10.152.64.60) by SN1NAM01FT008.mail.protection.outlook.com (10.152.64.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.11 via Frontend Transport; Fri, 22 Feb 2019 05:15:54 +0000 Received: from DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968]) by DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968%5]) with mapi id 15.20.1643.016; Fri, 22 Feb 2019 05:15:54 +0000 From: Kristian McColm To: Tom Herbert , Raymond Burkholder CC: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ Thread-Topic: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) Thread-Index: AQHUylQ7xClo1pMmD0qbB4iWLKyk0aXrFpQAgAAAlH2AAAfcAIAACn2DgAAXDwCAAASJ4w== Date: Fri, 22 Feb 2019 05:15:54 +0000 Message-ID: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:360562332F71CD752C38F3B7EBD16037DF82F5AFF4CB1B1F2ECC91EC6B2CB581; UpperCasedChecksum:D15305AC4C1EA4317BC212C8F0181E240C94E4BF643915583B4613754E5547A5; SizeAsReceived:8167; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [X1EPqcdtH4TtrwsKP2oIda7mW1CLGCd/] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM01HT178; x-ms-traffictypediagnostic: SN1NAM01HT178: x-microsoft-antispam-message-info: qhrvvJSCpyHCNz6Ex4QQLY0AMqHN7yAXN6uoTyaI2/8nvjZaz01xtw2esC9HkK6o Content-Type: multipart/alternative; boundary="_000_DM6PR04MB40099E6E9BE59DFD48091AE2DD7F0DM6PR04MB4009namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: df537aa8-b34a-4130-2b49-08d69884d1c0 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 05:15:54.0650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT178 Archived-At: Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 05:15:58 -0000 --_000_DM6PR04MB40099E6E9BE59DFD48091AE2DD7F0DM6PR04MB4009namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What you describe is, unless I missed something, network segmentation. I ab= solutely agree that network segmentation, either physical or virtual, is an= important concept in network security. Separating customer facing interfac= es from management interfaces is one example that comes to mind. But I believe in the context of this discussion we are taking about layer 3= and up, deep packet inspection, flow analysis, and packet filtering, etc. Even still, one could argue layer 1 and 2 segmentation is still done at the= host level. The host has different physical or virtual interfaces that can= have different policy in terms of routing/switching. The switches provide = the different segments but the host ultimately decides which interface to p= ut an ethernet frame onto, and if one arrives, how it should be processed. = Likewise, the owner of the host requests a port that will put the interface= into an appropriate network segment. In other words, the host still decides what resources it needs and how it u= ses them. An important concept to understand is that networks do not create data, the= y are merely the conduit that hosts use to communicate with each other. So = then, in my view, the creators and consumers of the data flowing across a g= iven network should be the ultimate point of access control and auditing, n= ot the conduit itself. From: Raymond Burkholder Sent: Friday, February 22, 2019 4:53:54 AM To: Kristian McColm; Tom Herbert Cc: Fernando Gont; IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumb= ering" scenarios) On 2019-02-21 8:31 p.m., Kristian McColm wrote: Then by that same token, can the end user devices, network services and net= work devices not provide their own packet filtering and other security mech= anisms rather than forcing all network traffic to traverse centralized secu= rity devices? It won't be a popular opinion with network security folks and security appl= iance vendors, but I am a believer that the endpoint device is the right pl= ace to implement network security. Intermediary network devices should not,= in my opinion be doing anything other than forwarding packets to their des= tination. There is a grey area here, from my experience. With virtualization and con= tainers, hosts are becoming routers, with the host thus being an intermedia= ry device. And there is tooling available which allows the host to apply p= rotection policies as well as segregation policies to the virtualized funct= ions it hosts. In other configurations, in a traditional vein, 'switches' connect hosts of= various sorts, and in that same traditional vein, are intermediary devices= and just forward packets. But there are security flavours out 'there' where the switch is no longer j= ust a switch. For those end-points which are unable or are unwilling to ha= ndle their own security, there is a form of network topology where the 'sw= itch' becomes more intelligent and can perform security functions on ingres= s/egress at the port level. This provides a form of distributed nonSPOF st= yle protection mechanisms. In combining the concepts of the virtualization host I mentioned initially,= and this edge 'protection switch', they are both sharing the concept of di= stributed nonSPOF security functionality (which I suppose is part of what N= etwork Function Virtualization does). As one specific example, I'll mentio= n Cillium, which is highly IPv6 aware, and excels at providing this distrib= uted routing/security/forwarding function in a distributed fashion. So I think there is a happy medium: some end points devices just can't do t= heir own security, and for paranoid network operators, you can't trust that= they can, as well as from an endpoint developer perspective (think microse= rvices), you don't want them to. Providing those services at the connectin= g port level is the next best thing for the consistent, distributed and rel= iable application of protection rules? --_000_DM6PR04MB40099E6E9BE59DFD48091AE2DD7F0DM6PR04MB4009namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What you describe is, unless I missed something, network segmentation. I ab= solutely agree that network segmentation, either physical or virtual, is an= important concept in network security. Separating customer facing interfac= es from management interfaces is one example that comes to mind.

But I believe in the context of this discussion we are taking about layer 3= and up, deep packet inspection, flow analysis, and packet filtering, etc.

Even still, one could argue layer 1 and 2 segmentation is still done at the= host level. The host has different physical or virtual interfaces that can= have different policy in terms of routing/switching. The switches provide = the different segments but the host ultimately decides which interface to put an ethernet frame onto, and if o= ne arrives, how it should be processed. Likewise, the owner of the host req= uests a port that will put the interface into an appropriate network segmen= t.

In other words, the host still decides what resources it needs and how it u= ses them.

An important concept to understand is that networks do not create data, the= y are merely the conduit that hosts use to communicate with each other. So = then, in my view, the creators and consumers of the data flowing across a g= iven network should be the ultimate point of access control and auditing, not the conduit itself.


From: Raymond= Burkholder <ray@oneunified.net>
Sent: Friday,= February 22, 2019 4:53:54 AM
To: Kristian = McColm; Tom Herbert
Cc: Fernando = Gont; IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ
Subject: Re: = [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering&qu= ot; scenarios)
 
On 2019-02-21 8:31 p.m., Kristian McColm wrote:
Then by that same token, can the end user devices, network services and net= work devices not provide their own packet filtering and other security mech= anisms rather than forcing all network traffic to traverse centralized secu= rity devices?

It won't be a popular opinion with network security folks and security appl= iance vendors, but I am a believer that the endpoint device is the right pl= ace to implement network security. Intermediary network devices should not,= in my opinion be doing anything other than forwarding packets to their destination.

There is a grey area here, from my experience.  With virtualization an= d containers, hosts are becoming routers, with the host thus being an inter= mediary device.  And there is tooling available which allows the host = to apply protection policies as well as segregation policies to the virtualized functions it hosts.

In other configurations, in a traditional vein, 'switches' connect hosts of= various sorts, and in that same traditional vein, are intermediary devices= and just forward packets. 

But there are security flavours out 'there' where the switch is no longer j= ust a switch.  For those end-points which are unable or are unwilling = to handle their own security, there is a form of network topology where&nbs= p; the 'switch' becomes more intelligent and can perform security functions on ingress/egress at the port level.  = This provides a form of distributed nonSPOF style protection mechanisms.

In combining the concepts of the virtualization host I mentioned initially,= and this edge 'protection switch', they are both sharing the concept of di= stributed nonSPOF security functionality (which I suppose is part of what N= etwork Function Virtualization does).  As one specific example, I'll mention Cillium, which is highly IPv6 aware,= and excels at providing this distributed routing/security/forwarding funct= ion in a distributed fashion.

So I think there is a happy medium: some end points devices just can't do t= heir own security, and for paranoid network operators, you can't trust that= they can, as well as from an endpoint developer perspective (think microse= rvices), you don't want them to.  Providing those services at the connecting port level is the next best thi= ng for the consistent, distributed and reliable application of protection r= ules?
--_000_DM6PR04MB40099E6E9BE59DFD48091AE2DD7F0DM6PR04MB4009namp_-- From nobody Thu Feb 21 23:36: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 4929A130DC9; Thu, 21 Feb 2019 23:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK3Xh8ucrxIm; Thu, 21 Feb 2019 23:35:55 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894C6126D00; Thu, 21 Feb 2019 23:35:55 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id c18so1072393otl.13; Thu, 21 Feb 2019 23:35:55 -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=RrzKIsDfDY/d6Cm4uKYbTVZ6viBaPc4qGrfBt7WLG7k=; b=nBKvQZB0i/h13IXLGRu2tfxMIM2Yr5uoEZdsEfr2AcUaHVZmwowNSDU1BFJH++4L9t SOV2Zc6m+q4Ap9FI3KJUNpbKBmhi/q+YhfWf9Njzx9C4sUtTBO7pdhXi5sxLE35Oai2n 7tz67MDMtQsB60uqu3HmfOnx5obwR2YagGGBy50oj638dY5ATj4tU0nn0JW6Q9qGJY3C bYKhnfv1LPG/HMAWFgP9XB6Uqyb4Zwqljho/glub7Y9DkufkSpmlG+T+AZJrwFbID3xg uFeJDlZHg6UaZWpbVkRhV7Qd+VMY2u4oUe38gLPK3Xe4m4LClsL5LoX3gxIa7iNsuIg1 JxeQ== 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=RrzKIsDfDY/d6Cm4uKYbTVZ6viBaPc4qGrfBt7WLG7k=; b=p+ru1E0UTOUcxBEAE+CyXYAXNnSFRe0n8QtPbAXYkcSrG/dWUvJE/x7rAgBwxTQJuA gjF/IMgZ9he5LWdPOIqFqpdKHQRYguXoJsVIQ0kTJ2ozIE165ZXl5H+1hkLZ3lkUvoc/ DAHzNLgvmGB5ebD/MQ/SEgq6LXtFk0Lv+HpiX0Ugz/W0rS2kT3y0dQdrNN6hdXrAVSrF l9HA6JiQHWXkKEB8Lzn/8Qa7YlnIRFmvzfaxII8AbBTXtTPIxJGWkSyiJX6YIJrPCXCn imYDj0vVEEEvA/nBKXTWRUat1SK0b0XsiBg92m+aTot1flRq76DBhC1X8OnCtMwE1Zmp 572Q== X-Gm-Message-State: AHQUAuYdPPuwZSuZv0z/eoMDCy9dsu4BLsVNLGN7AqbNEfUAiFmGL2Mt g9snO/ZHnYrZSwUH22SzNuKdbWGG2Cr31PdgAfg= X-Google-Smtp-Source: AHgI3IbBcze1wEt/D/gtYWzMjIn0TrghhrhJ4fgJwHm0N/jQHmYp9/ovjRP9I/ldmkYY6siV8o2eqR7zggReMSwNy+Q= X-Received: by 2002:a9d:630f:: with SMTP id q15mr1735591otk.187.1550820954473; Thu, 21 Feb 2019 23:35:54 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Mark Smith Date: Fri, 22 Feb 2019 18:35:27 +1100 Message-ID: To: Tom Herbert Cc: "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 07:35:58 -0000 Hi Tom, On Fri, 22 Feb 2019 at 10:04, Tom Herbert wrote: > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith wrote: > > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E > > wrote: > > > > > > > So I think there's commonly a big different between works and works > > well. NAT may work, however compared to stateless IPv6 (and IPv4) > > forwarding, it doesn't work anywhere as near as well. > > > Mark, > > I agreee with that with one exception. I believe that NAT/IPv4 can > offer better privacy in addressing than IPv6 given current addess > allocation methods. > So I don't think addressing privacy via NAT is really all that valuable if there are many other ways, some quite easy, to uniquely identify an anonymity desiring end-point/end-user, whose effectiveness aren't impacted at all by NAT. For example, this website is coming over IPv4 for me, and I'm using IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn't be able to tracked. https://amiunique.org/ Yet it is saying I can be with both Chrome and Firefox on Fedora 29 in Incognito/Private windows mode on this host. It says the same about my Android 9 phone with Chrome in Incognito mode. Going into the detail of how, they don't seem to be using IP address at all for any identification, it is all browser attributes. We have IPv6 temporary addresses, which makes using addresses harder to use to identify a node. I think that is a lot better than nothing. However, I don't see how IPv6 NAT would improve it much, and it introduces the other drawbacks of NAT. Regards, Mark. > Tom > > > Regards, > > Mark. > > > > > > > > > Bert > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 21 23:45: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 8951D124D68 for ; Thu, 21 Feb 2019 23:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7woh4B7hDlOf for ; Thu, 21 Feb 2019 23:45:04 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 787091200B3 for ; Thu, 21 Feb 2019 23:45:04 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx147.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gx5W0-000yn3-Rc for v6ops@ietf.org; Fri, 22 Feb 2019 08:45:01 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gx5Vz-00033Q-6R for v6ops@ietf.org; Fri, 22 Feb 2019 02:44:59 -0500 Received: (qmail 30827 invoked from network); 22 Feb 2019 07:44:54 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <6man@ietf.org>; 22 Feb 2019 07:44:54 -0000 To: JORDI PALET MARTINEZ , Tom Herbert , Mark Smith Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> Date: Thu, 21 Feb 2019 23:44:52 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.245 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.05) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rnMwtg0w1Guz+EaE3CscBp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9AxpS2ybzKyoEqHHtAJ/hHP21Dj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5kB7L9qFZEB58fINh4BP9MqXe0Of4jddu9xC8 8+iQ5nb7LoaTAX7mj3bIh4FDz/DsTWjvPyjQw0UjfF+Jrlh6iu5FWD3Fo0oXNNKNfWMJhMmBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQviUSfAdJk YJaAlfzQz6q7eKBmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsi2uVu9e8T3JeB2VHikG6U0dNfzLdPbOHdUSHHIg6V8YFLmSWqIR7sJ Xe0cEb2VxClqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+fEKFx8hzfwEGiRmbFGMHRaDg5/bq7ChmPMN Ycw1QSmRN23CM1Ehwt9Pwg5eZWQ5neBH9yUu2FjXMPwRBmDITkZm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhisGkxkte1vyWWpOPNVWEuo6+NTKQHNkjJg8xvPcdYB8Xf5AUf1kCAsFmubjw BGSJFf27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 07:45:07 -0000 Debating the beauty of NAT on an IPv6 list is surely good fun for some, but could we get some progress on the original issue, which could be summed up as a "bug in SLAAC"? Fernando filed that bug 3 weeks ago, I saw hundreds of messages on the mailing list, but I did not see much progress. Do we agree that this is indeed a bug, or do we think that having users disconnected from the Internet after a home router reboots is just a desirable feature of IPv6? Do we agree that it would be good if routers that reboot could just reacquire the same prefix from DHCPv6 PD? Do we also agree that there will always be a significant fraction of deployment in which that won't be possible? Do we agree that the working group should actually start working on some improvement in SLAAC that would mitigate the issue? Not excluding of course solutions that would also mitigate related egress filtering issue?= -- Christian Huitema From nobody Thu Feb 21 23:51: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 135CE130DC9; Thu, 21 Feb 2019 23:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVoheF8Aw70y; Thu, 21 Feb 2019 23:51:16 -0800 (PST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75E5126D00; Thu, 21 Feb 2019 23:51:15 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id q81so1049423oic.5; Thu, 21 Feb 2019 23:51: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:content-transfer-encoding; bh=qDuroK3z8BztG3jKm++r4AGzJVDpi822jZsEupQ6l+U=; b=OPwNsdFh7hSv2FQcNK+kmb5zJhF8E/3SY+DoUhRE8AzaWZN36c5+nRon68e/ACptEI Q7ukV9gHcLrUUbk45uGU/QN4jto1ITJMnTSBVMdoagA8nY5LAxy28b6IdOZiFrOwVwju 7u1scQlQQu4/G8PL1EIuokxXP6Ov2m2RlEHOhlJsOr7do8ysAfKgBLTBOw+oSLg9iNtb 7SF7oVAP3Jy5wRYfHvhpO1+GPDqvrmPXa66zXqi7MY42wabjKguqAsVjGfbPg1zya74U R6OaqinTlHsJTBTmiN4IBZUdA/BbtHmIJE6nKqlfuVj57wMuAqe8li2CEvDB5ulEh5Um XTGw== 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:content-transfer-encoding; bh=qDuroK3z8BztG3jKm++r4AGzJVDpi822jZsEupQ6l+U=; b=noh+5G1Kk8Tp4JMSvmL+BP+G/rApgP9I0A9E1xhVuc5FbxcxReyFcIlgCS2vIUvBsa 5aMCOow1k/+Tqs3XyWUBIqD9mard8xS7d022WCguZYwpuZJk9nIF4oQMl3KN8Bm62b4a cvHL+jl7WVJT4JGq3EVMf7Ywvs1Ndl/vd3XT138OC89W3T5r0gZx3HrXM4er63+UTzCS oclVlMnqJ+1BVppWQ2yVE2cLUiBHA2eDiwrhg+wwsY/FST/WEs4+JV0uQcQRTmMS84XF izH0tXOw72Q9tLrEvnmvuyE+mYhjtqg3KgO1MrqPKxJZaARaq/JAiaITTAKt57ep5i2B O/hQ== X-Gm-Message-State: AHQUAuYHR2lwonZWH/M9QAFalvp4KtVQ0+5jom3VJTM/3QtUEFTekbPc QLTQKHUVTkYb/9UZ1RsYc1DbNtIgiQJQTLJTsr0= X-Google-Smtp-Source: AHgI3Ias0Yt3qXN/Yd/Zvb8PM6+UuwMbJz4bR5nSFU43VPwvRKVtd32PCMBX2XjLe6OZfE82XuaiDeI/vw9fbCAY6uE= X-Received: by 2002:aca:5785:: with SMTP id l127mr1663617oib.14.1550821874680; Thu, 21 Feb 2019 23:51:14 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> In-Reply-To: From: Mark Smith Date: Fri, 22 Feb 2019 18:50:48 +1100 Message-ID: To: Ca By Cc: Kristian McColm , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 07:51:18 -0000 On Fri, 22 Feb 2019 at 15:08, Ca By wrote: > > > > On Thu, Feb 21, 2019 at 8:31 PM Kristian McColm wrote: >> >> Then by that same token, can the end user devices, network services and = network devices not provide their own packet filtering and other security m= echanisms rather than forcing all network traffic to traverse centralized s= ecurity devices? >> >> It won't be a popular opinion with network security folks and security a= ppliance vendors, but I am a believer that the endpoint device is the right= place to implement network security. Intermediary network devices should n= ot, in my opinion be doing anything other than forwarding packets to their = destination. > > > +1, i have had a good experience removing stateful devices for the majori= ty of flows from a large mobile network over the last 5 years as we transit= ioned for 464xlat. No downsides. > +1 Encryption plus multipath transport layer protocols like MP-TCP is really going to screw up a lot of things a lot of people are used to doing in the network. Multipathing doesn't just mean via two network interfaces, it may mean different IPv6 addresses (say, one older, one newer, during transition) temporary addresses on the same network interface. Jump to the Impacts section on slide 63 if you want to cut to the chase. "The Rapid Rise of the Mobile Multihomed Host, and what it might mean to the network" https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20= P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf Regards, Mark. > And, with larger ipv6 space and random iid, discoverability risk is very = low for 3rd parties / scans / botnets > > CB >> >> ________________________________ >> From: Tom Herbert >> Sent: Thursday, February 21, 2019 9:53:50 PM >> To: Kristian McColm >> Cc: Fernando Gont; IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ >> >> Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "ren= umbering" scenarios) >> >> On Thu, Feb 21, 2019 at 6:25 PM Kristian McColm >> wrote: >> > >> > Amen to that. Make the end user devices responsible for their own secu= rity. >> > >> Kristian, >> >> Devices and applications are already responsible for their own >> security. No serious application or OS would ever rely on the presence >> of an external firewall for its security. >> >> However, there is still some benefit of stateful firewalls to protect >> network resources from attack. So we want the functionality of a >> stateful firewall in stateless solution without any of the annoying >> limitations of stateful devices (like they only work with certain >> protocols, force flows to traverse specific intermediate nodes, are >> single points of failure, etc). FAST ( draft-herbert-fast-00) is one >> proposal for this. >> >> Tom >> >> _______________________________ >> > From: v6ops on behalf of Tom Herbert >> > Sent: Thursday, February 21, 2019 9:23:38 PM >> > To: Fernando Gont >> > Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ >> > Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "r= enumbering" scenarios) >> > >> > On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont = wrote: >> > > >> > > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote: >> > > > >> > > > I agreee with that with one exception. I believe that NAT/IPv4= can >> > > > offer better privacy in addressing than IPv6 given current add= ess >> > > > allocation methods. >> > > > >> > > > I'm for as much privacy as possible, however, not at the cost of t= hings such as: >> > > > - Unnecessary complexity increase >> > > > - Moving from peer-to-peer to client-server for everything >> > > > - Single point of failure >> > > > - Increasing the attacks chances by reducing the surface to the se= rvers >> > > > - Increase the complexity of app development >> > > > - Complexity to host services in "clients" >> > > > - Complexity to use "freely" and "efficient" DNS >> > > > - etc >> > > >> > > There are two protocols associated with NATs: >> > > 1) Apps that incorporate IP addresses and ports in the app protocol >> > > require an ALG >> > > 2) Because of of the "only allow outgoing connections" side-effect o= f >> > > NATs, you need UPnP to open holes in the NAT, or some NAT traversal >> > > technique. >> > > >> > > >> > > "1)" goes away when you remove the NAT. >> > > >> > > "2)" does not if you replace the NAT with a stateful firewall that o= nly >> > > allows outgoing connections. -- the majority of the IPv6 deployments >> > > I've seen use this policy/model. And, of course, this is also a sing= le >> > > point of failure, will also increase application complexity, etc., e= tc., >> > > etc. >> > >> > So we need to eliminate stateful firewalls as well as NAT... >> > >> > Tom >> > >> > > >> > > >> > > >> > > -- >> > > 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 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Feb 22 02:27: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 00C60129524 for ; Fri, 22 Feb 2019 02:27:09 -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, HTML_MESSAGE=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 gteiBn7x3N_K for ; Fri, 22 Feb 2019 02:27:06 -0800 (PST) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 1933B129532 for ; Fri, 22 Feb 2019 02:27:05 -0800 (PST) Received: from [192.168.1.119] (host-79-121-38-138.kabelnet.hu [79.121.38.138]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x1MAQsHe052724 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 22 Feb 2019 11:27:01 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-38-138.kabelnet.hu [79.121.38.138] claimed to be [192.168.1.119] To: IPv6 Operations References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <4eac4cf8-a231-2221-e390-86ff55f63d64@hit.bme.hu> Date: Fri, 22 Feb 2019 11:26:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A3EB70BEA06FF0D80391CAAC" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.38.138; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] 464XLAT -- Re: NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 10:27:09 -0000 This is a multi-part message in MIME format. --------------A3EB70BEA06FF0D80391CAAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Cameron, 2/22/2019 5:08 AM keltezéssel, Ca By írta: [...] > +1, i have had a good experience removing stateful devices for the > majority of flows from a large mobile network over the last 5 years as > we transitioned for 464xlat.   No downsides. However, 464XLAT also contains Stateful NAT64 (as PLAT). Have you experienced any problems with that? (E.g. bottleneck, no scale up, etc.) Full disclosure: - I am soliciting your experience for our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", available at: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02 - I personally think that 464XLAT is a good IPv4aaS solution, I am just playing the devil's advocate. Best regards, Gábor Lencse --------------A3EB70BEA06FF0D80391CAAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Cameron,

2/22/2019 5:08 AM keltezéssel, Ca By írta:

[...]
+1, i have had a good experience removing stateful devices for the majority of flows from a large mobile network over the last 5 years as we transitioned for 464xlat.   No downsides.

However, 464XLAT also contains Stateful NAT64 (as PLAT). Have you experienced any problems with that? (E.g. bottleneck, no scale up, etc.)

Full disclosure:
- I am soliciting your experience for our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", available at: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02
- I personally think that 464XLAT is a good IPv4aaS solution, I am just playing the devil's advocate.

Best regards,

Gábor Lencse
--------------A3EB70BEA06FF0D80391CAAC-- From nobody Fri Feb 22 04:37: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 EB68912D84D; Fri, 22 Feb 2019 04:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_f-Hjpi7l14; Fri, 22 Feb 2019 04:37:20 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83264124BF6; Fri, 22 Feb 2019 04:37:20 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x1MCauMN028797 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2019 12:36:56 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Christian Huitema Cc: JORDI PALET MARTINEZ , Tom Herbert , Mark Smith , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> From: Nick Hilliard Message-ID: <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> Date: Fri, 22 Feb 2019 12:36:55 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.10 MIME-Version: 1.0 In-Reply-To: <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 12:37:22 -0000 Christian Huitema wrote on 22/02/2019 07:44: > Debating the beauty of NAT on an IPv6 list is surely good fun for some, > but could we get some progress on the original issue, which could be > summed up as a "bug in SLAAC"? Fernando filed that bug 3 weeks ago, I > saw hundreds of messages on the mailing list, but I did not see much > progress. There seems to be lack of consensus on whether this can be thrown into the "bug in SLAAC" category. Ole declared that the root cause was "misconfiguration/error". Fernando and others feel that it's the compound outcome of several independent protocol and design-choice behaviours, none of which, incidentally, is inherently broken per se. > Do we agree that this is indeed a bug, or do we think that having users > disconnected from the Internet after a home router reboots is just a > desirable feature of IPv6? Most people feel the outcome is undesirable when it happens. Some people feel that it's not worth getting too excited about because assignment stickiness tends to ensure that prefix assignments are long-lived enough that it probably won't cause too much difficulty. Others noted that long SLAAC lifetimes and lack of application workarounds (HE, etc) would make it a noticeable problem, when it happens, but didn't comment on how frequently it happened. > Do we agree that it would be good if routers that reboot could just > reacquire the same prefix from DHCPv6 PD? Most operators seem to provision their networks such that they will not commit to prefix stability over the lifetime of a customer contract unless the customer coughs up more money for it. Hand in hand with this, static ip addressing is routinely handled differently to dynamic IP addressing on service provider networks. > Do we also agree that there > will always be a significant fraction of deployment in which that won't > be possible? This is a complex question which interplays with cost, network design and long term network complexity. There is no easy answer to it. > Do we agree that the working group should actually start working on some > improvement in SLAAC that would mitigate the issue? Not excluding of > course solutions that would also mitigate related egress filtering issue? Fixing or updating SLAAC is likely to take years to roll out and at least one person was of the opinion that SLAAC was basically unfixable in this regard. This ignores whether it would be useful or viable for the IETF to issue advice to CPE vendors and service providers about how to avoid the problem from happening in the first place. Ultimately, your email shows why the discussion ended up in a discussion about NAT. There's no single cause of the problem and no quick fix; declaring the problem to be solely the domain of any particular stakeholder may cause CPE vendors to deploy NPTv6 in the long term to work around the issue, because this would make the problem mostly disappear from the point of view of the user. There is a cost, of course, but it's a cost which most end users are already familiar with, and accept. It would be sad and unfortunate if this were to be the outcome of this discussion. Nick From nobody Fri Feb 22 06:24: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 0C8061200D7 for ; Fri, 22 Feb 2019 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPcPgTELdJQ0 for ; Fri, 22 Feb 2019 06:24:35 -0800 (PST) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04981128766 for ; Fri, 22 Feb 2019 06:24:35 -0800 (PST) Received: by mail-yw1-xc2c.google.com with SMTP id s204so884493ywg.2 for ; Fri, 22 Feb 2019 06:24:34 -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=JgXwd8aohGOQEiRin3Xdsd6YkwFOKpLjNSVkemH71Qg=; b=eC6t9jTTG5Nc/Y213pmATzwlFBCdg/YJJmw054oVsYVz+Tgk5hMOhkBntdGI+YswHZ ttmcbRXf+f/8n6tKPmeUUiGS9TQXt/VClqWXVJAC5upWfXsUwUGrR4uMG3K6IblQcpyJ XizNkJxJZqKt28ZARarDvzSgQ9JJMuDY4wnmUvt9eITKwKESo3pHdcshNqXLd/QWrWkk sQkGlz9Jymbyv49gy43UZ3t+8WYSS56vExNFDM+fyGWWrkJS6qa75gx2m6uSOCimYwjt IMVUEw3zLCS9lSKazFysVMaGYaWzKYBhrlfJzls7edHWHvmSXtKCrig3JTrJYsgpZFy2 Mn9g== 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=JgXwd8aohGOQEiRin3Xdsd6YkwFOKpLjNSVkemH71Qg=; b=Q9GW8NT0jlid04lcu8xKM21EVRZ5MxBRcxkPUEIn8HFC+6sl6RPAeU/YWtCtQUcU5p rwkltbOomjzumJscfstKOLZ9tkEmMqJqj0Wt6BBvdkGsEVKHquDddmM/or22hUu0leE3 MGhsiZSDwkftd086hmET9mguDsECWzXovVf64+zPOk1JHuFnz83TsgRkEUfSbSbWZTjb 8S+Db/nVR7vp0PHRKHidpxrGaTZ5JEKJmBc0+8+p4ANRt/CM+u/52SvgEgUXaNE68/YD O63aodBsssRlad152AL/waBFEisphuHRY4cO4Jb2BjLjmsi0XYAtuAuZzenVts9UXldc fV7A== X-Gm-Message-State: AHQUAubIchwA+3kWcDfEZF5JfqcAbYqf5BDZL2tbmIwL6xceSCapRtBN k/QjNAOhMs5EO9Az8Js4yInZi8WQbWuwFf9G22k= X-Google-Smtp-Source: AHgI3IaeUlsVURqOE6xwue5nAe0Gl8luoyJTwyNkkaAEA8pOQaINSiRUpIiEdNgTZJKdKj1VcNgbBPrKGdDaRHj6T6Y= X-Received: by 2002:a81:98cf:: with SMTP id p198mr3545943ywg.54.1550845473765; Fri, 22 Feb 2019 06:24:33 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> <4eac4cf8-a231-2221-e390-86ff55f63d64@hit.bme.hu> In-Reply-To: <4eac4cf8-a231-2221-e390-86ff55f63d64@hit.bme.hu> From: Ca By Date: Fri, 22 Feb 2019 07:24:22 -0700 Message-ID: To: =?UTF-8?Q?Lencse_G=C3=A1bor?= Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="00000000000090be7405827c591e" Archived-At: Subject: Re: [v6ops] 464XLAT -- Re: NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 14:24:37 -0000 --00000000000090be7405827c591e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 3:27 AM Lencse G=C3=A1bor wrote= : > Dear Cameron, > > 2/22/2019 5:08 AM keltez=C3=A9ssel, Ca By =C3=ADrta: > > [...] > > +1, i have had a good experience removing stateful devices for the > majority of flows from a large mobile network over the last 5 years as we > transitioned for 464xlat. No downsides. > > > However, 464XLAT also contains Stateful NAT64 (as PLAT). Have you > experienced any problems with that? (E.g. bottleneck, no scale up, etc.) > Correct, that is why i said =E2=80=9Cmajority=E2=80=9D of flows No, our NAT64 is the same box as the NAT44 This means that as soon as a client moves from ipv4 NAT44 to NAT64 the client load on the box moves from 100% of traffic needing NAT44 to clients only sending less than 35% of traffic to that box. > > Full disclosure: > - I am soliciting your experience for our draft "Pros and Cons of IPv6 > Transition Technologies for IPv4aaS", available at: > https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02 > - I personally think that 464XLAT is a good IPv4aaS solution, I am just > playing the devil's advocate. > > Best regards, > > G=C3=A1bor Lencse > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000090be7405827c591e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 22, 2019 at 3:27 AM Lencse G=C3=A1bor <lencse@hit.bme.hu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =20 =20 =20
Dear Cameron,

2/22/2019 5:08 AM = keltez=C3=A9ssel, Ca By =C3=ADrta:

[...]
=20
+1, i have had a good experience removing stateful devices for the majority of flows from a large mobile network over the last 5 years as we transitioned for 464xlat. =C2=A0 No downsides.

However, 464XLAT also contains Stateful NAT64 (as PLAT). Have you experienced any problems with that? (E.g. bottleneck, no scale up, etc.)

C= orrect, that is why i said =E2=80=9Cmajority=E2=80=9D of flows

No, our NAT64 is the same box as the= NAT44

This means that a= s soon as a client moves from ipv4 NAT44 to NAT64 the client load on the bo= x moves from 100% of traffic needing NAT44 to clients only sending less tha= n 35% of traffic to that box.=C2=A0



Full disclosure:
- I am soliciting your experience for our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", available at: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-= 02
- I personally think that 464XLAT is a good IPv4aaS solution, I am just playing the devil's advocate.

Best regards,

G=C3=A1bor Lencse
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000090be7405827c591e-- From nobody Fri Feb 22 08:36: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 6988F130EE4 for ; Fri, 22 Feb 2019 08:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9pJnUmuJ6d1 for ; Fri, 22 Feb 2019 08:36:22 -0800 (PST) Received: from atl4mhob10.registeredsite.com (atl4mhob10.registeredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 58F1C130ED8 for ; Fri, 22 Feb 2019 08:36:22 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob10.registeredsite.com (8.14.4/8.14.4) with ESMTP id x1MGaKOG027715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 22 Feb 2019 11:36:20 -0500 Received: (qmail 4980 invoked by uid 0); 22 Feb 2019 16:36:20 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Feb 2019 16:36:20 -0000 To: ipv6@ietf.org, IPv6 Ops WG References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> From: Lee Howard Message-ID: <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> Date: Fri, 22 Feb 2019 11:36:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------303D1DAE42CA8ED37CD5213C" Content-Language: en-US Archived-At: Subject: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 16:36:24 -0000 This is a multi-part message in MIME format. --------------303D1DAE42CA8ED37CD5213C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I think I have heard the following suggestions in this conversation. I hope that taken all together, rather than as individual spot solutions, they can be a consensus recommendation. ISPs should, as much as possible, reissue the same prefix to customers. Some things ISPs can do to increase the chances of this: 1. Share lease information between redundant DHCPv6 servers. Most ISPs probably have redundant servers, since this is critical provisioning infrastructure. It may be difficult to synch information between servers for millions of leases over tens of milliseconds of latency; see RFC6853, "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP vendors can report. 2. Aggregate above the provider edge device, so that grooming customers between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a few years since I worked on CMTSs, but when I did they did not support MP-BGP well (if at all), so routes had to be aggregated on the PE, or leaked in the IGP which is bad for convergence time. Maybe PE vendors can report. 3. Set DHCPv6 lease timers very low prior to grooming events. A short interval during the maintenance window will increase load on the DHCPv6 server until timers have been returned to normal values. 4. In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the routing table. I think all of the necessary information is in those responses. Again, last time I was working on CMTSs, this feature was not supported. Maybe PE vendors can report. Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience: 1. Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot. 2. Use dynamic DNS and shorter TTLs. 3. Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense. In the case of failures, it cannot be assumed that sessions will stay active. We try to build in redundancy and resilience where we can, but where there's a single point of failure (such as CE or PE), and it fails (such as an unplanned reboot), our expectations should be appropriate. Is this a reasonable summary? Lee --------------303D1DAE42CA8ED37CD5213C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I think I have heard the following suggestions in this conversation. I hope that taken all together, rather than as individual spot solutions, they can be a consensus recommendation.


ISPs should, as much as possible, reissue the same prefix to customers. Some things ISPs can do to increase the chances of this:

  1. Share lease information between redundant DHCPv6 servers. Most ISPs probably have redundant servers, since this is critical provisioning infrastructure. It may be difficult to synch information between servers for millions of leases over tens of milliseconds of latency; see RFC6853, "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP vendors can report.

  2. Aggregate above the provider edge device, so that grooming customers between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a few years since I worked on CMTSs, but when I did they did not support MP-BGP well (if at all), so routes had to be aggregated on the PE, or leaked in the IGP which is bad for convergence time. Maybe PE vendors can report.

  3. Set DHCPv6 lease timers very low prior to grooming events. A short interval during the maintenance window will increase load on the DHCPv6 server until timers have been returned to normal values.

  4. In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the routing table. I think all of the necessary information is in those responses. Again, last time I was working on CMTSs, this feature was not supported. Maybe PE vendors can report.


Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:

  1. Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.

  2. Use dynamic DNS and shorter TTLs.

  3. Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.


In the case of failures, it cannot be assumed that sessions will stay active. We try to build in redundancy and resilience where we can, but where there's a single point of failure (such as CE or PE), and it fails (such as an unplanned reboot), our expectations should be appropriate.

Is this a reasonable summary?

Lee







--------------303D1DAE42CA8ED37CD5213C-- From nobody Fri Feb 22 08: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 2ED6F130ED8 for ; Fri, 22 Feb 2019 08:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 gH92XWaQ4hgK for ; Fri, 22 Feb 2019 08:45:08 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 0B135130ECD for ; Fri, 22 Feb 2019 08:45:08 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gxDwf-000C11-34 for v6ops@ietf.org; Fri, 22 Feb 2019 17:45:06 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gxDwZ-0000ni-P2 for v6ops@ietf.org; Fri, 22 Feb 2019 11:45:03 -0500 Received: (qmail 13420 invoked from network); 22 Feb 2019 16:44:58 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <6man@ietf.org>; 22 Feb 2019 16:44:57 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16D57) In-Reply-To: <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> Date: Fri, 22 Feb 2019 08:44:55 -0800 Cc: JORDI PALET MARTINEZ , Tom Herbert , Mark Smith , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> To: Nick Hilliard X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.21) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5mIcSwB5GPBtxo+7Kmp4PGx602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9AxfJ4CrqkUTuuMGVsG78VHUVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5CmLguVI7uaKQZnk5mHowEU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMR0q/8r+vli3P7r8BoPzXffG1JhEiAOdl0Bn/vyebShl+/yIVE9fjnl JfamFMKDmCNqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+RA1ehb6HWONF4LFnY3FB8iDg5/bq7ChmPMN Ycw1QSmRHe5rnYh9P6tLDh5EyXErYkULTOklG2cVzBAagMrdh/Rm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhih19I4GlR3I7yPSC6eTb8vy+NTKQHNkjJg8xvPcdYB8XrwJaVYn9nnZjaUrj DGzQ2f27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 22 Feb 2019 16:45:12 -0000 =20 > On Feb 22, 2019, at 4:36 AM, Nick Hilliard wrote: >=20 > Christian Huitema wrote on 22/02/2019 07:44: >> Debating the beauty of NAT on an IPv6 list is surely good fun for some, >> but could we get some progress on the original issue, which could be >> summed up as a "bug in SLAAC"? Fernando filed that bug 3 weeks ago, I >> saw hundreds of messages on the mailing list, but I did not see much >> progress. >=20 > There seems to be lack of consensus on whether this can be thrown into the= "bug in SLAAC" category. >=20 > Ole declared that the root cause was "misconfiguration/error". >=20 > Fernando and others feel that it's the compound outcome of several indepen= dent protocol and design-choice behaviours, none of which, incidentally, is i= nherently broken per se. >=20 >> Do we agree that this is indeed a bug, or do we think that having users >> disconnected from the Internet after a home router reboots is just a >> desirable feature of IPv6? >=20 > Most people feel the outcome is undesirable when it happens. Some people f= eel that it's not worth getting too excited about because assignment stickin= ess tends to ensure that prefix assignments are long-lived enough that it pr= obably won't cause too much difficulty. Others noted that long SLAAC lifetim= es and lack of application workarounds (HE, etc) would make it a noticeable p= roblem, when it happens, but didn't comment on how frequently it happened. I think that's a good summary: a problem that does not occur very often, but= is very annoying when it does. >=20 >> Do we agree that it would be good if routers that reboot could just >> reacquire the same prefix from DHCPv6 PD? >=20 > Most operators seem to provision their networks such that they will not co= mmit to prefix stability over the lifetime of a customer contract unless the= customer coughs up more money for it. Hand in hand with this, static ip ad= dressing is routinely handled differently to dynamic IP addressing on servic= e provider networks. >=20 >> Do we also agree that there >> will always be a significant fraction of deployment in which that won't >> be possible? >=20 > This is a complex question which interplays with cost, network design and l= ong term network complexity. There is no easy answer to it. I think that your response to the previous question also sums up this side o= f the issue. Many operators do provision fairly stable prefixes. However, fo= r a set of complicated reasons, not all of them will guarantee this stabilit= y, not all the time. The answer there could very well be to do nothing, and t= o not add another mandate to operators. >=20 >> Do we agree that the working group should actually start working on some >> improvement in SLAAC that would mitigate the issue? Not excluding of >> course solutions that would also mitigate related egress filtering issue?= >=20 > Fixing or updating SLAAC is likely to take years to roll out and at least o= ne person was of the opinion that SLAAC was basically unfixable in this rega= rd. This ignores whether it would be useful or viable for the IETF to issue= advice to CPE vendors and service providers about how to avoid the problem f= rom happening in the first place. Anything we do in this space can take a long time to roll out, but it does n= ot take forever. In many cases it probably takes less time than it takes to a= gree on a potential solution in the IETF. For example, security bugs in oper= ating systems can get patched in a matter of weeks or maybe months. Not all d= evices can be patched quickly, but many can. As usual, we don't want to see creative solutions popping in different devic= es. A common standard seems preferable. So, if a subset of the working group= wants to work on the solution, we should be happy to let them do that. -- Christian Huitema=20= From nobody Fri Feb 22 09:04: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 0CA55130F06; Fri, 22 Feb 2019 09:04:46 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 iC28CaRHPLxE; Fri, 22 Feb 2019 09:04:44 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3D0130EEE; Fri, 22 Feb 2019 09:04:43 -0800 (PST) Received: from [IPv6:2620::930:0:cd1e:5233:3f23:c8d8] ([IPv6:2620:0:930:0:cd1e:5233:3f23:c8d8]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x1MH4cMX029861 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Feb 2019 09:04:38 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x1MH4cMX029861 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1550855078; bh=UfrKlN71t6uJn1zCbFV4gpxoNRnlCMt8Rd2csgQWMt4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=4Q+s3zexEScOXvn37gLRm7Vmq/LbzpAAxot2WfH4MpU/ErMN5Mgfq3GdG2WCrFkGJ Ojq8jGc5qKw1E2//boU3OGoRW84D6M8wWf5lj47CgOnBc+5wR4wUqRa8qJhy7BeIxW b8k1Y+hitp+G/N4ym2HkWkzUxdIMArioY90f4jY4= Content-Type: multipart/alternative; boundary=Apple-Mail-3E243873-3335-4E4B-9059-B59F46846C6B Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (16D57) In-Reply-To: <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> Date: Fri, 22 Feb 2019 09:04:38 -0800 Cc: ipv6@ietf.org, IPv6 Ops WG Content-Transfer-Encoding: 7bit Message-Id: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> To: Lee Howard 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]); Fri, 22 Feb 2019 09:04:38 -0800 (PST) Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 17:04:46 -0000 --Apple-Mail-3E243873-3335-4E4B-9059-B59F46846C6B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Networks should, as much as possible, be resilient to prefix changes. Some= things networks can do to improve resilience: > Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for= that prefix on reboot. > Use dynamic DNS and shorter TTLs. > Implement something like NETCONF to distribute prefix information to polic= y devices like firewalls or SD-WAN controllers. I think a separate document d= escribing this application of NETCONF would make sense. If the prefix is written to nv men, wouldn=E2=80=99t it also be possible for= implementers to send rapid deprecation RAs for any prefix not renewed? In other words, after reboot, try to reacquire same prefix. If that doesn=E2= =80=99t work, when you advertise the new prefix, you could also include the o= ld prefix with a very short preferred and valid lifetime (e.g. 1 second) in t= he first RA, which should be sent to the all nodes on link multicast? It doesn=E2=80=99t eliminate the problem, but 1 second additional duration w= ould be barley noticeable amid the minute or so it takes most home gateways t= o reboot.=20 Owen --Apple-Mail-3E243873-3335-4E4B-9059-B59F46846C6B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Ne= tworks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:

  1. Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.

  2. Use dynamic DNS and shorter TTLs.

  3. Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.

=20

If the prefix is written to nv men, wouldn= =E2=80=99t it also be possible for implementers to send rapid deprecation RA= s for any prefix not renewed?

In other words, after reboo= t, try to reacquire same prefix. If that doesn=E2=80=99t work, when you adve= rtise the new prefix, you could also include the old prefix with a very shor= t preferred and valid lifetime (e.g. 1 second) in the first RA, which should= be sent to the all nodes on link multicast?

It doe= sn=E2=80=99t eliminate the problem, but 1 second additional duration would b= e barley noticeable amid the minute or so it takes most home gateways to reb= oot. 

Owen

= --Apple-Mail-3E243873-3335-4E4B-9059-B59F46846C6B-- From nobody Fri Feb 22 09:05: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 17759130FE2; Fri, 22 Feb 2019 09:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJODLQWa2O6z; Fri, 22 Feb 2019 09:05:16 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0B8130F8A; Fri, 22 Feb 2019 09:05:15 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 9373C3826C; Fri, 22 Feb 2019 12:05:03 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id DA2B21DBD; Fri, 22 Feb 2019 12:05:13 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D7A3D1DB1; Fri, 22 Feb 2019 12:05:13 -0500 (EST) From: Michael Richardson To: Lee Howard cc: ipv6@ietf.org, IPv6 Ops WG In-Reply-To: <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 17:05:22 -0000 --=-=-= Content-Type: text/plain Lee Howard wrote: > 2 > Aggregate above the provider edge device, so that grooming customers > between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a > few years since I worked on CMTSs, but when I did they did not support > MP-BGP well (if at all), so routes had to be aggregated on the PE, or > leaked in the IGP which is bad for convergence time. Maybe PE vendors can > report. I don't understand this comment/concern about convergence time. I was the architect at a PE vendor (PPPoE, not CMTS, but from the north-interface, it is pretty similar) for a numbers of years. [2012 to 2017, parttime]. We didn't support BGP; we got no call for it as an IGP. We supported OSPF/OSPFv3, and we assumed aggregation above the provider edge devices. We counselled our customers to make an OSPF area for this, and so it naturally aggregated above, and the customer grooming did not leak out of the area. Few of our customers' IPv6 usage grew very much during this time, so I can't say if this turned out to be a problem. The customers for whom this was a problem architecturally had the problem that their network was so small that they the "above" point was their EBGP device anyway. We're talking about rather small ISPs with O(10^3) customers here :-) (that would be the entire country/island) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxwK8kACgkQgItw+93Q 3WXYuAf/VQs4mShB/KRn2GShtLCZ2RcD+OowNC6bpTcaSJa2Hko+75X7g2ZT8yOF DO41LSyPoeV4aObyPAenlXTBYbqMlapqlfp8hHBlTLpqlgjYCo0ia3YMt1LCf55p xqIp4ZhzlhvfuMHpwamKs5DYQ43SstdgrUcbFXzGavCSTEviM/Q75zj9xgMrUsZ5 HKTuRasYyPRhlIBoewfl4hdyA/9y5emL2TuLn9G5FXww8eSmECwlSj2nLLErBcPZ 9oBWSzfh4cWaTIzk5SY+EuSvvi3UluRemupyEw3j4MVlUWilY3dvSm3mMR0BJ2TZ gxm/k7YmljOCNbx4+gPd2Piunzv0MA== =NsgA -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 22 09:11: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 CB6A6130F32 for ; Fri, 22 Feb 2019 09:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 VVJIyUHX_Lnb for ; Fri, 22 Feb 2019 09:11:22 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16E8130F14 for ; Fri, 22 Feb 2019 09:11:21 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id s1so3307477qte.5 for ; Fri, 22 Feb 2019 09:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HhY23CnDz/ABwxl23wmePBRcOWqV/h5kk2zb2avDqQs=; b=ejR53xV8fcDqDT1uWpY2LtkWdgKTSfTiUpxjkG8fg0CsqKkjsm4k7I5ZvPdiCIMtoR 13wmueOZJZ7XaL9XaBDFZN9HtVA4RL+L9xlDeHHENUhww+hxFVu1uQPeaMIcGPVwL3Ul e02Q0IPaLzffuoDZuxJlZ5pNGb7qc+Hbt390Qd2JJUYPs2NSmc4kzQzWuV9dgqEdyhpq dJpFaYJABuPCwm0Bs7isq5rnn+8/IP6CnM6Gz0qZ8nPcp5ZHM/IL0YUFO5F1kM7lgNZp uDGTJRrOXRqJX5LeIYq+7+BWBSKgnV8xQeTXj7CBkpxkDSvrFya2G8N7PE+1+vrJjwtT yYHg== 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=HhY23CnDz/ABwxl23wmePBRcOWqV/h5kk2zb2avDqQs=; b=EL7BRWYdIrvvQ4Kj45ZNV3ZYVQv2yzThMLzlPOT4XmXgt3rxhYsX/jITpNBmOAd//4 R6Mr0niLYYtEgxm63/5OoKB5b+Xu9k7BrqlzVDEhkK9JXWAnXIYpgLEMej6U/fzv2R/Q wRAEvATV0837Qt5NOFGYymaKwlekDtd8MPZwjmQkvq34dWICYPyVYo3cz7wrs6wfjuep kcI2wmbWk4KdsnSdSBSA4FJKTy9XOHqMRTXchyve++b0b7+qLsqulp6sN4dKvvEryfgA sAyDD78pj9TM8wlIH1Xu+cZtSWmnH03WKOuZxOmLKdnZ723qlB4gZPShVfqJb6yoqtMh y8yg== X-Gm-Message-State: AHQUAuadm3/Ux71H2iR/pn4fKrqGxh/hctVhM911pNmtc1avrXlMgrF7 94qurdiqQF8l0QIinTl1p3Fht4oQyV4mS+MnyT5tVg== X-Google-Smtp-Source: AHgI3IbIFqUjbi7vOPnxWWJaQamHmzKhlcq5EHWaYWTvMJc/mub07qGPvAsEKy2mX/gAMQyyooD4+8aQoEOVzdkVFvg= X-Received: by 2002:a0c:8dc2:: with SMTP id u2mr3969836qvb.168.1550855480581; Fri, 22 Feb 2019 09:11:20 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Tom Herbert Date: Fri, 22 Feb 2019 09:11:09 -0800 Message-ID: To: Mark Smith Cc: "Manfredi (US), Albert E" , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 17:11:24 -0000 On Thu, Feb 21, 2019 at 11:35 PM Mark Smith wrote: > > Hi Tom, > > On Fri, 22 Feb 2019 at 10:04, Tom Herbert wrote: > > > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith wrote: > > > > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E > > > wrote: > > > > > > > > > > > > > So I think there's commonly a big different between works and works > > > well. NAT may work, however compared to stateless IPv6 (and IPv4) > > > forwarding, it doesn't work anywhere as near as well. > > > > > Mark, > > > > I agreee with that with one exception. I believe that NAT/IPv4 can > > offer better privacy in addressing than IPv6 given current addess > > allocation methods. > > > > So I don't think addressing privacy via NAT is really all that > valuable if there are many other ways, some quite easy, to uniquely > identify an anonymity desiring end-point/end-user, whose effectiveness > aren't impacted at all by NAT. > > For example, this website is coming over IPv4 for me, and I'm using > IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn't > be able to tracked. > > https://amiunique.org/ > > Yet it is saying I can be with both Chrome and Firefox on Fedora 29 in > Incognito/Private windows mode on this host. It says the same about my > Android 9 phone with Chrome in Incognito mode. > > Going into the detail of how, they don't seem to be using IP address > at all for any identification, it is all browser attributes. > > We have IPv6 temporary addresses, which makes using addresses harder > to use to identify a node. I think that is a lot better than nothing. Mark, Yes, but by that same rationale a simple substitution cipher is better than nothing in cryptography! What pretty much any conversation about privacy in addressing seems to lacking is a quantitative description of privacy and any empiracal data on the impact that privacy mechanisms, like those defined in RFC4941, have had. You might say it "makes using addresses harder to use to identify a node". But then the obvious question is _how_ much harder? Is this really protecting anyone's privacy, or it is just a minor inconvenience to attackers and only giving users a false sense of security? The irony is that CGN seems to have the best supporting evidence for being a mechanism that impacts privacy, but it was never even intended to be a privacy mechanism. The evidence is in the form of concerns form law enforcement that the privacy side effect is too strong and impedes their investigations (https://www.theregister.co.uk/2017/10/18/europol_cgnat/). So I don't think "Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity?" is the right question. The right question to ask is "Is addressing privacy via any IETF defined mechanism achieving much compared to a privacy goal of anonymity?" Tom > However, I don't see how IPv6 NAT would improve it much, and it > introduces the other drawbacks of NAT. > > Regards, > Mark. > > > > > > > > > > > > > > Tom > > > > > Regards, > > > Mark. > > > > > > > > > > > > > Bert > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 22 09:30:33 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 4649A12EB11 for ; Fri, 22 Feb 2019 09:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_TEMPERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMN_VNXQRGaD for ; Fri, 22 Feb 2019 09:30:21 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27B1130F27 for ; Fri, 22 Feb 2019 09:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1550856618; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ANQxV2pb5yUq5vJN/tqRNZL3c1rJguZtqy4OhMNMWrk=; b=EZeJ254giw0maPLFM/WQLjJN62In5SkDhodRvkCUNFREO+SlhLtaHnZ+yILfkECmXtbps11kwAK0YWwu/gcfOU5ndMee0EFvutyZhZoGtOXu46M8j7R7kirJs1jc6LQxPd5Cixw4mMnRDdaNjf9W+IfxmVuexSsamgT94UjH3dA= Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2054.outbound.protection.outlook.com [104.47.13.54]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-184-jia-mL8QPFuZkEaSLUZdIg-2; Fri, 22 Feb 2019 17:30:15 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.54.140) by AM0PR07MB3988.eurprd07.prod.outlook.com (52.134.80.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Fri, 22 Feb 2019 17:30:11 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb%4]) with mapi id 15.20.1665.008; Fri, 22 Feb 2019 17:30:11 +0000 From: Tim Chown To: Owen DeLong CC: Lee Howard , IPv6 Ops WG , "ipv6@ietf.org" Thread-Topic: [v6ops] Stability and Resilience (was Re: A common...) Thread-Index: AQHUytDKOAr/QA2oqUmIfoA6xQEuxqXsEuSA Date: Fri, 22 Feb 2019 17:30:11 +0000 Message-ID: <763ED571-AC76-419A-A0B6-43F9AC763F53@jisc.ac.uk> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-originating-ip: [2001:a88:d510:1101:28c8:aca5:5953:beb6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7e71d4ea-fa7e-411d-5304-08d698eb662f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB3988; x-ms-traffictypediagnostic: AM0PR07MB3988: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: 1; AM0PR07MB3988; 20:UE4BXX0p+bBhfDJO29b0Lx1zOylzuzuRdTK9m5GP5h9crV5vipgIUnVxUX3fzSFRTx1wssXUYlDXYzYH8CnO2X83KCUitKgLmW03YIVJGpSC3ermWv8Mt1RnfInD4UREKZ3GFzdgCNS2WNloD0Wfla1cokCQa1QXZzsCBva3Rzk= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39860400002)(346002)(366004)(396003)(199004)(189003)(76176011)(6506007)(68736007)(236005)(786003)(81156014)(106356001)(25786009)(53546011)(316002)(4326008)(57306001)(74482002)(53936002)(8676002)(6116002)(54906003)(6512007)(14454004)(229853002)(54896002)(6306002)(105586002)(50226002)(86362001)(606006)(102836004)(81166006)(99286004)(446003)(46003)(7736002)(72206003)(476003)(8936002)(6486002)(82746002)(6246003)(11346002)(71200400001)(71190400001)(83716004)(5660300002)(33656002)(93886005)(6436002)(97736004)(256004)(2616005)(36756003)(2906002)(486006)(186003)(6916009)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB3988; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mmEqGzEW4QFmvj2lqb1Rcr47DJgHT/pV3PmD4VMa/BKRCHt0Cp3HQ6ynVqt0tuJx5RPeD1XZ21EfClAoUbRg65qpt+4fJBx1Jg1e5p/L4vltKv3j7xO5WsZzmK2VTP0IXxtlJQJP3d0QNWt/JActaFsioO2P9piQNlkBan8QPy3xoMVZifmhJc2mJi7pchwCNGk2D3wYIzUul19ja6n8s8jSQTaW8eHKpQEKFH2hGogGNLyGheWrMoCRt4FE9MURkz/lrXgAPX5p3rSOx4FAAp0rq7qrXADzJsuiaFTkaubqfFVPkwj9lkEsuOQe1uSDMYiNHjiFDD4cFNZU8MfudXmnNxCLnYLH8kr8VWTZ6D2JgcWPKG7g8aXnOSg9s5vDOVCM+hLjwgW0FhFoTB6n2AnVzam8M6M1uQykrQXAtsc= MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 7e71d4ea-fa7e-411d-5304-08d698eb662f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 17:30:11.7487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3988 X-MC-Unique: jia-mL8QPFuZkEaSLUZdIg-2 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_763ED571AC76419AA0B643F9AC763F53jiscacuk_" Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 17:30:24 -0000 --_000_763ED571AC76419AA0B643F9AC763F53jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCk9uIDIyIEZlYiAyMDE5LCBhdCAxNzowNCwgT3dlbiBEZUxvbmcgPG93ZW5AZGVsb25n LmNvbTxtYWlsdG86b3dlbkBkZWxvbmcuY29tPj4gd3JvdGU6DQoNCk5ldHdvcmtzIHNob3VsZCwg YXMgbXVjaCBhcyBwb3NzaWJsZSwgYmUgcmVzaWxpZW50IHRvIHByZWZpeCBjaGFuZ2VzLiBTb21l IHRoaW5ncyBuZXR3b3JrcyBjYW4gZG8gdG8gaW1wcm92ZSByZXNpbGllbmNlOg0KDQogIDEuDQoN Cg0KV3JpdGUgYSBsZWFybmVkIHByZWZpeCB0byBub24tdm9sYXRpbGUgbWVtb3J5IGFuZCBpc3N1 ZSBhIERIQ1B2NiBSZW5ldyBmb3IgdGhhdCBwcmVmaXggb24gcmVib290Lg0KDQogIDIuDQoNCg0K VXNlIGR5bmFtaWMgRE5TIGFuZCBzaG9ydGVyIFRUTHMuDQoNCiAgMy4NCg0KDQpJbXBsZW1lbnQg c29tZXRoaW5nIGxpa2UgTkVUQ09ORiB0byBkaXN0cmlidXRlIHByZWZpeCBpbmZvcm1hdGlvbiB0 byBwb2xpY3kgZGV2aWNlcyBsaWtlIGZpcmV3YWxscyBvciBTRC1XQU4gY29udHJvbGxlcnMuIEkg dGhpbmsgYSBzZXBhcmF0ZSBkb2N1bWVudCBkZXNjcmliaW5nIHRoaXMgYXBwbGljYXRpb24gb2Yg TkVUQ09ORiB3b3VsZCBtYWtlIHNlbnNlLg0KDQpJZiB0aGUgcHJlZml4IGlzIHdyaXR0ZW4gdG8g bnYgbWVuLCB3b3VsZG7igJl0IGl0IGFsc28gYmUgcG9zc2libGUgZm9yIGltcGxlbWVudGVycyB0 byBzZW5kIHJhcGlkIGRlcHJlY2F0aW9uIFJBcyBmb3IgYW55IHByZWZpeCBub3QgcmVuZXdlZD8N Cg0KSW4gb3RoZXIgd29yZHMsIGFmdGVyIHJlYm9vdCwgdHJ5IHRvIHJlYWNxdWlyZSBzYW1lIHBy ZWZpeC4gSWYgdGhhdCBkb2VzbuKAmXQgd29yaywgd2hlbiB5b3UgYWR2ZXJ0aXNlIHRoZSBuZXcg cHJlZml4LCB5b3UgY291bGQgYWxzbyBpbmNsdWRlIHRoZSBvbGQgcHJlZml4IHdpdGggYSB2ZXJ5 IHNob3J0IHByZWZlcnJlZCBhbmQgdmFsaWQgbGlmZXRpbWUgKGUuZy4gMSBzZWNvbmQpIGluIHRo ZSBmaXJzdCBSQSwgd2hpY2ggc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGFsbCBub2RlcyBvbiBsaW5r IG11bHRpY2FzdD8NCg0KSXQgZG9lc27igJl0IGVsaW1pbmF0ZSB0aGUgcHJvYmxlbSwgYnV0IDEg c2Vjb25kIGFkZGl0aW9uYWwgZHVyYXRpb24gd291bGQgYmUgYmFybGV5IG5vdGljZWFibGUgYW1p ZCB0aGUgbWludXRlIG9yIHNvIGl0IHRha2VzIG1vc3QgaG9tZSBnYXRld2F5cyB0byByZWJvb3Qu DQoNClRoYXQncyBzaW1pbGFyIGluIHNwaXJpdCB0byBSQW1vbmQsIHdoaWNoIHdlIHVzZWQgdG8g dXNlIHdoZW4gc2VlaW5nIHJvZ3VlIFJBcyBvbiBvdXIgY2FtcHVzIG5ldHdvcmsuICBJdCB3b3Vs ZCBhdXRvLWRlcHJlY2F0ZSBhbnkgcHJlZml4ZXMgdGhhdCBzaG91bGRuJ3QgYmUgdGhlcmUuICho dHRwOi8vcmFtb25kLnNvdXJjZWZvcmdlLm5ldC8pDQoNClRoZSBzbmFnIGlzIHRoYXQgSSBzdXNw ZWN0IG1vc3QgT1NlcyB3b3VsZCBpZ25vcmUgYSB2YWxpZCB0aW1lciBvZiAxIHNlY29uZCwgZ2l2 ZW4gdGhlIDcyMDAgc2Vjb25kICgyIGhvdXIpIG1pbmltdW0gZGVmaW5lZCBpbiBSRkMgNDg2MiAo dW5sZXNzIHRoZSBSQSBpcyBhdXRoZW50aWNhdGVkLCBzb21laG93KS4gIFRoZSBwcmVmZXJyZWQg dGltZXIgY2FuIGJlIHplcm8uICBXaGVuIFJBbW9uZCB3YXMgd3JpdHRlbiwgaWYgd2UgdXNlZCBh IHZhbGlkIHRpbWVyIGxlc3MgdGhhbiA3MjAwIHNlY29uZHMgaXQgc2VlbWVkIHRoYXQgdGhlIGRl cHJlY2F0aW5nIFJBcyB3ZXJlIGlnbm9yZWQuICBUaGF0IHdhcyAxMCsgeWVhcnMgYWdvIHRob3Vn aC4gIFBlcmhhcHMgVGltIFdpbnRlcnMgaGFzIGRhdGEgb24gd2hldGhlciB0aGF0IHJ1bGUgaXMg aW1wbGVtZW50ZWQgdG9kYXkgaW4gcHJhY3RpY2U7IEknZCBhc3N1bWUgdGhlIHRlc3RzIGhlIHJ1 bnMgbWlnaHQgaW5jbHVkZSB0aGF0Lg0KDQpCdXQgSSBsaWtlIExlZSdzIGFuYWx5c2lzLg0KDQpU aW0NCg== --_000_763ED571AC76419AA0B643F9AC763F53jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <900657E92887C24E9775A2A952D0D79C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXY+SGksPC9kaXY+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P biAyMiBGZWIgMjAxOSwgYXQgMTc6MDQsIE93ZW4gRGVMb25nICZsdDs8YSBocmVmPSJtYWlsdG86 b3dlbkBkZWxvbmcuY29tIiBjbGFzcz0iIj5vd2VuQGRlbG9uZy5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+DQo8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iIj48L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMGlu OyBsaW5lLWhlaWdodDogMTAwJSIgY2xhc3M9IiI+TmV0d29ya3Mgc2hvdWxkLCBhcyBtdWNoIGFz IHBvc3NpYmxlLCBiZSByZXNpbGllbnQgdG8gcHJlZml4IGNoYW5nZXMuIFNvbWUgdGhpbmdzIG5l dHdvcmtzIGNhbiBkbyB0byBpbXByb3ZlIHJlc2lsaWVuY2U6PC9wPg0KPG9sIGNsYXNzPSIiPg0K PGxpIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFj ZWhvbGRlciI+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAwaW47IGxpbmUtaGVp Z2h0OiAxMDAlIiBjbGFzcz0iIj5Xcml0ZSBhIGxlYXJuZWQgcHJlZml4IHRvIG5vbi12b2xhdGls ZSBtZW1vcnkgYW5kIGlzc3VlIGEgREhDUHY2IFJlbmV3IGZvciB0aGF0IHByZWZpeCBvbiByZWJv b3QuPC9wPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRl ciI+DQo8L2Rpdj4NCjwvbGk+PGxpIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW4tYm90 dG9tOiAwaW47IGxpbmUtaGVpZ2h0OiAxMDAlIiBjbGFzcz0iIj5Vc2UgZHluYW1pYyBETlMgYW5k IHNob3J0ZXIgVFRMcy48L3A+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0id2Via2l0LWJsb2Nr LXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9saT48bGkgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPHAgc3R5bGU9 Im1hcmdpbi1ib3R0b206IDBpbjsgbGluZS1oZWlnaHQ6IDEwMCUiIGNsYXNzPSIiPkltcGxlbWVu dCBzb21ldGhpbmcgbGlrZSBORVRDT05GIHRvIGRpc3RyaWJ1dGUgcHJlZml4IGluZm9ybWF0aW9u IHRvIHBvbGljeSBkZXZpY2VzIGxpa2UgZmlyZXdhbGxzIG9yIFNELVdBTiBjb250cm9sbGVycy4g SSB0aGluayBhIHNlcGFyYXRlIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhpcyBhcHBsaWNhdGlvbiBv ZiBORVRDT05GIHdvdWxkIG1ha2UNCiBzZW5zZS48L3A+DQo8L2xpPjwvb2w+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpJZiB0aGUg cHJlZml4IGlzIHdyaXR0ZW4gdG8gbnYgbWVuLCB3b3VsZG7igJl0IGl0IGFsc28gYmUgcG9zc2li bGUgZm9yIGltcGxlbWVudGVycyB0byBzZW5kIHJhcGlkIGRlcHJlY2F0aW9uIFJBcyBmb3IgYW55 IHByZWZpeCBub3QgcmVuZXdlZD8NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkluIG90aGVyIHdvcmRzLCBhZnRlciByZWJvb3QsIHRyeSB0byByZWFj cXVpcmUgc2FtZSBwcmVmaXguIElmIHRoYXQgZG9lc27igJl0IHdvcmssIHdoZW4geW91IGFkdmVy dGlzZSB0aGUgbmV3IHByZWZpeCwgeW91IGNvdWxkIGFsc28gaW5jbHVkZSB0aGUgb2xkIHByZWZp eCB3aXRoIGEgdmVyeSBzaG9ydCBwcmVmZXJyZWQgYW5kIHZhbGlkIGxpZmV0aW1lIChlLmcuIDEg c2Vjb25kKSBpbiB0aGUgZmlyc3QgUkEsIHdoaWNoIHNob3VsZA0KIGJlIHNlbnQgdG8gdGhlIGFs bCBub2RlcyBvbiBsaW5rIG11bHRpY2FzdD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0IGRvZXNu4oCZdCBlbGltaW5hdGUgdGhlIHBy b2JsZW0sIGJ1dCAxIHNlY29uZCBhZGRpdGlvbmFsIGR1cmF0aW9uIHdvdWxkIGJlIGJhcmxleSBu b3RpY2VhYmxlIGFtaWQgdGhlIG1pbnV0ZSBvciBzbyBpdCB0YWtlcyBtb3N0IGhvbWUgZ2F0ZXdh eXMgdG8gcmVib290LiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGF0J3Mgc2ltaWxhciBpbiBzcGlyaXQgdG8g UkFtb25kLCB3aGljaCB3ZSB1c2VkIHRvIHVzZSB3aGVuIHNlZWluZyByb2d1ZSBSQXMgb24gb3Vy IGNhbXB1cyBuZXR3b3JrLiAmbmJzcDtJdCB3b3VsZCBhdXRvLWRlcHJlY2F0ZSBhbnkgcHJlZml4 ZXMgdGhhdCBzaG91bGRuJ3QgYmUgdGhlcmUuICg8YSBocmVmPSJodHRwOi8vcmFtb25kLnNvdXJj ZWZvcmdlLm5ldC8iIGNsYXNzPSIiPmh0dHA6Ly9yYW1vbmQuc291cmNlZm9yZ2UubmV0LzwvYT4p PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGUgc25hZyBpcyB0aGF0 IEkgc3VzcGVjdCBtb3N0IE9TZXMgd291bGQgaWdub3JlIGEgdmFsaWQgdGltZXIgb2YgMSBzZWNv bmQsIGdpdmVuIHRoZSA3MjAwIHNlY29uZCAoMiBob3VyKSBtaW5pbXVtIGRlZmluZWQgaW4gUkZD IDQ4NjIgKHVubGVzcyB0aGUgUkEgaXMgYXV0aGVudGljYXRlZCwgc29tZWhvdykuICZuYnNwO1Ro ZSBwcmVmZXJyZWQgdGltZXIgY2FuIGJlIHplcm8uICZuYnNwO1doZW4gUkFtb25kIHdhcyB3cml0 dGVuLCBpZiB3ZSB1c2VkIGENCiB2YWxpZCB0aW1lciBsZXNzIHRoYW4gNzIwMCBzZWNvbmRzIGl0 IHNlZW1lZCB0aGF0IHRoZSBkZXByZWNhdGluZyBSQXMgd2VyZSBpZ25vcmVkLiAmbmJzcDtUaGF0 IHdhcyAxMCYjNDM7IHllYXJzIGFnbyB0aG91Z2guICZuYnNwO1BlcmhhcHMgVGltIFdpbnRlcnMg aGFzIGRhdGEgb24gd2hldGhlciB0aGF0IHJ1bGUgaXMgaW1wbGVtZW50ZWQgdG9kYXkgaW4gcHJh Y3RpY2U7IEknZCBhc3N1bWUgdGhlIHRlc3RzIGhlIHJ1bnMgbWlnaHQgaW5jbHVkZSB0aGF0LiAm bmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkJ1dCBJIGxpa2Ug TGVlJ3MgYW5hbHlzaXMuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5U aW08L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_763ED571AC76419AA0B643F9AC763F53jiscacuk_-- From nobody Fri Feb 22 09:43: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 42F29130E2B for ; Fri, 22 Feb 2019 09:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpOyVziXisj3 for ; Fri, 22 Feb 2019 09:43:44 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9ED130DEF for ; Fri, 22 Feb 2019 09:43:44 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id x7so2712576wmj.0 for ; Fri, 22 Feb 2019 09:43:43 -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=l13H6hyWLRUo0rn6tC6AKmGm/RgogC+3RjiR0sfhNGc=; b=RyUJKsqdROVJOWK4wmceb3LJYE9lObjRhkadtrcgBzKvdN2GvUAXCQ76y8S4ITKP9S K36yA3LvReNpg82skxJHCiq6J110CoS/pXZUtSvNVmpHTzQ+hbOmJrPaGurexodks9Pu FgnMNmx7U0IbipqlAxweHfqv6NMjzxiTelhWY= 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=l13H6hyWLRUo0rn6tC6AKmGm/RgogC+3RjiR0sfhNGc=; b=rX4FEB4XMgF+u+SPoBczFHKzTW74tuX6xMO4UpVdXmYHnsIqC2dcWmXzS6aq9cUHf6 G+EmXo6/OzHbfm5U3MTs1QRo22mic/vb0n51uMYaCxCRNmpwcfA0dA7a7I6FWww0geV0 cgUJnNEvlFoV/wGyQnwl+sF03zG9mMnz+EFjdT7qsFp9hGv1LdER9BIS4upkzkw1nT7j vgtlaYxQqZMfcBaKPTU/JqyO2cX2b6DUUIZ8C7idmfSevZg+z/Ubz3H4VeXHBl1UKqB0 hbP5bGyhpD9sg8VlBU+DSxeGZyzDQKILUImwFWnG0rDuwCdbfsydSx4RX53D81ayjeHY tycA== X-Gm-Message-State: AHQUAub7ft/SxnygpGsZIuZ2GpZ60XCsBtEEX/fcN9OH0J4okNHLxccB /3T2GALTaTiQQ6zZkAwEzNE//iS6s9mUeOSG1nE5qQ== X-Google-Smtp-Source: AHgI3IbD+TauXOrQFXiGNkRx1XoZZhidxwk5fF/f/V56fdWGBfYZxhKV8l8l7YZ/SBYSBpBl4nNLqwXSQ8Yvj/cggJM= X-Received: by 2002:a1c:230e:: with SMTP id j14mr3379890wmj.9.1550857422056; Fri, 22 Feb 2019 09:43:42 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> <763ED571-AC76-419A-A0B6-43F9AC763F53@jisc.ac.uk> In-Reply-To: <763ED571-AC76-419A-A0B6-43F9AC763F53@jisc.ac.uk> From: Timothy Winters Date: Fri, 22 Feb 2019 12:43:30 -0500 Message-ID: To: Tim Chown Cc: Owen DeLong , "ipv6@ietf.org" , IPv6 Ops WG Content-Type: multipart/alternative; boundary="000000000000bd412605827f21cb" Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 17:43:47 -0000 --000000000000bd412605827f21cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 12:30 PM Tim Chown wrote: > Hi, > > On 22 Feb 2019, at 17:04, Owen DeLong wrote: > > Networks should, as much as possible, be resilient to prefix changes. Som= e > things networks can do to improve resilience: > > 1. > > Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew > for that prefix on reboot. > > 2. > > Use dynamic DNS and shorter TTLs. > > 3. > > Implement something like NETCONF to distribute prefix information to > policy devices like firewalls or SD-WAN controllers. I think a separat= e > document describing this application of NETCONF would make sense. > > > If the prefix is written to nv men, wouldn=E2=80=99t it also be possible = for > implementers to send rapid deprecation RAs for any prefix not renewed? > > In other words, after reboot, try to reacquire same prefix. If that > doesn=E2=80=99t work, when you advertise the new prefix, you could also i= nclude the > old prefix with a very short preferred and valid lifetime (e.g. 1 second) > in the first RA, which should be sent to the all nodes on link multicast? > > It doesn=E2=80=99t eliminate the problem, but 1 second additional duratio= n would > be barley noticeable amid the minute or so it takes most home gateways to > reboot. > > > That's similar in spirit to RAmond, which we used to use when seeing rogu= e > RAs on our campus network. It would auto-deprecate any prefixes that > shouldn't be there. (http://ramond.sourceforge.net/) > > The snag is that I suspect most OSes would ignore a valid timer of 1 > second, given the 7200 second (2 hour) minimum defined in RFC 4862 (unles= s > the RA is authenticated, somehow). The preferred timer can be zero. Whe= n > RAmond was written, if we used a valid timer less than 7200 seconds it > seemed that the deprecating RAs were ignored. That was 10+ years ago > though. Perhaps Tim Winters has data on whether that rule is implemented > today in practice; I'd assume the tests he runs might include that. > So we test that IPv6 implementations set the address to two hours if the address was higher then gets a low value (such as 1). Currently there is no way to make it less then two hours if a Rogue RA gets out and gives out a longer address lifetime. > > But I like Lee's analysis. > > Tim > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000bd412605827f21cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 22, 2019 at 12:30 PM Tim = Chown <Tim.Chown@jisc.ac.uk&= gt; wrote:
Hi,

On 22 Feb 2019, at 17:04, Owen DeLong <owen@delong.com> wrote:

Networks should, as much as= possible, be resilient to prefix changes. Some things networks can do to i= mprove resilience:


  1. Write a learned prefix to n= on-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.



  2. Use dynamic DNS and shorter= TTLs.



  3. Implement something like NE= TCONF to distribute prefix information to policy devices like firewalls or = SD-WAN controllers. I think a separate document describing this application= of NETCONF would make sense.


If the prefix is written to nv men, wouldn=E2=80=99t it also be possible fo= r implementers to send rapid deprecation RAs for any prefix not renewed?

In other words, after reboot, try to reacquire same prefix. If that do= esn=E2=80=99t work, when you advertise the new prefix, you could also inclu= de the old prefix with a very short preferred and valid lifetime (e.g. 1 se= cond) in the first RA, which should be sent to the all nodes on link multicast?

It doesn=E2=80=99t eliminate the problem, but 1 second additional dura= tion would be barley noticeable amid the minute or so it takes most home ga= teways to reboot.=C2=A0

That's similar in spirit to RAmond, which we used to use when seei= ng rogue RAs on our campus network.=C2=A0 It would auto-deprecate any prefi= xes that shouldn't be there. (http://ramond.sourceforge.net/)

The snag is that I suspect most OSes would ignore a valid timer of 1 s= econd, given the 7200 second (2 hour) minimum defined in RFC 4862 (unless t= he RA is authenticated, somehow).=C2=A0 The preferred timer can be zero.=C2= =A0 When RAmond was written, if we used a valid timer less than 7200 seconds it seemed that the deprecating RAs were= ignored.=C2=A0 That was 10+ years ago though.=C2=A0 Perhaps Tim Winters ha= s data on whether that rule is implemented today in practice; I'd assum= e the tests he runs might include that. =C2=A0
So we test that IPv6 implementations set the address to two hours if the a= ddress was higher then gets a low value (such as 1).=C2=A0 =C2=A0Currently = there is no way to make it less then two hours if a Rogue RA gets out and g= ives out a longer address lifetime.

But I like Lee's analysis.

Tim
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000bd412605827f21cb-- From nobody Fri Feb 22 09:54: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 3E468130E2B for ; Fri, 22 Feb 2019 09:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixksTjBNGzab for ; Fri, 22 Feb 2019 09:54:16 -0800 (PST) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E82130F1E for ; Fri, 22 Feb 2019 09:54:16 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id C3620BA9 for ; Fri, 22 Feb 2019 17:54:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njArsRqttZHC for ; Fri, 22 Feb 2019 11:54:15 -0600 (CST) Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 6D5DFA78 for ; Fri, 22 Feb 2019 11:54:15 -0600 (CST) Received: by mail-ua1-f71.google.com with SMTP id j2so477917uap.18 for ; Fri, 22 Feb 2019 09:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VLvXf1Xn9Ck6nTOxypqJAc/ITKvkn+ktYe9kcbdFKo0=; b=qwzMI1WDhvNPA0i2SNf8xTne8M9vkatRcm07I9H5ABNr63ET4LCFMLbhqJ/t8MJ7D9 C39Xa5hquiNS2HZshYGnnh/nBEEmRxSDEL6y+dwr6Y6KNJ+KyPScooa3k0zwk8yH7tEx faVmLZhT8qRNl0hbpcmgh8Qq6ne1bDWzIaNDkvVOySzYjC/nkRkUn1PPejmvOdgs/Wbu wKvf3GEac5tEsk/aQso/NwsxiojgrG2q3lF/ofbed0NrDYcOxgzYgF35Si/3APH2Ziek ukfyS4zorjYagEwZ7+Z04VmFO4DnvEzLHTOkm4FR6DXrv9wJt6+oycX+MLyHOSiG7TPU Qgtw== 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=VLvXf1Xn9Ck6nTOxypqJAc/ITKvkn+ktYe9kcbdFKo0=; b=Tm3tMG0oCfnVAF+yci6GXxI34bPnykQ/Sare4D/MCREUYq/S01vGcNy+2480YumY0K rOGzKsj4eE556Pz4b23Zvsyt0aGyqE2DOP5KoSiyUrkGadOHxtXWfeGLkNxeVOMJ4XWT TxgSsqURi2ELNYx3l3ZtBTYKiFQnHeR3EPa0/uGUkc5CTO94G6DqgMCglfDSC0e2anIM IJQAZEnb4fHC3BBpqd2N5F/of6pm+mxa9ymxneucQm17ZdH2K69cpAF557K4rTlxz2em bV4oLJjVyhnfgmHG/JwPZd0wOl1nA64dawarhE/dYHX5cUCSAYiiuIICfL8tVDLe8Pyu vItQ== X-Gm-Message-State: AHQUAuauN2Tidb/HEpEDqFUzO5JBRyUmsC6RPUUh8cDDk62orHFz5K8a gpX1SlZ9Lua/k9MPO/XMy1lznk+yglIu7Ax5xRmnwIxbZ22iSp6RVPC2UT3RS14TfcSwAl8l+17 2QQkbNH4pcZG1oEIepYC67PzOLw== X-Received: by 2002:a67:e907:: with SMTP id c7mr2964173vso.221.1550858053990; Fri, 22 Feb 2019 09:54:13 -0800 (PST) X-Google-Smtp-Source: AHgI3IaPpQoTzuUqT9JMUHt/YMgKKz/Yp9s9eLsSG3lYGUn2hWc0KZG0Rp2+aLEWLiZxfF1zqezz0cPnzNLDVZal+ws= X-Received: by 2002:a67:e907:: with SMTP id c7mr2964151vso.221.1550858053443; Fri, 22 Feb 2019 09:54:13 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> In-Reply-To: <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> From: David Farmer Date: Fri, 22 Feb 2019 11:53:56 -0600 Message-ID: To: Lee Howard Cc: 6man WG , IPv6 Ops WG Content-Type: multipart/alternative; boundary="0000000000005f7d9b05827f4747" Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 17:54:20 -0000 --0000000000005f7d9b05827f4747 Content-Type: text/plain; charset="UTF-8" Generally, I agree with what you are saying, but I'd like to see something like the following added as well; Even if an ISP intends to change the IPv6 prefix regularly in the longer-term, say every few months or even each month at an extreme, in the shorter-term IPv6 prefixes SHOULD be stable, for time periods of hours, days, and maybe even weeks at a time. Or, put another way, CPE devices SHOULD NOT get a new IPv6 prefix every time they are rebooted. Note: even in locations where utility power is generally stable, power outages frequently occur in clusters over a few hours or days. This occurs when an emergency repair is made to restore power and then more permanent repairs cause short outages in the following hours or days. In this scenario, each of these events in the cluster SHOULD NOT result in the CPE receiving a different IPv6 prefix. Conversely, when widespread power events occur, affecting thousands or even tens of thousands of customers, it may not be practical or even possible for an ISP to guarantee all CPE will receive the same IPv6 prefix they had before. Therefore to the extent possible, CPE and local networks SHOULD be resilient to their ISP provided IPv6 prefix changing, sometimes even unexpectedly changing. Thanks. On Fri, Feb 22, 2019 at 10:36 AM Lee Howard wrote: > I think I have heard the following suggestions in this conversation. I > hope that taken all together, rather than as individual spot solutions, > they can be a consensus recommendation. > > > ISPs should, as much as possible, reissue the same prefix to customers. > Some things ISPs can do to increase the chances of this: > > 1. > > Share lease information between redundant DHCPv6 servers. Most ISPs > probably have redundant servers, since this is critical provisioning > infrastructure. It may be difficult to synch information between servers > for millions of leases over tens of milliseconds of latency; see RFC6853, > "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP vendors can > report. > > 2. > > Aggregate above the provider edge device, so that grooming customers > between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a > few years since I worked on CMTSs, but when I did they did not support > MP-BGP well (if at all), so routes had to be aggregated on the PE, or > leaked in the IGP which is bad for convergence time. Maybe PE vendors can > report. > > 3. > > Set DHCPv6 lease timers very low prior to grooming events. A short > interval during the maintenance window will increase load on the DHCPv6 > server until timers have been returned to normal values. > > 4. > > In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the > routing table. I think all of the necessary information is in those > responses. Again, last time I was working on CMTSs, this feature was not > supported. Maybe PE vendors can report. > > > > Networks should, as much as possible, be resilient to prefix changes. Some > things networks can do to improve resilience: > > 1. > > Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew > for that prefix on reboot. > > 2. > > Use dynamic DNS and shorter TTLs. > > 3. > > Implement something like NETCONF to distribute prefix information to > policy devices like firewalls or SD-WAN controllers. I think a separate > document describing this application of NETCONF would make sense. > > > > In the case of failures, it cannot be assumed that sessions will stay > active. We try to build in redundancy and resilience where we can, but > where there's a single point of failure (such as CE or PE), and it fails > (such as an unplanned reboot), our expectations should be appropriate. > > Is this a reasonable summary? > > Lee > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --0000000000005f7d9b05827f4747 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Generally, I agree with what you are saying, but I= 9;d like to see something like the following added as well;

<= /div>Even if an ISP intends to change the IPv6 prefix regularly in the=C2= =A0longer-term, say every few months or even each month=C2=A0at an extreme,= in the shorter-term IPv6 prefixes SHOULD be stable, for time periods of ho= urs, days, and maybe even weeks at a time.=C2=A0 Or, put another way, CPE d= evices SHOULD NOT get a new IPv6 prefix every time they are rebooted.=C2=A0= Note: even in locations where utility power is generally stable, power out= ages frequently occur in clusters over a few hours or days.=C2=A0 This occu= rs when an emergency repair is made to restore power and then more permanen= t repairs cause short outages in the following hours or days. In this scena= rio, each of these events in the cluster SHOULD NOT result in the CPE recei= ving a different=C2=A0IPv6 prefix.=C2=A0

Conversely, whe= n widespread power events occur, affecting thousands or even tens of thousa= nds of customers, it may not be practical=C2=A0or even possible for an ISP = to guarantee all CPE=C2=A0will receive the same IPv6 prefix they had before= .=C2=A0 Therefore to the extent possible, CPE and local networks SHOULD be = resilient to their ISP provided IPv6 prefix changing, sometimes even unexpe= ctedly changing.

Thanks.

On Fri, Feb 22, 2019= at 10:36 AM Lee Howard <lee@asgard.or= g> wrote:
=20 =20 =20

I think I have heard the following suggestions in this conversation. I hope that taken all together, rather than as individual spot solutions, they can be a consensus recommendation.


ISPs should, as much as possible, reissue the same prefix to customers. Some things ISPs can do to increase the chances of this:

  1. Share lease information between redundant DHCPv6 servers. Most ISPs probably have redundant servers, since this is critical provisioning infrastructure. It may be difficult to synch information between servers for millions of leases over tens of milliseconds of latency; see RFC6853, "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP vendors can report.

  2. Aggregate above the provider edge device, so that grooming customers between Provider Edge boxes (PEs) doesn't force a renumbering. It'= ;s been a few years since I worked on CMTSs, but when I did they did not support MP-BGP well (if at all), so routes had to be aggregated on the PE, or leaked in the IGP which is bad for convergence time. Maybe PE vendors can report.

  3. Set DHCPv6 lease timers very low prior to grooming events. A short interval during the maintenance window will increase load on the DHCPv6 server until timers have been returned to normal values.

  4. In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the routing table. I think all of the necessary information is in those responses. Again, last time I was working on CMTSs, this feature was not supported. Maybe PE vendors can report.


Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:

  1. Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.

  2. Use dynamic DNS and shorter TTLs.

  3. Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.


In the case of failures, it cannot be assumed that sessions will stay active. We try to build in redundancy and resilience where we can, but where there's a single point of failure (such as CE or PE), and it fails (such as an unplanned reboot), our expectations should be appropriate.

Is this a reasonable summary?

Lee







--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0=C2=A0 E= mail:farmer@umn.edu
Networking & Telecommunication Services
O= ffice of Information Technology
University of Minnesota=C2=A0=C2=A0
= 2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Mi= nneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--0000000000005f7d9b05827f4747-- From nobody Fri Feb 22 10:06: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 B285812426A; Fri, 22 Feb 2019 10:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po18h07bDhx9; Fri, 22 Feb 2019 10:06:33 -0800 (PST) Received: from mail-yw1-xc44.google.com (mail-yw1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFDE1228B7; Fri, 22 Feb 2019 10:06:33 -0800 (PST) Received: by mail-yw1-xc44.google.com with SMTP id c67so1158277ywa.7; Fri, 22 Feb 2019 10:06: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=aNDeqzhCOxFGcWsyrPaCcfCXIwIHTJNeg2ZWyLqQLsM=; b=SEtrzFKlCTa7fOCgT5GCISWG7uuFAovFxJQYpgDa9wk5T8cnCa2O1+ksA58DoropXR ZPUUnN2fPyXrgcafw+vjKxS7Pp+M5FgRfoLqXjErDwfrnm2v5PS83ZPVNW403G7UWQ8y IHnV63tgcL/7aYxNYe2KMldJaO+HhPtumQEed7nO9lVbePwqxQBp8qpxA1efPRJ1qKDm Lcs1XrXwCckbIEDSSZB2H0obzjJcl8lU6qsB255ivx1eJZbD2iNMx3HW0O0UnlLGDhL6 vknWQ66easYh596eYwJdINgvgLlicbftxW8gdGhnBFphS6hoj/Oo85PTTo8MauLSGeLs V7hw== 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=aNDeqzhCOxFGcWsyrPaCcfCXIwIHTJNeg2ZWyLqQLsM=; b=SjIniQoIlkbiQJmJS0OYw8kjf+kwXMpRYsGrLqcvwSfoMe4CPK5eW0sTTQ4Sndlzof rnxMl//X0zoBKonPNzVwLQhT2NmBgUQ3kDkp8BYsawxspbI4hjtf8w+jnrgEI+3Za+K8 FIcACPF0J2Ws7GS4w3p2mPc91rjF7PJfOgJbJnjXzk2YBOPKYHx+L6/iAwp87DVE/t6P ZR5vtU0hHB4EoKzOYCL81PUjMoNaIXIJ2Xi0w2vZmHfL08g1NcdYeJZwFa4qDZ10jmqL 6nWJCy9nI7b/pw/J6XzEYHSUnPJ1llvyJO8q/fjivt/0+KtVhGq7Ix0YcgyJJOuZr4+W r1OA== X-Gm-Message-State: AHQUAuYv0h/pm+3EZdK2EPZCvSE8NkRsclJNp7haqPrBdq4HOupTecmy jfK0mVLnnX6WE9Sl8JQNRECVHJWSrC8kAvy1kPo= X-Google-Smtp-Source: AHgI3IYJ26cEQRxCN8B5W0zXe/LNw2u+iMHkwKQPGpoLg0UFsVN/0sN9F1Jr4/c7BkjBQXwsoZbAGAbpniY7bUTZbxE= X-Received: by 2002:a0d:c4c2:: with SMTP id g185mr4275703ywd.31.1550858792388; Fri, 22 Feb 2019 10:06:32 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Ca By Date: Fri, 22 Feb 2019 11:06:20 -0700 Message-ID: To: Tom Herbert Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , Mark Smith Content-Type: multipart/alternative; boundary="0000000000006acd2b05827f73d3" Archived-At: Subject: Re: [v6ops] Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 18:06:36 -0000 --0000000000006acd2b05827f73d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert wrote: > On Thu, Feb 21, 2019 at 11:35 PM Mark Smith > wrote: > > > > Hi Tom, > > > > On Fri, 22 Feb 2019 at 10:04, Tom Herbert wrote: > > > > > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith > wrote: > > > > > > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E > > > > wrote: > > > > > > > > > > > > > > > > > > > So I think there's commonly a big different between works and works > > > > well. NAT may work, however compared to stateless IPv6 (and IPv4) > > > > forwarding, it doesn't work anywhere as near as well. > > > > > > > Mark, > > > > > > I agreee with that with one exception. I believe that NAT/IPv4 can > > > offer better privacy in addressing than IPv6 given current addess > > > allocation methods. > > > > > > > So I don't think addressing privacy via NAT is really all that > > valuable if there are many other ways, some quite easy, to uniquely > > identify an anonymity desiring end-point/end-user, whose effectiveness > > aren't impacted at all by NAT. > > > > For example, this website is coming over IPv4 for me, and I'm using > > IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn't > > be able to tracked. > > > > https://amiunique.org/ > > > > Yet it is saying I can be with both Chrome and Firefox on Fedora 29 in > > Incognito/Private windows mode on this host. It says the same about my > > Android 9 phone with Chrome in Incognito mode. > > > > Going into the detail of how, they don't seem to be using IP address > > at all for any identification, it is all browser attributes. > > > > We have IPv6 temporary addresses, which makes using addresses harder > > to use to identify a node. I think that is a lot better than nothing. > > Mark, > > Yes, but by that same rationale a simple substitution cipher is better > than nothing in cryptography! > > What pretty much any conversation about privacy in addressing seems to > lacking is a quantitative description of privacy and any empiracal > data on the impact that privacy mechanisms, like those defined in > RFC4941, have had. You might say it "makes using addresses harder to > use to identify a node". But then the obvious question is _how_ much > harder? Is this really protecting anyone's privacy, or it is just a > minor inconvenience to attackers and only giving users a false sense > of security? > > The irony is that CGN seems to have the best supporting evidence for > being a mechanism that impacts privacy, but it was never even intended > to be a privacy mechanism. The evidence is in the form of concerns > form law enforcement that the privacy side effect is too strong and > impedes their investigations > (https://www.theregister.co.uk/2017/10/18/europol_cgnat/). > > So I don't think "Is addressing privacy via NAT really achieving much > compared to a privacy goal of anonymity?" is the right question. The > right question to ask is "Is addressing privacy via any IETF defined > mechanism achieving much compared to a privacy goal of anonymity?" > > Tom > 1. Network service providers cannot provide address anonymity. LEA requirements in the USA and many jurisdictions simply do not allow it, so who is the customer of such a standard? Who would make and deploy it? 2. Network address annonimity today is generally provided via Tor. How could the ietf provide something better than existiting tor solutions, knowing that it will not be baked into the network =E2=80=94 meaning it mus= t be over the top. 3. CGN is not private. It throw off per session logs of every transaction, so this is a full click stream archived ... with varing levels of intentional monetization and security from hackers. > > However, I don't see how IPv6 NAT would improve it much, and it > > introduces the other drawbacks of NAT. > > > > Regards, > > Mark. > > > > > > > > > > > > > > > > > > > > > > > > > > > Tom > > > > > > > Regards, > > > > Mark. > > > > > > > > > > > > > > > > > Bert > > > > > > > > _______________________________________________ > > > > v6ops mailing list > > > > v6ops@ietf.org > > > > https://www.ietf.org/mailman/listinfo/v6ops > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000006acd2b05827f73d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert <tom@herbertland.com> wrote:
On Thu, Feb 21, 2019 at 11:35 PM Mark Smith &l= t;markzzzsmith@= gmail.com> wrote:
>
> Hi Tom,
>
> On Fri, 22 Feb 2019 at 10:04, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith <markzzzsmith@gmail.com> wr= ote:
> > >
> > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E
> > > <albert.e.manfredi@boeing.com> wrote:
> > > >
>
> <snip>
>
> > >
> > > So I think there's commonly a big different between work= s and works
> > > well. NAT may work, however compared to stateless IPv6 (and = IPv4)
> > > forwarding, it doesn't work anywhere as near as well. > > >
> > Mark,
> >
> > I agreee with that with one exception. I believe that NAT/IPv4 ca= n
> > offer better privacy in addressing than IPv6 given current addess=
> > allocation methods.
> >
>
> So I don't think addressing privacy via NAT is really all that
> valuable if there are many other ways, some quite easy, to uniquely > identify an anonymity desiring end-point/end-user, whose effectiveness=
> aren't impacted at all by NAT.
>
> For example, this website is coming over IPv4 for me, and I'm usin= g
> IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn'= ;t
> be able to tracked.
>
> https://amiunique.org/
>
> Yet it is saying I can be with both Chrome and Firefox on Fedora 29 in=
> Incognito/Private windows mode on this host. It says the same about my=
> Android 9 phone with Chrome in Incognito mode.
>
> Going into the detail of how, they don't seem to be using IP addre= ss
> at all for any identification, it is all browser attributes.
>
> We have IPv6 temporary addresses, which makes using addresses harder > to use to identify a node. I think that is a lot better than nothing.<= br>
Mark,

Yes, but by that same rationale a simple substitution cipher is better
than nothing in cryptography!

What pretty much any conversation about privacy in addressing seems to
lacking is a quantitative description of privacy and any empiracal
data on the impact that privacy mechanisms, like those defined in
RFC4941, have had. You might say it "makes using addresses harder to use to identify a node". But then the obvious question is _how_ much harder? Is this really protecting anyone's privacy, or it is just a
minor inconvenience to attackers and only giving users a false sense
of security?

The irony is that CGN seems to have the best supporting evidence for
being a mechanism that impacts privacy, but it was never even intended
to be a privacy mechanism. The evidence is in the form of concerns
form law enforcement that the privacy side effect is too strong and
impedes their investigations
(https://www.theregister.co.uk/2017/10/18/eur= opol_cgnat/).

So I don't think "Is addressing privacy via NAT really achieving m= uch
compared to a privacy goal of anonymity?" is the right question. The right question to ask is "Is addressing privacy via any IETF defined mechanism achieving much compared to a privacy goal of anonymity?"

Tom



1.=C2=A0 Network service providers = cannot provide address anonymity.=C2=A0 LEA requirements in the USA and man= y jurisdictions simply do not allow it, so who is the customer of such a st= andard?=C2=A0 Who would make and deploy it? =C2=A0
<= br>
2. Network address annonimity today is generally= provided via Tor.=C2=A0 How could the ietf provide something better than e= xistiting tor solutions, knowing that it will not be baked into the network= =E2=80=94 meaning it must be over the top.=C2=A0
3. CGN is not private. It throw off per session l= ogs of every transaction, so this is a full click stream archived ... with = varing levels of intentional monetization and security from hackers.=C2=A0<= /div>



> However, I don't see how IPv6 NAT would improve it much, and it > introduces the other drawbacks of NAT.
>
> Regards,
> Mark.
>
>
>
>
>
>
>
>
>
>
>
>
> > Tom
> >
> > > Regards,
> > > Mark.
> > >
> > >
> > >
> > > > Bert
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ie= tf.org
> > > https://www.ietf.org/mailman/listinfo/v6o= ps

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--0000000000006acd2b05827f73d3-- From nobody Fri Feb 22 10: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 1E3CA1279E6 for ; Fri, 22 Feb 2019 10:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIBycdShaxay for ; Fri, 22 Feb 2019 10:43:30 -0800 (PST) Received: from atl4mhob12.registeredsite.com (atl4mhob12.registeredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 730A9130EBA for ; Fri, 22 Feb 2019 10:43:28 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob12.registeredsite.com (8.14.4/8.14.4) with ESMTP id x1MIhPAm029123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 22 Feb 2019 13:43:25 -0500 Received: (qmail 25144 invoked by uid 0); 22 Feb 2019 18:43:25 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Feb 2019 18:43:25 -0000 To: David Farmer Cc: 6man WG , IPv6 Ops WG References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> From: Lee Howard Message-ID: Date: Fri, 22 Feb 2019 13:43:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A6F837081AAA03660F1CBEBF" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 18:43:33 -0000 This is a multi-part message in MIME format. --------------A6F837081AAA03660F1CBEBF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/22/19 12:53 PM, David Farmer wrote: > Generally, I agree with what you are saying, but I'd like to see > something like the following added as well; > > Even if an ISP intends to change the IPv6 prefix regularly in > the longer-term, say every few months or even each month at an > extreme, in the shorter-term IPv6 prefixes SHOULD be stable, for time > periods of hours, days, and maybe even weeks at a time. Or, put > another way, CPE devices SHOULD NOT get a new IPv6 prefix every time > they are rebooted.  Note: even in locations where utility power is > generally stable, power outages frequently occur in clusters over a > few hours or days.  This occurs when an emergency repair is made to > restore power and then more permanent repairs cause short outages in > the following hours or days. In this scenario, each of these events in > the cluster SHOULD NOT result in the CPE receiving a different IPv6 > prefix. > > Conversely, when widespread power events occur, affecting thousands or > even tens of thousands of customers, it may not be practical or even > possible for an ISP to guarantee all CPE will receive the same IPv6 > prefix they had before. Therefore to the extent possible, CPE and > local networks SHOULD be resilient to their ISP provided IPv6 prefix > changing, sometimes even unexpectedly changing. What's the difference between what you said and "ISPs should, as much as possible, reissue the same prefix to customers."? Lee > > Thanks. > > On Fri, Feb 22, 2019 at 10:36 AM Lee Howard > wrote: > > I think I have heard the following suggestions in this > conversation. I hope that taken all together, rather than as > individual spot solutions, they can be a consensus recommendation. > > > ISPs should, as much as possible, reissue the same prefix to > customers. Some things ISPs can do to increase the chances of this: > > 1. > > Share lease information between redundant DHCPv6 servers. Most > ISPs probably have redundant servers, since this is critical > provisioning infrastructure. It may be difficult to synch > information between servers for millions of leases over tens > of milliseconds of latency; see RFC6853, "DHCPv6 Redundancy > Deployment Considerations." Maybe DHCP vendors can report. > > 2. > > Aggregate above the provider edge device, so that grooming > customers between Provider Edge boxes (PEs) doesn't force a > renumbering. It's been a few years since I worked on CMTSs, > but when I did they did not support MP-BGP well (if at all), > so routes had to be aggregated on the PE, or leaked in the IGP > which is bad for convergence time. Maybe PE vendors can report. > > 3. > > Set DHCPv6 lease timers very low prior to grooming events. A > short interval during the maintenance window will increase > load on the DHCPv6 server until timers have been returned to > normal values. > > 4. > > In the case of a PE reboot, use DHCPv6 Bulk Leasequery to > rebuild the routing table. I think all of the necessary > information is in those responses. Again, last time I was > working on CMTSs, this feature was not supported. Maybe PE > vendors can report. > > > Networks should, as much as possible, be resilient to prefix > changes. Some things networks can do to improve resilience: > > 1. > > Write a learned prefix to non-volatile memory and issue a > DHCPv6 Renew for that prefix on reboot. > > 2. > > Use dynamic DNS and shorter TTLs. > > 3. > > Implement something like NETCONF to distribute prefix > information to policy devices like firewalls or SD-WAN > controllers. I think a separate document describing this > application of NETCONF would make sense. > > > In the case of failures, it cannot be assumed that sessions will > stay active. We try to build in redundancy and resilience where we > can, but where there's a single point of failure (such as CE or > PE), and it fails (such as an unplanned reboot), our expectations > should be appropriate. > > Is this a reasonable summary? > > Lee > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE        Phone: 612-626-0815 > Minneapolis, MN 55414-3029   Cell: 612-812-9952 > =============================================== --------------A6F837081AAA03660F1CBEBF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/22/19 12:53 PM, David Farmer wrote:
Generally, I agree with what you are saying, but I'd like to see something like the following added as well;

Even if an ISP intends to change the IPv6 prefix regularly in the longer-term, say every few months or even each month at an extreme, in the shorter-term IPv6 prefixes SHOULD be stable, for time periods of hours, days, and maybe even weeks at a time.  Or, put another way, CPE devices SHOULD NOT get a new IPv6 prefix every time they are rebooted.  Note: even in locations where utility power is generally stable, power outages frequently occur in clusters over a few hours or days.  This occurs when an emergency repair is made to restore power and then more permanent repairs cause short outages in the following hours or days. In this scenario, each of these events in the cluster SHOULD NOT result in the CPE receiving a different IPv6 prefix. 

Conversely, when widespread power events occur, affecting thousands or even tens of thousands of customers, it may not be practical or even possible for an ISP to guarantee all CPE will receive the same IPv6 prefix they had before.  Therefore to the extent possible, CPE and local networks SHOULD be resilient to their ISP provided IPv6 prefix changing, sometimes even unexpectedly changing.

What's the difference between what you said and "ISPs should, as much as possible, reissue the same prefix to customers."?

Lee


Thanks.

On Fri, Feb 22, 2019 at 10:36 AM Lee Howard <lee@asgard.org> wrote:

I think I have heard the following suggestions in this conversation. I hope that taken all together, rather than as individual spot solutions, they can be a consensus recommendation.


ISPs should, as much as possible, reissue the same prefix to customers. Some things ISPs can do to increase the chances of this:

  1. Share lease information between redundant DHCPv6 servers. Most ISPs probably have redundant servers, since this is critical provisioning infrastructure. It may be difficult to synch information between servers for millions of leases over tens of milliseconds of latency; see RFC6853, "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP vendors can report.

  2. Aggregate above the provider edge device, so that grooming customers between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a few years since I worked on CMTSs, but when I did they did not support MP-BGP well (if at all), so routes had to be aggregated on the PE, or leaked in the IGP which is bad for convergence time. Maybe PE vendors can report.

  3. Set DHCPv6 lease timers very low prior to grooming events. A short interval during the maintenance window will increase load on the DHCPv6 server until timers have been returned to normal values.

  4. In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the routing table. I think all of the necessary information is in those responses. Again, last time I was working on CMTSs, this feature was not supported. Maybe PE vendors can report.


Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:

  1. Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.

  2. Use dynamic DNS and shorter TTLs.

  3. Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.


In the case of failures, it cannot be assumed that sessions will stay active. We try to build in redundancy and resilience where we can, but where there's a single point of failure (such as CE or PE), and it fails (such as an unplanned reboot), our expectations should be appropriate.

Is this a reasonable summary?

Lee







--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
--------------A6F837081AAA03660F1CBEBF-- From nobody Fri Feb 22 10:45: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 68387130FFF for ; Fri, 22 Feb 2019 10:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAPxXE_bnMJA for ; Fri, 22 Feb 2019 10:44:54 -0800 (PST) Received: from atl4mhob08.registeredsite.com (atl4mhob08.registeredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id F2B63130FBB for ; Fri, 22 Feb 2019 10:44:50 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob08.registeredsite.com (8.14.4/8.14.4) with ESMTP id x1MIinrj007968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 22 Feb 2019 13:44:49 -0500 Received: (qmail 1825 invoked by uid 0); 22 Feb 2019 18:44:49 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Feb 2019 18:44:49 -0000 To: Owen DeLong Cc: ipv6@ietf.org, IPv6 Ops WG References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> From: Lee Howard Message-ID: Date: Fri, 22 Feb 2019 13:44:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1190F829F530FCB027311E69" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 18:45:02 -0000 This is a multi-part message in MIME format. --------------1190F829F530FCB027311E69 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/22/19 12:04 PM, Owen DeLong wrote: >> >> Networks should, as much as possible, be resilient to prefix changes. >> Some things networks can do to improve resilience: >> >> 1. >> >> Write a learned prefix to non-volatile memory and issue a DHCPv6 >> Renew for that prefix on reboot. >> >> 2. >> >> Use dynamic DNS and shorter TTLs. >> >> 3. >> >> Implement something like NETCONF to distribute prefix information >> to policy devices like firewalls or SD-WAN controllers. I think a >> separate document describing this application of NETCONF would >> make sense. >> > > If the prefix is written to nv men, wouldn’t it also be possible for > implementers to send rapid deprecation RAs for any prefix not renewed? > > In other words, after reboot, try to reacquire same prefix. If that > doesn’t work, when you advertise the new prefix, you could also > include the old prefix with a very short preferred and valid lifetime > (e.g. 1 second) in the first RA, which should be sent to the all nodes > on link multicast? > > It doesn’t eliminate the problem, but 1 second additional duration > would be barley noticeable amid the minute or so it takes most home > gateways to reboot. I like this suggestion; don't think I'd seen it before. "Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot. If renew fails, send new RAs for that prefix with a preferred lifetime of 0, and a valid lifetime of two hours." Lee > > Owen > --------------1190F829F530FCB027311E69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/22/19 12:04 PM, Owen DeLong wrote:

Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:

  1. Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.

  2. Use dynamic DNS and shorter TTLs.

  3. Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.


If the prefix is written to nv men, wouldn’t it also be possible for implementers to send rapid deprecation RAs for any prefix not renewed?

In other words, after reboot, try to reacquire same prefix. If that doesn’t work, when you advertise the new prefix, you could also include the old prefix with a very short preferred and valid lifetime (e.g. 1 second) in the first RA, which should be sent to the all nodes on link multicast?

It doesn’t eliminate the problem, but 1 second additional duration would be barley noticeable amid the minute or so it takes most home gateways to reboot.

I like this suggestion; don't think I'd seen it before.

"Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot. If renew fails, send new RAs for that prefix with a preferred lifetime of 0, and a valid lifetime of two hours."

Lee


Owen

--------------1190F829F530FCB027311E69-- From nobody Fri Feb 22 10:56: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 2059D130F65 for ; Fri, 22 Feb 2019 10:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 qFsqR70GlW1v for ; Fri, 22 Feb 2019 10:56:04 -0800 (PST) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EBF130EBA for ; Fri, 22 Feb 2019 10:56:04 -0800 (PST) Received: by mail-qk1-x742.google.com with SMTP id p15so1767114qkl.5 for ; Fri, 22 Feb 2019 10:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x7sUjCK6t2Zo+CTA01NnSvPJ02ay1bSGa4FVV1ZsZUk=; b=KFsvPrCUr70MM/SKPu0F6hQvdtkHdwRyXJOdeJqvThNXWEiWPxu/pnBLjsJoIHKPdL vowdQDVM8mcadr1XUbIP+jbG/0mLzbKFieJBJGyvWhwp29c3JYK+yfydB0JxFEL9NWC8 OGE4xyOyg97LKW2vheYohEJio/iOwc7Y7i8MXe/4XiKFJAfqbrQcU/9DurhPKFJOQMzg ZOnXukOn/MhA2XY1bcTWrGPVJ7eymfS7l2ayonT9t9Bkab1gzPiNfWUVHm/C1M+wHqg/ gFBCpxmt64cC47l9NHYnajzTNG5V+Q2MqetYSSJwI64t1IaST+pgNTq09B416H7FMMQB k9Fg== 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:content-transfer-encoding; bh=x7sUjCK6t2Zo+CTA01NnSvPJ02ay1bSGa4FVV1ZsZUk=; b=Jx5/40jfwHhU1y1UZMVVxopiR6UYewQzmsFN7C5DQKaI3zVm0wywO07JXRlJL/9hGY 3YlpUD/SBfE3eIaLpI6qXU4z7yZkvTrueUlagSeLwqTyoyTvCnxc4wgkha3CtXbNaZ0M T/qaTUcTFbd+Tg45zjZ49ygGXsyRKb6iOUCJxsXZJnTBVaXX+/kYmyVPltb5IZIIVuQb kQ4qzPMMGND+NSJBU4D4zsr6AgJpO430n+4J3fa76YUmLdsglT+f/cg4lh/GtrjDCyg8 CrnMkdvMDYPsARPkn8+xMwU+50tc3aplD7VPZeduKm3cph5DpgIyFJqIJuSlDtIXAkzL DxpA== X-Gm-Message-State: AHQUAuYazxJSd1IZlJTk1ynH2QcZari4fqWm/Pj/8tSEDGAONEw+9nFY ThFi7oLsYNhzvTKoYYmFoMYkg6bwmDybo65B+HrlSg== X-Google-Smtp-Source: AHgI3IaRFjAPx+yNi41qwk8QCMT/N8F2j5/RbQxZXmotiVku0WD5DZ574rCjVq7kuIfPyCGD/kiZtFq9pUUwcsYhhJE= X-Received: by 2002:ae9:dc84:: with SMTP id q126mr3381020qkf.121.1550861763128; Fri, 22 Feb 2019 10:56:03 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Tom Herbert Date: Fri, 22 Feb 2019 10:55:52 -0800 Message-ID: To: Ca By Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , Mark Smith Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 18:56:07 -0000 On Fri, Feb 22, 2019 at 10:06 AM Ca By wrote: > > > > On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert wrote: >> >> On Thu, Feb 21, 2019 at 11:35 PM Mark Smith wro= te: >> > >> > Hi Tom, >> > >> > On Fri, 22 Feb 2019 at 10:04, Tom Herbert wrote: >> > > >> > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith = wrote: >> > > > >> > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E >> > > > wrote: >> > > > > >> > >> > >> > >> > > > >> > > > So I think there's commonly a big different between works and work= s >> > > > well. NAT may work, however compared to stateless IPv6 (and IPv4) >> > > > forwarding, it doesn't work anywhere as near as well. >> > > > >> > > Mark, >> > > >> > > I agreee with that with one exception. I believe that NAT/IPv4 can >> > > offer better privacy in addressing than IPv6 given current addess >> > > allocation methods. >> > > >> > >> > So I don't think addressing privacy via NAT is really all that >> > valuable if there are many other ways, some quite easy, to uniquely >> > identify an anonymity desiring end-point/end-user, whose effectiveness >> > aren't impacted at all by NAT. >> > >> > For example, this website is coming over IPv4 for me, and I'm using >> > IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn't >> > be able to tracked. >> > >> > https://amiunique.org/ >> > >> > Yet it is saying I can be with both Chrome and Firefox on Fedora 29 in >> > Incognito/Private windows mode on this host. It says the same about my >> > Android 9 phone with Chrome in Incognito mode. >> > >> > Going into the detail of how, they don't seem to be using IP address >> > at all for any identification, it is all browser attributes. >> > >> > We have IPv6 temporary addresses, which makes using addresses harder >> > to use to identify a node. I think that is a lot better than nothing. >> >> Mark, >> >> Yes, but by that same rationale a simple substitution cipher is better >> than nothing in cryptography! >> >> What pretty much any conversation about privacy in addressing seems to >> lacking is a quantitative description of privacy and any empiracal >> data on the impact that privacy mechanisms, like those defined in >> RFC4941, have had. You might say it "makes using addresses harder to >> use to identify a node". But then the obvious question is _how_ much >> harder? Is this really protecting anyone's privacy, or it is just a >> minor inconvenience to attackers and only giving users a false sense >> of security? >> >> The irony is that CGN seems to have the best supporting evidence for >> being a mechanism that impacts privacy, but it was never even intended >> to be a privacy mechanism. The evidence is in the form of concerns >> form law enforcement that the privacy side effect is too strong and >> impedes their investigations >> (https://www.theregister.co.uk/2017/10/18/europol_cgnat/). >> >> So I don't think "Is addressing privacy via NAT really achieving much >> compared to a privacy goal of anonymity?" is the right question. The >> right question to ask is "Is addressing privacy via any IETF defined >> mechanism achieving much compared to a privacy goal of anonymity?" >> >> Tom > > > > > 1. Network service providers cannot provide address anonymity. LEA requ= irements in the USA and many jurisdictions simply do not allow it, so who i= s the customer of such a standard? Who would make and deploy it? The customer of this is political dissident that is speaking out against injustice of a corrupt government. There is nothing that prevents a solution that provides the privacy for the dissident, but still allows their network provider to maintain records that correlate address to identity is available to LEA for the local jurisdiction under lawful order. This really isn't different than other areas of privacy on the Internet (like the logs that Facebook or Google keep). The point is that anonimity is needed to prevent unauthorized third parties from breaking someones privacy. > > 2. Network address annonimity today is generally provided via Tor. How c= ould the ietf provide something better than existiting tor solutions, knowi= ng that it will not be baked into the network =E2=80=94 meaning it must be = over the top. > I'm not sure what "provided via Tor" means. > 3. CGN is not private. It throw off per session logs of every transaction= , so this is a full click stream archived ... with varing levels of intenti= onal monetization and security from hackers. > Yes, it is expected that the local provider has full view of all associations of address to some device, that's pretty much a given and we have to trust the local provider to some extent. What we're trying to prevent is untrusted external parties from deducing identity or location of users. > >> >> > However, I don't see how IPv6 NAT would improve it much, and it >> > introduces the other drawbacks of NAT. >> > >> > Regards, >> > Mark. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > Tom >> > > >> > > > Regards, >> > > > Mark. >> > > > >> > > > >> > > > >> > > > > Bert >> > > > >> > > > _______________________________________________ >> > > > v6ops mailing list >> > > > v6ops@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/v6ops >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Fri Feb 22 13:22: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 12FA9130E8F; Fri, 22 Feb 2019 13:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFvcdPA_xv2m; Fri, 22 Feb 2019 13:22:14 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22771275F3; Fri, 22 Feb 2019 13:22:13 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 14C673826C; Fri, 22 Feb 2019 16:21:46 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 98E2A1DBD; Fri, 22 Feb 2019 16:21:56 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 977F41DB1; Fri, 22 Feb 2019 16:21:56 -0500 (EST) From: Michael Richardson To: Ca By cc: Tom Herbert , IPv6 Operations , "6man\@ietf.org" <6man@ietf.org> In-Reply-To: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 21:22:17 -0000 --=-=-= Content-Type: text/plain Ca By wrote: > What pretty much any conversation about privacy in addressing seems to > lacking is a quantitative description of privacy and any empiracal > data on the impact that privacy mechanisms, like those defined in > RFC4941, have had. You might say it "makes using addresses harder to > use to identify a node". But then the obvious question is _how_ much > harder? Is this really protecting anyone's privacy, or it is just a > minor inconvenience to attackers and only giving users a false sense > of security? > The irony is that CGN seems to have the best supporting evidence for > being a mechanism that impacts privacy, but it was never even intended > to be a privacy mechanism. The evidence is in the form of concerns > form law enforcement that the privacy side effect is too strong and > impedes their investigations > (https://www.theregister.co.uk/2017/10/18/europol_cgnat/). Has anyone seen any well-written explanations of how anti-privacy CGN is? It seems that due to the need to: > 3. CGN is not private. It throw off per session logs of every transaction, so > this is a full click stream archived ... with varing levels of intentional > monetization and security from hackers. that CGN results in significantly higher privacy invasion than IPv6 (even without privacy extensions). (which is your point) But, how we can explain this easily to other less technical people? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxwZ/QACgkQgItw+93Q 3WU55gf/e/e8t7NhDkuYyYDTHNm4veQtbxhwPQIaoFLPxOO9bAhbeuI3gp+kikwN D9iTUfS3TzXWDC5ODZThRbTFZnCk/K1tIavTxEwyu39F9IeGNB7i5MJvy6tNr9YX zDpy8FGELjzIPq2KHY1ym2hbq0xvRHYkooHvo4zGRP1vS93OAEAW3gpNASykHJI6 CzE/Ij336u66pusJGLuk3QM+Xuif1ZMZmp1GtjG064xSvWbTw/mGsy5kfCwUEaCe PpvCpJBUz89falpLlD2Y9xYEtA3OXvWtmJ08jqYUxs7ICLA7B8qGzehUucJY77wt BCQXaQ+y5gSiM6FfO4DgARxDveGGuw== =KhEq -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 22 13:41: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 9A38A130E7F for ; Fri, 22 Feb 2019 13:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOd9ph6V4VDs for ; Fri, 22 Feb 2019 13:40:47 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F461275F3 for ; Fri, 22 Feb 2019 13:40:47 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 2F046548 for ; Fri, 22 Feb 2019 21:40:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKnNsQ0O6xYU for ; Fri, 22 Feb 2019 15:40:45 -0600 (CST) Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id C4966184 for ; Fri, 22 Feb 2019 15:40:45 -0600 (CST) Received: by mail-vk1-f198.google.com with SMTP id x200so1690060vkd.0 for ; Fri, 22 Feb 2019 13:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D63bq5HpWUFTtJ4siHBh3RrLLAZUjxSzpeofpODGTrc=; b=NDznbxYkVLjOPhEadocEF22l61LGncTuNhLd+ah8ni7Yjtv1XIrZoayDOIaBeNOtvZ IigXftcvGcwqWEKqrw3WI3jv+9US+I73VMkK7eJjxl/iFm4BazbfWQfaDmHiqw1Wpy+r BwMP07LSovT4mN+xMv2r0ADLvunigFyef9yqcKg/GATtgeTkm1N/pVo/BwjV/UCVwBSf POocUesiNBEtRPmjj2f7hFQZhvWxFM+uv70CzBHJUBfTSiXCOJvoaYmKcDxWVpLDklq4 NML93qVz7J8K4dH7C6XCM6rSYSNcDDmyPqYxs4tqsTuWlWk+k5mfNEuR7JfkkqNZTLSW WefQ== 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=D63bq5HpWUFTtJ4siHBh3RrLLAZUjxSzpeofpODGTrc=; b=d2K/L9Ee4h9Swj1Ij5cxWI2LZcGCcU6hlrTNQ+PRpR937IzcjvVwv4JwBMg3dFsSAF vuHSYVur0b02gwOio1U4tLRSzRjIPlRT1nupsgFtJJv5Sa9Mnvx+Xvth1kK+54vbzpho +zyY+w6NNEa13OEcATt8eeQdnye6D5cmUpCnAKISmviUxiTAHTDUxCZ4OIvRNcbPPovN BwAvak93uXSSAQ6X/rmQP2n2g6/TKXGwdTOXNV3tb+YlOkaCTT0Y8oZSGA62xFHdsM0D lmtIP8D4XVDHgNsQ8dk2IbCQEyeSyc+M1l95nBVQuOg102e5yLpjVC8/66mWxuwx9N74 hFJA== X-Gm-Message-State: AHQUAubNOYENTmvKNC+SRyMe5qmnY6a9Myv1Col2VaBDqwJtfwD76tZc 1juZbXlpyrspEoG6+TO7ucYIYhqTz8CVl/j3V1vRnrg7HSItBhtaYrTGZ9kckv1CYXYpYzPrAax Xnw5QnyUeCEFe1beRmzqB0RAqNg== X-Received: by 2002:a67:2ed1:: with SMTP id u200mr3133657vsu.167.1550871644510; Fri, 22 Feb 2019 13:40:44 -0800 (PST) X-Google-Smtp-Source: AHgI3IbDt/1Ov5seNEgMFBz+m7gCaSrDRUeIV+iut7S5cvbN9EGiS+Pr9IjZBSForCv6rob8GVtSuiHv3B7baP9iI78= X-Received: by 2002:a67:2ed1:: with SMTP id u200mr3133638vsu.167.1550871643822; Fri, 22 Feb 2019 13:40:43 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> In-Reply-To: From: David Farmer Date: Fri, 22 Feb 2019 15:40:26 -0600 Message-ID: To: Lee Howard Cc: 6man WG , IPv6 Ops WG Content-Type: multipart/alternative; boundary="0000000000006c36240582827127" Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 21:40:52 -0000 --0000000000006c36240582827127 Content-Type: text/plain; charset="UTF-8" Yes, at a very high level, it boils down to the same thing. However, saying "as much as possible", set a very wide standard, providing few parameters to set expectations seems useful and helpful in developing a consensus. For example, if someone says it is impossible for their solution to ever issues the same prefix, they need to be told they should probably find a different solution. Where on the other hand, what if an ISP could always provide the same prefix, this basically says that is what they should do, where once they exceed some minimum I would want to give the ISP flexibility to implement what makes sense for their business model. Also, it needs to be clear this is "in normal circumstances", it should be acknowledged there will be situations where this is not a reasonable expectation. On Fri, Feb 22, 2019 at 12:43 PM Lee Howard wrote: > > On 2/22/19 12:53 PM, David Farmer wrote: > > Generally, I agree with what you are saying, but I'd like to see something > like the following added as well; > > Even if an ISP intends to change the IPv6 prefix regularly in > the longer-term, say every few months or even each month at an extreme, in > the shorter-term IPv6 prefixes SHOULD be stable, for time periods of hours, > days, and maybe even weeks at a time. Or, put another way, CPE devices > SHOULD NOT get a new IPv6 prefix every time they are rebooted. Note: even > in locations where utility power is generally stable, power outages > frequently occur in clusters over a few hours or days. This occurs when an > emergency repair is made to restore power and then more permanent repairs > cause short outages in the following hours or days. In this scenario, each > of these events in the cluster SHOULD NOT result in the CPE receiving a > different IPv6 prefix. > > Conversely, when widespread power events occur, affecting thousands or > even tens of thousands of customers, it may not be practical or even > possible for an ISP to guarantee all CPE will receive the same IPv6 prefix > they had before. Therefore to the extent possible, CPE and local networks > SHOULD be resilient to their ISP provided IPv6 prefix changing, sometimes > even unexpectedly changing. > > What's the difference between what you said and "ISPs should, as much as > possible, reissue the same prefix to customers."? > > Lee > > > Thanks. > > On Fri, Feb 22, 2019 at 10:36 AM Lee Howard wrote: > >> I think I have heard the following suggestions in this conversation. I >> hope that taken all together, rather than as individual spot solutions, >> they can be a consensus recommendation. >> >> >> ISPs should, as much as possible, reissue the same prefix to customers. >> Some things ISPs can do to increase the chances of this: >> >> 1. >> >> Share lease information between redundant DHCPv6 servers. Most ISPs >> probably have redundant servers, since this is critical provisioning >> infrastructure. It may be difficult to synch information between servers >> for millions of leases over tens of milliseconds of latency; see RFC6853, >> "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP vendors can >> report. >> >> 2. >> >> Aggregate above the provider edge device, so that grooming customers >> between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a >> few years since I worked on CMTSs, but when I did they did not support >> MP-BGP well (if at all), so routes had to be aggregated on the PE, or >> leaked in the IGP which is bad for convergence time. Maybe PE vendors can >> report. >> >> 3. >> >> Set DHCPv6 lease timers very low prior to grooming events. A short >> interval during the maintenance window will increase load on the DHCPv6 >> server until timers have been returned to normal values. >> >> 4. >> >> In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the >> routing table. I think all of the necessary information is in those >> responses. Again, last time I was working on CMTSs, this feature was not >> supported. Maybe PE vendors can report. >> >> >> >> Networks should, as much as possible, be resilient to prefix changes. >> Some things networks can do to improve resilience: >> >> 1. >> >> Write a learned prefix to non-volatile memory and issue a DHCPv6 >> Renew for that prefix on reboot. >> >> 2. >> >> Use dynamic DNS and shorter TTLs. >> >> 3. >> >> Implement something like NETCONF to distribute prefix information to >> policy devices like firewalls or SD-WAN controllers. I think a separate >> document describing this application of NETCONF would make sense. >> >> >> >> In the case of failures, it cannot be assumed that sessions will stay >> active. We try to build in redundancy and resilience where we can, but >> where there's a single point of failure (such as CE or PE), and it fails >> (such as an unplanned reboot), our expectations should be appropriate. >> >> Is this a reasonable summary? >> >> Lee >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --0000000000006c36240582827127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, at a very high level, it boils down to the same = thing.=C2=A0 However, saying "as much as possible", set a very wi= de standard, providing few parameters to set expectations seems useful and = helpful in developing a consensus. For example, if someone says it is impos= sible for their solution to ever issues the same prefix, they need to be to= ld they should probably find a different solution. Where on the other hand,= what if an ISP could always provide the same prefix, this basically says t= hat is what they should do, where once they exceed some minimum I would wan= t to give the ISP flexibility to implement what makes sense for their busin= ess model.=C2=A0 Also, it needs to be clear this is "in normal circums= tances", it should be acknowledged there will be situations where this= is not a reasonable expectation.=C2=A0 =C2=A0=C2=A0
=
On Fri= , Feb 22, 2019 at 12:43 PM Lee Howard <lee@asgard.org> wrote:
=20 =20 =20


On 2/22/19 12:53 PM, David Farmer wrot= e:
=20
Generally, I agree with what you are saying, but I'd like = to see something like the following added as well;

Even if an ISP intends to change the IPv6 prefix regularly in= the=C2=A0longer-term, say every few months or even each month=C2=A0at an e= xtreme, in the shorter-term IPv6 prefixes SHOULD be stable, for time period= s of hours, days, and maybe even weeks at a time.=C2=A0 Or, put another way= , CPE devices SHOULD NOT get a new IPv6 prefix every time they are rebooted= .=C2=A0 Note: even in locations where utility power is generally stable, po= wer outages frequently occur in clusters over a few hours or days.=C2=A0 Th= is occurs when an emergency repair is made to restore power and then more p= ermanent repairs cause short outages in the following hours or days. In thi= s scenario, each of these events in the cluster SHOULD NOT result in the CP= E receiving a different=C2=A0IPv6 prefix.=C2=A0

Conversely, when widespread power events occur, affecting thou= sands or even tens of thousands of customers, it may not be practical=C2=A0= or even possible for an ISP to guarantee all CPE=C2=A0will receive the same= IPv6 prefix they had before.=C2=A0 Therefore to the extent possible, CPE a= nd local networks SHOULD be resilient to their ISP provided IPv6 prefix cha= nging, sometimes even unexpectedly changing.

What's the difference between what you said and "ISPs shoul= d, as much as possible, reissue the same prefix to customers."?

Lee


Thanks.

On Fri, Feb 22, 2019 at 10:36= AM Lee Howard <lee@= asgard.org> wrote:

I think I have = heard the following suggestions in this conversation. I hope that taken all= together, rather than as individual spot solutions, they can be a consensu= s recommendation.


ISPs should, as= much as possible, reissue the same prefix to customers. Some things ISPs c= an do to increase the chances of this:

  1. Share lease= information between redundant DHCPv6 servers. Most ISPs probably have redu= ndant servers, since this is critical provisioning infrastructure. It may b= e difficult to synch information between servers for millions of leases ove= r tens of milliseconds of latency; see RFC6853, "DHCPv6 Redundancy Dep= loyment Considerations." Maybe DHCP vendors can report.

  2. Aggregate a= bove the provider edge device, so that grooming customers between Provider = Edge boxes (PEs) doesn't force a renumbering. It's been a few years= since I worked on CMTSs, but when I did they did not support MP-BGP well (= if at all), so routes had to be aggregated on the PE, or leaked in the IGP = which is bad for convergence time. Maybe PE vendors can report.

  3. Set DHCPv6 = lease timers very low prior to grooming events. A short interval during the= maintenance window will increase load on the DHCPv6 server until timers ha= ve been returned to normal values.

  4. In the case= of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the routing table. I= think all of the necessary information is in those responses. Again, last = time I was working on CMTSs, this feature was not supported. Maybe PE vendo= rs can report.


Networks should= , as much as possible, be resilient to prefix changes. Some things networks= can do to improve resilience:

  1. Write a lea= rned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix= on reboot.

  2. Use dynamic= DNS and shorter TTLs.

  3. Implement s= omething like NETCONF to distribute prefix information to policy devices li= ke firewalls or SD-WAN controllers. I think a separate document describing = this application of NETCONF would make sense.


In the case of = failures, it cannot be assumed that sessions will stay active. We try to bu= ild in redundancy and resilience where we can, but where there's a sing= le point of failure (such as CE or PE), and it fails (such as an unplanned = reboot), our expectations should be appropriate.

Is this a reaso= nable summary?

Lee







-----------------------------------------------------------= ---------
IETF IPv6 working group mailing list
ipv6@ietf.org<= /a>
Administrative Requests: https://www.ietf.org/mailm= an/listinfo/ipv6
---------------------------------------------------= -----------------


--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecom= munication Services
Office of Information Technology
University of Mi= nnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 P= hone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-= 9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu<= br>Networking & Telecommunication Services
Office of Information Tec= hnology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--0000000000006c36240582827127-- From nobody Fri Feb 22 14:02: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 8511F129B88 for ; Fri, 22 Feb 2019 14:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGar4blNUM0c for ; Fri, 22 Feb 2019 14:02:01 -0800 (PST) Received: from atl4mhob13.registeredsite.com (atl4mhob13.registeredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4D71312D861 for ; Fri, 22 Feb 2019 14:02:01 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob13.registeredsite.com (8.14.4/8.14.4) with ESMTP id x1MM1vIB007014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 22 Feb 2019 17:01:58 -0500 Received: (qmail 9457 invoked by uid 0); 22 Feb 2019 22:01:57 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Feb 2019 22:01:57 -0000 To: David Farmer Cc: 6man WG , IPv6 Ops WG References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> From: Lee Howard Message-ID: <79d9ab60-999f-85e3-7551-9dc6c0c400b4@asgard.org> Date: Fri, 22 Feb 2019 17:01:56 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------77B002BA8BFC6C8FCEA6BA38" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 22:02:04 -0000 This is a multi-part message in MIME format. --------------77B002BA8BFC6C8FCEA6BA38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/22/19 4:40 PM, David Farmer wrote: > Yes, at a very high level, it boils down to the same thing.  However, > saying "as much as possible", set a very wide standard, providing few > parameters to set expectations seems useful and helpful in developing > a consensus. For example, if someone says it is impossible for their > solution to ever issues the same prefix, they need to be told they > should probably find a different solution. Hmm. Has anyone said it's impossible to ever issue the same prefix? And even if they did, is it in charter for us to say, "You bought the wrong gear, buy something else"? We're kind of arguing the definition of "possible," I think. > Where on the other hand, what if an ISP could always provide the same > prefix, this basically says that is what they should do, where once > they exceed some minimum I would want to give the ISP flexibility to > implement what makes sense for their business model.  Also, it needs > to be clear this is "in normal circumstances", it should be > acknowledged there will be situations where this is not a reasonable > expectation. I was trying to figure out how to add this as a #5, but I kept getting stuck on #1. Is it possible to ensure that the same DHCPv6 server always responds to queries, and therefore always Renews the lease? Or is this specifically for Requests, not Renewals? The synchronization on #1 is still not something I'm sure about, and if that's not fixed (and maybe it is), I don't see any way to satisfy this proposal. Lee > > On Fri, Feb 22, 2019 at 12:43 PM Lee Howard > wrote: > > > On 2/22/19 12:53 PM, David Farmer wrote: >> Generally, I agree with what you are saying, but I'd like to see >> something like the following added as well; >> >> Even if an ISP intends to change the IPv6 prefix regularly in >> the longer-term, say every few months or even each month at an >> extreme, in the shorter-term IPv6 prefixes SHOULD be stable, for >> time periods of hours, days, and maybe even weeks at a time.  Or, >> put another way, CPE devices SHOULD NOT get a new IPv6 prefix >> every time they are rebooted. Note: even in locations where >> utility power is generally stable, power outages frequently occur >> in clusters over a few hours or days.  This occurs when an >> emergency repair is made to restore power and then more permanent >> repairs cause short outages in the following hours or days. In >> this scenario, each of these events in the cluster SHOULD NOT >> result in the CPE receiving a different IPv6 prefix. >> >> Conversely, when widespread power events occur, affecting >> thousands or even tens of thousands of customers, it may not be >> practical or even possible for an ISP to guarantee all CPE will >> receive the same IPv6 prefix they had before. Therefore to the >> extent possible, CPE and local networks SHOULD be resilient to >> their ISP provided IPv6 prefix changing, sometimes even >> unexpectedly changing. > > What's the difference between what you said and "ISPs should, as > much as possible, reissue the same prefix to customers."? > > Lee > >> >> Thanks. >> >> On Fri, Feb 22, 2019 at 10:36 AM Lee Howard > > wrote: >> >> I think I have heard the following suggestions in this >> conversation. I hope that taken all together, rather than as >> individual spot solutions, they can be a consensus >> recommendation. >> >> >> ISPs should, as much as possible, reissue the same prefix to >> customers. Some things ISPs can do to increase the chances of >> this: >> >> 1. >> >> Share lease information between redundant DHCPv6 servers. >> Most ISPs probably have redundant servers, since this is >> critical provisioning infrastructure. It may be difficult >> to synch information between servers for millions of >> leases over tens of milliseconds of latency; see RFC6853, >> "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP >> vendors can report. >> >> 2. >> >> Aggregate above the provider edge device, so that >> grooming customers between Provider Edge boxes (PEs) >> doesn't force a renumbering. It's been a few years since >> I worked on CMTSs, but when I did they did not support >> MP-BGP well (if at all), so routes had to be aggregated >> on the PE, or leaked in the IGP which is bad for >> convergence time. Maybe PE vendors can report. >> >> 3. >> >> Set DHCPv6 lease timers very low prior to grooming >> events. A short interval during the maintenance window >> will increase load on the DHCPv6 server until timers have >> been returned to normal values. >> >> 4. >> >> In the case of a PE reboot, use DHCPv6 Bulk Leasequery to >> rebuild the routing table. I think all of the necessary >> information is in those responses. Again, last time I was >> working on CMTSs, this feature was not supported. Maybe >> PE vendors can report. >> >> >> Networks should, as much as possible, be resilient to prefix >> changes. Some things networks can do to improve resilience: >> >> 1. >> >> Write a learned prefix to non-volatile memory and issue a >> DHCPv6 Renew for that prefix on reboot. >> >> 2. >> >> Use dynamic DNS and shorter TTLs. >> >> 3. >> >> Implement something like NETCONF to distribute prefix >> information to policy devices like firewalls or SD-WAN >> controllers. I think a separate document describing this >> application of NETCONF would make sense. >> >> >> In the case of failures, it cannot be assumed that sessions >> will stay active. We try to build in redundancy and >> resilience where we can, but where there's a single point of >> failure (such as CE or PE), and it fails (such as an >> unplanned reboot), our expectations should be appropriate. >> >> Is this a reasonable summary? >> >> Lee >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer@umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE        Phone: 612-626-0815 >> Minneapolis, MN 55414-3029   Cell: 612-812-9952 >> =============================================== > > > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE        Phone: 612-626-0815 > Minneapolis, MN 55414-3029   Cell: 612-812-9952 > =============================================== --------------77B002BA8BFC6C8FCEA6BA38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/22/19 4:40 PM, David Farmer wrote:
Yes, at a very high level, it boils down to the same thing.  However, saying "as much as possible", set a very wide standard, providing few parameters to set expectations seems useful and helpful in developing a consensus. For example, if someone says it is impossible for their solution to ever issues the same prefix, they need to be told they should probably find a different solution.

Hmm. Has anyone said it's impossible to ever issue the same prefix?

And even if they did, is it in charter for us to say, "You bought the wrong gear, buy something else"?

We're kind of arguing the definition of "possible," I think.

Where on the other hand, what if an ISP could always provide the same prefix, this basically says that is what they should do, where once they exceed some minimum I would want to give the ISP flexibility to implement what makes sense for their business model.  Also, it needs to be clear this is "in normal circumstances", it should be acknowledged there will be situations where this is not a reasonable expectation.   

I was trying to figure out how to add this as a #5, but I kept getting stuck on #1. Is it possible to ensure that the same DHCPv6 server always responds to queries, and therefore always Renews the lease? Or is this specifically for Requests, not Renewals? The synchronization on #1 is still not something I'm sure about, and if that's not fixed (and maybe it is), I don't see any way to satisfy this proposal.

Lee



On Fri, Feb 22, 2019 at 12:43 PM Lee Howard <lee@asgard.org> wrote:


On 2/22/19 12:53 PM, David Farmer wrote:
Generally, I agree with what you are saying, but I'd like to see something like the following added as well;

Even if an ISP intends to change the IPv6 prefix regularly in the longer-term, say every few months or even each month at an extreme, in the shorter-term IPv6 prefixes SHOULD be stable, for time periods of hours, days, and maybe even weeks at a time.  Or, put another way, CPE devices SHOULD NOT get a new IPv6 prefix every time they are rebooted.  Note: even in locations where utility power is generally stable, power outages frequently occur in clusters over a few hours or days.  This occurs when an emergency repair is made to restore power and then more permanent repairs cause short outages in the following hours or days. In this scenario, each of these events in the cluster SHOULD NOT result in the CPE receiving a different IPv6 prefix. 

Conversely, when widespread power events occur, affecting thousands or even tens of thousands of customers, it may not be practical or even possible for an ISP to guarantee all CPE will receive the same IPv6 prefix they had before.  Therefore to the extent possible, CPE and local networks SHOULD be resilient to their ISP provided IPv6 prefix changing, sometimes even unexpectedly changing.

What's the difference between what you said and "ISPs should, as much as possible, reissue the same prefix to customers."?

Lee


Thanks.

On Fri, Feb 22, 2019 at 10:36 AM Lee Howard <lee@asgard.org> wrote:

I think I have heard the following suggestions in this conversation. I hope that taken all together, rather than as individual spot solutions, they can be a consensus recommendation.


ISPs should, as much as possible, reissue the same prefix to customers. Some things ISPs can do to increase the chances of this:

  1. Share lease information between redundant DHCPv6 servers. Most ISPs probably have redundant servers, since this is critical provisioning infrastructure. It may be difficult to synch information between servers for millions of leases over tens of milliseconds of latency; see RFC6853, "DHCPv6 Redundancy Deployment Considerations." Maybe DHCP vendors can report.

  2. Aggregate above the provider edge device, so that grooming customers between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a few years since I worked on CMTSs, but when I did they did not support MP-BGP well (if at all), so routes had to be aggregated on the PE, or leaked in the IGP which is bad for convergence time. Maybe PE vendors can report.

  3. Set DHCPv6 lease timers very low prior to grooming events. A short interval during the maintenance window will increase load on the DHCPv6 server until timers have been returned to normal values.

  4. In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild the routing table. I think all of the necessary information is in those responses. Again, last time I was working on CMTSs, this feature was not supported. Maybe PE vendors can report.


Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:

  1. Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.

  2. Use dynamic DNS and shorter TTLs.

  3. Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.


In the case of failures, it cannot be assumed that sessions will stay active. We try to build in redundancy and resilience where we can, but where there's a single point of failure (such as CE or PE), and it fails (such as an unplanned reboot), our expectations should be appropriate.

Is this a reasonable summary?

Lee







--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


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


--
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
--------------77B002BA8BFC6C8FCEA6BA38-- From nobody Fri Feb 22 14:30: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 8F1FF130E83; Fri, 22 Feb 2019 14:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 Iigwid28rami; Fri, 22 Feb 2019 14:30:41 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AACE4130E7F; Fri, 22 Feb 2019 14:30:38 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [192.159.10.5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x1MMUZPs026308 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Feb 2019 14:30:35 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x1MMUZPs026308 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1550874636; bh=OUu3Z+N43ySD0QAjtaBcpXO4WeAMMniNI8LAOEb4E98=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=2Ao7zzyNvxNu8Br5qABBYUSbHIbN11jJn1vtgAkKzlp+5fYSNQd9FixPhEcGZPJXl 5YHSPoyAdUwWzOSlAv2pIJ0dODFHqGOaXpfaBjArpJRjC7SR+ks3YyuwZCvOJSu4tM AfdTsRJ1n2meAl3xdHaMrGK6LertbZjZpGYdP8a0= From: Owen DeLong Message-Id: <40957060-9A71-4D1D-BF2D-46305D60EE6F@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B5FF9A25-0191-4787-8E47-F85784368B2D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 22 Feb 2019 14:30:35 -0800 In-Reply-To: <763ED571-AC76-419A-A0B6-43F9AC763F53@jisc.ac.uk> Cc: Lee Howard , IPv6 Ops WG , "ipv6@ietf.org" To: Tim Chown References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> <763ED571-AC76-419A-A0B6-43F9AC763F53@jisc.ac.uk> X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 22 Feb 2019 14:30:36 -0800 (PST) Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 22 Feb 2019 22:30:44 -0000 --Apple-Mail=_B5FF9A25-0191-4787-8E47-F85784368B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 22, 2019, at 09:30 , Tim Chown wrote: >=20 > Hi, >=20 >> On 22 Feb 2019, at 17:04, Owen DeLong > wrote: >>> Networks should, as much as possible, be resilient to prefix = changes. Some things networks can do to improve resilience: >>>=20 >>> Write a learned prefix to non-volatile memory and issue a DHCPv6 = Renew for that prefix on reboot. >>>=20 >>>=20 >>> Use dynamic DNS and shorter TTLs. >>>=20 >>>=20 >>> Implement something like NETCONF to distribute prefix information to = policy devices like firewalls or SD-WAN controllers. I think a separate = document describing this application of NETCONF would make sense. >>=20 >> If the prefix is written to nv men, wouldn=E2=80=99t it also be = possible for implementers to send rapid deprecation RAs for any prefix = not renewed? >>=20 >> In other words, after reboot, try to reacquire same prefix. If that = doesn=E2=80=99t work, when you advertise the new prefix, you could also = include the old prefix with a very short preferred and valid lifetime = (e.g. 1 second) in the first RA, which should be sent to the all nodes = on link multicast? >>=20 >> It doesn=E2=80=99t eliminate the problem, but 1 second additional = duration would be barley noticeable amid the minute or so it takes most = home gateways to reboot.=20 >=20 > That's similar in spirit to RAmond, which we used to use when seeing = rogue RAs on our campus network. It would auto-deprecate any prefixes = that shouldn't be there. (http://ramond.sourceforge.net/ = ) >=20 > The snag is that I suspect most OSes would ignore a valid timer of 1 = second, given the 7200 second (2 hour) minimum defined in RFC 4862 = (unless the RA is authenticated, somehow). The preferred timer can be = zero. When RAmond was written, if we used a valid timer less than 7200 = seconds it seemed that the deprecating RAs were ignored. That was 10+ = years ago though. Perhaps Tim Winters has data on whether that rule is = implemented today in practice; I'd assume the tests he runs might = include that. =20 >=20 > But I like Lee's analysis. >=20 > Tim Actually, a preferred:0 valid:7200 probably would do the trick as well. = It won=E2=80=99t salvage the sessions on the old address since they = don=E2=80=99t route any more, but at least it will allow new sessions to = use a valid address. Owen --Apple-Mail=_B5FF9A25-0191-4787-8E47-F85784368B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 22, 2019, at 09:30 , Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

Hi,

On 22 Feb 2019, at 17:04, Owen = DeLong <owen@delong.com> wrote:

Networks should, as = much as possible, be resilient to prefix changes. Some things networks = can do to improve resilience:


  1. Write a learned prefix = to non-volatile memory and issue a DHCPv6 Renew for that prefix on = reboot.



  2. Use dynamic DNS and = shorter TTLs.



  3. Implement something = like NETCONF to distribute prefix information to policy devices like = firewalls or SD-WAN controllers. I think a separate document describing = this application of NETCONF would make = sense.


If the prefix is written to nv men, wouldn=E2=80=99t it = also be possible for implementers to send rapid deprecation RAs for any = prefix not renewed?

In= other words, after reboot, try to reacquire same prefix. If that = doesn=E2=80=99t work, when you advertise the new prefix, you could also = include the old prefix with a very short preferred and valid lifetime = (e.g. 1 second) in the first RA, which should be sent to the all nodes = on link multicast?

It doesn=E2=80=99t eliminate the problem, but 1 second = additional duration would be barley noticeable amid the minute or so it = takes most home gateways to = reboot. 

That's = similar in spirit to RAmond, which we used to use when seeing rogue RAs = on our campus network.  It would auto-deprecate any prefixes that = shouldn't be there. (http://ramond.sourceforge.net/)

The snag is that I suspect most OSes would ignore a = valid timer of 1 second, given the 7200 second (2 hour) minimum defined = in RFC 4862 (unless the RA is authenticated, somehow).  The = preferred timer can be zero.  When RAmond was written, if we used a = valid timer less than 7200 seconds it seemed that the deprecating RAs = were ignored.  That was 10+ years ago though.  Perhaps Tim = Winters has data on whether that rule is implemented today in practice; = I'd assume the tests he runs might include that.  

But I like Lee's analysis.

Tim

Actually, a preferred:0 valid:7200 probably would do the = trick as well. It won=E2=80=99t salvage the sessions on the old address = since they don=E2=80=99t route any more, but at least it will allow new = sessions to use a valid address.

Owen

= --Apple-Mail=_B5FF9A25-0191-4787-8E47-F85784368B2D-- From nobody Fri Feb 22 14: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 8AF9E130DEF; Fri, 22 Feb 2019 14:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVtjFhb3tvjF; Fri, 22 Feb 2019 14:36:17 -0800 (PST) Received: from mail-yw1-xc44.google.com (mail-yw1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FE71294FA; Fri, 22 Feb 2019 14:36:17 -0800 (PST) Received: by mail-yw1-xc44.google.com with SMTP id 189so1451292ywi.3; Fri, 22 Feb 2019 14:36:17 -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=GjA5kXIf8JA+dtMWpa9KR46G5CO4jBlhcRvFT46A3cs=; b=u06mdeRFBIz9dbpRxbU0TbZ8OVEF7h3OqctScjVTa6MyiX8KqNePlZ8t1xS8mn09Xb DsXKvl90hkvjCzWqXIaytqV7lPb6DYTiJ/luAj7u5sWpxjMsrO9rTjFLhT1uOSi04FqP hMa1S2WPYq5L+VR2T4cmaiJ9ss8Fc/IcUYGbKQpCV9Vpzt5650DMAla541U9ixhPxQn9 msAG9DSLZxEXtv7PRFdDqopJrvzWYPYiflTrmSSWYIVWCjqVSntUqXWE1wr6zjLBtW+Y JLix8x/VgrP+3aolOHtsTdVtCadIxyRpQEuJMdtxC2rJR0smn1TwXqONWn96KKoAPvrS ATzA== 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=GjA5kXIf8JA+dtMWpa9KR46G5CO4jBlhcRvFT46A3cs=; b=SHfYx0tC6RId3avTDSj+oEMEaWyyUEMNE2A/2LfN2yyKOlzqfRU3aqR3fgRuHIVAvc Z5WW4SF+2KwYPb+TNLWqS6dP2E8rd1fY/PWsKUzk+72yutIzPzJNb2zMaxgTvkzyDY1w +iHwRGnMAop26lwDtso4AaLaKILCyP29um0MtEcEu4wirrrLKTKpggwh582ZSKNByEel gjUjd9LypHcQRerPgj8s+kUAOMuZFRdIUZ3qOJZFMjuuYiQ4vSY0pw/UbNeeksz6sLXh ZsqYIJqDuhr+0Q/lFh9kU646+t/k2NH6ekBIDPU2EBAPSjtGKjigrcmzZeER1jW9Dlp4 gSdA== X-Gm-Message-State: AHQUAubfhkbsy2iCHafDXJrLdM9ZrjtOqZuQPd/OV798G/lJfTRTfsEY T/33ck5WdfAffV47NRnYwnWm6sRlwAOzA4afOuQ= X-Google-Smtp-Source: AHgI3IbYbkIasskhQRhBt/gGvZurJpQ4VNa1GTLHf+lsLwW+LtkXcTpxXTnbmHcCAXphuVzHpPBO3+fpWYbrO0bNKmQ= X-Received: by 2002:a0d:d882:: with SMTP id a124mr5389380ywe.184.1550874976550; Fri, 22 Feb 2019 14:36:16 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Ca By Date: Fri, 22 Feb 2019 15:36:05 -0700 Message-ID: To: Tom Herbert Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , Mark Smith Content-Type: multipart/alternative; boundary="00000000000011844b058283383d" Archived-At: Subject: Re: [v6ops] Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 22:36:21 -0000 --00000000000011844b058283383d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 11:56 AM Tom Herbert wrote: > On Fri, Feb 22, 2019 at 10:06 AM Ca By wrote: > > > > > > > > On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert > wrote: > >> > >> On Thu, Feb 21, 2019 at 11:35 PM Mark Smith > wrote: > >> > > >> > Hi Tom, > >> > > >> > On Fri, 22 Feb 2019 at 10:04, Tom Herbert > wrote: > >> > > > >> > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith > wrote: > >> > > > > >> > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E > >> > > > wrote: > >> > > > > > >> > > >> > > >> > > >> > > > > >> > > > So I think there's commonly a big different between works and > works > >> > > > well. NAT may work, however compared to stateless IPv6 (and IPv4= ) > >> > > > forwarding, it doesn't work anywhere as near as well. > >> > > > > >> > > Mark, > >> > > > >> > > I agreee with that with one exception. I believe that NAT/IPv4 can > >> > > offer better privacy in addressing than IPv6 given current addess > >> > > allocation methods. > >> > > > >> > > >> > So I don't think addressing privacy via NAT is really all that > >> > valuable if there are many other ways, some quite easy, to uniquely > >> > identify an anonymity desiring end-point/end-user, whose effectivene= ss > >> > aren't impacted at all by NAT. > >> > > >> > For example, this website is coming over IPv4 for me, and I'm using > >> > IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn't > >> > be able to tracked. > >> > > >> > https://amiunique.org/ > >> > > >> > Yet it is saying I can be with both Chrome and Firefox on Fedora 29 = in > >> > Incognito/Private windows mode on this host. It says the same about = my > >> > Android 9 phone with Chrome in Incognito mode. > >> > > >> > Going into the detail of how, they don't seem to be using IP address > >> > at all for any identification, it is all browser attributes. > >> > > >> > We have IPv6 temporary addresses, which makes using addresses harder > >> > to use to identify a node. I think that is a lot better than nothing= . > >> > >> Mark, > >> > >> Yes, but by that same rationale a simple substitution cipher is better > >> than nothing in cryptography! > >> > >> What pretty much any conversation about privacy in addressing seems to > >> lacking is a quantitative description of privacy and any empiracal > >> data on the impact that privacy mechanisms, like those defined in > >> RFC4941, have had. You might say it "makes using addresses harder to > >> use to identify a node". But then the obvious question is _how_ much > >> harder? Is this really protecting anyone's privacy, or it is just a > >> minor inconvenience to attackers and only giving users a false sense > >> of security? > >> > >> The irony is that CGN seems to have the best supporting evidence for > >> being a mechanism that impacts privacy, but it was never even intended > >> to be a privacy mechanism. The evidence is in the form of concerns > >> form law enforcement that the privacy side effect is too strong and > >> impedes their investigations > >> (https://www.theregister.co.uk/2017/10/18/europol_cgnat/). > >> > >> So I don't think "Is addressing privacy via NAT really achieving much > >> compared to a privacy goal of anonymity?" is the right question. The > >> right question to ask is "Is addressing privacy via any IETF defined > >> mechanism achieving much compared to a privacy goal of anonymity?" > >> > >> Tom > > > > > > > > > > 1. Network service providers cannot provide address anonymity. LEA > requirements in the USA and many jurisdictions simply do not allow it, so > who is the customer of such a standard? Who would make and deploy it? > > The customer of this is political dissident that is speaking out > against injustice of a corrupt government. There is nothing that > prevents a solution that provides the privacy for the dissident, but > still allows their network provider to maintain records that correlate > address to identity is available to LEA for the local jurisdiction > under lawful order. This really isn't different than other areas of > privacy on the Internet (like the logs that Facebook or Google keep). > The point is that anonimity is needed to prevent unauthorized third > parties from breaking someones privacy. > > > > > 2. Network address annonimity today is generally provided via Tor. How > could the ietf provide something better than existiting tor solutions, > knowing that it will not be baked into the network =E2=80=94 meaning it m= ust be > over the top. > > > > I'm not sure what "provided via Tor" means. Tor is this https://www.torproject.org/about/overview.html.en Tor is what people use today for address anonimity today > > > > 3. CGN is not private. It throw off per session logs of every > transaction, so this is a full click stream archived ... with varing leve= ls > of intentional monetization and security from hackers. > > > Yes, it is expected that the local provider has full view of all > associations of address to some device, that's pretty much a given and > we have to trust the local provider to some extent. What we're trying > to prevent is untrusted external parties from deducing identity or > location of users. > > > > >> > >> > However, I don't see how IPv6 NAT would improve it much, and it > >> > introduces the other drawbacks of NAT. > >> > > >> > Regards, > >> > Mark. > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > Tom > >> > > > >> > > > Regards, > >> > > > Mark. > >> > > > > >> > > > > >> > > > > >> > > > > Bert > >> > > > > >> > > > _______________________________________________ > >> > > > v6ops mailing list > >> > > > v6ops@ietf.org > >> > > > https://www.ietf.org/mailman/listinfo/v6ops > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > --00000000000011844b058283383d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 22, 2019 at 11:56 AM Tom Herbert <tom@herbertland.com> wrote:
On Fri, Feb 22, 2019 at 10:06 AM Ca By <cb.list6@gmail.com= > wrote:
>
>
>
> On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert <tom@herbertland.com> wrote:
>>
>> On Thu, Feb 21, 2019 at 11:35 PM Mark Smith <markzzzsmith@gmail.com> wr= ote:
>> >
>> > Hi Tom,
>> >
>> > On Fri, 22 Feb 2019 at 10:04, Tom Herbert <tom@herbertland.com> wrote= :
>> > >
>> > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith <markzzzsmith@gmail.com= > wrote:
>> > > >
>> > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert= E
>> > > > <albert.e.manfredi@boeing.com> wrote:
>> > > > >
>> >
>> > <snip>
>> >
>> > > >
>> > > > So I think there's commonly a big different bet= ween works and works
>> > > > well. NAT may work, however compared to stateless I= Pv6 (and IPv4)
>> > > > forwarding, it doesn't work anywhere as near as= well.
>> > > >
>> > > Mark,
>> > >
>> > > I agreee with that with one exception. I believe that NA= T/IPv4 can
>> > > offer better privacy in addressing than IPv6 given curre= nt addess
>> > > allocation methods.
>> > >
>> >
>> > So I don't think addressing privacy via NAT is really all= that
>> > valuable if there are many other ways, some quite easy, to un= iquely
>> > identify an anonymity desiring end-point/end-user, whose effe= ctiveness
>> > aren't impacted at all by NAT.
>> >
>> > For example, this website is coming over IPv4 for me, and I&#= 39;m using
>> > IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I sh= ouldn't
>> > be able to tracked.
>> >
>> > https://amiunique.org/
>> >
>> > Yet it is saying I can be with both Chrome and Firefox on Fed= ora 29 in
>> > Incognito/Private windows mode on this host. It says the same= about my
>> > Android 9 phone with Chrome in Incognito mode.
>> >
>> > Going into the detail of how, they don't seem to be using= IP address
>> > at all for any identification, it is all browser attributes.<= br> >> >
>> > We have IPv6 temporary addresses, which makes using addresses= harder
>> > to use to identify a node. I think that is a lot better than = nothing.
>>
>> Mark,
>>
>> Yes, but by that same rationale a simple substitution cipher is be= tter
>> than nothing in cryptography!
>>
>> What pretty much any conversation about privacy in addressing seem= s to
>> lacking is a quantitative description of privacy and any empiracal=
>> data on the impact that privacy mechanisms, like those defined in<= br> >> RFC4941, have had. You might say it "makes using addresses ha= rder to
>> use to identify a node". But then the obvious question is _ho= w_ much
>> harder? Is this really protecting anyone's privacy, or it is j= ust a
>> minor inconvenience to attackers and only giving users a false sen= se
>> of security?
>>
>> The irony is that CGN seems to have the best supporting evidence f= or
>> being a mechanism that impacts privacy, but it was never even inte= nded
>> to be a privacy mechanism. The evidence is in the form of concerns=
>> form law enforcement that the privacy side effect is too strong an= d
>> impedes their investigations
>> (https://www.theregister.co.uk/2017/= 10/18/europol_cgnat/).
>>
>> So I don't think "Is addressing privacy via NAT really ac= hieving much
>> compared to a privacy goal of anonymity?" is the right questi= on. The
>> right question to ask is "Is addressing privacy via any IETF = defined
>> mechanism achieving much compared to a privacy goal of anonymity?&= quot;
>>
>> Tom
>
>
>
>
> 1.=C2=A0 Network service providers cannot provide address anonymity.= =C2=A0 LEA requirements in the USA and many jurisdictions simply do not all= ow it, so who is the customer of such a standard?=C2=A0 Who would make and = deploy it?

The customer of this is political dissident that is speaking out
against injustice of a corrupt government. There is nothing that
prevents a solution that provides the privacy for the dissident, but
still allows their network provider to maintain records that correlate
address to identity is available to LEA for the local jurisdiction
under lawful order. This really isn't different than other areas of
privacy on the Internet (like the logs that Facebook or Google keep).
The point is that anonimity is needed to prevent unauthorized third
parties from breaking someones privacy.

>
> 2. Network address annonimity today is generally provided via Tor.=C2= =A0 How could the ietf provide something better than existiting tor solutio= ns, knowing that it will not be baked into the network =E2=80=94 meaning it= must be over the top.
>

I'm not sure what "provided via Tor" means.

Tor is this=C2=A0

Tor is what people use today for address anonimity today
=C2=A0


> 3. CGN is not private. It throw off per session logs of every transact= ion, so this is a full click stream archived ... with varing levels of inte= ntional monetization and security from hackers.
>
Yes, it is expected that the local provider has full view of all
associations of address to some device, that's pretty much a given and<= br> we have to trust the local provider to some extent. What we're trying to prevent is untrusted external parties from deducing identity or
location of users.

>
>>
>> > However, I don't see how IPv6 NAT would improve it much, = and it
>> > introduces the other drawbacks of NAT.
>> >
>> > Regards,
>> > Mark.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > Tom
>> > >
>> > > > Regards,
>> > > > Mark.
>> > > >
>> > > >
>> > > >
>> > > > > Bert
>> > > >
>> > > > _______________________________________________
>> > > > v6ops mailing list
>> > > > v6ops@ietf.org
>> > > > https://www.ietf.org/mailman/list= info/v6ops
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6
>> ------------------------------------------------------------------= --
--00000000000011844b058283383d-- From nobody Fri Feb 22 14:59: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 0813712950A for ; Fri, 22 Feb 2019 14:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 tljD-xBFlqrO for ; Fri, 22 Feb 2019 14:58:53 -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 7455E12DD85 for ; Fri, 22 Feb 2019 14:58:53 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id s1so4439801qte.5 for ; Fri, 22 Feb 2019 14:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hJF/sbv6hZiOhRtpdjd26ezIG+5oF8Wu2boaGeVnB/s=; b=OeiXe3AMgejBMA8kIRUjIz4EUJ5AKLjr/fDoSCUtoZ9jSRjOsWQoL9+4amvse9OxUQ U9ZvsGb5mLg41iuoftHX7GR3g0JC7/L6zEFy96MCB37z1qMq9A67Jhyb7KANDo8mnoTT CsMDVQrr+6v/xqBO6qTR9M39upqJ6yA7cqLMOs3Fsc2By3J1fivBafFsPWaQth+iXvrw bYllEH+ePzcG2qHfqeFtWc9zM/vNDa4xnkaPCaSWV3REqDbqN1IXoqXZiBgToBymmeDl vySBdX/Ma7uxMHDgZSdeP3C9346HJSA0JsJ4sSh/zrx8jAbonsI9NQPx1Gu1fScyNOZ/ 2BXw== 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:content-transfer-encoding; bh=hJF/sbv6hZiOhRtpdjd26ezIG+5oF8Wu2boaGeVnB/s=; b=ii9GNJCdRPRpha3Yj1dxZR2RbZmj9QG/PA0V4B7h+IKfORt1Sbrp6O31kT6LWDTm9/ POzhzJuVRIE1/Ooc+jRcIeI6c7hL7TyK7Uf4QoQNs0PXoGW6jjPom2wjd8+VCFI5BP32 XW8bP/tnEHmGUSiLEKnBAvszp+swdByvkMkyK64fM/tRLlz80lnhh/GOHOiNIcg24WqK jgnllT0zWZv4wWUsdqwiM+bEFYV54h0lr3GM14g1uYfj19ZzKzUstH0caoFLNjqxN1El iMXSuwPWmnISpqyVsNp+DyMAFooVDnCZEAZS6W3O/UcJw8RmimjT2BMShdODJ9oYqCwA sBxA== X-Gm-Message-State: AHQUAuaU3Vv53nQXVHZH/wNj+OIrnU2mZ8OXtm0vHaas405najsnCO0B HTcxz4f+2di1S4uJkOpPMHavKstnAFyjztRXfObsfA== X-Google-Smtp-Source: AHgI3IY7f//1ySUVFE+y/JvLNoWHV4/1pQCPsuLBPp8GCP9a0QvQG+Izc7vdOL8G37+APbD9vMadQ3aOvvxlAVGOdGc= X-Received: by 2002:ac8:3928:: with SMTP id s37mr5177502qtb.246.1550876332335; Fri, 22 Feb 2019 14:58:52 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: From: Tom Herbert Date: Fri, 22 Feb 2019 14:58:40 -0800 Message-ID: To: Ca By Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , Mark Smith Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: A common problem with SLAAC in "renumbering" scenarios) 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, 22 Feb 2019 22:58:57 -0000 On Fri, Feb 22, 2019 at 2:36 PM Ca By wrote: > > > > On Fri, Feb 22, 2019 at 11:56 AM Tom Herbert wrote: >> >> On Fri, Feb 22, 2019 at 10:06 AM Ca By wrote: >> > >> > >> > >> > On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert wro= te: >> >> >> >> On Thu, Feb 21, 2019 at 11:35 PM Mark Smith = wrote: >> >> > >> >> > Hi Tom, >> >> > >> >> > On Fri, 22 Feb 2019 at 10:04, Tom Herbert wro= te: >> >> > > >> >> > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith wrote: >> >> > > > >> >> > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E >> >> > > > wrote: >> >> > > > > >> >> > >> >> > >> >> > >> >> > > > >> >> > > > So I think there's commonly a big different between works and w= orks >> >> > > > well. NAT may work, however compared to stateless IPv6 (and IPv= 4) >> >> > > > forwarding, it doesn't work anywhere as near as well. >> >> > > > >> >> > > Mark, >> >> > > >> >> > > I agreee with that with one exception. I believe that NAT/IPv4 ca= n >> >> > > offer better privacy in addressing than IPv6 given current addess >> >> > > allocation methods. >> >> > > >> >> > >> >> > So I don't think addressing privacy via NAT is really all that >> >> > valuable if there are many other ways, some quite easy, to uniquely >> >> > identify an anonymity desiring end-point/end-user, whose effectiven= ess >> >> > aren't impacted at all by NAT. >> >> > >> >> > For example, this website is coming over IPv4 for me, and I'm using >> >> > IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I shouldn'= t >> >> > be able to tracked. >> >> > >> >> > https://amiunique.org/ >> >> > >> >> > Yet it is saying I can be with both Chrome and Firefox on Fedora 29= in >> >> > Incognito/Private windows mode on this host. It says the same about= my >> >> > Android 9 phone with Chrome in Incognito mode. >> >> > >> >> > Going into the detail of how, they don't seem to be using IP addres= s >> >> > at all for any identification, it is all browser attributes. >> >> > >> >> > We have IPv6 temporary addresses, which makes using addresses harde= r >> >> > to use to identify a node. I think that is a lot better than nothin= g. >> >> >> >> Mark, >> >> >> >> Yes, but by that same rationale a simple substitution cipher is bette= r >> >> than nothing in cryptography! >> >> >> >> What pretty much any conversation about privacy in addressing seems t= o >> >> lacking is a quantitative description of privacy and any empiracal >> >> data on the impact that privacy mechanisms, like those defined in >> >> RFC4941, have had. You might say it "makes using addresses harder to >> >> use to identify a node". But then the obvious question is _how_ much >> >> harder? Is this really protecting anyone's privacy, or it is just a >> >> minor inconvenience to attackers and only giving users a false sense >> >> of security? >> >> >> >> The irony is that CGN seems to have the best supporting evidence for >> >> being a mechanism that impacts privacy, but it was never even intende= d >> >> to be a privacy mechanism. The evidence is in the form of concerns >> >> form law enforcement that the privacy side effect is too strong and >> >> impedes their investigations >> >> (https://www.theregister.co.uk/2017/10/18/europol_cgnat/). >> >> >> >> So I don't think "Is addressing privacy via NAT really achieving much >> >> compared to a privacy goal of anonymity?" is the right question. The >> >> right question to ask is "Is addressing privacy via any IETF defined >> >> mechanism achieving much compared to a privacy goal of anonymity?" >> >> >> >> Tom >> > >> > >> > >> > >> > 1. Network service providers cannot provide address anonymity. LEA r= equirements in the USA and many jurisdictions simply do not allow it, so wh= o is the customer of such a standard? Who would make and deploy it? >> >> The customer of this is political dissident that is speaking out >> against injustice of a corrupt government. There is nothing that >> prevents a solution that provides the privacy for the dissident, but >> still allows their network provider to maintain records that correlate >> address to identity is available to LEA for the local jurisdiction >> under lawful order. This really isn't different than other areas of >> privacy on the Internet (like the logs that Facebook or Google keep). >> The point is that anonimity is needed to prevent unauthorized third >> parties from breaking someones privacy. >> >> > >> > 2. Network address annonimity today is generally provided via Tor. Ho= w could the ietf provide something better than existiting tor solutions, kn= owing that it will not be baked into the network =E2=80=94 meaning it must = be over the top. >> > >> >> I'm not sure what "provided via Tor" means. > > > Tor is this > https://www.torproject.org/about/overview.html.en > > Tor is what people use today for address anonimity today Thanks for the reference. It's interesting but then there's https://www.esecurityplanet.com/open-source-security/the-trouble-with-tor.h= tml. In any case, I believe it's in IETF's best interest to continually evaluate security and privacy in IP protocols. Privacy in IP addressing seems to be an area of weakness in that regard. Tom > >> >> >> >> > 3. CGN is not private. It throw off per session logs of every transact= ion, so this is a full click stream archived ... with varing levels of inte= ntional monetization and security from hackers. >> > >> Yes, it is expected that the local provider has full view of all >> associations of address to some device, that's pretty much a given and >> we have to trust the local provider to some extent. What we're trying >> to prevent is untrusted external parties from deducing identity or >> location of users. >> >> > >> >> >> >> > However, I don't see how IPv6 NAT would improve it much, and it >> >> > introduces the other drawbacks of NAT. >> >> > >> >> > Regards, >> >> > Mark. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > > Tom >> >> > > >> >> > > > Regards, >> >> > > > Mark. >> >> > > > >> >> > > > >> >> > > > >> >> > > > > Bert >> >> > > > >> >> > > > _______________________________________________ >> >> > > > v6ops mailing list >> >> > > > v6ops@ietf.org >> >> > > > https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> >> ipv6@ietf.org >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- From nobody Fri Feb 22 21: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 C78C7130F03; Fri, 22 Feb 2019 21: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, 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 bqwzwQQg3KIq; Fri, 22 Feb 2019 21:21:48 -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 DBE8B130E8B; Fri, 22 Feb 2019 21:21:47 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 71E7583B0D; Sat, 23 Feb 2019 06:21:43 +0100 (CET) To: Nick Hilliard , Christian Huitema Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> Date: Sat, 23 Feb 2019 02:03:01 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 23 Feb 2019 05:21:51 -0000 On 22/2/19 09:36, Nick Hilliard wrote: > Christian Huitema wrote on 22/02/2019 07:44: >> Debating the beauty of NAT on an IPv6 list is surely good fun for some, >> but could we get some progress on the original issue, which could be >> summed up as a "bug in SLAAC"? Fernando filed that bug 3 weeks ago, I >> saw hundreds of messages on the mailing list, but I did not see much >> progress. > > There seems to be lack of consensus on whether this can be thrown into > the "bug in SLAAC" category. > > Ole declared that the root cause was "misconfiguration/error". I'm not sure that's Ole's view. Actually, it would seem to me that at the very least he agrees that the "CPE crashes-and-reboots and network continues using a stale prefix" is a problem to solve. > Fernando and others feel that it's the compound outcome of several > independent protocol and design-choice behaviours, none of which, > incidentally, is inherently broken per se. I'd disagree a bit. e.g., * The current default values for the prefix lifetimes does not seem to be the result of much of a "design choice". * The underspecification of DHCPv6-PD/SLAAC is.. that... fault on our side * As per RFC4862, it turns out that you cannot remove a stale prefix vy sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards, not even the CPEs can (even if they wanted to) do something to fix the problem. >> Do we agree that this is indeed a bug, or do we think that having users >> disconnected from the Internet after a home router reboots is just a >> desirable feature of IPv6? > > Most people feel the outcome is undesirable when it happens.  Some > people feel that it's not worth getting too excited about because > assignment stickiness tends to ensure that prefix assignments are > long-lived enough that it probably won't cause too much difficulty. This work was triggered from such (bad) experience by an ISP. As per a survey referenced in our I-D, 37% of IPv6 deployment seem to offer dynamic prefixes. The problem we are discussing may be masked via IPv4/HE -- but I don't think we can or want to rely on that. >> Do we agree that the working group should actually start working on some >> improvement in SLAAC that would mitigate the issue? Not excluding of >> course solutions that would also mitigate related egress filtering issue? > > Fixing or updating SLAAC is likely to take years to roll out and at > least one person was of the opinion that SLAAC was basically unfixable > in this regard.  This ignores whether it would be useful or viable for > the IETF to issue advice to CPE vendors and service providers about how > to avoid the problem from happening in the first place. May I ask why SLAAC is unfixable? > Ultimately, your email shows why the discussion ended up in a discussion > about NAT.  There's no single cause of the problem and no quick fix; > declaring the problem to be solely the domain of any particular > stakeholder may cause CPE vendors to deploy NPTv6 in the long term to > work around the issue, because this would make the problem mostly > disappear from the point of view of the user. There is a cost, of > course, but it's a cost which most end users are already familiar with, > and accept.  It would be sad and unfortunate if this were to be the > outcome of this discussion. Indeed. Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Feb 22 21:22: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 EA67F13107E; Fri, 22 Feb 2019 21:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QunV22k8ldzs; Fri, 22 Feb 2019 21:21:52 -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 65BF4130E8B; Fri, 22 Feb 2019 21:21:52 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 C1630841D6; Sat, 23 Feb 2019 06:21:48 +0100 (CET) To: Lee Howard , ipv6@ietf.org, IPv6 Ops WG References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <6ee48b35-d20b-3aca-063c-53b500341a46@gont.com.ar> Date: Sat, 23 Feb 2019 02:12:16 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 23 Feb 2019 05:22:00 -0000 On 22/2/19 13:36, Lee Howard wrote: > I think I have heard the following suggestions in this conversation. I > hope that taken all together, rather than as individual spot solutions, > they can be a consensus recommendation. > > > ISPs should, as much as possible, reissue the same prefix to customers. Actually, I think that we agreed on not to tell ISPs how to run their networks! > Some things ISPs can do to increase the chances of this: [...] Analysis of the tradeoffs between stable vs dynamic prefixes can be valuable, as well as advice on how to achieve each of them. However, that certainly doesn't solve the problem... and at the end of the day, it's an ISP choice whether they do dynamic or stable prefixes. ANy such advice should happen in a separate document. > 3. > > Set DHCPv6 lease timers very low prior to grooming events. A short > interval during the maintenance window will increase load on the > DHCPv6 server until timers have been returned to normal values. Please see the full discussion in our I-D. That said, as per RFC4862 you cannot lower the Valid Lifetime any further than two hours. So this is, unfortunately, mostly useless. > Networks should, as much as possible, be resilient to prefix changes. > Some things networks can do to improve resilience: > > 1. > > Write a learned prefix to non-volatile memory and issue a DHCPv6 > Renew for that prefix on reboot. Ultimately, you can only improve resiliency by improving the host behaviour. > In the case of failures, it cannot be assumed that sessions will stay > active. Of course. > We try to build in redundancy and resilience where we can, but > where there's a single point of failure (such as CE or PE), and it fails > (such as an unplanned reboot), our expectations should be appropriate. > > Is this a reasonable summary? I don't think so. Please check Sections 3 and 5 of our document. mY working copy is at: https://github.com/fgont/draft-slaac-renum/blob/master/draft-gont-6man-slaac-renum-02.txt . Our plan is to publish a rev soon. Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Feb 22 21:22: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 580B51310C9; Fri, 22 Feb 2019 21:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92RxlfzoVTPg; Fri, 22 Feb 2019 21:22:00 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C2C1310C3; Fri, 22 Feb 2019 21:22:00 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 EF1CC84287; Sat, 23 Feb 2019 06:21:52 +0100 (CET) To: Christian Huitema , Nick Hilliard Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <564ca34e-981a-ff92-3318-aaeb46b31dac@gont.com.ar> Date: Sat, 23 Feb 2019 02:21:28 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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, 23 Feb 2019 05:22:06 -0000 On 22/2/19 13:44, Christian Huitema wrote: > >>> Do we agree that this is indeed a bug, or do we think that having >>> users disconnected from the Internet after a home router reboots >>> is just a desirable feature of IPv6? >> >> Most people feel the outcome is undesirable when it happens. Some >> people feel that it's not worth getting too excited about because >> assignment stickiness tends to ensure that prefix assignments are >> long-lived enough that it probably won't cause too much difficulty. >> Others noted that long SLAAC lifetimes and lack of application >> workarounds (HE, etc) would make it a noticeable problem, when it >> happens, but didn't comment on how frequently it happened. > > I think that's a good summary: a problem that does not occur very > often, but is very annoying when it does. Everytime there's a power outage, this problem will happen. Similarly, at least in these latitudes, whenever you call tech support at your ISP, first question is "have you tried disconnecting and reconnecting the router" -- that's the way most non-technical users (and also technical users) first approach issues with their connectivity. Everytime this happens, this problem may occur. For the time being, as long as we have IPv4, IPv4/HE may mask the problem. So, as long as this gets fixed before we go IPv6-only (which in many places will not be anytime soon), that's pretty good timing to get the problem solved. [....] > >> >>> Do we agree that the working group should actually start working >>> on some improvement in SLAAC that would mitigate the issue? Not >>> excluding of course solutions that would also mitigate related >>> egress filtering issue? >> >> Fixing or updating SLAAC is likely to take years to roll out and at >> least one person was of the opinion that SLAAC was basically >> unfixable in this regard. This ignores whether it would be useful >> or viable for the IETF to issue advice to CPE vendors and service >> providers about how to avoid the problem from happening in the >> first place. > > Anything we do in this space can take a long time to roll out, but it > does not take forever. Indeed. As one datapoint, we published RFC8064 in early 2017. And even mid 2018 if you were to install a fresh copy of a modern OS, in most cases it would implement RFC8064/RFC7217. Particularly when you get implementers in the loop, and when they realize that stuff makes sense, things don't take that long. > In many cases it probably takes less time than > it takes to agree on a potential solution in the IETF. For example, > security bugs in operating systems can get patched in a matter of > weeks or maybe months. Not all devices can be patched quickly, but > many can. Agreed. > As usual, we don't want to see creative solutions popping in > different devices. A common standard seems preferable. So, if a > subset of the working group wants to work on the solution, we should > be happy to let them do that. Exactly. Some of those solutions have already popped (see the FRITZ reference in our I-D). Ignoring the problem is simply asking for more (and worse) -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Feb 22 21:25: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 7050A12785F; Fri, 22 Feb 2019 21:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_TlAV-jd2tP; Fri, 22 Feb 2019 21:25:45 -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 09765130E8B; Fri, 22 Feb 2019 21:25:43 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 D314D8394A; Sat, 23 Feb 2019 06:25:39 +0100 (CET) To: Timothy Winters , Tim Chown Cc: "ipv6@ietf.org" , IPv6 Ops WG References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> <763ED571-AC76-419A-A0B6-43F9AC763F53@jisc.ac.uk> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <6af57d08-e5c4-bba3-b18e-0ca9ca9d6a5b@gont.com.ar> Date: Sat, 23 Feb 2019 02:25:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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] Stability and Resilience (was Re: A common...) 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, 23 Feb 2019 05:25:48 -0000 On 22/2/19 14:43, Timothy Winters wrote: > > > On Fri, Feb 22, 2019 at 12:30 PM Tim Chown > wrote: > > Hi, > >> On 22 Feb 2019, at 17:04, Owen DeLong > > wrote: >>> [....] >> >> If the prefix is written to nv men, wouldn’t it also be possible >> for implementers to send rapid deprecation RAs for any prefix not >> renewed? >> >> In other words, after reboot, try to reacquire same prefix. If >> that doesn’t work, when you advertise the new prefix, you could >> also include the old prefix with a very short preferred and valid >> lifetime (e.g. 1 second) in the first RA, which should be sent to >> the all nodes on link multicast? >> >> It doesn’t eliminate the problem, but 1 second additional duration >> would be barley noticeable amid the minute or so it takes most >> home gateways to reboot.  > > That's similar in spirit to RAmond, which we used to use when seeing > rogue RAs on our campus network.  It would auto-deprecate any > prefixes that shouldn't be there. (http://ramond.sourceforge.net/) IIRC, ramond debrecates the default router, not the advertised prefixes.... > > The snag is that I suspect most OSes would ignore a valid timer of 1 > second, given the 7200 second (2 hour) minimum defined in RFC 4862 > (unless the RA is authenticated, somehow).  The preferred timer can > be zero.  When RAmond was written, if we used a valid timer less > than 7200 seconds it seemed that the deprecating RAs were ignored.  > That was 10+ years ago though.  Perhaps Tim Winters has data on > whether that rule is implemented today in practice; I'd assume the > tests he runs might include that.   > > So we test that IPv6 implementations set the address to two hours if the > address was higher then gets a low value (such as 1).   Currently there > is no way to make it less then two hours if a Rogue RA gets out and > gives out a longer address lifetime. Yep. As per RFC4862. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Sat Feb 23 00:22:33 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 111BB131050; Sat, 23 Feb 2019 00:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3N8fbx_TW6N; Sat, 23 Feb 2019 00:22:17 -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 14A4D1200B3; Sat, 23 Feb 2019 00:22:16 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 4010784888; Sat, 23 Feb 2019 09:22:08 +0100 (CET) To: Lee Howard , David Farmer Cc: IPv6 Ops WG , 6man WG References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org> <79d9ab60-999f-85e3-7551-9dc6c0c400b4@asgard.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <130bc415-c0ef-831e-357f-79172fba1386@si6networks.com> Date: Sat, 23 Feb 2019 05:20:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <79d9ab60-999f-85e3-7551-9dc6c0c400b4@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Stability and Resilience (was Re: A common...) 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, 23 Feb 2019 08:22:20 -0000 On 22/2/19 19:01, Lee Howard wrote: > > On 2/22/19 4:40 PM, David Farmer wrote: >> Yes, at a very high level, it boils down to the same thing.  However, >> saying "as much as possible", set a very wide standard, providing few >> parameters to set expectations seems useful and helpful in developing >> a consensus. For example, if someone says it is impossible for their >> solution to ever issues the same prefix, they need to be told they >> should probably find a different solution. > > Hmm. Has anyone said it's impossible to ever issue the same prefix? > > And even if they did, is it in charter for us to say, "You bought the > wrong gear, buy something else"? > > We're kind of arguing the definition of "possible," I think. We can (in a different, unrelated document, that has nothing to do with the problem we are discussing :-) ) discuss trade-offs between stable vs dynamic prefixes, and provide advice on how to achieve each. Mandating one or the other is, at best, unrealistic. -- but not as much as expecting to solve the problem being discussed by having ISPs to change their existing deployments according to a "mandate" from our side.... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Feb 23 05:00:33 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 D62E312D4EF for ; Sat, 23 Feb 2019 05:00:20 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpDbF9Q9Bog0 for ; Sat, 23 Feb 2019 05:00:18 -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 A9164130EC9 for ; Sat, 23 Feb 2019 05:00:14 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id v139so2747196qkb.12 for ; Sat, 23 Feb 2019 05:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wLPK65F+Q52QMWgZxdxN60J4OWlNmnakcrCqJA6lo3Y=; b=XhVHbTvHCqryWln90NGrcEOXm5hdysRLmWHAgSkt4jKRh6FS4ao9RHJOg9uusBDVIw iZa2ojqAiqlQMJ7QWM5wyk4vTiZCBZnTD6DPqB+SzgZKLPELQXXljLexZM6T8zuACWEp MMXEwsXqLoOhMt3BFggdbQl/+4E+VaIxDtAo+IXTr7D7CNJOwvD7O6qoRg9SYTSzaIV9 vmJSHwIHo5KOQmQK0ACEOKtONy/DjexXdEdxdCKYOeUT8D7oeJddFuLwA/gGpH3VRXlO Tv1haWwkCbAlifdP0mLgNLBKQLMY/LC3/zJk3rA91jA/5p0tGa6HX7Uvtqu55VkQmmIH x6Jg== 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=wLPK65F+Q52QMWgZxdxN60J4OWlNmnakcrCqJA6lo3Y=; b=BR0n9SVcy5TR8TuZdIukPcK6sLiR/GX/auUnPbgXH/tDMj2Rou4NMkP+5MVva8GNIe vsBDkR9Ze9B3R1Jc9sbIPv0brQs6eqJnAAcr6JqEYsblfbDukLku6mvaLOi6GuvU+3vo c8CmUYakGoQ+Zz6AA6lJMUdODpsYUvpmePsCKbB9IQGfyBXiw0cgh7mN3g8zJWGpCjHb RZc1FKe0XCrIHtfwelFdpYVVHk2Z1uLvMtZk3cRG8qMaVr5RxA+VPD121fyrcY+7gD5f HppOQWOIkQy0dRe4HHudGpydmDmeElRQNQRk5bZUmXZnt5aV80BY9AdntAVPXIM9R/GK /G8Q== X-Gm-Message-State: AHQUAub/H+P1RSh0thpz2HdgruItkIvqqbwu7xGnm0Og5B3rTgeW/ws7 9hIe1G87sbW70LTvuYTO7BC8kaGQNAitm6T/BVwTPw== X-Google-Smtp-Source: AHgI3IbKsKdAMVcjcZgJgySnWdIyPLBkU5Z9o6UvYgu/pqBDhQAFiOKVnp52DVSbJuL0MbpCAzYqd4k0rnlXT9tCHQ4= X-Received: by 2002:a37:3d7:: with SMTP id 206mr6381445qkd.164.1550926813005; Sat, 23 Feb 2019 05:00:13 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <564ca34e-981a-ff92-3318-aaeb46b31dac@gont.com.ar> In-Reply-To: <564ca34e-981a-ff92-3318-aaeb46b31dac@gont.com.ar> From: Ted Lemon Date: Sat, 23 Feb 2019 08:00:00 -0500 Message-ID: To: Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org>, Christian Huitema , IPv6 Operations , JORDI PALET MARTINEZ , Nick Hilliard Content-Type: multipart/alternative; boundary="000000000000c325fd05828f490d" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 23 Feb 2019 13:00:21 -0000 --000000000000c325fd05828f490d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, who=E2=80=99s going to summarize this discussion in a presentation at I= ETF, and will it be in 6man or v6ops? On Sat, Feb 23, 2019 at 00:23 Fernando Gont wrote: > On 22/2/19 13:44, Christian Huitema wrote: > > > >>> Do we agree that this is indeed a bug, or do we think that having > >>> users disconnected from the Internet after a home router reboots > >>> is just a desirable feature of IPv6? > >> > >> Most people feel the outcome is undesirable when it happens. Some > >> people feel that it's not worth getting too excited about because > >> assignment stickiness tends to ensure that prefix assignments are > >> long-lived enough that it probably won't cause too much difficulty. > >> Others noted that long SLAAC lifetimes and lack of application > >> workarounds (HE, etc) would make it a noticeable problem, when it > >> happens, but didn't comment on how frequently it happened. > > > > I think that's a good summary: a problem that does not occur very > > often, but is very annoying when it does. > > Everytime there's a power outage, this problem will happen. Similarly, > at least in these latitudes, whenever you call tech support at your ISP, > first question is "have you tried disconnecting and reconnecting the > router" -- that's the way most non-technical users (and also technical > users) first approach issues with their connectivity. Everytime this > happens, this problem may occur. > > For the time being, as long as we have IPv4, IPv4/HE may mask the > problem. So, as long as this gets fixed before we go IPv6-only (which in > many places will not be anytime soon), that's pretty good timing to get > the problem solved. > > > > [....] > > > >> > >>> Do we agree that the working group should actually start working > >>> on some improvement in SLAAC that would mitigate the issue? Not > >>> excluding of course solutions that would also mitigate related > >>> egress filtering issue? > >> > >> Fixing or updating SLAAC is likely to take years to roll out and at > >> least one person was of the opinion that SLAAC was basically > >> unfixable in this regard. This ignores whether it would be useful > >> or viable for the IETF to issue advice to CPE vendors and service > >> providers about how to avoid the problem from happening in the > >> first place. > > > > Anything we do in this space can take a long time to roll out, but it > > does not take forever. > > Indeed. As one datapoint, we published RFC8064 in early 2017. And even > mid 2018 if you were to install a fresh copy of a modern OS, in most > cases it would implement RFC8064/RFC7217. > > Particularly when you get implementers in the loop, and when they > realize that stuff makes sense, things don't take that long. > > > > > In many cases it probably takes less time than > > it takes to agree on a potential solution in the IETF. For example, > > security bugs in operating systems can get patched in a matter of > > weeks or maybe months. Not all devices can be patched quickly, but > > many can. > > Agreed. > > > > As usual, we don't want to see creative solutions popping in > > different devices. A common standard seems preferable. So, if a > > subset of the working group wants to work on the solution, we should > > be happy to let them do that. > > Exactly. Some of those solutions have already popped (see the FRITZ > reference in our I-D). Ignoring the problem is simply asking for more > (and worse) > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000c325fd05828f490d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, who=E2=80=99s going to summarize this discussion= in a presentation at IETF, and will it be in 6man or v6ops?

On S= at, Feb 23, 2019 at 00:23 Fernando Gont <fernando@gont.com.ar> wrote:
On 22/2/19 13:44, Christian Huitema wrote:
>
>>> Do we agree that this is indeed a bug, or do we think that hav= ing
>>> users disconnected from the Internet after a home router reboo= ts
>>> is just a desirable feature of IPv6?
>>
>> Most people feel the outcome is undesirable when it happens.=C2=A0= Some
>> people feel that it's not worth getting too excited about beca= use
>> assignment stickiness tends to ensure that prefix assignments are<= br> >> long-lived enough that it probably won't cause too much diffic= ulty.
>> Others noted that long SLAAC lifetimes and lack of application
>> workarounds (HE, etc) would make it a noticeable problem, when it<= br> >> happens, but didn't comment on how frequently it happened.
>
> I think that's a good summary: a problem that does not occur very<= br> > often, but is very annoying when it does.

Everytime there's a power outage, this problem will happen. Similarly,<= br> at least in these latitudes, whenever you call tech support at your ISP, first question is "have you tried disconnecting and reconnecting the router" -- that's the way most non-technical users (and also techn= ical
users) first approach issues with their connectivity. Everytime this
happens, this problem may occur.

For the time being, as long as we have IPv4, IPv4/HE may mask the
problem. So, as long as this gets fixed before we go IPv6-only (which in many places will not be anytime soon), that's pretty good timing to get=
the problem solved.



[....]
>
>>
>>> Do we agree that the working group should actually start worki= ng
>>> on some improvement in SLAAC that would mitigate the issue? No= t
>>> excluding of course solutions that would also mitigate related=
>>> egress filtering issue?
>>
>> Fixing or updating SLAAC is likely to take years to roll out and a= t
>> least one person was of the opinion that SLAAC was basically
>> unfixable in this regard.=C2=A0 This ignores whether it would be u= seful
>> or viable for the IETF to issue advice to CPE vendors and service<= br> >> providers about how to avoid the problem from happening in the
>> first place.
>
> Anything we do in this space can take a long time to roll out, but it<= br> > does not take forever.

Indeed. As one datapoint, we published RFC8064 in early 2017. And even
mid 2018 if you were to install a fresh copy of a modern OS, in most
cases it would implement RFC8064/RFC7217.

Particularly when you get implementers in the loop, and when they
realize that stuff makes sense, things don't take that long.



> In many cases it probably takes less time than
> it takes to agree on a potential solution in the IETF. For example, > security bugs in operating systems can get patched in a matter of
> weeks or maybe months. Not all devices can be patched quickly, but
> many can.

Agreed.


> As usual, we don't want to see creative solutions popping in
> different devices. A common standard seems preferable. So, if a
> subset of the working group wants to work on the solution, we should > be happy to let them do that.

Exactly. Some of those solutions have already popped (see the FRITZ
reference in our I-D). Ignoring the problem is simply asking for more
(and worse)

--
Fernando Gont
e-mail: fernando@= gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000c325fd05828f490d-- From nobody Sat Feb 23 06:34: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 1CFB312426A for ; Sat, 23 Feb 2019 06:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSEF1Tq2mkL3 for ; Sat, 23 Feb 2019 06:34:20 -0800 (PST) Received: from atl4mhob23.registeredsite.com (atl4mhob23.registeredsite.com [209.17.115.117]) by ietfa.amsl.com (Postfix) with ESMTP id 202081200D7 for ; Sat, 23 Feb 2019 06:34:20 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob23.registeredsite.com (8.14.4/8.14.4) with ESMTP id x1NEYHbo060046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 23 Feb 2019 09:34:17 -0500 Received: (qmail 1746 invoked by uid 0); 23 Feb 2019 14:34:17 -0000 X-TCPREMOTEIP: 108.48.167.207 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.163?) (lee@asgard.org@108.48.167.207) by 0 with ESMTPA; 23 Feb 2019 14:34:17 -0000 In-Reply-To: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <2EEFFB58-C665-48BF-B09E-5AF5A7CA91E6@conjury.org> X-Referenced-Uid: 6266 Thread-Topic: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios X-Blue-Identity: !l=133&o=96583&fo=98109&pl=23&po=0&qs=PREFIX&f=HTML&n=Lee%20Howard&e=lee%40asgard.org&m=!%3ANDFkNDZjODMtNDhmZi00ZGM0LTljODUtMTdlMzQ0MjFmOTdk%3ASU5CT1g%3D%3ANjI2Ng%3D%3D%3AANSWERED&p=0&q=SHOW X-Is-Generated-Message-Id: true User-Agent: Android MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 From: Lee Howard Date: Sat, 23 Feb 2019 09:34:16 -0500 To: Fernando Gont CC: j h woodyatt , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Message-ID: <43a72334-9b20-4d6d-be6e-a3872147c8b8@asgard.org> Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 23 Feb 2019 14:34:22 -0000 =E2=81=A3Sent from BlueMail =E2=80=8B On Feb 20, 2019, 9:42 PM, at 9:42 = PM, Fernando Gont wrote: >On 20/2/19 23:28, j h = woodyatt wrote: >> On Feb 20, 2019, at 17:13, Fernando Gont > > wrote: >>> >>> Given that RF= C6092 recommends "only allow outgoing connections=E2=80=9D=2E=2E=2E >> >> = I certainly don=E2=80=99t remember writing that, and I just double-checked = >the >> text, and I=E2=80=99m pretty sure that recommendation is not in RFC= 6092=2E > >I quickly grep'ed RFC6092=2E Found this: > > If an inbound S= YN packet is filtered, either because a corresponding > state record does= not exist or because of the filter's normal > behavior, a filter has two= basic choices: to discard the packet > silently, or to signal an error t= o the sender=2E Signaling an error > through ICMPv6 messages allows the = sender to detect that the SYN did > not reach the intended destination=2E= Discarding the packet, on the > other hand, allows applications to perf= orm simultaneous-open more > reliably=2E A more detailed discussion of t= his issue can be found in > [RFC5382], but the basic outcome of it is tha= t filters need to wait > on signaling errors until simultaneous-open will= not be impaired=2E > > REC-34: By DEFAULT, a gateway MUST respond with a= n ICMPv6 > "Destination Unreachable" error code 1 (Communication with > = destination administratively prohibited) to any unsolicited inbound > SY= N packet after waiting at least 6 seconds without first forwarding > the = associated outbound SYN or SYN/ACK from the interior peer=2E > >FWIW, I do = agree with the advice=2E > > > > >> As far as I know, IETF has not yet actu= ally written a Standards Track >> RFC that says Internet gateways SHOULD (n= ote well: requirements >> language) block inbound flows to passive listener= s=2E I=E2=80=99d be interested >to >> know if I=E2=80=99ve missed that news= =2E In any case, my recollection is that >it >> wasn=E2=80=99t the case whe= n RFC 6092 was published=2E >> >> Shorter james: don=E2=80=99t blame me fo= r this=2E I didn=E2=80=99t do it=2E > >Actually, I'm in favor of such advic= e ;-) I do think that CPEs should >support UPnP for IPv6, such that apps c= an punch holes in the fw, as >they >do for the IPv4 case=2E > > >-- >Ferna= ndo Gont >e-mail: fernando@gont=2Ecom=2Ear || fgont@si6networks=2Ecom >PGP = Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > >_____= __________________________________________ >v6ops mailing list >v6ops@ietf= =2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/v6ops From nobody Sat Feb 23 10:28: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 C4D4E1286E7; Sat, 23 Feb 2019 10:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMm2Se-cLLlE; Sat, 23 Feb 2019 10:28:46 -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 0665D130DEA; Sat, 23 Feb 2019 10:28:44 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 9FCB684B0F; Sat, 23 Feb 2019 19:28:37 +0100 (CET) To: Ted Lemon , Fernando Gont Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Christian Huitema , JORDI PALET MARTINEZ References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <564ca34e-981a-ff92-3318-aaeb46b31dac@gont.com.ar> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <7aad94ae-4adb-349c-e2d4-7fb2485f649d@si6networks.com> Date: Sat, 23 Feb 2019 14:22:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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, 23 Feb 2019 18:28:47 -0000 On 23/2/19 10:00, Ted Lemon wrote: > So, who’s going to summarize this discussion in a presentation at IETF, > and will it be in 6man or v6ops? It is extremely likely that I will be requesting agenda myself for 6man. If the v6ops chairs think it makes sense to do/present something in v6ops, I'd be happy too. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Feb 23 11:07: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 184AF130DFA for ; Sat, 23 Feb 2019 11:07: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeY9JYGbbQAt for ; Sat, 23 Feb 2019 11:07:32 -0800 (PST) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F40C12008F for ; Sat, 23 Feb 2019 11:07:32 -0800 (PST) Received: by mail-qk1-x742.google.com with SMTP id m9so3110932qkl.4 for ; Sat, 23 Feb 2019 11:07:32 -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=MDC2sueDvJr9x+LgbMguma8ziUPrAxwG4d16aMPSaYE=; b=cIRuaIAkQ7zuBaSolYY4M7/jyQefZZsMPR/su5CoXp/+S8BWzLDh8lGkGKckAl+Jzk Ll0HqwBVjb1Hpk2rgDJDw0rtl16DQT9MPf+8KdhXpEwSRfW44P992B8KYWyvsfWRVd7Z 8Z/Rg34IHLNTBy5KR+qZaq2bZOQv/bwZ8YlDedb6KdG6OwjdxZ7wsNVz8Rglqajx4zEF g4+EjB4oXOYB+dJEo4xZ5wibYQXmGlTokklJUHuSQORbEC2wg9yv3U9Has9fmbplpoCL 1nDjn6o+hCZ7UGOxaqg66bYSYDUnaTFRZrOUiO9AgU/cnh0dY0ox7zeTLPwoTubVNEim xOaA== 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=MDC2sueDvJr9x+LgbMguma8ziUPrAxwG4d16aMPSaYE=; b=lnn3rfDSA//6gzsbauNfJn/4vSLSihrspFf5TbElQ3kW5c1fC/uG/aF6fY2h2ursgH Yhstblq8MXvdUKuSHrHJd+NCOaIxQpcrcA4vu/TqFFeL0luK5G9BJILs3YzI0dy3PlOF qYgUZWqJO3do2PI2fNdAqbyeGsqJFR0SC6cGxUr6POoMZ1Y3mSvnwBvkCftQ8H0+uz54 B9C+oEVNe6eUOMeoEN8tPABhXruOX7Z7rftfQ/7ITPykEEw2qb2aDT0ir1dYQq4kdatT C7Lxz48UKQDUfGZZv7R3NclspR9aL9C5d1O8pDn3BtcSUzlD/OpbwroZWEz58XoRMcT8 yOmQ== X-Gm-Message-State: AHQUAuaTAceVQ4mPFLTEMIC0VS7L4enfxEDgIDERIgDatq6cjvrYzuBP bzXDq9ZCbIZqIdOksAnK8s0x3g== X-Google-Smtp-Source: AHgI3IZjhQvOEsdqmnSl1sw4SQcKUEVTmJeCYqabTuwKzytOPpOiWSfgvpH6qvUMYFmJAOiSycW+pA== X-Received: by 2002:a37:d492:: with SMTP id s18mr7101104qks.343.1550948851192; Sat, 23 Feb 2019 11:07:31 -0800 (PST) Received: from [10.0.100.12] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id j66sm5457236qkj.27.2019.02.23.11.07.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Feb 2019 11:07:30 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_108F1B23-24F6-4CDB-A587-7915E753445F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Sat, 23 Feb 2019 14:07:29 -0500 In-Reply-To: <7aad94ae-4adb-349c-e2d4-7fb2485f649d@si6networks.com> Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Christian Huitema , JORDI PALET MARTINEZ To: Fernando Gont References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <564ca34e-981a-ff92-3318-aaeb46b31dac@gont.com.ar> <7aad94ae-4adb-349c-e2d4-7fb2485f649d@si6networks.com> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 23 Feb 2019 19:07:36 -0000 --Apple-Mail=_108F1B23-24F6-4CDB-A587-7915E753445F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Feb 23, 2019, at 12:22 PM, Fernando Gont wrote: > It is extremely likely that I will be requesting agenda myself for 6man. > > If the v6ops chairs think it makes sense to do/present something in > v6ops, I'd be happy too. Great, thanks! --Apple-Mail=_108F1B23-24F6-4CDB-A587-7915E753445F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Feb 23, 2019, at 12:22 PM, Fernando Gont <fgont@si6networks.com> wrote:
It is extremely likely that I will be requesting agenda = myself for 6man.

If the v6ops chairs think it makes sense to do/present = something in
v6ops, I'd be = happy too.

Great, thanks!

= --Apple-Mail=_108F1B23-24F6-4CDB-A587-7915E753445F-- From nobody Mon Feb 25 02:33: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 DDFF6130E84 for ; Mon, 25 Feb 2019 02:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1Lmidbm54W59 for ; Mon, 25 Feb 2019 02:33:09 -0800 (PST) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43290130E58 for ; Mon, 25 Feb 2019 02:33:08 -0800 (PST) Received: by mail-yb1-xb31.google.com with SMTP id s5so3557449ybp.6 for ; Mon, 25 Feb 2019 02:33:08 -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:content-transfer-encoding; bh=m+0nhSQ35CrTfoDF687FvYXc+XpfwSIXuysOp9LG4H4=; b=oqlSldaSYucxWJR2j7sqkKLD9SQxChR9Xja1Mde3WE/+6jA7f9RRudTWEbkZVaxCNY 4PlgzDHzqI8SwP1dni8hSFze64FXgbFmpKVWWoczw5g8DNIHTvxLC+WmopZN/w80bHw8 uIgu2/flyVHG54ylJSB7WEbTbyNiQSWr53BELKunQLEkC/wxjHLogguD9lV4NC4BE5OO DZ+tAOUnmeNjk2xDmF8FUpYG4P16HdEpH1R7r0DLE2JpLBQsx09Zki+GOKmC+pJ2qY5W oXL82e/x5BCUEx8rsCghveSpmz8NBYCsayNfjWkMLZ9FPMaKdxoGbYILyi44gD+9bw3V lKEQ== 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:content-transfer-encoding; bh=m+0nhSQ35CrTfoDF687FvYXc+XpfwSIXuysOp9LG4H4=; b=nRCbqVYDPZxND+jLkeG+VLb3kr87AXD+qC+wqPVlpk+iv0Os+/d92cOHhIQQN1cUS0 Pj0r0oepf0BBmS03SriLWz9E9SvS4H7gwJCa21VA3Y2O3vz54r/OtGR4ACjh3PnWc968 Gg2miSqXZL//RXZAW6qRGtoalIFs2jlk0Ky71YH92MVJeQ667IjfgofBUE3u8Ok/hYD+ Sy7qj6svKvFjui0CcifqAI7An+URc8YFvg/QXDbRfcDnim/Zk7K+OKhFGQPjWqw5U727 4mpoaKuR/Wg/FRVpowoA05IRj7imsCNjSzD9/Coe7HDATETGT3Qq6QqOFmeFpRjVb3Px W1jg== X-Gm-Message-State: AHQUAuZXZTQ+8mzocrcVmSw/LISKulTJJlJZ76lBGSgh8D1YlOOmA+ik WhdWULpvhKFiL1zEG5MtffMAvx6HFCQ= X-Google-Smtp-Source: AHgI3IZJXo3tnuqw0HceFxT0GQkcQudbvwafNLZXVOO1TxSO8rmyLCuraQMLZl2xqfVeWLZhKa319A== X-Received: by 2002:a25:9110:: with SMTP id v16mr13107108ybl.490.1551090787850; Mon, 25 Feb 2019 02:33:07 -0800 (PST) Received: from mail-yw1-f43.google.com (mail-yw1-f43.google.com. [209.85.161.43]) by smtp.gmail.com with ESMTPSA id z201sm3402868ywd.23.2019.02.25.02.33.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 02:33:06 -0800 (PST) Received: by mail-yw1-f43.google.com with SMTP id o184so3446945ywo.5; Mon, 25 Feb 2019 02:33:06 -0800 (PST) X-Received: by 2002:a81:360e:: with SMTP id d14mr13220168ywa.489.1551090786602; Mon, 25 Feb 2019 02:33:06 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> In-Reply-To: <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> From: Richard Patterson Date: Mon, 25 Feb 2019 10:32:54 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 25 Feb 2019 10:33:12 -0000 On Sat, 23 Feb 2019 at 05:22, Fernando Gont wrote: > * As per RFC4862, it turns out that you cannot remove a stale prefix vy > sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards, > not even the CPEs can (even if they wanted to) do something to fix the > problem. The Valid Lifetime cannot be zeroed or shortened below 2 hours, but the Preferred Lifetime can. So we can't invalidate the prefix, but we can deprecate it so it's not used for new outbound sessions. This is what we've implemented in our CPEs, after an unavoidable change in prefix, and it seems to have mitigated (or reduced the impact of) the issue. RFC4862 =C2=A75.5.3 e) If the advertised prefix is equal to the prefix of an address configured by stateless autoconfiguration in the list, the preferred lifetime of the address is reset to the Preferred Lifetime in the received advertisement. .... Note that the preferred lifetime of the corresponding address is always reset to the Preferred Lifetime in the received Prefix Information option, regardless of whether the valid lifetime is also reset or ignored. The difference comes from the fact that the possible attack for the preferred lifetime is relatively minor. Additionally, it is even undesirable to ignore the preferred lifetime when a valid administrator wants to deprecate a particular address by sending a short preferred lifetime (and the valid lifetime is ignored by accident). From nobody Mon Feb 25 04:57: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 88E47130EF9; Mon, 25 Feb 2019 04:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at8SvGGjPj83; Mon, 25 Feb 2019 04:57:10 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97952130EF1; Mon, 25 Feb 2019 04:57:10 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id 32so7666738ota.12; Mon, 25 Feb 2019 04:57: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=t91KmrOcShCiGNFxgeFZ+wgrsKlYcaky/UZBC49vHeQ=; b=DMaBJgDcA8hm86GvOBpcbC/Fx00ftxxtYmYMzDm9lHhhb/FhxsxOqDW7DKOE7hnK// hoHVk2I1kkiZI5/KVyq6AEKPkxOpODXTxYAwMkH9m3pFn2nffr76k92/45UpE/JsdU+b uI0FcprAwjfVtseKhFGkCU10dorVUQkwZv/2OCbHyTcwXEAc3cimfGAfdsaTCmu5DRsu cS6bUC/hOB31TQOBfZbumXW5QYMUj1i6JEsVUzh5DCWQrzh8POnPWWmm4tvlFNwTQbWi M05b9hkGzb24dAj63Af1uBJ6e1q5lh8IpXPvdvPkyYQfa/G7hVFq92OtqZE/3+2G34BO MbWA== 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=t91KmrOcShCiGNFxgeFZ+wgrsKlYcaky/UZBC49vHeQ=; b=ZIYgg6jNPI+VmEQL6QwcsKjPT1UI8aw5qgR/FU4R3m3/QbHCTwMSOdSCtxWCL9YMf9 6BLEpHSGZ4G32cIb5+NOtjc/md/xLmP9LbholImLvQEO5okyHxhjOwX+Ivf+Ukk/WpOI BWLAiLFy0hbW3hU66clOUJ8Px2ZI2EnBaoUgb+s3pzTXxELqRHvFFrx/Me/gNqBK+RH0 +d3Im3UjTFzvqw3unJKWirpmZig2vLlkuVU9iCrQklPlbAiZv+6FvPRWNrr9Oxhb+9BT jydi7dyJtkMWpSXgxsb+Hr2R/P3PQaDW8Vte8griBXU8Jd0wqjQ5zdwYn09bsCAmYVEN MXPA== X-Gm-Message-State: AHQUAuYsmv2rCUtsXZQOvQkl2v9Jb6hYHUQtUV9rtephmgl4/F34WMmo LcxNzbd2WMA1SXZI24PeDLctWfwNtTKjDlVY+yoWPw== X-Google-Smtp-Source: AHgI3Ia9DtpuvH2balubIFyEO/oh0SHtqUKIXcSSwm4LhXtqrhfM04F+ki2769veIBJ139FN2XfWbdfaDD9BUMQ9fEA= X-Received: by 2002:a9d:6d98:: with SMTP id x24mr11813740otp.318.1551099429621; Mon, 25 Feb 2019 04:57:09 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> In-Reply-To: From: Mark Smith Date: Mon, 25 Feb 2019 23:56:57 +1100 Message-ID: To: Richard Patterson Cc: Fernando Gont , v6ops list , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000083978f0582b77aa0" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 25 Feb 2019 12:57:13 -0000 --00000000000083978f0582b77aa0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon., 25 Feb. 2019, 21:33 Richard Patterson, wrote: > On Sat, 23 Feb 2019 at 05:22, Fernando Gont wrote: > > > * As per RFC4862, it turns out that you cannot remove a stale prefix vy > > sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards= , > > not even the CPEs can (even if they wanted to) do something to fix the > > problem. > > > The Valid Lifetime cannot be zeroed or shortened below 2 hours, but > the Preferred Lifetime can. So we can't invalidate the prefix, but we > can deprecate it so it's not used for new outbound sessions. This is > what we've implemented in our CPEs, after an unavoidable change in > prefix, and it seems to have mitigated (or reduced the impact of) the > issue. > It seems the Ubiquity Networks community have discovered the DeprecatePrefix option of 'radvd' and are suggesting its use to mitigate this issue. https://community.ubnt.com/t5/EdgeRouter/Solution-for-client-losing-IPv6-co= nnectivity-after-PPPoE-re/td-p/2019416 > RFC4862 =C2=A75.5.3 > > e) If the advertised prefix is equal to the prefix of an address > configured by stateless autoconfiguration in the list, the > preferred lifetime of the address is reset to the Preferred > Lifetime in the received advertisement. > > .... > > Note that the preferred lifetime of the corresponding address is > always reset to the Preferred Lifetime in the received Prefix > Information option, regardless of whether the valid lifetime is > also reset or ignored. The difference comes from the fact that > the possible attack for the preferred lifetime is relatively > minor. Additionally, it is even undesirable to ignore the > preferred lifetime when a valid administrator wants to deprecate a > particular address by sending a short preferred lifetime (and the > valid lifetime is ignored by accident). > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00000000000083978f0582b77aa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon., 25 Feb. 2019, 21:33 Richard Patterson, <= richard@helix.net.nz> wrote:
On Sat, 23 Feb 2019 at 05:22, Fernando Gont <fernando@gont= .com.ar> wrote:

> * As per RFC4862, it turns out that you cannot remove a stale prefix v= y
> sending an RA wiht a "Prefix Lifetime" of 0. SO, with curren= t standards,
> not even the CPEs can (even if they wanted to) do something to fix the=
> problem.


The Valid Lifetime cannot be zeroed or shortened below 2 hours, but
the Preferred Lifetime can.=C2=A0 So we can't invalidate the prefix, bu= t we
can deprecate it so it's not used for new outbound sessions.=C2=A0 =C2= =A0This is
what we've implemented in our CPEs, after an unavoidable change in
prefix, and it seems to have mitigated (or reduced the impact of) the
issue.

It seems the Ubiquity Networks community have discovered the Deprecat= ePrefix option of 'radvd' and are suggesting its use to mitigate th= is issue.




RFC4862 =C2=A75.5.3

e)=C2=A0 If the advertised prefix is equal to the prefix of an address
=C2=A0 =C2=A0 =C2=A0 configured by stateless autoconfiguration in the list,= the
=C2=A0 =C2=A0 =C2=A0 preferred lifetime of the address is reset to the Pref= erred
=C2=A0 =C2=A0 =C2=A0 Lifetime in the received advertisement.

....

=C2=A0 =C2=A0 =C2=A0 Note that the preferred lifetime of the corresponding = address is
=C2=A0 =C2=A0 =C2=A0 always reset to the Preferred Lifetime in the received= Prefix
=C2=A0 =C2=A0 =C2=A0 Information option, regardless of whether the valid li= fetime is
=C2=A0 =C2=A0 =C2=A0 also reset or ignored.=C2=A0 The difference comes from= the fact that
=C2=A0 =C2=A0 =C2=A0 the possible attack for the preferred lifetime is rela= tively
=C2=A0 =C2=A0 =C2=A0 minor.=C2=A0 Additionally, it is even undesirable to i= gnore the
=C2=A0 =C2=A0 =C2=A0 preferred lifetime when a valid administrator wants to= deprecate a
=C2=A0 =C2=A0 =C2=A0 particular address by sending a short preferred lifeti= me (and the
=C2=A0 =C2=A0 =C2=A0 valid lifetime is ignored by accident).

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www= .ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--00000000000083978f0582b77aa0-- From nobody Mon Feb 25 05:27: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 753E3128CB7 for ; Mon, 25 Feb 2019 05:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4ng85g5LH1o for ; Mon, 25 Feb 2019 05:27:17 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6148A130EFC for ; Mon, 25 Feb 2019 05:27:17 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id p17so7428953iol.7 for ; Mon, 25 Feb 2019 05:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tEqGDKnB4qj4L/nVnzoHNBXLU32qbj3AOh8u9b8rA8s=; b=KhYY8E6R7M4WXa6lFO9KdUJws8IxkBa2eY09xodwcwHej0PwlSPmX2MCguJORFMm0l M3d1x8g9cQd9Mu7VXBFmPGRNdNXDnAyc9MtVFl8AOJssdnu0GNZrJ6SXWZPhvfulmGgl bOPaqX8Doqvkx+mF8MkSMWiqg6TW+IdGZtxTmSLm6x03HTC7MeDELttNTyBnmKSoVDsE GHgdiBHmA5gaQe4TvalQsK63oLnsy7WoxTKcggapoQkj1xI0ehRmbb9MgFlRPHGRH+TT WZ9OjzP1WbWXqHaFNDE0RSsX2AXtuxLn1ChiW3jOhO2Xk+VZwk4Wew1OOSXk7Y7bMFW8 i0Kw== 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=tEqGDKnB4qj4L/nVnzoHNBXLU32qbj3AOh8u9b8rA8s=; b=A8C2OuFWom3u5ek/IDFcxneinsJ4s3db8Yt0v+R1KcbKSIuRtrui+FH0mLzQwATSsF 2Y962Fwb/R7y9F509IQhHMdET6S5yFu4Fi1dIvorT0xBMdlIAHzbgj/zQEdhzUcSsOKs 0wYUisZH60PWnStn/xjBys8/DZPsk70uFgtTKBmetoOjDFS/xVv5kURZpwO3/O50jYdl +iQWbM7OYR79ncR2WbwbcvIC6YetTfS4NIBoxT+gYaqihY7KMroGd+ai3K9szKcnDK/L oZzYTcWHGwHizXqZOeYOQOmAvmRUyQRMPGlChbhVTEXIlgliW8TnbDjD+MtRUiY4xjaW q7Lg== X-Gm-Message-State: AHQUAuab+1OW83C8wDsVDhbcJn6Dtm/dA5tFl55DLpbwFojQjo0w4+q9 AhER2Z5n66NYCMmnYY/JAuc/TXXeZZ8VCzL7wMnSSwcx71o= X-Google-Smtp-Source: AHgI3IZxB2XDL7THtAxfxDcJlzmECWK3A/50ctKcvcwwDuCIL8MaXDhCBMoLyeO5069cz1nSV4lkKKfbq910XUAOmhs= X-Received: by 2002:a5d:848d:: with SMTP id t13mr9695310iom.278.1551101236144; Mon, 25 Feb 2019 05:27:16 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> In-Reply-To: From: Lorenzo Colitti Date: Mon, 25 Feb 2019 22:27:02 +0900 Message-ID: To: Richard Patterson Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000003176ed0582b7e6a2" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 25 Feb 2019 13:27:19 -0000 --0000000000003176ed0582b7e6a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 25, 2019 at 7:33 PM Richard Patterson wrote: > The Valid Lifetime cannot be zeroed or shortened below 2 hours, but > the Preferred Lifetime can. So we can't invalidate the prefix, but we > can deprecate it so it's not used for new outbound sessions. This is > what we've implemented in our CPEs, after an unavoidable change in > prefix, and it seems to have mitigated (or reduced the impact of) the > issue. > > RFC4862 =C2=A75.5.3 > > e) If the advertised prefix is equal to the prefix of an address > configured by stateless autoconfiguration in the list, the > preferred lifetime of the address is reset to the Preferred > Lifetime in the received advertisement. > Have we considered simply removing this paragraph and allowing routers to send RA lifetimes of 0? On an IPv6-capable network, an attacker that is able to send RAs can do way more damage than just this sort of DOS attack - they can collect/monitor traffic, selectively block destinations or sources, etc. etc. --0000000000003176ed0582b7e6a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 25, 2019 at 7:33 PM Richard P= atterson <richard@helix.net.nz> wrote:
The Valid Lifetime cannot be zeroed or shortened b= elow 2 hours, but
the Preferred Lifetime can.=C2=A0 So we can't invalidate the prefix, bu= t we
can deprecate it so it's not used for new outbound sessions.=C2=A0 =C2= =A0This is
what we've implemented in our CPEs, after an unavoidable change in
prefix, and it seems to have mitigated (or reduced the impact of) the
issue.

RFC4862 =C2=A75.5.3

e)=C2=A0 If the advertised prefix is equal to the prefix of an address
=C2=A0 =C2=A0 =C2=A0 configured by stateless autoconfiguration in the list,= the
=C2=A0 =C2=A0 =C2=A0 preferred lifetime of the address is reset to the Pref= erred
=C2=A0 =C2=A0 =C2=A0 Lifetime in the received advertisement.

Have we considered simply removing this paragraph and= allowing routers to send RA lifetimes of 0? On an IPv6-capable network, an= attacker that is able to send RAs can do way more damage than just this so= rt of DOS attack - they can collect/monitor traffic, selectively block dest= inations or sources, etc. etc.
--0000000000003176ed0582b7e6a2-- From nobody Mon Feb 25 06:36: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 6EEC4130F05; Mon, 25 Feb 2019 06:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 85haY7U9dqYq; Mon, 25 Feb 2019 06:36:18 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AAD130EF9; Mon, 25 Feb 2019 06:36:18 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x1PCZnkO047536; Mon, 25 Feb 2019 07:42:28 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2qv841h8tr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Feb 2019 07:42:28 -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 x1PCgQ5Y000451; Mon, 25 Feb 2019 07:42:26 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x1PCgJfI000384; Mon, 25 Feb 2019 07:42:19 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 66A3941413C1; Mon, 25 Feb 2019 12:42:19 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30488.vci.att.com (Service) with ESMTPS id 4D90D41413BF; Mon, 25 Feb 2019 12:42:19 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0435.000; Mon, 25 Feb 2019 07:42:19 -0500 From: "STARK, BARBARA H" To: "'Richard Patterson'" , Fernando Gont CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUyRB1A4rRXEu/AkCHHYmUZ2FLvaXpdPCAgAAT7oCAAAy1AIAAGD2AgACD6wCAAOwQAIAAA7GAgAAOpoCAAAUjAIAAMI8AgABg2gCAAFGZgIABE4OAgAOA1QD//8/GIA== Date: Mon, 25 Feb 2019 12:42:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E0B9446@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.217.239] 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-02-25_06:, , 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=974 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902250093 Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 25 Feb 2019 14:36:20 -0000 PiA+ICogQXMgcGVyIFJGQzQ4NjIsIGl0IHR1cm5zIG91dCB0aGF0IHlvdSBjYW5ub3QgcmVtb3Zl IGEgc3RhbGUgcHJlZml4DQo+ID4gdnkgc2VuZGluZyBhbiBSQSB3aWh0IGEgIlByZWZpeCBMaWZl dGltZSIgb2YgMC4gU08sIHdpdGggY3VycmVudA0KPiA+IHN0YW5kYXJkcywgbm90IGV2ZW4gdGhl IENQRXMgY2FuIChldmVuIGlmIHRoZXkgd2FudGVkIHRvKSBkbyBzb21ldGhpbmcNCj4gPiB0byBm aXggdGhlIHByb2JsZW0uDQo+IA0KPiANCj4gVGhlIFZhbGlkIExpZmV0aW1lIGNhbm5vdCBiZSB6 ZXJvZWQgb3Igc2hvcnRlbmVkIGJlbG93IDIgaG91cnMsIGJ1dCB0aGUNCj4gUHJlZmVycmVkIExp ZmV0aW1lIGNhbi4gIFNvIHdlIGNhbid0IGludmFsaWRhdGUgdGhlIHByZWZpeCwgYnV0IHdlDQo+ IGNhbiBkZXByZWNhdGUgaXQgc28gaXQncyBub3QgdXNlZCBmb3IgbmV3IG91dGJvdW5kIHNlc3Np b25zLiAgIFRoaXMgaXMNCj4gd2hhdCB3ZSd2ZSBpbXBsZW1lbnRlZCBpbiBvdXIgQ1BFcywgYWZ0 ZXIgYW4gdW5hdm9pZGFibGUgY2hhbmdlIGluIHByZWZpeCwNCj4gYW5kIGl0IHNlZW1zIHRvIGhh dmUgbWl0aWdhdGVkIChvciByZWR1Y2VkIHRoZSBpbXBhY3Qgb2YpIHRoZSBpc3N1ZS4NCj4gDQo+ IFJGQzQ4NjIgwqc1LjUuMw0KPiANCj4gZSkgIElmIHRoZSBhZHZlcnRpc2VkIHByZWZpeCBpcyBl cXVhbCB0byB0aGUgcHJlZml4IG9mIGFuIGFkZHJlc3MNCj4gICAgICAgY29uZmlndXJlZCBieSBz dGF0ZWxlc3MgYXV0b2NvbmZpZ3VyYXRpb24gaW4gdGhlIGxpc3QsIHRoZQ0KPiAgICAgICBwcmVm ZXJyZWQgbGlmZXRpbWUgb2YgdGhlIGFkZHJlc3MgaXMgcmVzZXQgdG8gdGhlIFByZWZlcnJlZA0K PiAgICAgICBMaWZldGltZSBpbiB0aGUgcmVjZWl2ZWQgYWR2ZXJ0aXNlbWVudC4NCj4gDQo+IC4u Li4NCj4gDQo+ICAgICAgIE5vdGUgdGhhdCB0aGUgcHJlZmVycmVkIGxpZmV0aW1lIG9mIHRoZSBj b3JyZXNwb25kaW5nIGFkZHJlc3MgaXMNCj4gICAgICAgYWx3YXlzIHJlc2V0IHRvIHRoZSBQcmVm ZXJyZWQgTGlmZXRpbWUgaW4gdGhlIHJlY2VpdmVkIFByZWZpeA0KPiAgICAgICBJbmZvcm1hdGlv biBvcHRpb24sIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgdmFsaWQgbGlmZXRpbWUgaXMNCj4g ICAgICAgYWxzbyByZXNldCBvciBpZ25vcmVkLiAgVGhlIGRpZmZlcmVuY2UgY29tZXMgZnJvbSB0 aGUgZmFjdCB0aGF0DQo+ICAgICAgIHRoZSBwb3NzaWJsZSBhdHRhY2sgZm9yIHRoZSBwcmVmZXJy ZWQgbGlmZXRpbWUgaXMgcmVsYXRpdmVseQ0KPiAgICAgICBtaW5vci4gIEFkZGl0aW9uYWxseSwg aXQgaXMgZXZlbiB1bmRlc2lyYWJsZSB0byBpZ25vcmUgdGhlDQo+ICAgICAgIHByZWZlcnJlZCBs aWZldGltZSB3aGVuIGEgdmFsaWQgYWRtaW5pc3RyYXRvciB3YW50cyB0byBkZXByZWNhdGUgYQ0K PiAgICAgICBwYXJ0aWN1bGFyIGFkZHJlc3MgYnkgc2VuZGluZyBhIHNob3J0IHByZWZlcnJlZCBs aWZldGltZSAoYW5kIHRoZQ0KPiAgICAgICB2YWxpZCBsaWZldGltZSBpcyBpZ25vcmVkIGJ5IGFj Y2lkZW50KS4NCg0KUGVyIFJGQyA3MDg0Og0KICAgTC0xMzogIElmIHRoZSBkZWxlZ2F0ZWQgcHJl Zml4IGNoYW5nZXMsIGkuZS4sIHRoZSBjdXJyZW50IHByZWZpeCBpcw0KICAgICAgICAgIHJlcGxh Y2VkIHdpdGggYSBuZXcgcHJlZml4IHdpdGhvdXQgYW55IG92ZXJsYXBwaW5nIHRpbWUNCiAgICAg ICAgICBwZXJpb2QsIHRoZW4gdGhlIElQdjYgQ0Ugcm91dGVyIE1VU1QgaW1tZWRpYXRlbHkgYWR2 ZXJ0aXNlIHRoZQ0KICAgICAgICAgIG9sZCBwcmVmaXggd2l0aCBhIFByZWZlcnJlZCBMaWZldGlt ZSBvZiB6ZXJvIGFuZCBhIFZhbGlkDQogICAgICAgICAgTGlmZXRpbWUgb2YgZWl0aGVyIGEpIHpl cm8gb3IgYikgdGhlIGxvd2VyIG9mIHRoZSBjdXJyZW50DQogICAgICAgICAgVmFsaWQgTGlmZXRp bWUgYW5kIHR3byBob3VycyAod2hpY2ggbXVzdCBiZSBkZWNyZW1lbnRlZCBpbg0KICAgICAgICAg IHJlYWwgdGltZSkgaW4gYSBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdlIGFzIGRlc2NyaWJl ZCBpbg0KICAgICAgICAgIFNlY3Rpb24gNS41LjMsIChlKSBvZiBbUkZDNDg2Ml0uDQoNCkJhcmJh cmENCg== From nobody Mon Feb 25 07:23: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 70461130EF9; Mon, 25 Feb 2019 07:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra7I5-FLwrnH; Mon, 25 Feb 2019 07:22:59 -0800 (PST) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA28112F1AB; Mon, 25 Feb 2019 07:22:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 5B84A3201FA9; Mon, 25 Feb 2019 12:22:56 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0wUmPCxPDeW1; Mon, 25 Feb 2019 12:22:54 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id B11073201FAC; Mon, 25 Feb 2019 12:22:54 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar B11073201FAC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1551108174; bh=d5wyBfK+LXFYfGVZW1SbIsvCMf/nIC4YGsQDp6Lta+g=; h=Date:From:To:Message-ID:MIME-Version; b=AoTw98JSCxPD7TTNgSA+F3UfvIElsk3PzUVgT3mj336RZ/954TWIFkSmQ8/dI6O+4 CacjSv0/jXfhRtVJJgXE6mf6WgoPM5t4pYSXBFeoyuV+RZronQfmwxOPOam6GDGway ih0hR58PDQLo7igKgWm7y7ntEigPUfa9WCxX7pq3gt37AvAENmQOaA4FukS3caietF TS7MKRsOgTjbwmS8g23tQDe7PzFw7XibyMeFcb1OB+FNIgtwsIkseoDC9uTTNIwohR Po2IpkchmGL/IN9YxWbxoQjtqF52rFPL/jbFPwBOjqqHO4g2uFxMJ0ZIvAJxvUq2Tn UrO6dWr7Pu7/w== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Zfq957ybW9Gp; Mon, 25 Feb 2019 12:22:54 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 759E13201FA9; Mon, 25 Feb 2019 12:22:54 -0300 (-03) Date: Mon, 25 Feb 2019 12:22:54 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" , dnsop Message-ID: <128899659.2649874.1551108174039.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <40C16CF8-8EE8-468D-8248-A2873CC7EAB6@consulintel.es> References: <40C16CF8-8EE8-468D-8248-A2873CC7EAB6@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC72 (Win)/8.8.8_GA_1703) Thread-Topic: inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment Thread-Index: 4g1eMoftmD8xnaYUH5EqHNFIxoK+Hg== Archived-At: Subject: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment 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, 25 Feb 2019 15:23:03 -0000 Hello Jordi, I like 464XLAT and this is something I would like to implement in DOCSIS networks. As Deployment Guidelines maybe you can include/consider the next case, if not please forget it or we can include it on another document. Today we still have many devices that don't support IPv6 or some applications on it don't support it, this is the case of SMART TVs and set top boxes. There is a common scenario where big public CDNs support deliver content to private IPv4 destinations (usually CGN prefixes) directly without going through a CGN. In that scenario, CPEs (with eRouter) that have IPv4 of CGN (ie 100.64.x.x) can connect receive traffic from CDNs directly without having any CGN in the middle. So I see three points in this case: 1- Traffic avoids a point of failure (CGN), obviously it should be redundant but the point of failure exists. 2- Traffic is more "transparent" avoiding another translation for CDN. 3- This traffic doesn't impact in CGN sizing. As I said, I like 464XLAT and I would like to have a IPv6-Only access network but this is a real case where ISPs can consider to continue provisioning IPv4 to customers. Regards, Alejandro ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "v6ops@ietf.org list" , "dnsop" Enviados: Jueves, 21 de Febrero 2019 2:58:36 Asunto: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment Hi all, (dnsop copied because DNS64) I'm working in a new version of this document. Link to the document: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ It will be great if we can get some new inputs. Thanks! Regards, Jordi ********************************************** 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. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 25 10:30: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 0FB05130F13; Mon, 25 Feb 2019 10:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv_9HFxFoz9w; Mon, 25 Feb 2019 10:30:07 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1B012426A; Mon, 25 Feb 2019 10:30:06 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 94CCF8425D; Mon, 25 Feb 2019 19:30:02 +0100 (CET) To: Lorenzo Colitti , Richard Patterson Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Mon, 25 Feb 2019 15:29:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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, 25 Feb 2019 18:30:11 -0000 Hello, Lorenzo, On 25/2/19 10:27, Lorenzo Colitti wrote: > On Mon, Feb 25, 2019 at 7:33 PM Richard Patterson > wrote: > > The Valid Lifetime cannot be zeroed or shortened below 2 hours, but > the Preferred Lifetime can.  So we can't invalidate the prefix, but we > can deprecate it so it's not used for new outbound sessions.   This is > what we've implemented in our CPEs, after an unavoidable change in > prefix, and it seems to have mitigated (or reduced the impact of) the > issue. > > RFC4862 §5.5.3 > > e)  If the advertised prefix is equal to the prefix of an address >       configured by stateless autoconfiguration in the list, the >       preferred lifetime of the address is reset to the Preferred >       Lifetime in the received advertisement. > > > Have we considered simply removing this paragraph and allowing routers > to send RA lifetimes of 0? On an IPv6-capable network, an attacker that > is able to send RAs can do way more damage than just this sort of DOS > attack - they can collect/monitor traffic, selectively block > destinations or sources, etc. etc. I completely agree. And yes, we have considered that and will be incorporating that in the next rev of the I-D. If you want to peek at my working copy (upcoming version -02), it is available at: https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt (Section 5.1.1.2 proposes this, with the same rationale you suggested above). 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 Feb 25 10:37:47 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 3C9B2130F33; Mon, 25 Feb 2019 10:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9v18nvWWRNb; Mon, 25 Feb 2019 10:37:32 -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 45EF6130F2B; Mon, 25 Feb 2019 10:37:32 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 06DBF8493E; Mon, 25 Feb 2019 19:37:27 +0100 (CET) To: Richard Patterson , Fernando Gont Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Mon, 25 Feb 2019 15:36:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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, 25 Feb 2019 18:37:34 -0000 On 25/2/19 07:32, Richard Patterson wrote: > On Sat, 23 Feb 2019 at 05:22, Fernando Gont wrote: > >> * As per RFC4862, it turns out that you cannot remove a stale prefix vy >> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards, >> not even the CPEs can (even if they wanted to) do something to fix the >> problem. > > > The Valid Lifetime cannot be zeroed or shortened below 2 hours, but > the Preferred Lifetime can. So we can't invalidate the prefix, but we > can deprecate it so it's not used for new outbound sessions. This is > what we've implemented in our CPEs, after an unavoidable change in > prefix, and it seems to have mitigated (or reduced the impact of) the > issue. Agreed. That said, with the current default lifetime values, things become tricky: At least in theory, you should be sending such RAs for "Valid Lifetime" seconds. With a default of one month, that means that, in theory, you should be sending such RAs for a month. And if there are multiple crash-and-reboot events, you should advertise each of the stale prefixes. (I assume the CPE just records the last one) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 25 17:12: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 0DCC5129C6A for ; Mon, 25 Feb 2019 17:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8M1E4yJ1gvN for ; Mon, 25 Feb 2019 17:12:27 -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 1401E1294FA for ; Mon, 25 Feb 2019 17:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1551143544; x=1551748344; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=g3bjO5q25gr4fRspYaYcf myBIh/eZh+hOVenzYzxXx8=; b=kvFtUz3IA+YMvn7wT0f+JzgVMTqGnDUDRy7lU v02cOyhr5R56V90r7A2UU7c+YbJ1esaCevjWcUXxgYi1BfgKHdEmlCfw9JeCA/Nq RlYpdxw//e579Dc5+NQuasuNXgZwcEPCAp1R0wxZbGNiMhbRgB+2Yfg3/nwZ+JaV Y/qMOM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 26 Feb 2019 02:12:24 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 26 Feb 2019 02:12:23 +0100 Received: from [220.247.145.169] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006167941.msg for ; Tue, 26 Feb 2019 02:12:22 +0100 X-MDRemoteIP: 220.247.145.169 X-MDHelo: [220.247.145.169] X-MDArrival-Date: Tue, 26 Feb 2019 02:12:22 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1960526b21=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Tue, 26 Feb 2019 10:12:12 +0900 From: JORDI PALET MARTINEZ To: Alejandro D'Egidio CC: "v6ops@ietf.org list" Message-ID: <20BC09A5-791D-4E6F-88C1-E20E0E75287B@consulintel.es> Thread-Topic: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment 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 Feb 2019 01:12:30 -0000 Hi Alejandro, (removed dnsop, as this is not - I think - relevant for them) My understanding is that CDNs today have IPv6 already (at least the most im= portant ones, the ones with more traffic). If that's the case, the traffic = from the CEs, will be IPv6. Now, if a CDN don't have IPv6 support, in 464XLAT, the link is IPv6-only, s= o I don't see how we can change that. However, also I see that a possible solution for an IPv4-only CDN to suppor= t IPv6 in this scenario, may be via stateless NAT64, with pre-configured EA= MT (RFC7757) rules or something similar and the relevant AAAA entries. I th= ink this is more an operational issue than a new protocol. Clearly that means that you don't have that traffic in the stateful NAT64, = which I understand is your main goal. Anyway, of course, the right thing for those IPv4-only CDNs will be to push= them for IPv6 support! I will be nice if you can publicly name them ... That make sense to you? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alejandro D'Egidio Fecha: martes, 26 de febrero de 2019, 0:24 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" , dnsop Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks draft-ietf-v6ops-nat64-deployment Hello Jordi, I like 464XLAT and this is something I would like to implement in DOCSI= S networks. As Deployment Guidelines maybe you can include/consider the next case, = if not please forget it or we can include it on another document. =20 Today we still have many devices that don't support IPv6 or some applic= ations on it don't support it, this is the case of SMART TVs and set top bo= xes. There is a common scenario where big public CDNs support deliver conten= t to private IPv4 destinations (usually CGN prefixes) directly without goin= g through a CGN. In that scenario, CPEs (with eRouter) that have IPv4 of CGN (ie 100.64.= x.x) can connect receive traffic from CDNs directly without having any CGN = in the middle. =20 So I see three points in this case: 1- Traffic avoids a point of failure (CGN), obviously it should be redu= ndant but the point of failure exists. 2- Traffic is more "transparent" avoiding another translation for CDN. 3- This traffic doesn't impact in CGN sizing. =20 As I said, I like 464XLAT and I would like to have a IPv6-Only access n= etwork but this is a real case where ISPs can consider to continue provisio= ning IPv4 to customers. =20 =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "v6ops@ietf.org list" , "dnsop" Enviados: Jueves, 21 de Febrero 2019 2:58:36 Asunto: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks draft-ietf-v6ops-nat64-deployment =20 Hi all, =20 (dnsop copied because DNS64) =20 I'm working in a new version of this document. =20 Link to the document: =20 https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 It will be great if we can get some new inputs. =20 Thanks! =20 Regards, Jordi =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, 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 awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.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 Feb 26 01:17:27 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 90F1B130EA3 for ; Tue, 26 Feb 2019 01:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-81ma5Lbbiw for ; Tue, 26 Feb 2019 01:17:12 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0FA130EE0 for ; Tue, 26 Feb 2019 01:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1551172629; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rdvDtTu3hdfsz/CNtklVp/m/snSIbyWZ5McOxIjQ7Vw=; b=Nj75tG4aaMMLCx5Mq+FCfPqI7ENuiGUqq/fteeKYwStM8hHqHv3D/UjsH5tqki0m6IUrjyNz0a4XFrHuOl4VR1Jb/451QZf3YPNVZLNHfzpVlDjyYJDiVMcu+YOMElG9yt7Qv03XCr73fa0oawwqCXGEBxy5tbkzMzNKy+o/K6U= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp2057.outbound.protection.outlook.com [104.47.8.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-51-FKS8RVzXMMqj9vQ_7XIlLg-2; Tue, 26 Feb 2019 09:17:06 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.54.140) by AM0PR07MB5473.eurprd07.prod.outlook.com (20.178.22.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.12; Tue, 26 Feb 2019 09:17:03 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb%4]) with mapi id 15.20.1665.012; Tue, 26 Feb 2019 09:17:03 +0000 From: Tim Chown To: Fernando Gont CC: Richard Patterson , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUzTkBQuNentVJFkebkUvTotpgtqXxzZ4A Date: Tue, 26 Feb 2019 09:17:03 +0000 Message-ID: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-originating-ip: [141.85.248.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e007613-c746-4eb5-6598-08d69bcb2baf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB5473; x-ms-traffictypediagnostic: AM0PR07MB5473: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: 1; AM0PR07MB5473; 20:018UKT0mtrIvMNvFBAkN1R/GP/aoVQZDzdKVBNjlhkRjJhtx0W6O2cN4G5UP1mIreyGbztVS6mjq1xDxcg1v44wjLY3RnPLjVlSXsDaYTS/tK3/Nq8h9marCETqj5+zKQJT3ruNWLjhFPN1eCmmZQ68pYC+jGYlwx2YiiWDkV90= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39850400004)(346002)(396003)(366004)(376002)(189003)(199004)(25786009)(4326008)(36756003)(446003)(6246003)(786003)(11346002)(2616005)(476003)(74482002)(93886005)(6916009)(81166006)(81156014)(8676002)(86362001)(316002)(97736004)(3846002)(6116002)(486006)(106356001)(53936002)(6512007)(105586002)(6306002)(256004)(14444005)(229853002)(66066001)(14454004)(478600001)(6436002)(5660300002)(57306001)(53546011)(33656002)(76176011)(186003)(26005)(6506007)(102836004)(8936002)(54906003)(50226002)(2906002)(7736002)(71200400001)(71190400001)(83716004)(82746002)(68736007)(305945005)(99286004)(72206003)(6486002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5473; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PoNx3OrwXAg2c7pCYeiXQgbTkOh7Rno6R1XeUFdTcx1eB8RG/68Erz479hjPUxfNQqkpAdkJcV+oqnii8KdQGyyDIoSjXFVLluPIVWayAZUaxXmiBtfD1xjJn0w+ZGwNN20YNF/gs8Pft5Ap/mKD0cIwWqJ8wIVVMAlPCyzQm2WnbdDVpesCzcBB327g3/szjynbzVUe3IB/NYbLIgMTqhZ/BStKAqFj3O4KtiHrQUZSOkLZuK3pjaqrbD+FTlmFk0wKVa/uRVeMROSFrcyB7xx0sGxy+CpFWyJze8zasF54S1Ukk+mqx5H3/c9A4N54TDNepj6VYw7ogBezgt/d1eIe1PmbwfYfY9dUWWfLJVB+qpv6AEPp11nZYFDWZIzmcU6UaE4toGl+D8FAxTfAYcJWlwduOBi42sPk74k4GQs= Content-ID: <1AEDECB4A05F584483A830FCEEC1F755@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 5e007613-c746-4eb5-6598-08d69bcb2baf X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 09:17:03.1574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5473 X-MC-Unique: FKS8RVzXMMqj9vQ_7XIlLg-2 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 09:17:16 -0000 > On 25 Feb 2019, at 18:36, Fernando Gont wrote: >=20 > On 25/2/19 07:32, Richard Patterson wrote: >> On Sat, 23 Feb 2019 at 05:22, Fernando Gont wrote= : >>=20 >>> * As per RFC4862, it turns out that you cannot remove a stale prefix vy >>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards= , >>> not even the CPEs can (even if they wanted to) do something to fix the >>> problem. >>=20 >> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but >> the Preferred Lifetime can. So we can't invalidate the prefix, but we >> can deprecate it so it's not used for new outbound sessions. This is >> what we've implemented in our CPEs, after an unavoidable change in >> prefix, and it seems to have mitigated (or reduced the impact of) the >> issue. >=20 > Agreed. That said, with the current default lifetime values, things > become tricky: > At least in theory, you should be sending such RAs for "Valid Lifetime" > seconds. With a default of one month, that means that, in theory, you > should be sending such RAs for a month. And if there are multiple > crash-and-reboot events, you should advertise each of the stale > prefixes. (I assume the CPE just records the last one) When / where was the default Valid Lifetime chosen to be one month? Tim > --=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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Feb 26 02:02: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 E0429130EBB; Tue, 26 Feb 2019 02:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q5o0LpkYxmSj; Tue, 26 Feb 2019 02:02:29 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC32C130EB8; Tue, 26 Feb 2019 02:02:28 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 1A37783989; Tue, 26 Feb 2019 11:02:07 +0100 (CET) To: Tim Chown Cc: Richard Patterson , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> Date: Tue, 26 Feb 2019 06:33:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:02:32 -0000 Hi, Tim, On 26/2/19 06:17, Tim Chown wrote: >> On 25 Feb 2019, at 18:36, Fernando Gont wrote: >> >> On 25/2/19 07:32, Richard Patterson wrote: >>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont wrote: >>> >>>> * As per RFC4862, it turns out that you cannot remove a stale prefix vy >>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards, >>>> not even the CPEs can (even if they wanted to) do something to fix the >>>> problem. >>> >>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but >>> the Preferred Lifetime can. So we can't invalidate the prefix, but we >>> can deprecate it so it's not used for new outbound sessions. This is >>> what we've implemented in our CPEs, after an unavoidable change in >>> prefix, and it seems to have mitigated (or reduced the impact of) the >>> issue. >> >> Agreed. That said, with the current default lifetime values, things >> become tricky: >> At least in theory, you should be sending such RAs for "Valid Lifetime" >> seconds. With a default of one month, that means that, in theory, you >> should be sending such RAs for a month. And if there are multiple >> crash-and-reboot events, you should advertise each of the stale >> prefixes. (I assume the CPE just records the last one) > > When / where was the default Valid Lifetime chosen to be one month? Section 6.2.1 of RFC 4861: AdvPrefixList A list of prefixes to be placed in Prefix Information options in Router Advertisement messages sent from the interface. Default: all prefixes that the router advertises via routing protocols as being on-link for the interface from which the advertisement is sent. The link-local prefix SHOULD NOT be included in the list of advertised prefixes. Each prefix has an associated: AdvValidLifetime The value to be placed in the Valid Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. Implementations MAY allow AdvValidLifetime to be specified in two ways: - a time that decrements in real time, that is, one that will result in a Lifetime of zero at the specified time in the future, or - a fixed time that stays the same in consecutive advertisements. Default: 2592000 seconds (30 days), fixed (i.e., stays the same in consecutive advertisements). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 26 02:06: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 DDA29130EBF for ; Tue, 26 Feb 2019 02:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37QfroDWw84d for ; Tue, 26 Feb 2019 02:06:33 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D57130EB4 for ; Tue, 26 Feb 2019 02:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1551175591; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fQKj0fAJEqKjTb+2iQWVZ1NXbxCjKAcD48R7GsP88oU=; b=HBcYMzvRhHQVTtl4OK8qzdzMM3xj/f24ks4k2GZQ9bfkrcGTpt/+TaMZLxuAmsctfxkoFsbx9GC3dHGWFt4au8hGT37vqRe6M2wvQbJLSxliS4A4idcR51I+hHZMaXdA1dOqPIP1N6YUF58KihpqqRb9a/6b6rC9xFvHEHjms7w= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp2051.outbound.protection.outlook.com [104.47.6.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-127-H3d02anXOdixwOMM5QFdIA-2; Tue, 26 Feb 2019 10:06:28 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.54.140) by AM0PR07MB4705.eurprd07.prod.outlook.com (52.135.151.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.6; Tue, 26 Feb 2019 10:06:24 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb%4]) with mapi id 15.20.1665.012; Tue, 26 Feb 2019 10:06:24 +0000 From: Tim Chown To: Fernando Gont CC: Richard Patterson , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios Thread-Index: AQHUzTkBQuNentVJFkebkUvTotpgtqXxzZ4AgAAEqwCAAAkfgA== Date: Tue, 26 Feb 2019 10:06:24 +0000 Message-ID: <899A1249-D3D9-4824-8B2E-7E950FBB316A@jisc.ac.uk> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> In-Reply-To: <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-originating-ip: [141.85.248.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a020c208-2b16-429a-bf02-08d69bd210db x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4705; x-ms-traffictypediagnostic: AM0PR07MB4705: x-microsoft-exchange-diagnostics: 1; AM0PR07MB4705; 20:v2OHvJWUCi2Rgsge4PGw6Wn8bEkHayb864Rqn9kBHGi9GTgY4nfbN2p+98D5g991t5UAaYlRo2TxRZaANbs5NRv9/b+tbVd5OlC3AqHNpMymu6fUNKLRqTROl5rLTAsUyfpHVr4WMMyE9UlL+iFyO42Qq3JMs0ubbiVUwrDhBQA= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39850400004)(396003)(366004)(346002)(189003)(199004)(305945005)(25786009)(6346003)(68736007)(93886005)(33656002)(26005)(7736002)(6246003)(3846002)(66066001)(6486002)(6116002)(186003)(102836004)(2616005)(105586002)(83716004)(71200400001)(71190400001)(6506007)(6512007)(74482002)(11346002)(446003)(53546011)(66574012)(97736004)(106356001)(476003)(6916009)(76176011)(478600001)(5660300002)(256004)(81156014)(8676002)(4326008)(14454004)(486006)(2906002)(8936002)(82746002)(81166006)(316002)(54906003)(53936002)(86362001)(6436002)(99286004)(786003)(50226002)(57306001)(14444005)(36756003)(229853002)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4705; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wek86SSiuYS0FCP69v4OpVFe+EvJumv8rdALIqgUv+X60+k5O9cF2L46iHk+eZvsNa1J/2qO7AWwlxIFmURvgRPAYoQEM8oMxuaarjyWbzXJuj4OkJi9bKNsdId132ZX9yBXOle+wNdNrORiTo1UXfWjwexk9KhBRY6jIQGZCGf11Tbt6oYQabPlvSfJSENjPizH/4bsNmSChRJlT6ogHW+IrT51KO6mr6WBk+fNTQ9lyNQ3IwRq+kboCs9NR0Zv91l1UlJh0RBL1G4GQDHZR9L2fpEw/jnEBS75e2ks991lOgh18b6G4J7CzCf+HQn/nIcRGIo0bawliRGwr50PtkwqSJEnVFZDFz4SusLtJQGcZZd8wzKmDVSzUdzWzsz2UVS1yJamFA61rY4NjUlHpgrPJv1oOB1y78EAu9EdtHY= Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: a020c208-2b16-429a-bf02-08d69bd210db X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 10:06:24.6587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4705 X-MC-Unique: H3d02anXOdixwOMM5QFdIA-2 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:06:35 -0000 > On 26 Feb 2019, at 09:33, Fernando Gont wrote: >=20 > Section 6.2.1 of RFC 4861: >=20 > AdvPrefixList > A list of prefixes to be placed in Prefix > Information options in Router Advertisement > messages sent from the interface. >=20 > Default: all prefixes that the router advertises > via routing protocols as being on-link for the > interface from which the advertisement is sent. > The link-local prefix SHOULD NOT be included in the > list of advertised prefixes. >=20 > Each prefix has an associated: >=20 > AdvValidLifetime > The value to be placed in the Valid > Lifetime in the Prefix Information option, > in seconds. The designated value of all > 1's (0xffffffff) represents infinity. > Implementations MAY allow AdvValidLifetime > to be specified in two ways: >=20 > - a time that decrements in real time, > that is, one that will result in a > Lifetime of zero at the specified time > in the future, or >=20 > - a fixed time that stays the same in > consecutive advertisements. >=20 > Default: 2592000 seconds (30 days), fixed > (i.e., stays the same in consecutive > advertisements). So given that document is 12 years old, with that default copied from one t= hat is 21 years old, is an update required? =20 And if so, to what? Tim From nobody Tue Feb 26 02:13: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 1F85C130EBC; Tue, 26 Feb 2019 02:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgmNJXOU2OzU; Tue, 26 Feb 2019 02:13:52 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C715130EB8; Tue, 26 Feb 2019 02:13:52 -0800 (PST) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 97858FECBB2B; Tue, 26 Feb 2019 10:13:50 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C8685EE96A7; Tue, 26 Feb 2019 11:13:47 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ole Troan In-Reply-To: <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> Date: Tue, 26 Feb 2019 11:13:47 +0100 Cc: Tim Chown , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:13:54 -0000 Fernando, >>> On 25 Feb 2019, at 18:36, Fernando Gont = wrote: >>>=20 >>> On 25/2/19 07:32, Richard Patterson wrote: >>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont = wrote: >>>>=20 >>>>> * As per RFC4862, it turns out that you cannot remove a stale = prefix vy >>>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current = standards, >>>>> not even the CPEs can (even if they wanted to) do something to fix = the >>>>> problem. >>>>=20 >>>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but >>>> the Preferred Lifetime can. So we can't invalidate the prefix, but = we >>>> can deprecate it so it's not used for new outbound sessions. This = is >>>> what we've implemented in our CPEs, after an unavoidable change in >>>> prefix, and it seems to have mitigated (or reduced the impact of) = the >>>> issue. >>>=20 >>> Agreed. That said, with the current default lifetime values, things >>> become tricky: >>> At least in theory, you should be sending such RAs for "Valid = Lifetime" >>> seconds. With a default of one month, that means that, in theory, = you >>> should be sending such RAs for a month. And if there are multiple >>> crash-and-reboot events, you should advertise each of the stale >>> prefixes. (I assume the CPE just records the last one) >>=20 >> When / where was the default Valid Lifetime chosen to be one month? >=20 > Section 6.2.1 of RFC 4861: >=20 > AdvPrefixList > A list of prefixes to be placed in Prefix > Information options in Router Advertisement > messages sent from the interface. >=20 > Default: all prefixes that the router advertises > via routing protocols as being on-link for the > interface from which the advertisement is sent. > The link-local prefix SHOULD NOT be included in = the > list of advertised prefixes. >=20 > Each prefix has an associated: >=20 > AdvValidLifetime > The value to be placed in the Valid > Lifetime in the Prefix Information option, > in seconds. The designated value of all > 1's (0xffffffff) represents infinity. > Implementations MAY allow AdvValidLifetime > to be specified in two ways: >=20 > - a time that decrements in real time, > that is, one that will result in a > Lifetime of zero at the specified time > in the future, or >=20 > - a fixed time that stays the same in > consecutive advertisements. >=20 > Default: 2592000 seconds (30 days), fixed > (i.e., stays the same in consecutive > advertisements). Red herring. RA lifetimes cannot be longer than the DHCP PD lifetimes. In the DHCP PD case they should also be counted down in real time. And the lifetimes can be dynamically adjusted. Cheers, Ole= From nobody Tue Feb 26 02:35: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 AC9F6130EC0 for ; Tue, 26 Feb 2019 02:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 udOYpCRHWJVU for ; Tue, 26 Feb 2019 02:35:34 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A7C130EBC for ; Tue, 26 Feb 2019 02:35:34 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id d9so5010779ybj.2 for ; Tue, 26 Feb 2019 02:35:34 -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=jIv8QrB/ukgD4eKiSDSc3OTuUb+3+ANBywpHfl7MPzs=; b=ptaAHM2QpTIR8lFk3h69N6P+yxG/Erl/z37icwm/GzTCn+Pin6s8oc9MI23iiyH7Kr uVtDD4F6yZQDTlGtm5+3nFnL3YpRfwLJMfLYPKjxpqDAzo7CuuE+IPdJ191T4MMaieUq bPscGkiKc2pipCKd5s1BY3Try2GHUTDtsexQ0Q5BxTYXXwXYiPS9x/N4OqWAjaXixpJU 3GiP8t8e/K3jaHU30CxHlb+XSAY/KYKcxzviy2vx5KwicBsJkyVF1RYMEN905COu3lXX UndiYzvddi6gouFVzTRUxt2+AIVb2hc6yg666L+lNOuuzMRyDVyXLIWp+ElNdCmYZxTx JHOA== 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=jIv8QrB/ukgD4eKiSDSc3OTuUb+3+ANBywpHfl7MPzs=; b=MS7GlKRc+Yuw29UPJcFT3NLMKhn1unPgVeIcDZqwhHEFHxQubf8mbB3KLjWzh8VnjZ FDhZg2X27Iaa+87Ru34XQja/Dx9pfQm4j9Qao3If5RPaXyJKCi2HqkLB90QgqhtFcwMN Vv6hEHUj0JDC87mEC2EKRCXfdbRtjaBb6nMwWcz7z+CbFcyX62h4PRBbwO4SA/BbNauF GsRIkXZgyzy6ZGH7WDc3E2qRYhknghGb51Tt3u0UiWfkdo1MR9/6P6L+4W2tVE33/nHF SmBD/O/TpVprTJVknudWDb6WsLC0Quy/M2+GxaVTmEKThX2rLxn079B1QBBkfqE0FaVs IGRg== X-Gm-Message-State: AHQUAubIcPIwQ1y1WgfSRERNILmImfVcfq7eSx2XXrwa1pjRm45bQwO7 HvmJEfTxl9OoKZnzCweKIwz//EFmgYE= X-Google-Smtp-Source: AHgI3IaGEOfjBck2f1sDhzy/dE02jNkP8NKOHJZJCefeoti9lALxTUdhb8Yvf7n9LTapwAJuhCKKvg== X-Received: by 2002:a25:b1a1:: with SMTP id h33mr15989099ybj.270.1551177333806; Tue, 26 Feb 2019 02:35:33 -0800 (PST) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com. [209.85.219.169]) by smtp.gmail.com with ESMTPSA id s186sm5045901yws.13.2019.02.26.02.35.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 02:35:33 -0800 (PST) Received: by mail-yb1-f169.google.com with SMTP id v63so1782603ybi.1; Tue, 26 Feb 2019 02:35:33 -0800 (PST) X-Received: by 2002:a25:4d02:: with SMTP id a2mr17656864ybb.90.1551177332859; Tue, 26 Feb 2019 02:35:32 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> In-Reply-To: From: Richard Patterson Date: Tue, 26 Feb 2019 10:35:21 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:35:37 -0000 On Mon, 25 Feb 2019 at 18:37, Fernando Gont wrote: > Agreed. That said, with the current default lifetime values, things > become tricky: > At least in theory, you should be sending such RAs for "Valid Lifetime" > seconds. With a default of one month, that means that, in theory, you > should be sending such RAs for a month. And if there are multiple > crash-and-reboot events, you should advertise each of the stale > prefixes. (I assume the CPE just records the last one) I get your reasoning, but I'm not sure if it's quite as dire as that, a single RA update with PrefLifetime of 0 should in theory suffice, but then we get in to discussing the reliability of ICMPv6 messaging. (as you have done in draft-gont-6man-slaac-renum-02 ) In my head, an address with the higher Preferred Lifetime should be selected over one with a lower value, however I couldn't find any recommendation as such in RFC6724, is this stipulated anywhere else? If not, would an update to 6724 that introduces a Preferred Lifetime comparison as a tie-breaker help? i.e. When deciding between multiple non-deprecated source addresses, always pick the address with the highest Preferred Lifetime? From nobody Tue Feb 26 02:59: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 569E9130EAA; Tue, 26 Feb 2019 02:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUCaCvCoYxqf; Tue, 26 Feb 2019 02:58:55 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42824130E30; Tue, 26 Feb 2019 02:58:55 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 6609284A21; Tue, 26 Feb 2019 11:58:51 +0100 (CET) To: Tim Chown Cc: Richard Patterson , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <899A1249-D3D9-4824-8B2E-7E950FBB316A@jisc.ac.uk> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <3c265000-8651-817d-f19f-cf7ccd8fd48e@si6networks.com> Date: Tue, 26 Feb 2019 07:39:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <899A1249-D3D9-4824-8B2E-7E950FBB316A@jisc.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:58:57 -0000 On 26/2/19 07:06, Tim Chown wrote: >> On 26 Feb 2019, at 09:33, Fernando Gont wrote: >> >> Section 6.2.1 of RFC 4861: >> >> AdvPrefixList >> A list of prefixes to be placed in Prefix >> Information options in Router Advertisement >> messages sent from the interface. >> >> Default: all prefixes that the router advertises >> via routing protocols as being on-link for the >> interface from which the advertisement is sent. >> The link-local prefix SHOULD NOT be included in the >> list of advertised prefixes. >> >> Each prefix has an associated: >> >> AdvValidLifetime >> The value to be placed in the Valid >> Lifetime in the Prefix Information option, >> in seconds. The designated value of all >> 1's (0xffffffff) represents infinity. >> Implementations MAY allow AdvValidLifetime >> to be specified in two ways: >> >> - a time that decrements in real time, >> that is, one that will result in a >> Lifetime of zero at the specified time >> in the future, or >> >> - a fixed time that stays the same in >> consecutive advertisements. >> >> Default: 2592000 seconds (30 days), fixed >> (i.e., stays the same in consecutive >> advertisements). > > So given that document is 12 years old, with that default copied from one that is 21 years old, is an update required? That's my take. > And if so, to what? At the very least, never larger than the "Router Lifetime". Please see: https://github.com/fgont/draft-slaac-renum/blob/master/draft-gont-6man-slaac-renum-02.txt (particularly Section 5.1.1) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 26 02:59: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 0A1F01310DD; Tue, 26 Feb 2019 02:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6v1bGgcDB3i; Tue, 26 Feb 2019 02:59:01 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5886130EE1; Tue, 26 Feb 2019 02:59:00 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 005EB84A4C; Tue, 26 Feb 2019 11:58:55 +0100 (CET) To: Ole Troan Cc: Tim Chown , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Tue, 26 Feb 2019 07:43:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:59:07 -0000 On 26/2/19 07:13, Ole Troan wrote: > Fernando, > >>>> On 25 Feb 2019, at 18:36, Fernando Gont wrote: >>>> >>>> On 25/2/19 07:32, Richard Patterson wrote: >>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont wrote: >>>>> >>>>>> * As per RFC4862, it turns out that you cannot remove a stale prefix vy >>>>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards, >>>>>> not even the CPEs can (even if they wanted to) do something to fix the >>>>>> problem. >>>>> >>>>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but >>>>> the Preferred Lifetime can. So we can't invalidate the prefix, but we >>>>> can deprecate it so it's not used for new outbound sessions. This is >>>>> what we've implemented in our CPEs, after an unavoidable change in >>>>> prefix, and it seems to have mitigated (or reduced the impact of) the >>>>> issue. >>>> >>>> Agreed. That said, with the current default lifetime values, things >>>> become tricky: >>>> At least in theory, you should be sending such RAs for "Valid Lifetime" >>>> seconds. With a default of one month, that means that, in theory, you >>>> should be sending such RAs for a month. And if there are multiple >>>> crash-and-reboot events, you should advertise each of the stale >>>> prefixes. (I assume the CPE just records the last one) >>> >>> When / where was the default Valid Lifetime chosen to be one month? >> >> Section 6.2.1 of RFC 4861: >> >> AdvPrefixList >> A list of prefixes to be placed in Prefix >> Information options in Router Advertisement >> messages sent from the interface. >> >> Default: all prefixes that the router advertises >> via routing protocols as being on-link for the >> interface from which the advertisement is sent. >> The link-local prefix SHOULD NOT be included in the >> list of advertised prefixes. >> >> Each prefix has an associated: >> >> AdvValidLifetime >> The value to be placed in the Valid >> Lifetime in the Prefix Information option, >> in seconds. The designated value of all >> 1's (0xffffffff) represents infinity. >> Implementations MAY allow AdvValidLifetime >> to be specified in two ways: >> >> - a time that decrements in real time, >> that is, one that will result in a >> Lifetime of zero at the specified time >> in the future, or >> >> - a fixed time that stays the same in >> consecutive advertisements. >> >> Default: 2592000 seconds (30 days), fixed >> (i.e., stays the same in consecutive >> advertisements). > > > Red herring. > > RA lifetimes cannot be longer than the DHCP PD lifetimes. I don't disagree with you. > In the DHCP PD case they should also be counted down in real time. > And the lifetimes can be dynamically adjusted. They should. However, quite frequently the DHCPv6-PD part is a different piece of software from the ra{d,dvd} part. Both pieces are glued by some script, and the lifetime is *not* dynamically adjusted. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 26 02:59: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 1857D130EC0; Tue, 26 Feb 2019 02:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URcfRr4ybppk; Tue, 26 Feb 2019 02:59:05 -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 BA55313114F; Tue, 26 Feb 2019 02:59:04 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 C5DBA84B07; Tue, 26 Feb 2019 11:59:01 +0100 (CET) To: Richard Patterson Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <781412ce-0627-0751-a4e2-bb9b5e485802@si6networks.com> Date: Tue, 26 Feb 2019 07:58:34 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 10:59:11 -0000 Hello, Richard, On 26/2/19 07:35, Richard Patterson wrote: > On Mon, 25 Feb 2019 at 18:37, Fernando Gont wrote: >> Agreed. That said, with the current default lifetime values, things >> become tricky: >> At least in theory, you should be sending such RAs for "Valid Lifetime" >> seconds. With a default of one month, that means that, in theory, you >> should be sending such RAs for a month. And if there are multiple >> crash-and-reboot events, you should advertise each of the stale >> prefixes. (I assume the CPE just records the last one) > > I get your reasoning, but I'm not sure if it's quite as dire as that, > a single RA update with PrefLifetime of 0 should in theory suffice, > but then we get in to discussing the reliability of ICMPv6 messaging. > (as you have done in draft-gont-6man-slaac-renum-02 ) That aside, if you don't get rid of the addresses/routes, you could not communicate with the new "owners" of the addresses/prefixes. > In my head, an address with the higher Preferred Lifetime should be > selected over one with a lower value, however I couldn't find any > recommendation as such in RFC6724, is this stipulated anywhere else? It is not. > If not, would an update to 6724 that introduces a Preferred Lifetime > comparison as a tie-breaker help? i.e. When deciding between multiple > non-deprecated source addresses, always pick the address with the > highest Preferred Lifetime? Not really. If you were to follow that road, then fore each prefix/router you should keep a new "Last Advertised" timer and use that as a tie breaker. Using the Preferred Lifetime would not be safe since, while there are default values, you don't really know what values the CPE will use for them. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 26 03:09: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 24905130EC5; Tue, 26 Feb 2019 03:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AvY9PGSL9jE; Tue, 26 Feb 2019 03:09:20 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2E8130DF1; Tue, 26 Feb 2019 03:09:20 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id i5so10703072oto.9; Tue, 26 Feb 2019 03:09:20 -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=z7mKdUUM2GqqSoiaEwQQDajOqoDwO4H19s4dGtb78I4=; b=DwpGvzPas2E37CExUkcUKLk2rWlNm5xzTe+AIDl17cCKVx2nUasD9eFzw4Wnq2AirK a0WVBHP9XJo/MYdoSPL+4FDoMYNrhbiX6+JFi2+Fi/7dZqv2KUcL/OcA+miItf0jLjyC zN9JeKgHvZwiC4LJcUqO7SPne1lXtFbbbl8Pb4la2etcreTdCyTNFsTno7Rm9ZBIY1ZW IC0/hvRDOFaN1SVAjWnNKmNgppwm2EfxAzBdYSvb9+OH2YSXNCHrCfIYjPxkZZzBkjYl ex08B62URzGbAJnwZ2iEMW19cjRMxHDFdgXMkA9IWwM9w0vKPa7rIagIIsEj7msoDFJi rc4Q== 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=z7mKdUUM2GqqSoiaEwQQDajOqoDwO4H19s4dGtb78I4=; b=mQd1ciaX9/GfN5v9SkeB9wDgogwcWtBEkTfe7/RH7o6qsc3LYHhZ4mpeDxFUiVRBKh EDhobdID7urPNpM6QV8WNxBmEBjENh5XMPBYCB/ukmWEMz5DzcvSkQeoMB3fFOu9qwEJ 9GSUDXM7OoJKjhcBweEkAscM8mTfQEkeFpj2dTibW89RGydZ9u7H1PFTY7t37sbe2xKD 99YUSSsPlbQWzv7hCsy7ovxO0H8NXQQEZav3P6m7EIXgy9qauqv/t7sdDZBJESJI+9y/ N5WE/Tvg6wDozBLSl5h9R64EEgxABGbMNsxCWYi43Ib3+5jxSt7jdCkVO7Y0sFElk6/b twpw== X-Gm-Message-State: AHQUAuadW4nOIhM7NLgRdfQRGvHFiSbVLuNKmkH59qFpXpdm8mQJ1dLe +PbK6TdLQ7e40dZF45EHWFdYKpTFiWBJ67W/R74= X-Google-Smtp-Source: AHgI3IYxRChmK3vxtF2U0bxHWkOtvbjZDQXFvncZTPgcuIGNUcUUDIHEblOQKkD593GrBJ6/uS8hwHc2dI0Ryl7QSCU= X-Received: by 2002:a9d:6d98:: with SMTP id x24mr15108730otp.318.1551179359426; Tue, 26 Feb 2019 03:09:19 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> In-Reply-To: From: Mark Smith Date: Tue, 26 Feb 2019 22:09:07 +1100 Message-ID: To: Fernando Gont Cc: Ole Troan , v6ops list , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Content-Type: multipart/alternative; boundary="000000000000b39e8d0582ca168d" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 11:09:22 -0000 --000000000000b39e8d0582ca168d Content-Type: text/plain; charset="UTF-8" On Tue., 26 Feb. 2019, 22:00 Fernando Gont, wrote: > On 26/2/19 07:13, Ole Troan wrote: > > Fernando, > > > >>>> On 25 Feb 2019, at 18:36, Fernando Gont > wrote: > >>>> > >>>> On 25/2/19 07:32, Richard Patterson wrote: > >>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont > wrote: > >>>>> > >>>>>> * As per RFC4862, it turns out that you cannot remove a stale > prefix vy > >>>>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current > standards, > >>>>>> not even the CPEs can (even if they wanted to) do something to fix > the > >>>>>> problem. > >>>>> > >>>>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but > >>>>> the Preferred Lifetime can. So we can't invalidate the prefix, but > we > >>>>> can deprecate it so it's not used for new outbound sessions. This > is > >>>>> what we've implemented in our CPEs, after an unavoidable change in > >>>>> prefix, and it seems to have mitigated (or reduced the impact of) the > >>>>> issue. > >>>> > >>>> Agreed. That said, with the current default lifetime values, things > >>>> become tricky: > >>>> At least in theory, you should be sending such RAs for "Valid > Lifetime" > >>>> seconds. With a default of one month, that means that, in theory, you > >>>> should be sending such RAs for a month. And if there are multiple > >>>> crash-and-reboot events, you should advertise each of the stale > >>>> prefixes. (I assume the CPE just records the last one) > >>> > >>> When / where was the default Valid Lifetime chosen to be one month? > >> > >> Section 6.2.1 of RFC 4861: > >> > >> AdvPrefixList > >> A list of prefixes to be placed in Prefix > >> Information options in Router Advertisement > >> messages sent from the interface. > >> > >> Default: all prefixes that the router advertises > >> via routing protocols as being on-link for the > >> interface from which the advertisement is sent. > >> The link-local prefix SHOULD NOT be included in the > >> list of advertised prefixes. > >> > >> Each prefix has an associated: > >> > >> AdvValidLifetime > >> The value to be placed in the Valid > >> Lifetime in the Prefix Information option, > >> in seconds. The designated value of all > >> 1's (0xffffffff) represents infinity. > >> Implementations MAY allow AdvValidLifetime > >> to be specified in two ways: > >> > >> - a time that decrements in real time, > >> that is, one that will result in a > >> Lifetime of zero at the specified time > >> in the future, or > >> > >> - a fixed time that stays the same in > >> consecutive advertisements. > >> > >> Default: 2592000 seconds (30 days), fixed > >> (i.e., stays the same in consecutive > >> advertisements). > > > > > > Red herring. > > > > RA lifetimes cannot be longer than the DHCP PD lifetimes. > > I don't disagree with you. > > > > In the DHCP PD case they should also be counted down in real time. > > And the lifetimes can be dynamically adjusted. > > They should. However, quite frequently the DHCPv6-PD part is a different > piece of software from the ra{d,dvd} part. Both pieces are glued by some > script, and the lifetime is *not* dynamically adjusted. > There is a knob in 'radvd' to do and suit that, the PD triggered/driven script just needs to do a bit of radvd.conf modification, stopping, starting, and signalling. *DecrementLifetimes* *on*|*off* This option causes radvd to decrement the values of the preferred and valid lifetimes for the prefix over time. The lifetimes are decremented by the number of seconds since the last RA. If radvd receives a SIGUSR1 signal, it will reset the values of the preferred and valid lifetimes back to the initial values used by radvd when it started. If radvd never receives a SIGUSR1 signal, it will continue to decrement the lifetimes until the preferred lifetime reaches zero. After a final RA with a zero value preferred lifetime, radvd will cease to announce the prefix. If a SIGUSR1 signal then causes the lifetimes to be reset, the prefix will then re-appear in the RAs. This option is intended to be used in conjunction with a DHCPv6 client that is using the Identity Association for Prefix Delegation (IA_PD) option to acquire a prefix from a Delegating Router for use by a Requesting Router. In this scenario, the prefix(es) from within the delegated prefix that are announced by radvd would age in parallel with and at the same rate as the delegated prefix, and expire at approximately the same time, if the delegated prefix's life isn't extended. See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6". Default: off > 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 > --000000000000b39e8d0582ca168d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue., 26 Feb. 2019, 22:00 Fernando Gont, <fgont@si6networks.com> wrote:
=
On 26/2/19 07:13, Ole Troan wrote:
> Fernando,
>
>>>> On 25 Feb 2019, at 18:36, Fernando Gont <fgont@si6ne= tworks.com> wrote:
>>>>
>>>> On 25/2/19 07:32, Richard Patterson wrote:
>>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont <fern= ando@gont.com.ar> wrote:
>>>>>
>>>>>> * As per RFC4862, it turns out that you cannot rem= ove a stale prefix vy
>>>>>> sending an RA wiht a "Prefix Lifetime" o= f 0. SO, with current standards,
>>>>>> not even the CPEs can (even if they wanted to) do = something to fix the
>>>>>> problem.
>>>>>
>>>>> The Valid Lifetime cannot be zeroed or shortened below= 2 hours, but
>>>>> the Preferred Lifetime can.=C2=A0 So we can't inva= lidate the prefix, but we
>>>>> can deprecate it so it's not used for new outbound= sessions.=C2=A0 =C2=A0This is
>>>>> what we've implemented in our CPEs, after an unavo= idable change in
>>>>> prefix, and it seems to have mitigated (or reduced the= impact of) the
>>>>> issue.
>>>>
>>>> Agreed. That said, with the current default lifetime value= s, things
>>>> become tricky:
>>>> At least in theory, you should be sending such RAs for &qu= ot;Valid Lifetime"
>>>> seconds. With a default of one month, that means that, in = theory, you
>>>> should be sending such RAs for a month. And if there are m= ultiple
>>>> crash-and-reboot events, you should advertise each of the = stale
>>>> prefixes. (I assume the CPE just records the last one)
>>>
>>> When / where was the default Valid Lifetime chosen to be one m= onth?
>>
>> Section 6.2.1 of RFC 4861:
>>
>>=C2=A0 =C2=A0 =C2=A0 AdvPrefixList
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0A list of prefixes to be placed in Prefix
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Information options in Router Advertisement
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0messages sent from the interface.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Default: all prefixes that the router advertises
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0via routing protocols as being on-link for the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0interface from which the advertisement is sent.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0The link-local prefix SHOULD NOT be included in the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0list of advertised prefixes.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Each prefix has an associated:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 AdvValidLifetime
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The value to be placed in the Valid >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lifetime in the Prefix Information op= tion,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in seconds.=C2=A0 The designated valu= e of all
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01's (0xffffffff) represents infin= ity.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Implementations MAY allow AdvValidLif= etime
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be specified in two ways:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- a time that decrements in re= al time,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that is, one that will = result in a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lifetime of zero at the= specified time
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the future, or
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- a fixed time that stays the = same in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consecutive advertiseme= nts.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Default: 2592000 seconds (30 days), f= ixed
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(i.e., stays the same in consecutive<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0advertisements).
>
>
> Red herring.
>
> RA lifetimes cannot be longer than the DHCP PD lifetimes.

I don't disagree with you.


> In the DHCP PD case they should also be counted down in real time.
> And the lifetimes can be dynamically adjusted.

They should. However, quite frequently the DHCPv6-PD part is a different piece of software from the ra{d,dvd} part. Both pieces are glued by some script, and the lifetime is *not* dynamically adjusted.

There is a knob in &= #39;radvd' to do and suit that, the PD triggered/driven script just nee= ds to do a bit of radvd.conf modification, stopping, starting, and signalli= ng.


DecrementL= ifetimes=C2=A0on|off

This option causes radvd to decrem= ent the values of the preferred and valid lifetimes for the prefix over tim= e. The lifetimes are decremented by the number of seconds since the last RA= . If radvd receives a SIGUSR1 signal, it will reset the values of the prefe= rred and valid lifetimes back to the initial values used by radvd when it s= tarted. If radvd never receives a SIGUSR1 signal, it will continue to decre= ment the lifetimes until the preferred lifetime reaches zero. After a final= RA with a zero value preferred lifetime, radvd will cease to announce the = prefix. If a SIGUSR1 signal then causes the lifetimes to be reset, the pref= ix will then re-appear in the RAs.

This option is intended to be used= in conjunction with a DHCPv6 client that is using the Identity Association= for Prefix Delegation (IA_PD) option to acquire a prefix from a Delegating= Router for use by a Requesting Router. In this scenario, the prefix(es) fr= om within the delegated prefix that are announced by radvd would age in par= allel with and at the same rate as the delegated prefix, and expire at appr= oximately the same time, if the delegated prefix's life isn't exten= ded.

See RFC3633, "IPv6 Prefix Options for Dynamic Host Configur= ation Protocol (DHCP) version 6".

Default: off



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
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000b39e8d0582ca168d-- From nobody Tue Feb 26 03:17: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 C3D95131117 for ; Tue, 26 Feb 2019 03:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rU3PtDxkFURH for ; Tue, 26 Feb 2019 03:17:08 -0800 (PST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DF2130ECD for ; Tue, 26 Feb 2019 03:17:07 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id v63so1823216ybi.1 for ; Tue, 26 Feb 2019 03:17:07 -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=Xmc9TKxRPu/Kvh7oFT5ua4EDFmZ+hB+TkmnK/DfgH2c=; b=nLAiCpPJDLrtDpBFih+CuH+pqvgGBWq6rqyIK0LF89Ocor74qAQNOsA/vLExfBDZHn ZGMw5eUFJ5Pmg6d5JXfGjYQYfA7VTfAmS9INY2LklNbafthiVbnnoMWYG7xVT2WHXUCI McjcllIo8unsceBPaJYRiQWdCwNqQDvC6xL6ZIfIFYLZsRoOXwEp+k1UCjsVNiF2rn6n p0vdtC+YWfTsVaqdQ2v8h5y3hiSpu1ozLDYLhN0NxtxQ4oi8VoQaJUg0Q66VGFWMaQXv X6Qc24qfSLWjbyliUSSZHKti09U36GO6tz+NWm41zEHKN+Q+bKFxg0k5S/EANs0nic4I f/DQ== 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=Xmc9TKxRPu/Kvh7oFT5ua4EDFmZ+hB+TkmnK/DfgH2c=; b=kqQ1GsTJPLM4xxNqjpiyy0oLDMtBxWNnUtD6jVUJDL/BINSc16OxBZdITM6dK+2am7 4ODprnoc7Z2pOxMv0YsxLBdDFVRqLGbVfcvMU2S2fawu4bFU0NX6Fd0K2UZDVveMDdDi jM23D+DDhay0gbbLJXVoa9sFUfnE62ECaXIcjfZp9pY0GZrgPQHt/KKT/RJLyd0J0PH5 uS9ItGoqy5t/h2Z5jx9fjNgf0JhiZGPk9eOe4c4wQdqUQcrPgljeKu5S/VIIOXanS3/S ZlakbpglhKOuEU3JCaLagvc+nVuUl6bmgd/qmhnTH+g0wtlUk7lVfmXvuvqxaN/ndw8R +OfA== X-Gm-Message-State: AHQUAuZeoh464jsxMwdC/xQYqcEOGL0ccy62kdaEv4/7+A8sCxgqo5uC F72V1hjVFX8F6Rwh2maIGwV3EDtmaBs= X-Google-Smtp-Source: AHgI3IZDXQwURok971vycraWblZJZJmEW2daaC6Wp8GGxw2roZGn39DQFXtVJkE6cF4V5H0nkDVBQg== X-Received: by 2002:a25:ad53:: with SMTP id l19mr11676621ybe.1.1551179826410; Tue, 26 Feb 2019 03:17:06 -0800 (PST) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id l203sm3984894ywe.3.2019.02.26.03.17.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 03:17:05 -0800 (PST) Received: by mail-yb1-f180.google.com with SMTP id 66so5093300ybo.13; Tue, 26 Feb 2019 03:17:05 -0800 (PST) X-Received: by 2002:a25:e686:: with SMTP id d128mr8082620ybh.193.1551179824889; Tue, 26 Feb 2019 03:17:04 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <781412ce-0627-0751-a4e2-bb9b5e485802@si6networks.com> In-Reply-To: <781412ce-0627-0751-a4e2-bb9b5e485802@si6networks.com> From: Richard Patterson Date: Tue, 26 Feb 2019 11:16:52 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 11:17:18 -0000 On Tue, 26 Feb 2019 at 10:59, Fernando Gont wrote: > > If not, would an update to 6724 that introduces a Preferred Lifetime > > comparison as a tie-breaker help? i.e. When deciding between multiple > > non-deprecated source addresses, always pick the address with the > > highest Preferred Lifetime? > > Not really. If you were to follow that road, then fore each > prefix/router you should keep a new "Last Advertised" timer and use that > as a tie breaker. Using the Preferred Lifetime would not be safe since, > while there are default values, you don't really know what values the > CPE will use for them. I don't think that or anything else is required to change on the CPE router. The onus is on the end host to track the Preferred Lifetime counter (it already does), and to adjust its source address selection. It doesn't really matter what the default values are, as long as the CPE router continues to send out RAs with that PIO to keep the timer refreshed. Although what I do think might be an issue is in a multi-homed environment, an end host might flip flop outgoing connections between prefixes depending on which PIO was refreshed last. From nobody Tue Feb 26 04:54: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 71DED124BAA; Tue, 26 Feb 2019 04:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOw0CHuoi26l; Tue, 26 Feb 2019 04:54:00 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CFE1200B3; Tue, 26 Feb 2019 04:54:00 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B9163826A; Tue, 26 Feb 2019 07:53:56 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id BC1101DB1; Tue, 26 Feb 2019 07:53:58 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BAAA41DA4; Tue, 26 Feb 2019 07:53:58 -0500 (EST) From: Michael Richardson To: Fernando Gont cc: Ole Troan , IPv6 Operations , "6man\@ietf.org" <6man@ietf.org>, Fernando Gont In-Reply-To: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 12:54:04 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: >> In the DHCP PD case they should also be counted down in real time. >> And the lifetimes can be dynamically adjusted. > They should. However, quite frequently the DHCPv6-PD part is a differ= ent > piece of software from the ra{d,dvd} part. Both pieces are glued by s= ome > script, and the lifetime is *not* dynamically adjusted. Yes, that script you mention was a quick hack to make it work from 2007. I think that we can do (and can require) people to do better today. From=20what I understand, OpenWRT already does better, having integrated bo= th sides into one program. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlx1NuYACgkQgItw+93Q 3WXpoAgAv7vnJodsM6DiSEfR2kzMib8yXCsZUYvplsga1PX3zP9/M/BWU2m5Ty2K mOhr2ZwamXvTa9rIvbKMJ0gI2VcDIU/Rxbbb7IDUJMpAxNgPVWTFcGWhaD6SMokg SQDMKgW8YIuaY8KfW7RYOLeLOJG86xjdfn0sRSZv4ywrTasFyHpaMJeCG5GibvEh ZCC/CEcDBk2QaSe6NQAfbyXcvLFHULs+akf+7mq1EiFW10sa47qb+YVpHyeXwwhI 4Oo2ADEvihxLUrul8WdoFZUBxl27a3TK3/XX0GnjV23XYfCT1iruZ7cf9VcvHMEW PseUMybKJN8jkExzx8K09jE1Z51FLQ== =4pPq -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 26 05:31: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 A3B4E130EA2; Tue, 26 Feb 2019 05:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epXq0fqpguZ7; Tue, 26 Feb 2019 05:31:09 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF91130E5D; Tue, 26 Feb 2019 05:31:09 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9E9A7B2; Tue, 26 Feb 2019 14:31:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1551187867; bh=XQ/tZrGPTqGmzCFXyiAK0w+rIu/edghGC0oX/UIhTr4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TRfiv47Yyqb2DZVL9vY/sNamyjieOIRmIAf0CnmnZ1jK2NhQLwEEuLRV4851yUwZ3 k4KNmuqxQkxNmQnTCsxEmZEyHXIUetXgF0CYpl8ZeHzy1opVmEQ62OPuuD9XwXEgx9 H5bUyav4CFdqz/n6sAkkGXka6jfV/+4GE1J9bxlQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9B4A9B0; Tue, 26 Feb 2019 14:31:07 +0100 (CET) Date: Tue, 26 Feb 2019 14:31:07 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont cc: Ole Troan , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont In-Reply-To: Message-ID: References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 13:31:16 -0000 On Tue, 26 Feb 2019, Fernando Gont wrote: > They should. However, quite frequently the DHCPv6-PD part is a different > piece of software from the ra{d,dvd} part. Both pieces are glued by some > script, and the lifetime is *not* dynamically adjusted. In OpenWrt they are, and I definitely think this should be the default. I also tries to deploy two upstreams in my home and this failed because the lifetime of my less preferred ISP was higher than my most preferred ISP, which meant the one with the highest lifetime was always used. So there should be some kind of configurable cap that the HGW uses, so that this isn't a problem. It might also make sense to not have 24 hour or a week lifetimes on the LAN, even if the PD leasetime is this high. But these are two different problems, and I would like to see the LAN lifetimes lowered to more sane values, so that it's capped to 24 hours max. Maybe it should be even lower. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Feb 26 06:20: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 96AB1128CE4 for ; Tue, 26 Feb 2019 06:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvsLc8tg20fY for ; Tue, 26 Feb 2019 06:20:12 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3077130EA0 for ; Tue, 26 Feb 2019 06:20:09 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id e1so10611640iok.1 for ; Tue, 26 Feb 2019 06:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6C+lNwplNCxFv81StS0vD2fsY/J9dmoZ9oVPYOCTZaE=; b=L1tQZe/rJErfHLM/8uF1agM8CHji7XvChhe0r+O+uS4giiqipf7zMQCCJ7BFM2Aw9r uuy74Q3t4Ekj/tFYkqai3dF20b58dQ4NALCYq3/MFEt5b0wYUV7qk/ZtugtMVu8TQ9uQ a6uDm6bu77nPl2Trk6VuWeHZbkx/sd3pSSHKPBTzoCwSO+GOyNLxaAPm+S+lJgCiFdzU Q2i1/2y1vWXEqJyBXjDqpZiOlWFO1SLgwIUlfmW2WCe+IzvcAwX7aMSSnumAcH4UsTX0 R1EpeZqKw3Z12Wzdq7vEZVIw2U02aiZBqGu3JCQBIzO0gTV+7MrgoYvDmquS1BXGGaF9 7b+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=6C+lNwplNCxFv81StS0vD2fsY/J9dmoZ9oVPYOCTZaE=; b=S+9UVORKhA7HPTU3XCNWwQoKVbcxoKNPx8P4waALIRWPuQ+dgTizF/oaYteQNaZmaI LCvYKpBTDq0nxVqr47aA9You13rdIG6WDxgMfB4qxg8SoRet8Op+x668q24tWBXl4sYC 1fSovkxESkJ3zX9eqgeKBELbd29ZdQjxFN2CzK+iWCYB0C9MfkO5uZd05RdgJ0CKlbuc o9Ogx1WNRTe74iGkrNGpgqQtSFBMNUPI6SygxiA0z5W3IfCe3KSZsEdvs2flH3U0nbwv 37+xOoojpqw22+RP8z5O9YODR2VWABqpygmQ9AW2yhP2QCsrwilHRE3P5b/GQ7idPbA+ nVdA== X-Gm-Message-State: AHQUAuai0X+us6Kk7eHXnqN5WS9MK2Ma64mmMZT9TX2BG5Uqmt/WPFI8 YGfZl68YRQzjzB7iq1zR+wrZ1TT+iCO8dnnNSqcdUw== X-Google-Smtp-Source: AHgI3IYI9OqKd4kBeAznRB55mS7aMT9SRsO/iWj0jnV/0e5dtA5Y9NFRQuNi8hzHNyynFL/GvCMuU5ZrjrFb3Sq/Gbo= X-Received: by 2002:a5e:c605:: with SMTP id f5mr12977992iok.252.1551190808779; Tue, 26 Feb 2019 06:20:08 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <899A1249-D3D9-4824-8B2E-7E950FBB316A@jisc.ac.uk> <3c265000-8651-817d-f19f-cf7ccd8fd48e@si6networks.com> In-Reply-To: <3c265000-8651-817d-f19f-cf7ccd8fd48e@si6networks.com> From: Lorenzo Colitti Date: Tue, 26 Feb 2019 23:19:56 +0900 Message-ID: To: Fernando Gont Cc: Tim Chown , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Content-Type: multipart/alternative; boundary="00000000000023763d0582ccc189" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 14:20:14 -0000 --00000000000023763d0582ccc189 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 26, 2019 at 7:59 PM Fernando Gont wrote: > >> Default: 2592000 seconds (30 days), fixed > >> (i.e., stays the same in consecutive > >> advertisements). > > > > So given that document is 12 years old, with that default copied from > one that is 21 years old, is an update required? > > That's my take. > > > And if so, to what? > > At the very least, never larger than the "Router Lifetime". Please see: > > https://github.com/fgont/draft-slaac-renum/blob/master/draft-gont-6man-slaac-renum-02.txt > (particularly Section 5.1.1) > Disagree that prefix lifetimes must never be larger than the router lifetime, particularly because 0 is a perfectly valid default lifetime. Also looking at section 5.1.1, the default MaxRtrAdvInterval of 5 minutes violates the best practices in RFC 7772. --00000000000023763d0582ccc189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Default: 2592000 seconds (30 days), fixed
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(i.e., stays the same in consecutive<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0advertisements).
>
> So given that document is 12 years old, with that default copied from = one that is 21 years old, is an update required?=C2=A0

That's my take.

> And if so, to what?

At the very least, never larger than the "Router Lifetime". Pleas= e see:
https://git= hub.com/fgont/draft-slaac-renum/blob/master/draft-gont-6man-slaac-renum-02.= txt
=C2=A0(particularly Section 5.1.1)

Disa= gree that prefix lifetimes must never be larger than the router lifetime, p= articularly because 0 is a perfectly valid default lifetime.

=
Also looking at section 5.1.1, the default MaxRtrAdvInterval of = 5 minutes violates the best practices in RFC 7772.
--00000000000023763d0582ccc189-- From nobody Tue Feb 26 06:28: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 E2D77130EC1 for ; Tue, 26 Feb 2019 06:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9KpuafkZipu for ; Tue, 26 Feb 2019 06:28:00 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C8F130E82 for ; Tue, 26 Feb 2019 06:28:00 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id e24so4080369itl.1 for ; Tue, 26 Feb 2019 06:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EpNdkqKF1Ay82/hX/81toels0zMdnuJtj1d5EM5nSC0=; b=C7OITWFrjJWfvHOKOP+2Xb3AviHdFUUVtz9k2ZouKl5A6FlaTD52ajvKSMI75yWwho L9X9LK3VmyaDah0fGbsl+UYsWOS3F/MdmRMIsCpIuH7OLWxbEoHhOCJBr70u+RKcruUs 5v7T/egnAxqN1QgvxElRUj6GX57moPDtohTSco0EVEB3PTbVGSykX+zAWlqIU95X7d07 RLOyWgNVzF21X1lk5/IzEWM/i19YkLbhjST+4rOUE6NFNdiAciPWEszdF0Vu76X2vN41 +rn1U22Nm7XeuKJpbvfjgH7uR/IzluqGIwzllrUPLHJvWK7ZMGgrrGvu0m1+KkbDpJcx mlag== 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=EpNdkqKF1Ay82/hX/81toels0zMdnuJtj1d5EM5nSC0=; b=ZXB3hsH5UPzi0jzTGK3atkM2zUBvNBsEIRJLbP7sgNFdeG9XcHllIwSxX5MOUfHFOJ lSAXpAPISa77wI7fRpEnOwJqnHE62Q2tFpdhr9pdXhQbGhyTmngdVWw4u6vJGtBpooKu 6JFE0KeexAqxwk8GA4+AZLCWtyQBjP1KcGyuHd4vf9pTNbx1wHSs7Kzq01KHwTnYBqPL rlMTuNuViyPE/03l0WCD67s/3YtmHltuu03cot9X0gzC9swYAiBNB2LxDo42VGU4wDmv tSD6uY0Ez91CQLDmy7tm4hMT7UF4WWVUfA4yx+lO5wffUyvXl6NyQH1hV5PC1LW/XrGC Nlhg== X-Gm-Message-State: AHQUAuactqhxlzBJOUS8DE89Ts3zfaGPSNft6MFtPhV6JG8sNyxAXG45 eLcGBrPkIhf9hKVdz5bbu8jhZ95BydDo2ZDtHkLjAQ== X-Google-Smtp-Source: AHgI3IY4fFYboPDJ7sN+h8NlerPHx/Phrntw9jb6phWsIZxbLaPKzBIz/H6cEDdFfeQBrVGCiU0S3roSzgYgrhaHw0M= X-Received: by 2002:a02:10c9:: with SMTP id 192mr650232jay.51.1551191279569; Tue, 26 Feb 2019 06:27:59 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> In-Reply-To: From: Lorenzo Colitti Date: Tue, 26 Feb 2019 23:27:46 +0900 Message-ID: To: Mark Smith Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, v6ops list , Fernando Gont Content-Type: multipart/alternative; boundary="000000000000330c2a0582ccdddc" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 14:28:04 -0000 --000000000000330c2a0582ccdddc Content-Type: text/plain; charset="UTF-8" FWIW, from a host implementer perspective, DecrementLifetimes is a bad idea since it makes it harder to drop duplicate RAs in firmware and thus has substantial battery impact. True story: many ISP routers use a maximum advertisement interval of 3 seconds in order to fix unreachability and IPv6 brokenness problems. In order to avoid draining the battery after 12 hours of this, phone manufacturers reacted by either dropping all RAs (or even all IPv6 packets!) when the screen is off, or putting RA filtering in firmware. Then some routers decided to use DecrementLifetimes as well. Firmware RA filtering couldn't match the RAs any more and the phone manufacturers probably reacted by dropping all RAs again. In order to fix this problem on Android we had to write a bytecode interpreter and get wifi chipset manufacturers to insert it into their firmware so we could push filtering rules to the chipset at runtime. Many chipset manufacturers still haven't adopted this though. Please don't do this if you care about mobile devices having correct IPv6 implementations and acceptable battery life. On Tue, Feb 26, 2019 at 8:09 PM Mark Smith wrote: > > > On Tue., 26 Feb. 2019, 22:00 Fernando Gont, wrote: > >> On 26/2/19 07:13, Ole Troan wrote: >> > Fernando, >> > >> >>>> On 25 Feb 2019, at 18:36, Fernando Gont >> wrote: >> >>>> >> >>>> On 25/2/19 07:32, Richard Patterson wrote: >> >>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont >> wrote: >> >>>>> >> >>>>>> * As per RFC4862, it turns out that you cannot remove a stale >> prefix vy >> >>>>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current >> standards, >> >>>>>> not even the CPEs can (even if they wanted to) do something to fix >> the >> >>>>>> problem. >> >>>>> >> >>>>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but >> >>>>> the Preferred Lifetime can. So we can't invalidate the prefix, but >> we >> >>>>> can deprecate it so it's not used for new outbound sessions. This >> is >> >>>>> what we've implemented in our CPEs, after an unavoidable change in >> >>>>> prefix, and it seems to have mitigated (or reduced the impact of) >> the >> >>>>> issue. >> >>>> >> >>>> Agreed. That said, with the current default lifetime values, things >> >>>> become tricky: >> >>>> At least in theory, you should be sending such RAs for "Valid >> Lifetime" >> >>>> seconds. With a default of one month, that means that, in theory, you >> >>>> should be sending such RAs for a month. And if there are multiple >> >>>> crash-and-reboot events, you should advertise each of the stale >> >>>> prefixes. (I assume the CPE just records the last one) >> >>> >> >>> When / where was the default Valid Lifetime chosen to be one month? >> >> >> >> Section 6.2.1 of RFC 4861: >> >> >> >> AdvPrefixList >> >> A list of prefixes to be placed in Prefix >> >> Information options in Router Advertisement >> >> messages sent from the interface. >> >> >> >> Default: all prefixes that the router advertises >> >> via routing protocols as being on-link for the >> >> interface from which the advertisement is sent. >> >> The link-local prefix SHOULD NOT be included in the >> >> list of advertised prefixes. >> >> >> >> Each prefix has an associated: >> >> >> >> AdvValidLifetime >> >> The value to be placed in the Valid >> >> Lifetime in the Prefix Information option, >> >> in seconds. The designated value of all >> >> 1's (0xffffffff) represents infinity. >> >> Implementations MAY allow AdvValidLifetime >> >> to be specified in two ways: >> >> >> >> - a time that decrements in real time, >> >> that is, one that will result in a >> >> Lifetime of zero at the specified time >> >> in the future, or >> >> >> >> - a fixed time that stays the same in >> >> consecutive advertisements. >> >> >> >> Default: 2592000 seconds (30 days), fixed >> >> (i.e., stays the same in consecutive >> >> advertisements). >> > >> > >> > Red herring. >> > >> > RA lifetimes cannot be longer than the DHCP PD lifetimes. >> >> I don't disagree with you. >> >> >> > In the DHCP PD case they should also be counted down in real time. >> > And the lifetimes can be dynamically adjusted. >> >> They should. However, quite frequently the DHCPv6-PD part is a different >> piece of software from the ra{d,dvd} part. Both pieces are glued by some >> script, and the lifetime is *not* dynamically adjusted. >> > > There is a knob in 'radvd' to do and suit that, the PD triggered/driven > script just needs to do a bit of radvd.conf modification, stopping, > starting, and signalling. > > > *DecrementLifetimes* *on*|*off* > > This option causes radvd to decrement the values of the preferred and > valid lifetimes for the prefix over time. The lifetimes are decremented by > the number of seconds since the last RA.. If radvd receives a SIGUSR1 > signal, it will reset the values of the preferred and valid lifetimes back > to the initial values used by radvd when it started. If radvd never > receives a SIGUSR1 signal, it will continue to decrement the lifetimes > until the preferred lifetime reaches zero. After a final RA with a zero > value preferred lifetime, radvd will cease to announce the prefix. If a > SIGUSR1 signal then causes the lifetimes to be reset, the prefix will then > re-appear in the RAs. > > This option is intended to be used in conjunction with a DHCPv6 client > that is using the Identity Association for Prefix Delegation (IA_PD) option > to acquire a prefix from a Delegating Router for use by a Requesting > Router. In this scenario, the prefix(es) from within the delegated prefix > that are announced by radvd would age in parallel with and at the same rate > as the delegated prefix, and expire at approximately the same time, if the > delegated prefix's life isn't extended. > > See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol > (DHCP) version 6". > > Default: off > > >> 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 >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000330c2a0582ccdddc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, from a host implementer perspective, Decre= mentLifetimes is a bad idea since it makes it harder to drop duplicate RAs = in firmware and thus has substantial battery impact.
=
True story: many ISP routers use a maximum adver= tisement interval of 3 seconds in order to fix unreachability and IPv6 brok= enness problems. In order to avoid draining the battery after 12 hours of t= his, phone manufacturers=C2=A0reacted by either dropping all RAs (or even a= ll IPv6 packets!) when the screen is off, or putting RA filtering in firmwa= re.=C2=A0Then some routers decided to use DecrementLifetimes as well.=C2=A0= Firmware RA filtering couldn't match the RAs any more and the phone man= ufacturers probably reacted by dropping all RAs again.

In order to fix this problem on Android we had to write a = bytecode interpreter and get wifi chipset manufacturers to insert it into t= heir firmware so we could push filtering rules to the chipset at runtime. M= any chipset manufacturers still haven't adopted this though.
=
Please don't do this if you care about mobile devices ha= ving correct IPv6 implementations and acceptable battery life.
<= /div>

On Tue, Feb 26, 2019 at 8:09 PM Mark Smith <markzzzsmith@gmail.com> wrote:


O= n Tue., 26 Feb. 2019, 22:00 Fernando Gont, <fgont@si6networks.com> wrote:
On 26/2/19 07:13, Ole T= roan wrote:
> Fernando,
>
>>>> On 25 Feb 2019, at 18:36, Fernando Gont <fgont@si6ne= tworks.com> wrote:
>>>>
>>>> On 25/2/19 07:32, Richard Patterson wrote:
>>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont <fern= ando@gont.com.ar> wrote:
>>>>>
>>>>>> * As per RFC4862, it turns out that you cannot rem= ove a stale prefix vy
>>>>>> sending an RA wiht a "Prefix Lifetime" o= f 0. SO, with current standards,
>>>>>> not even the CPEs can (even if they wanted to) do = something to fix the
>>>>>> problem.
>>>>>
>>>>> The Valid Lifetime cannot be zeroed or shortened below= 2 hours, but
>>>>> the Preferred Lifetime can.=C2=A0 So we can't inva= lidate the prefix, but we
>>>>> can deprecate it so it's not used for new outbound= sessions.=C2=A0 =C2=A0This is
>>>>> what we've implemented in our CPEs, after an unavo= idable change in
>>>>> prefix, and it seems to have mitigated (or reduced the= impact of) the
>>>>> issue.
>>>>
>>>> Agreed. That said, with the current default lifetime value= s, things
>>>> become tricky:
>>>> At least in theory, you should be sending such RAs for &qu= ot;Valid Lifetime"
>>>> seconds. With a default of one month, that means that, in = theory, you
>>>> should be sending such RAs for a month. And if there are m= ultiple
>>>> crash-and-reboot events, you should advertise each of the = stale
>>>> prefixes. (I assume the CPE just records the last one)
>>>
>>> When / where was the default Valid Lifetime chosen to be one m= onth?
>>
>> Section 6.2.1 of RFC 4861:
>>
>>=C2=A0 =C2=A0 =C2=A0 AdvPrefixList
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0A list of prefixes to be placed in Prefix
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Information options in Router Advertisement
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0messages sent from the interface.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Default: all prefixes that the router advertises
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0via routing protocols as being on-link for the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0interface from which the advertisement is sent.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0The link-local prefix SHOULD NOT be included in the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0list of advertised prefixes.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Each prefix has an associated:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 AdvValidLifetime
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The value to be placed in the Valid >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lifetime in the Prefix Information op= tion,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in seconds.=C2=A0 The designated valu= e of all
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01's (0xffffffff) represents infin= ity.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Implementations MAY allow AdvValidLif= etime
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be specified in two ways:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- a time that decrements in re= al time,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that is, one that will = result in a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lifetime of zero at the= specified time
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the future, or
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- a fixed time that stays the = same in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consecutive advertiseme= nts.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Default: 2592000 seconds (30 days), f= ixed
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(i.e., stays the same in consecutive<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0advertisements).
>
>
> Red herring.
>
> RA lifetimes cannot be longer than the DHCP PD lifetimes.

I don't disagree with you.


> In the DHCP PD case they should also be counted down in real time.
> And the lifetimes can be dynamically adjusted.

They should. However, quite frequently the DHCPv6-PD part is a different piece of software from the ra{d,dvd} part. Both pieces are glued by some script, and the lifetime is *not* dynamically adjusted.

There is a knob in &= #39;radvd' to do and suit that, the PD triggered/driven script just nee= ds to do a bit of radvd.conf modification, stopping, starting, and signalli= ng.


Decrem= entLifetimes=C2=A0on|off

This option causes radvd to de= crement the values of the preferred and valid lifetimes for the prefix over= time. The lifetimes are decremented by the number of seconds since the las= t RA.. If radvd receives a SIGUSR1 signal, it will reset the values of the = preferred and valid lifetimes back to the initial values used by radvd when= it started. If radvd never receives a SIGUSR1 signal, it will continue to = decrement the lifetimes until the preferred lifetime reaches zero. After a = final RA with a zero value preferred lifetime, radvd will cease to announce= the prefix. If a SIGUSR1 signal then causes the lifetimes to be reset, the= prefix will then re-appear in the RAs.

This option is intended to be= used in conjunction with a DHCPv6 client that is using the Identity Associ= ation for Prefix Delegation (IA_PD) option to acquire a prefix from a Deleg= ating Router for use by a Requesting Router. In this scenario, the prefix(e= s) from within the delegated prefix that are announced by radvd would age i= n parallel with and at the same rate as the delegated prefix, and expire at= approximately the same time, if the delegated prefix's life isn't = extended.

See RFC3633, "IPv6 Prefix Options for Dynamic Host Con= figuration Protocol (DHCP) version 6".

Default: off



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
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000330c2a0582ccdddc-- From nobody Tue Feb 26 08:03: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 51EFF128CB7; Tue, 26 Feb 2019 08:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baOA72RjBUTt; Tue, 26 Feb 2019 08:03:24 -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 22C9D1289FA; Tue, 26 Feb 2019 08:03:24 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 8975B84858; Tue, 26 Feb 2019 17:03:19 +0100 (CET) To: Lorenzo Colitti Cc: Tim Chown , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <899A1249-D3D9-4824-8B2E-7E950FBB316A@jisc.ac.uk> <3c265000-8651-817d-f19f-cf7ccd8fd48e@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <3b2fbad8-f5ea-c40a-1710-1da527ae8992@si6networks.com> Date: Tue, 26 Feb 2019 12:51:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 16:03:27 -0000 Hello, Lorenzo, On 26/2/19 11:19, Lorenzo Colitti wrote: > On Tue, Feb 26, 2019 at 7:59 PM Fernando Gont > wrote: > > >>                             Default: 2592000 seconds (30 days), fixed > >>                             (i.e., stays the same in consecutive > >>                             advertisements). > > > > So given that document is 12 years old, with that default copied > from one that is 21 years old, is an update required?  > > That's my take. > > > And if so, to what? > > At the very least, never larger than the "Router Lifetime". Please see: > https://github.com/fgont/draft-slaac-renum/blob/master/draft-gont-6man-slaac-renum-02.txt >  (particularly Section 5.1.1) > > > Disagree that prefix lifetimes must never be larger than the router > lifetime, particularly because 0 is a perfectly valid default lifetime. How does a Lifetime of 0 fit in RFC8028? > Also looking at section 5.1.1, the default MaxRtrAdvInterval of 5 > minutes violates the best practices in RFC 7772. Thanks for the pointer! Looking at RFC7772, it says: Thus, the minimum lifetimes for RA configuration parameters such as default router lifetime might reasonably be 5-10 times the RA period, or roughly 45-90 minutes. Question: I'm trying to parse this paragraph. It would seem that, in order to ahve an appropriate RA frequency, you need to have a Default Router Lifetime of 45-90 minutes, but the default is actually 30 minutes. Am I missing something? And, how do you get the 45'-90' numbers? FWIW, with the default values in RFC4861 you get, for the *average* case, ~ 6.6 RAs /hour, and a DEfault Lifetime of 30 minutes... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 26 08:11: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 0D9FD1289FA; Tue, 26 Feb 2019 08:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTHQwv6GJtM8; Tue, 26 Feb 2019 08:11:26 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040D81200D8; Tue, 26 Feb 2019 08:11:26 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 7560884592; Tue, 26 Feb 2019 17:11:21 +0100 (CET) To: Lorenzo Colitti , Mark Smith Cc: "6man@ietf.org" <6man@ietf.org>, v6ops list , Fernando Gont References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <478244e5-608f-dc3a-a3d9-b7a12f470db1@si6networks.com> Date: Tue, 26 Feb 2019 13:07:45 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 16:11:28 -0000 Hello, Lorenzo, On 26/2/19 11:27, Lorenzo Colitti wrote: > FWIW, from a host implementer perspective, DecrementLifetimes is a bad > idea since it makes it harder to drop duplicate RAs in firmware and thus > has substantial battery impact. Well... it would be incorrect for these Lifetime values to span past the DHCPv6-PD lease time --- so either you set the lifetimes to a small value (that is never larger than the DHCPv6 lease time, and hence can be constant), or you have to dynamically adjust the Lifetimes. If you're filtering RAs in firmware, it would seem to me that the first option would be better. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 26 08:51: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 218191200D8; Tue, 26 Feb 2019 08:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZHJn8UVXShU; Tue, 26 Feb 2019 08:51:10 -0800 (PST) Received: from mail-yw1-xc43.google.com (mail-yw1-xc43.google.com [IPv6:2607:f8b0:4864:20::c43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2FF12785F; Tue, 26 Feb 2019 08:51:09 -0800 (PST) Received: by mail-yw1-xc43.google.com with SMTP id n12so5669471ywn.13; Tue, 26 Feb 2019 08:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=m4AiyyClkGN3BZatGwCf2zvqIGZpmeGQFIURX8T17MM=; b=jzlsZMa+lcA3Dvag1L8bMZKG8odNwGxxtqrsdkaHNUT/ZNuYokrbgDA7Eo8uR/bW8w MldyJSQVBewFNPuA36OWzsFjCcDv80DpL6rIisNryORQ0Umxf7pIclvsB1FpfeSg2p1c MdbJcRiUzAjsvRB5qfiSlrlrrShu6PJVC5418I49X2AZ04KUUtUMMs3zBqge0r//cmOW P+P+lN2XJxbQvQK5D9i3pZRaa4Gt6NXT4IqVN7TaywCdmvIk3fDgwvn7E1OS2I8N/KWu VRNNqgTujsPOgLQ7IFcw1KzxGFuUrSg+9ihk+H5NM4GqV3sIcJRJatG52FVfQ8sDF5la Tmlg== 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:reply-to :from:date:message-id:subject:to:cc; bh=m4AiyyClkGN3BZatGwCf2zvqIGZpmeGQFIURX8T17MM=; b=ARPEkympZW/sVoc/7FSvkQkBuF+NtO2CBl62xic7sSSEo1JaW2ov3cZ0OAxLkB1+Lz jFi1wUMNKcso5gaGLbfIU0D5sOcyCMQuT1XF/17hyDw3wytObov9IYYfLf6GZ+Jx2y4w e3O6UeDifmEtHbGBrt1TteuqqCoxmAZJe0x7qBlWZNeoAzY6+kZC+jjhswKZc/8nN1ZD gsaUukWBzncJ4XD7aN3mwOcmLV2sFbnOwdgNe/VrJacztrqw11CSHHYDncg2oR0P6UfQ qIxiOE344oQ5XJMY7AYRsIsFk+TAA2NhgUrh6cBNICi44f3cSd1S4KJdxv3ti6zpZU9h KeQA== X-Gm-Message-State: AHQUAuZhsrK7o6UnU5TmRGHTrSNUqRkFYIdU44hdGqP9b73lxZuF1Ref +cuW7k33GLQkw5kNLg8xVvgdZC6QbRW9FZmtXuA= X-Google-Smtp-Source: AHgI3Ibo/MmxWQmZPNWe9LeGeY/tYcx1ZnZmv5zUsngaZaEd1bx7tED8eOS3fk2FOrx4wQdx7FiATXlluCJ4c3tU/Qk= X-Received: by 2002:a81:5211:: with SMTP id g17mr19103829ywb.346.1551199868841; Tue, 26 Feb 2019 08:51:08 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Tue, 26 Feb 2019 10:50:57 -0600 Message-ID: To: Tom Herbert Cc: Ca By , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, dirk.von-hugo@telecom.de Content-Type: multipart/alternative; boundary="0000000000002872b60582ceddb5" Archived-At: Subject: Re: [v6ops] Is addressing privacy via NAT really achieving much compared to a privacy goal of anonymity? (Re: A common problem with SLAAC in "renumbering" scenarios) 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 Feb 2019 16:51:12 -0000 --0000000000002872b60582ceddb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 4:59 PM Tom Herbert wrote: > On Fri, Feb 22, 2019 at 2:36 PM Ca By wrote: > > > > > > > > On Fri, Feb 22, 2019 at 11:56 AM Tom Herbert > wrote: > >> > >> On Fri, Feb 22, 2019 at 10:06 AM Ca By wrote: > >> > > >> > > >> > > >> > On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert > wrote: > >> >> > >> >> On Thu, Feb 21, 2019 at 11:35 PM Mark Smith > wrote: > >> >> > > >> >> > Hi Tom, > >> >> > > >> >> > On Fri, 22 Feb 2019 at 10:04, Tom Herbert > wrote: > >> >> > > > >> >> > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith < > markzzzsmith@gmail.com> wrote: > >> >> > > > > >> >> > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US), Albert E > >> >> > > > wrote: > >> >> > > > > > >> >> > > >> >> > > >> >> > > >> >> > > > > >> >> > > > So I think there's commonly a big different between works and > works > >> >> > > > well. NAT may work, however compared to stateless IPv6 (and > IPv4) > >> >> > > > forwarding, it doesn't work anywhere as near as well. > >> >> > > > > >> >> > > Mark, > >> >> > > > >> >> > > I agreee with that with one exception. I believe that NAT/IPv4 > can > >> >> > > offer better privacy in addressing than IPv6 given current adde= ss > >> >> > > allocation methods. > >> >> > > > >> >> > > >> >> > So I don't think addressing privacy via NAT is really all that > >> >> > valuable if there are many other ways, some quite easy, to unique= ly > >> >> > identify an anonymity desiring end-point/end-user, whose > effectiveness > >> >> > aren't impacted at all by NAT. > >> >> > > >> >> > For example, this website is coming over IPv4 for me, and I'm usi= ng > >> >> > IPv4+NAPT. If IPv4+NAPT was that effective at anonymity, I > shouldn't > >> >> > be able to tracked. > >> >> > > >> >> > https://amiunique.org/ > >> >> > > >> >> > Yet it is saying I can be with both Chrome and Firefox on Fedora > 29 in > >> >> > Incognito/Private windows mode on this host. It says the same > about my > >> >> > Android 9 phone with Chrome in Incognito mode. > >> >> > > >> >> > Going into the detail of how, they don't seem to be using IP > address > >> >> > at all for any identification, it is all browser attributes. > >> >> > > >> >> > We have IPv6 temporary addresses, which makes using addresses > harder > >> >> > to use to identify a node. I think that is a lot better than > nothing. > >> >> > >> >> Mark, > >> >> > >> >> Yes, but by that same rationale a simple substitution cipher is > better > >> >> than nothing in cryptography! > >> >> > >> >> What pretty much any conversation about privacy in addressing seems > to > >> >> lacking is a quantitative description of privacy and any empiracal > >> >> data on the impact that privacy mechanisms, like those defined in > >> >> RFC4941, have had. You might say it "makes using addresses harder t= o > >> >> use to identify a node". But then the obvious question is _how_ muc= h > >> >> harder? Is this really protecting anyone's privacy, or it is just a > >> >> minor inconvenience to attackers and only giving users a false sens= e > >> >> of security? > >> >> > >> >> The irony is that CGN seems to have the best supporting evidence fo= r > >> >> being a mechanism that impacts privacy, but it was never even > intended > >> >> to be a privacy mechanism. The evidence is in the form of concerns > >> >> form law enforcement that the privacy side effect is too strong and > >> >> impedes their investigations > >> >> (https://www.theregister.co.uk/2017/10/18/europol_cgnat/). > >> >> > >> >> So I don't think "Is addressing privacy via NAT really achieving mu= ch > >> >> compared to a privacy goal of anonymity?" is the right question. Th= e > >> >> right question to ask is "Is addressing privacy via any IETF define= d > >> >> mechanism achieving much compared to a privacy goal of anonymity?" > >> >> > >> >> Tom > >> > > >> > > >> > > >> > > >> > 1. Network service providers cannot provide address anonymity. LEA > requirements in the USA and many jurisdictions simply do not allow it, so > who is the customer of such a standard? Who would make and deploy it? > >> > >> The customer of this is political dissident that is speaking out > >> against injustice of a corrupt government. There is nothing that > >> prevents a solution that provides the privacy for the dissident, but > >> still allows their network provider to maintain records that correlate > >> address to identity is available to LEA for the local jurisdiction > >> under lawful order. This really isn't different than other areas of > >> privacy on the Internet (like the logs that Facebook or Google keep). > >> The point is that anonimity is needed to prevent unauthorized third > >> parties from breaking someones privacy. > >> > >> > > >> > 2. Network address annonimity today is generally provided via Tor. > How could the ietf provide something better than existiting tor solutions= , > knowing that it will not be baked into the network =E2=80=94 meaning it m= ust be > over the top. > >> > > >> > >> I'm not sure what "provided via Tor" means. > > > > > > Tor is this > > https://www.torproject.org/about/overview.html.en > > > > Tor is what people use today for address anonimity today > > Thanks for the reference. It's interesting but then there's > > https://www.esecurityplanet.com/open-source-security/the-trouble-with-tor= .html > . > In any case, I believe it's in IETF's best interest to continually > evaluate security and privacy in IP protocols. Privacy in IP > addressing seems to be an area of weakness in that regard. > > +1 We with Dirk are pursuing this kind of activity in pidloc list pidloc@ietf.org more in the context of Identifier locator separation protocol context. Please join pidloc. Regards, Behcet > Tom > > > > >> > >> > >> > >> > 3. CGN is not private. It throw off per session logs of every > transaction, so this is a full click stream archived ... with varing leve= ls > of intentional monetization and security from hackers. > >> > > >> Yes, it is expected that the local provider has full view of all > >> associations of address to some device, that's pretty much a given and > >> we have to trust the local provider to some extent. What we're trying > >> to prevent is untrusted external parties from deducing identity or > >> location of users. > >> > >> > > >> >> > >> >> > However, I don't see how IPv6 NAT would improve it much, and it > >> >> > introduces the other drawbacks of NAT. > >> >> > > >> >> > Regards, > >> >> > Mark. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > Tom > >> >> > > > >> >> > > > Regards, > >> >> > > > Mark. > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > Bert > >> >> > > > > >> >> > > > _______________________________________________ > >> >> > > > v6ops mailing list > >> >> > > > v6ops@ietf.org > >> >> > > > https://www.ietf.org/mailman/listinfo/v6ops > >> >> > >> >> -------------------------------------------------------------------= - > >> >> IETF IPv6 working group mailing list > >> >> ipv6@ietf.org > >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> >> -------------------------------------------------------------------= - > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000002872b60582ceddb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 22, 2019 at 4:59 PM Tom H= erbert <tom@herbertland.com&g= t; wrote:
On Fri, Feb 22, 2019 at 2:36 PM Ca By &= lt;cb.list6@gmail.c= om> wrote:
>
>
>
> On Fri, Feb 22, 2019 at 11:56 AM Tom Herbert <tom@herbertland.com> wrote:
>>
>> On Fri, Feb 22, 2019 at 10:06 AM Ca By <cb.list6@gmail.com> wrote:
>> >
>> >
>> >
>> > On Fri, Feb 22, 2019 at 10:12 AM Tom Herbert <tom@herbertland.com> wr= ote:
>> >>
>> >> On Thu, Feb 21, 2019 at 11:35 PM Mark Smith <markzzzsmith@gmail.com= > wrote:
>> >> >
>> >> > Hi Tom,
>> >> >
>> >> > On Fri, 22 Feb 2019 at 10:04, Tom Herbert <tom@herbertland.com&= gt; wrote:
>> >> > >
>> >> > > On Thu, Feb 21, 2019 at 2:46 PM Mark Smith <= markzzzsmith@gm= ail.com> wrote:
>> >> > > >
>> >> > > > On Fri, 22 Feb 2019 at 08:53, Manfredi (US= ), Albert E
>> >> > > > <albert.e.manfredi@boeing.com> wrote:
>> >> > > > >
>> >> >
>> >> > <snip>
>> >> >
>> >> > > >
>> >> > > > So I think there's commonly a big diff= erent between works and works
>> >> > > > well. NAT may work, however compared to st= ateless IPv6 (and IPv4)
>> >> > > > forwarding, it doesn't work anywhere a= s near as well.
>> >> > > >
>> >> > > Mark,
>> >> > >
>> >> > > I agreee with that with one exception. I believ= e that NAT/IPv4 can
>> >> > > offer better privacy in addressing than IPv6 gi= ven current addess
>> >> > > allocation methods.
>> >> > >
>> >> >
>> >> > So I don't think addressing privacy via NAT is r= eally all that
>> >> > valuable if there are many other ways, some quite ea= sy, to uniquely
>> >> > identify an anonymity desiring end-point/end-user, w= hose effectiveness
>> >> > aren't impacted at all by NAT.
>> >> >
>> >> > For example, this website is coming over IPv4 for me= , and I'm using
>> >> > IPv4+NAPT. If IPv4+NAPT was that effective at anonym= ity, I shouldn't
>> >> > be able to tracked.
>> >> >
>> >> > https://amiunique.org/
>> >> >
>> >> > Yet it is saying I can be with both Chrome and Firef= ox on Fedora 29 in
>> >> > Incognito/Private windows mode on this host. It says= the same about my
>> >> > Android 9 phone with Chrome in Incognito mode.
>> >> >
>> >> > Going into the detail of how, they don't seem to= be using IP address
>> >> > at all for any identification, it is all browser att= ributes.
>> >> >
>> >> > We have IPv6 temporary addresses, which makes using = addresses harder
>> >> > to use to identify a node. I think that is a lot bet= ter than nothing.
>> >>
>> >> Mark,
>> >>
>> >> Yes, but by that same rationale a simple substitution cip= her is better
>> >> than nothing in cryptography!
>> >>
>> >> What pretty much any conversation about privacy in addres= sing seems to
>> >> lacking is a quantitative description of privacy and any = empiracal
>> >> data on the impact that privacy mechanisms, like those de= fined in
>> >> RFC4941, have had. You might say it "makes using add= resses harder to
>> >> use to identify a node". But then the obvious questi= on is _how_ much
>> >> harder? Is this really protecting anyone's privacy, o= r it is just a
>> >> minor inconvenience to attackers and only giving users a = false sense
>> >> of security?
>> >>
>> >> The irony is that CGN seems to have the best supporting e= vidence for
>> >> being a mechanism that impacts privacy, but it was never = even intended
>> >> to be a privacy mechanism. The evidence is in the form of= concerns
>> >> form law enforcement that the privacy side effect is too = strong and
>> >> impedes their investigations
>> >> (https://www.theregister.co= .uk/2017/10/18/europol_cgnat/).
>> >>
>> >> So I don't think "Is addressing privacy via NAT = really achieving much
>> >> compared to a privacy goal of anonymity?" is the rig= ht question. The
>> >> right question to ask is "Is addressing privacy via = any IETF defined
>> >> mechanism achieving much compared to a privacy goal of an= onymity?"
>> >>
>> >> Tom
>> >
>> >
>> >
>> >
>> > 1.=C2=A0 Network service providers cannot provide address ano= nymity.=C2=A0 LEA requirements in the USA and many jurisdictions simply do = not allow it, so who is the customer of such a standard?=C2=A0 Who would ma= ke and deploy it?
>>
>> The customer of this is political dissident that is speaking out >> against injustice of a corrupt government. There is nothing that >> prevents a solution that provides the privacy for the dissident, b= ut
>> still allows their network provider to maintain records that corre= late
>> address to identity is available to LEA for the local jurisdiction=
>> under lawful order. This really isn't different than other are= as of
>> privacy on the Internet (like the logs that Facebook or Google kee= p).
>> The point is that anonimity is needed to prevent unauthorized thir= d
>> parties from breaking someones privacy.
>>
>> >
>> > 2. Network address annonimity today is generally provided via= Tor.=C2=A0 How could the ietf provide something better than existiting tor= solutions, knowing that it will not be baked into the network =E2=80=94 me= aning it must be over the top.
>> >
>>
>> I'm not sure what "provided via Tor" means.
>
>
> Tor is this
> https://www.torproject.org/about/overview.html= .en
>
> Tor is what people use today for address anonimity today

Thanks for the reference. It's interesting but then there's
https://www.esecurityp= lanet.com/open-source-security/the-trouble-with-tor.html.
In any case, I believe it's in IETF's best interest to continually<= br> evaluate security and privacy in IP protocols. Privacy in IP
addressing seems to be an area of weakness in that regard.



+1

=
We with Dirk are pursuing this kind of activity in pidloc list pidloc@ietf.org more in the context of Iden= tifier locator separation protocol context.
Please join pidloc.

=C2=A0Regards,
Behcet
Tom

>
>>
>>
>>
>> > 3. CGN is not private. It throw off per session logs of every= transaction, so this is a full click stream archived ... with varing level= s of intentional monetization and security from hackers.
>> >
>> Yes, it is expected that the local provider has full view of all >> associations of address to some device, that's pretty much a g= iven and
>> we have to trust the local provider to some extent. What we're= trying
>> to prevent is untrusted external parties from deducing identity or=
>> location of users.
>>
>> >
>> >>
>> >> > However, I don't see how IPv6 NAT would improve = it much, and it
>> >> > introduces the other drawbacks of NAT.
>> >> >
>> >> > Regards,
>> >> > Mark.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > > Tom
>> >> > >
>> >> > > > Regards,
>> >> > > > Mark.
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > > Bert
>> >> > > >
>> >> > > > __________________________________________= _____
>> >> > > > v6ops mailing list
>> >> > > > v6ops@ietf.org
>> >> > > > https://www.ietf.org/mai= lman/listinfo/v6ops
>> >>
>> >> ---------------------------------------------------------= -----------
>> >> IETF IPv6 working group mailing list
>> >> ipv6@i= etf.org
>> >> Administrative Requests: https://www.iet= f.org/mailman/listinfo/ipv6
>> >> ---------------------------------------------------------= -----------

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000002872b60582ceddb5-- From nobody Tue Feb 26 08:54: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 42F7F1292F1 for ; Tue, 26 Feb 2019 08:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fxez7TsM6H8h for ; Tue, 26 Feb 2019 08:54:46 -0800 (PST) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BD01200D8 for ; Tue, 26 Feb 2019 08:54:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id BE13C32031A6; Tue, 26 Feb 2019 13:54:44 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qB3KlzSQeH5l; Tue, 26 Feb 2019 13:54:42 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id D12D83203231; Tue, 26 Feb 2019 13:54:42 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar D12D83203231 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1551200082; bh=mp+oFihz00Nvif//9qhq89296Sf7N/NcR1Goc17B4NQ=; h=Date:From:To:Message-ID:MIME-Version; b=niBc+v15c22jH/FGPfXx9jzyNcfJXZhqdMqcRZH40Uq+cG99q7wF1Op3Vdh+LhWMj gcYMVFlKa1GSySvAnzpqrhSuCvzirJhOsWitwz/E8u6089MkkFlFWotioPCDA7DYiN RXdsvJyqs/hRVMEiaoFNtKVG3VMYmUq17pdbR0/6yAWM1VtI9lEH61nJdBKPXzZHT+ W4EJQ22KSWLHfVaqMbrO25qfAIkWGXEt723eJh8eReM8tgLiX877eIQ0hCTivY/Hnw tfgqWElJ2wRA9ipi7uiYAGuxuN5i267RXwpVdxe+wGMtGA/ePqBpyVdYAhAGX2h6zr 1oCaiXv2IWvNg== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aY1HI-6ZyAst; Tue, 26 Feb 2019 13:54:42 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 8DEB732031E5; Tue, 26 Feb 2019 13:54:42 -0300 (-03) Date: Tue, 26 Feb 2019 13:54:42 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Message-ID: <2077258554.10806756.1551200081988.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <20BC09A5-791D-4E6F-88C1-E20E0E75287B@consulintel.es> References: <20BC09A5-791D-4E6F-88C1-E20E0E75287B@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC72 (Win)/8.8.8_GA_1703) Thread-Topic: inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment Thread-Index: azAOgmq1zpIuRk7ry7IP4He8F8SiTQ== Archived-At: Subject: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment 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 Feb 2019 16:54:50 -0000 Hello Jordi, All these big public CDNs work in dual-stack natively. The case is when we have a customer in dual-stack but behind CGN for IPv4 a= nd he/she also has devices (or applications within those devices) that don'= t support IPv6 (e.g.: Smart TVs and Set-top-Boxes). This is the scenario: +------------+ | | |Public CDN | = Priv IPv4 +-----------+ | | = | | | | = +---------+ SMART TV | +------------+ = | | | |Dual-Stack = | +-----------+ |Pub IPv4 = | |GUA IPv6 = | +------------+ +------------------+ = | +-------------+ | | | | = +-------+-+ Priv +-----------+ | |Dual-Stack | | | | = | | IPv4 | | | Internet +------------+ Router +-------+ ISP Network +-------= ------+ CPE +-------+ STB | | | | | | | = | | | | +-------------+ | | | | = +-------+-+ +-----------+ +-+--------+-+ +------------------+ = Dual-Stack | | | = IPv4 CGN | | | = IPv6 | | | = | +-----------+ Outside | |Inside = | | | Pub IPv4| |IPv4 CGN = +---------+ Notebook | +------------+ = Dual-Stack| | | | = Priv IPv4 +-----------+ | CGN | = GUA IPv6 | | +------------+ Notebook has dual-stack. It will prefer IPv6 to connect to CDN. Smart TV and STB don't have IPv6. They will usually need to go through CGN = to connect to Public CDN. Some Public CDNs are supporting to receive connections from CGN addresses (= usually 100.64.x.x). In this case we can avoid to go through CGN and have a= direct connection between customers and CDN. Customers normally are behind= NAT of CPEs but they can have a CPE in bridge mode. So, customers behind CGN don't need a CGN to connect to a public CDN instal= led within the ISP. This case is where I see the three points where an ISP can use to consider = to don't have an IPv6-only access network: 1- Traffic avoids a point of failure (CGN), obviously it should be redundan= t but the point of failure exists. 2- Traffic is more "transparent" avoiding another translation for CDN. 3- This traffic doesn't impact in CGN sizing. Regards, Alejandro ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "Alejandro Degidio" CC: "v6ops@ietf.org list" Enviados: Lunes, 25 de Febrero 2019 22:12:12 Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks draft-ietf-v6ops-nat64-deployment Hi Alejandro, (removed dnsop, as this is not - I think - relevant for them) My understanding is that CDNs today have IPv6 already (at least the most im= portant ones, the ones with more traffic). If that's the case, the traffic = from the CEs, will be IPv6. Now, if a CDN don't have IPv6 support, in 464XLAT, the link is IPv6-only, s= o I don't see how we can change that. However, also I see that a possible solution for an IPv4-only CDN to suppor= t IPv6 in this scenario, may be via stateless NAT64, with pre-configured EA= MT (RFC7757) rules or something similar and the relevant AAAA entries. I th= ink this is more an operational issue than a new protocol. Clearly that means that you don't have that traffic in the stateful NAT64, = which I understand is your main goal. Anyway, of course, the right thing for those IPv4-only CDNs will be to push= them for IPv6 support! I will be nice if you can publicly name them ... That make sense to you? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alejandro D'Egidio Fecha: martes, 26 de febrero de 2019, 0:24 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" , dnsop Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks draft-ietf-v6ops-nat64-deployment Hello Jordi, I like 464XLAT and this is something I would like to implement in DOCSI= S networks. As Deployment Guidelines maybe you can include/consider the next case, = if not please forget it or we can include it on another document. =20 Today we still have many devices that don't support IPv6 or some applic= ations on it don't support it, this is the case of SMART TVs and set top bo= xes. There is a common scenario where big public CDNs support deliver conten= t to private IPv4 destinations (usually CGN prefixes) directly without goin= g through a CGN. In that scenario, CPEs (with eRouter) that have IPv4 of CGN (ie 100.64.= x.x) can connect receive traffic from CDNs directly without having any CGN = in the middle. =20 So I see three points in this case: 1- Traffic avoids a point of failure (CGN), obviously it should be redu= ndant but the point of failure exists. 2- Traffic is more "transparent" avoiding another translation for CDN. 3- This traffic doesn't impact in CGN sizing. =20 As I said, I like 464XLAT and I would like to have a IPv6-Only access n= etwork but this is a real case where ISPs can consider to continue provisio= ning IPv4 to customers. =20 =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "v6ops@ietf.org list" , "dnsop" Enviados: Jueves, 21 de Febrero 2019 2:58:36 Asunto: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks draft-ietf-v6ops-nat64-deployment =20 Hi all, =20 (dnsop copied because DNS64) =20 I'm working in a new version of this document. =20 Link to the document: =20 https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 It will be great if we can get some new inputs. =20 Thanks! =20 Regards, Jordi =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, 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 awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.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 Feb 26 09:16: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 A947312785F; Tue, 26 Feb 2019 09:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 YJ_ZfM_uRsqj; Tue, 26 Feb 2019 09:16:40 -0800 (PST) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B394124B0C; Tue, 26 Feb 2019 09:16:40 -0800 (PST) Received: by mail-wm1-f48.google.com with SMTP id n19so3183990wmi.1; Tue, 26 Feb 2019 09:16:40 -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=5LBmknigahiuE7ihP1kUMXnQh0fCKnGyUXOb0msRlFo=; b=Tx78sUdcdd0WY7x+j8F++n0ePocBpL3+DtJB0aBpi0r8XYasMO3DtlrKA4zwXasvwd x8ghLVKniv32Q8w60Cov6swcAGf+X0JONP3hNWSx8yR/LcUd98BVSYkDmY1EYsSGXfOm /2bsmjAPJdhf+OhumqY30p6HRqLVYvZyhY/hZm5RgOXeJW/CGi+unhhLiq6wkR6bdrF2 K8gZ1zDMI2pBiXyJ0ROK4Ixt5GRyOg3LJYJaHFBy6SsDB4qnH+90u8VCBqdSqaCCNwzT lgHb2Z7dnWmTJz15EBqxPTVF6mPJkklOWIno0s4qqfXFGGZ54VtQXD7VA3dYNZEOMLLT AHew== X-Gm-Message-State: AHQUAubTD/sOyFCgP3kwuZeG3apLUBdmEc5+qh/Yic+EFlCQBIeexqxO 7PEtFu+EOqfiYHfDX++felD39znhA/oQH5F/aak= X-Google-Smtp-Source: AHgI3Ib75je0VOytmjr5s4dci3WkzSudq609Xr5xYRJOgQb9+uivQbNU/7OTUNIwL3H84dUpMD4euMMur37H3zZHzLg= X-Received: by 2002:a1c:6409:: with SMTP id y9mr3528574wmb.68.1551201398450; Tue, 26 Feb 2019 09:16:38 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 26 Feb 2019 09:16:25 -0800 Message-ID: To: Fernando Gont Cc: Ole Troan , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Content-Type: multipart/alternative; boundary="0000000000005470a70582cf385e" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 17:16:43 -0000 --0000000000005470a70582cf385e Content-Type: text/plain; charset="UTF-8" At Tue, 26 Feb 2019 07:43:00 -0300, Fernando Gont wrote: > > In the DHCP PD case they should also be counted down in real time. > > And the lifetimes can be dynamically adjusted. > > They should. However, quite frequently the DHCPv6-PD part is a different > piece of software from the ra{d,dvd} part. Both pieces are glued by some > script, and the lifetime is *not* dynamically adjusted. It's a clear violation of Section 18.2.10.1 of RFC8415: If the client uses a delegated prefix to configure addresses on interfaces on itself or other nodes behind it, the preferred and valid lifetimes of those addresses MUST be no longer than the remaining preferred and valid lifetimes, respectively, for the delegated prefix at any time. In particular, if the delegated prefix or a prefix derived from it is advertised for stateless address autoconfiguration [RFC4862], the advertised preferred and valid lifetimes MUST NOT exceed the corresponding remaining lifetimes of the delegated prefix. while we cannot completely ignore non-compliant implementations (if any) in practice, IMO the existence of violators shouldn't be the primary reason for tweaking the protocol. Besides, I'm actually not so sure if it's so difficult to comply with today's tools. RFC4861 has the concept of dynamically decrementing the advertised lifetimes as a protocol parameter (with a MAY): AdvValidLifetime [...] - a time that decrements in real time, that is, one that will result in a Lifetime of zero at the specified time in the future, or [...] AdvPreferredLifetime [...] - a time that decrements in real time, that is, one that will result in a Lifetime of zero at a specified time in the future, or and I suspect that non-negligible number of implementations support this concept. BSD's rtadvd does, apparently so does Linux radvd. For these implementations, it's just a matter of configuration, even if the DHCP-PD client and RA advertisement are implemented as different pieces of software: a "script" takes the lifetimes from DHCPv6 PD and dumps the RA configuration by setting AdvXXXLifetimes to that values that decrement in real time. I don't necessarily oppose to the idea of revising the default prefix lifetimes currently specified in RFC4861. The growing deployment of mobile environments may justify an update, for example. But the discussion should be based on accurate understanding of what's possible with the current specification and actual implementations, rather than speculative "red herring". -- JINMEI, Tatuya --0000000000005470a70582cf385e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+QXQgVHVlLCAyNiBGZWIgMjAxOSAwNzo0Mzow MCAtMDMwMCw8YnI+RmVybmFuZG8gR29udCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZnb250QHNpNm5l dHdvcmtzLmNvbSI+ZmdvbnRAc2k2bmV0d29ya3MuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj4m Z3Q7ICZndDsgSW4gdGhlIERIQ1AgUEQgY2FzZSB0aGV5IHNob3VsZCBhbHNvIGJlIGNvdW50ZWQg ZG93biBpbiByZWFsIHRpbWUuPGJyPiZndDsgJmd0OyBBbmQgdGhlIGxpZmV0aW1lcyBjYW4gYmUg ZHluYW1pY2FsbHkgYWRqdXN0ZWQuPGJyPiZndDsgPGJyPiZndDsgVGhleSBzaG91bGQuIEhvd2V2 ZXIsIHF1aXRlIGZyZXF1ZW50bHkgdGhlIERIQ1B2Ni1QRCBwYXJ0IGlzIGEgZGlmZmVyZW50PGJy PiZndDsgcGllY2Ugb2Ygc29mdHdhcmUgZnJvbSB0aGUgcmF7ZCxkdmR9IHBhcnQuIEJvdGggcGll Y2VzIGFyZSBnbHVlZCBieSBzb21lPGJyPiZndDsgc2NyaXB0LCBhbmQgdGhlIGxpZmV0aW1lIGlz ICpub3QqIGR5bmFtaWNhbGx5IGFkanVzdGVkLjxicj48YnI+SXQmIzM5O3MgYSBjbGVhciB2aW9s YXRpb24gb2YgU2VjdGlvbiAxOC4yLjEwLjEgb2YgUkZDODQxNTo8YnI+PGJyPsKgwqDCoMKgwqAg SWYgdGhlIGNsaWVudCB1c2VzIGEgZGVsZWdhdGVkIHByZWZpeCB0byBjb25maWd1cmUgYWRkcmVz c2VzIG9uPGJyPsKgwqDCoMKgwqAgaW50ZXJmYWNlcyBvbiBpdHNlbGYgb3Igb3RoZXIgbm9kZXMg YmVoaW5kIGl0LCB0aGUgcHJlZmVycmVkIGFuZDxicj7CoMKgwqDCoMKgIHZhbGlkIGxpZmV0aW1l cyBvZiB0aG9zZSBhZGRyZXNzZXMgTVVTVCBiZSBubyBsb25nZXIgdGhhbiB0aGU8YnI+wqDCoMKg wqDCoCByZW1haW5pbmcgcHJlZmVycmVkIGFuZCB2YWxpZCBsaWZldGltZXMsIHJlc3BlY3RpdmVs eSwgZm9yIHRoZTxicj7CoMKgwqDCoMKgIGRlbGVnYXRlZCBwcmVmaXggYXQgYW55IHRpbWUuwqAg SW4gcGFydGljdWxhciwgaWYgdGhlIGRlbGVnYXRlZDxicj7CoMKgwqDCoMKgIHByZWZpeCBvciBh IHByZWZpeCBkZXJpdmVkIGZyb20gaXQgaXMgYWR2ZXJ0aXNlZCBmb3Igc3RhdGVsZXNzPGJyPsKg wqDCoMKgwqAgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlvbiBbUkZDNDg2Ml0sIHRoZSBhZHZlcnRp c2VkIHByZWZlcnJlZCBhbmQ8YnI+wqDCoMKgwqDCoCB2YWxpZCBsaWZldGltZXMgTVVTVCBOT1Qg ZXhjZWVkIHRoZSBjb3JyZXNwb25kaW5nIHJlbWFpbmluZzxicj7CoMKgwqDCoMKgIGxpZmV0aW1l cyBvZiB0aGUgZGVsZWdhdGVkIHByZWZpeC48YnI+PGJyPndoaWxlIHdlIGNhbm5vdCBjb21wbGV0 ZWx5IGlnbm9yZSBub24tY29tcGxpYW50IGltcGxlbWVudGF0aW9ucyAoaWY8YnI+YW55KSBpbiBw cmFjdGljZSwgSU1PIHRoZSBleGlzdGVuY2Ugb2YgdmlvbGF0b3JzIHNob3VsZG4mIzM5O3QgYmUg dGhlPGJyPnByaW1hcnkgcmVhc29uIGZvciB0d2Vha2luZyB0aGUgcHJvdG9jb2wuPGJyPjxicj5C ZXNpZGVzLCBJJiMzOTttIGFjdHVhbGx5IG5vdCBzbyBzdXJlIGlmIGl0JiMzOTtzIHNvIGRpZmZp Y3VsdCB0byBjb21wbHkgd2l0aDxicj50b2RheSYjMzk7cyB0b29scy7CoCBSRkM0ODYxIGhhcyB0 aGUgY29uY2VwdCBvZiBkeW5hbWljYWxseSBkZWNyZW1lbnRpbmc8YnI+dGhlIGFkdmVydGlzZWQg bGlmZXRpbWVzIGFzIGEgcHJvdG9jb2wgcGFyYW1ldGVyICh3aXRoIGEgTUFZKTo8YnI+PGJyPsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQWR2VmFsaWRMaWZl dGltZTxicj5bLi4uXTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBhIHRpbWUgdGhhdCBkZWNyZW1lbnRzIGluIHJlYWwgdGlt ZSw8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB0aGF0IGlzLCBvbmUgdGhhdCB3aWxsIHJlc3VsdCBpbiBhPGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgTGlmZXRpbWUgb2YgemVybyBhdCB0aGUgc3BlY2lmaWVkIHRpbWU8YnI+wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpbiB0 aGUgZnV0dXJlLCBvcjxicj5bLi4uXTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIEFkdlByZWZlcnJlZExpZmV0aW1lPGJyPlsuLi5dPGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAtIGEg dGltZSB0aGF0IGRlY3JlbWVudHMgaW4gcmVhbCB0aW1lLDxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRoYXQgaXMsIG9u ZSB0aGF0IHdpbGwgcmVzdWx0IGluIGE8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBMaWZldGltZSBvZiB6ZXJvIGF0IGEg c3BlY2lmaWVkIHRpbWUgaW48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aGUgZnV0dXJlLCBvcjxicj48YnI+YW5kIEkg c3VzcGVjdCB0aGF0IG5vbi1uZWdsaWdpYmxlIG51bWJlciBvZiBpbXBsZW1lbnRhdGlvbnMgc3Vw cG9ydDxicj50aGlzIGNvbmNlcHQuwqAgQlNEJiMzOTtzIHJ0YWR2ZCBkb2VzLCBhcHBhcmVudGx5 IHNvIGRvZXMgTGludXggcmFkdmQuPGJyPkZvciB0aGVzZSBpbXBsZW1lbnRhdGlvbnMsIGl0JiMz OTtzIGp1c3QgYSBtYXR0ZXIgb2YgY29uZmlndXJhdGlvbiwgZXZlbjxicj5pZiB0aGUgREhDUC1Q RCBjbGllbnQgYW5kIFJBIGFkdmVydGlzZW1lbnQgYXJlIGltcGxlbWVudGVkIGFzPGJyPmRpZmZl cmVudCBwaWVjZXMgb2Ygc29mdHdhcmU6IGEgJnF1b3Q7c2NyaXB0JnF1b3Q7IHRha2VzIHRoZSBs aWZldGltZXMgZnJvbTxicj5ESENQdjYgUEQgYW5kIGR1bXBzIHRoZSBSQSBjb25maWd1cmF0aW9u IGJ5IHNldHRpbmcgQWR2WFhYTGlmZXRpbWVzIHRvPGJyPnRoYXQgdmFsdWVzIHRoYXQgZGVjcmVt ZW50IGluIHJlYWwgdGltZS48YnI+PGJyPkkgZG9uJiMzOTt0IG5lY2Vzc2FyaWx5IG9wcG9zZSB0 byB0aGUgaWRlYSBvZiByZXZpc2luZyB0aGUgZGVmYXVsdCBwcmVmaXg8YnI+bGlmZXRpbWVzIGN1 cnJlbnRseSBzcGVjaWZpZWQgaW4gUkZDNDg2MS7CoCBUaGUgZ3Jvd2luZyBkZXBsb3ltZW50IG9m PGJyPm1vYmlsZSBlbnZpcm9ubWVudHMgbWF5IGp1c3RpZnkgYW4gdXBkYXRlLCBmb3IgZXhhbXBs ZS7CoCBCdXQgdGhlPGJyPmRpc2N1c3Npb24gc2hvdWxkIGJlIGJhc2VkIG9uIGFjY3VyYXRlIHVu ZGVyc3RhbmRpbmcgb2Ygd2hhdCYjMzk7czxicj5wb3NzaWJsZSB3aXRoIHRoZSBjdXJyZW50IHNw ZWNpZmljYXRpb24gYW5kIGFjdHVhbCBpbXBsZW1lbnRhdGlvbnMsPGJyPnJhdGhlciB0aGFuIHNw ZWN1bGF0aXZlICZxdW90O3JlZCBoZXJyaW5nJnF1b3Q7Ljxicj48YnI+LS08YnI+SklOTUVJLCBU YXR1eWE8YnI+PC9kaXY+PC9kaXY+DQo= --0000000000005470a70582cf385e-- From nobody Tue Feb 26 09:35: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 410D7130E84; Tue, 26 Feb 2019 09:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM-FaT7cN-PY; Tue, 26 Feb 2019 09:35:34 -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 1B98812D4F2; Tue, 26 Feb 2019 09:35:34 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 52010848BA; Tue, 26 Feb 2019 18:35:30 +0100 (CET) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Ole Troan , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <924e562a-82e8-e224-d5c3-859c493657e8@si6networks.com> Date: Tue, 26 Feb 2019 14:35:20 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 17:35:37 -0000 Hello, Jinmei, On 26/2/19 14:16, 神明達哉 wrote: > At Tue, 26 Feb 2019 07:43:00 -0300, > Fernando Gont > wrote: > >> > In the DHCP PD case they should also be counted down in real time. >> > And the lifetimes can be dynamically adjusted. >> >> They should. However, quite frequently the DHCPv6-PD part is a different >> piece of software from the ra{d,dvd} part. Both pieces are glued by some >> script, and the lifetime is *not* dynamically adjusted. > > It's a clear violation of Section 18.2.10.1 of RFC8415: > >       If the client uses a delegated prefix to configure addresses on >       interfaces on itself or other nodes behind it, the preferred and >       valid lifetimes of those addresses MUST be no longer than the >       remaining preferred and valid lifetimes, respectively, for the >       delegated prefix at any time.  In particular, if the delegated >       prefix or a prefix derived from it is advertised for stateless >       address autoconfiguration [RFC4862], the advertised preferred and >       valid lifetimes MUST NOT exceed the corresponding remaining >       lifetimes of the delegated prefix. > > while we cannot completely ignore non-compliant implementations (if > any) in practice, IMO the existence of violators shouldn't be the > primary reason for tweaking the protocol. Which specific tweak are you referring to? > Besides, I'm actually not so sure if it's so difficult to comply with > today's tools.  RFC4861 has the concept of dynamically decrementing > the advertised lifetimes as a protocol parameter (with a MAY): > >                         AdvValidLifetime > [...] >                                - a time that decrements in real time, >                                  that is, one that will result in a >                                  Lifetime of zero at the specified time >                                  in the future, or > [...] >                         AdvPreferredLifetime > [...] >                                - a time that decrements in real time, >                                  that is, one that will result in a >                                  Lifetime of zero at a specified time in >                                  the future, or > > and I suspect that non-negligible number of implementations support > this concept.  BSD's rtadvd does, apparently so does Linux radvd. > For these implementations, it's just a matter of configuration, even > if the DHCP-PD client and RA advertisement are implemented as > different pieces of software: a "script" takes the lifetimes from > DHCPv6 PD and dumps the RA configuration by setting AdvXXXLifetimes to > that values that decrement in real time. I haven't been following developments in this area... but I do remember scripts to put the two pieces together, and others doing the same. > I don't necessarily oppose to the idea of revising the default prefix > lifetimes currently specified in RFC4861.  The growing deployment of > mobile environments may justify an update, for example.  But the > discussion should be based on accurate understanding of what's > possible with the current specification and actual implementations, > rather than speculative "red herring". Tee only thing that I mentioned is that the CPE should be prepared to "deprecate" a prefix for "Valid Lifetime". -- a local ISP recently reported that they employ DHCPv6-PD times of over a month. IN those cases, the spec you reference is complied with, and what I mention above is the case: -- if there-s a carsh-and-reboot scenario, the CPE should (in theory) be prepared to deprecate a prefix for "Valid LIfetime". -- whether in practice you can get away with firing a few RAs is a different thing. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 26 11:13: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 2EAD51228B7; Tue, 26 Feb 2019 11:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw9CHiVWfmYJ; Tue, 26 Feb 2019 11:13:43 -0800 (PST) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F9B129532; Tue, 26 Feb 2019 11:13:43 -0800 (PST) Received: by mail-wr1-f53.google.com with SMTP id l5so15221527wrw.6; Tue, 26 Feb 2019 11:13:42 -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=+X894PO95qi2y6CuxoYk0Wpr7eBesafNnoUOQIbDu3Q=; b=Ks78WIRmYEYq2edtPaXK48EZnnjZU77KihBDDwwQq6QIDeKEMiU+W7oI01tXxcOkS7 MPFO/RyLpVN9Oxcl/dSZTXiPm1a2xQcviQQ2R/JDttrF15bz116m4FTC79cJ3wFe+04L 9EsYbH0z1zjOMtU39eI09DJ4Hvv6tAtk4NqznLm9c1Gr0KeImyTlCZGkRtt0cXEknc+a 7hEDby0WG2el9xdLSc3X/CzxVIgAAhkywt3hryWMU0Kd7yvpVSzQrVZpW83EqEyQEX4f Q0CEmuZGmcaDdLBdZeBeHkYJ7Rjwh0fgT04W2aBcUsJIxCZayqPdAYHTcipTQPx0A7sJ zqgg== X-Gm-Message-State: AHQUAubDrfnArsGrXCQkm2tWdpULmuQ2cM0Fn1yqZKijrlUH4eGdHSPD Hryl0KF0usuSiWCH0Cy8iPpKQYCTgT90DK8caKElOBMW X-Google-Smtp-Source: AHgI3IZfRQ3nX/UWIrGldHdFHDK/TBDAzwnUaOjLBqG77NmzAYjGk1I+v7fQXfJGFpHDhfJeX68PWzp7IMYzjGIaIrU= X-Received: by 2002:adf:f103:: with SMTP id r3mr19227293wro.50.1551208421086; Tue, 26 Feb 2019 11:13:41 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <924e562a-82e8-e224-d5c3-859c493657e8@si6networks.com> In-Reply-To: <924e562a-82e8-e224-d5c3-859c493657e8@si6networks.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 26 Feb 2019 11:13:29 -0800 Message-ID: To: Fernando Gont Cc: Ole Troan , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Content-Type: multipart/alternative; boundary="000000000000e95c650582d0da11" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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 Feb 2019 19:13:45 -0000 --000000000000e95c650582d0da11 Content-Type: text/plain; charset="UTF-8" At Tue, 26 Feb 2019 14:35:20 -0300, Fernando Gont wrote: > > while we cannot completely ignore non-compliant implementations (if > > any) in practice, IMO the existence of violators shouldn't be the > > primary reason for tweaking the protocol. > > Which specific tweak are you referring to? Changing the default value of AdvPreferredLifetime and AdvPreferredLifetime currently defined in in RFC4861. >> and I suspect that non-negligible number of implementations support >> this concept. BSD's rtadvd does, apparently so does Linux radvd. >> For these implementations, it's just a matter of configuration, >> even if the DHCP-PD client and RA advertisement are implemented as >> different pieces of software: a "script" takes the lifetimes from >> DHCPv6 PD and dumps the RA configuration by setting AdvXXXLifetimes >> to that values that decrement in real time. > I haven't been following developments in this area... but I do remember > scripts to put the two pieces together, and others doing the same. The question is specifically how those script put the pieces together. As long as the "RA piece" supports the "decrement in real time" part of RFC4861, not using it is a mere bug of those scripts (in that it at least violates Section 18.2.10.1 of RFC8415). My point here is that the existence of buggy implementation (if it exists at all) doesn't seem to be a strong justification of updating the spec. > > I don't necessarily oppose to the idea of revising the default prefix > > lifetimes currently specified in RFC4861. The growing deployment of > > mobile environments may justify an update, for example. But the > > discussion should be based on accurate understanding of what's > > possible with the current specification and actual implementations, > > rather than speculative "red herring". > > Tee only thing that I mentioned is that the CPE should be prepared to > "deprecate" a prefix for "Valid Lifetime". -- a local ISP recently > reported that they employ DHCPv6-PD times of over a month. IN those > cases, the spec you reference is complied with, and what I mention above > is the case: -- if there-s a carsh-and-reboot scenario, the CPE should > (in theory) be prepared to deprecate a prefix for "Valid LIfetime". -- > whether in practice you can get away with firing a few RAs is a > different thing. In that case I'd rather see a point in what Ole keeps saying: either the ISP should use a much shorter DHCPv6-PD prefix lifetimes in the first place or they shouldn't change the delegated prefix. I'm not saying this to argue there's nothing we can/should do for such a broken operation. But this case seems weak as a justification to change the default lifetime values in RFC4861. -- JINMEI, Tatuya --000000000000e95c650582d0da11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Tue, 26 Feb 2019 14:35:20 -0300,
Fe= rnando Gont <fgont@si6networks.= com> wrote:

> > while we cannot completely ignore non-c= ompliant implementations (if
> > any) in practice, IMO the existen= ce of violators shouldn't be the
> > primary reason for tweaki= ng the protocol.
>
> Which specific tweak are you referring to= ?

Changing the default value of AdvPreferredLifetime and
AdvPrefe= rredLifetime currently defined in in RFC4861.

>> and I suspect= that non-negligible number of implementations support
>> this con= cept.=C2=A0 BSD's rtadvd does, apparently so does Linux radvd.
>&= gt; For these implementations, it's just a matter of configuration,
= >> even if the DHCP-PD client and RA advertisement are implemented as=
>> different pieces of software: a "script" takes the l= ifetimes from
>> DHCPv6 PD and dumps the RA configuration by setti= ng AdvXXXLifetimes
>> to that values that decrement in real time.<= br>
> I haven't been following developments in this area... but I= do remember
> scripts to put the two pieces together, and others doi= ng the same.

The question is specifically how those script put the p= ieces together.
As long as the "RA piece" supports the "d= ecrement in real time" part
of RFC4861, not using it is a mere bug = of those scripts (in that it at
least violates Section 18.2.10.1 of RFC8= 415).=C2=A0 My point here is that
the existence of buggy implementation = (if it exists at all) doesn't
seem to be a strong justification of u= pdating the spec.

> > I don't necessarily oppose to the id= ea of revising the default prefix
> > lifetimes currently specifie= d in RFC4861.=C2=A0 The growing deployment of
> > mobile environme= nts may justify an update, for example.=C2=A0 But the
> > discussi= on should be based on accurate understanding of what's
> > pos= sible with the current specification and actual implementations,
> &g= t; rather than speculative "red herring".
>
> Tee on= ly thing that I mentioned is that the CPE should be prepared to
> &qu= ot;deprecate" a prefix for "Valid Lifetime". -- a local ISP = recently
> reported that they employ DHCPv6-PD times of over a month.= IN those
> cases, the spec you reference is complied with, and what = I mention above
> is the case: -- if there-s a carsh-and-reboot scena= rio, the CPE should
> (in theory) be prepared to deprecate a prefix f= or "Valid LIfetime". --
> whether in practice you can get a= way with firing a few RAs is a
> different thing.

In that case= I'd rather see a point in what Ole keeps saying: either
the ISP sho= uld use a much shorter DHCPv6-PD prefix lifetimes in the
first place or = they shouldn't change the delegated prefix.=C2=A0 I'm not
saying= this to argue there's nothing we can/should do for such a broken
op= eration.=C2=A0 But this case seems weak as a justification to change thedefault lifetime values in RFC4861.

--
JINMEI, Tatuya
<= /div> --000000000000e95c650582d0da11-- From nobody Tue Feb 26 22:19: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 43E0E130E57 for ; Tue, 26 Feb 2019 22:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BPKlorH6pF0 for ; Tue, 26 Feb 2019 22:19:07 -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 6767012F1A6 for ; Tue, 26 Feb 2019 22:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1551248343; x=1551853143; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=gXCU7Ljfnq3cfJUFLCpMe pJ7uZSgQLeZf6Z2Ujhn+4U=; b=nmx50EDuwVAtCQUKL3mzo4razjCpF5ju5ZZ+v lmB3OCxRbRcFOhZZlEPMG/ZCTI5lpDBVcnckpFRyMTf5gNfJRZxwhUD3XwODJauK GoJ5BMX7ytZRnoq/J9o8uJb0Lo6v2dAti3IKvDSGm593/cTlGhRjrnzRhjIiJ9Yb JpUXhk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 27 Feb 2019 07:19:03 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 27 Feb 2019 07:19:02 +0100 Received: from [220.247.145.169] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006169252.msg for ; Wed, 27 Feb 2019 07:19:01 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [220.247.145.169] X-MDArrival-Date: Wed, 27 Feb 2019 07:19:01 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1961127b7a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.7.190210 Date: Wed, 27 Feb 2019 15:18:47 +0900 From: JORDI PALET MARTINEZ To: Alejandro D'Egidio CC: "v6ops@ietf.org list" Message-ID: <86B7975E-87B1-44BE-8220-661A73A016B8@consulintel.es> Thread-Topic: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment 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, 27 Feb 2019 06:19:10 -0000 Hi Alejandro, Thanks, I understand your point better now. I was thinking only that you me= an IPv4-only CDN resources. However, I believe that by using routing (I didn't actually try it myself, = but I think it is simple to do), because the CLAT brings this IPv4-only as = IPv6 traffic into your access/distribution network, so you can make sure to= route more specifics prefixes directly to the CDN as IPv6, without going t= hru the NAT64 and then the CLAT will translate it back to IPv4 for the Smar= tTV. So I don't think we need any additional "protocol" or change to 464XLAT to = do that. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alejandro D'Egidio Fecha: mi=C3=A9rcoles, 27 de febrero de 2019, 1:55 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks draft-ietf-v6ops-nat64-deployment Hello Jordi, =20 All these big public CDNs work in dual-stack natively. The case is when we have a customer in dual-stack but behind CGN for IP= v4 and he/she also has devices (or applications within those devices) that = don't support IPv6 (e.g.: Smart TVs and Set-top-Boxes). This is the scenario: +------------+ | | |Public CDN | = Priv IPv4 +-----------+ | | = | | | | = +---------+ SMART TV | +------------+ = | | | |Dual-Stack = | +-----------+ |Pub IPv4 = | |GUA IPv6 = | +------------+ +------------------+ = | +-------------+ | | | | = +-------+-+ Priv +-----------+ | |Dual-Stack | | | | = | | IPv4 | | | Internet +------------+ Router +-------+ ISP Network +---= ----------+ CPE +-------+ STB | | | | | | | = | | | | +-------------+ | | | | = +-------+-+ +-----------+ +-+--------+-+ +------------------+ = Dual-Stack | | | = IPv4 CGN | | | = IPv6 | | | = | +-----------+ Outside | |Inside = | | | Pub IPv4| |IPv4 CGN = +---------+ Notebook | +------------+ = Dual-Stack| | | | = Priv IPv4 +-----------+ | CGN | = GUA IPv6 | | +------------+ =20 Notebook has dual-stack. It will prefer IPv6 to connect to CDN. Smart TV and STB don't have IPv6. They will usually need to go through = CGN to connect to Public CDN. Some Public CDNs are supporting to receive connections from CGN address= es (usually 100.64.x.x). In this case we can avoid to go through CGN and ha= ve a direct connection between customers and CDN. Customers normally are be= hind NAT of CPEs but they can have a CPE in bridge mode. So, customers behind CGN don't need a CGN to connect to a public CDN in= stalled within the ISP. =20 This case is where I see the three points where an ISP can use to consi= der to don't have an IPv6-only access network: 1- Traffic avoids a point of failure (CGN), obviously it should be redu= ndant but the point of failure exists. 2- Traffic is more "transparent" avoiding another translation for CDN. 3- This traffic doesn't impact in CGN sizing. =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "Alejandro Degidio" CC: "v6ops@ietf.org list" Enviados: Lunes, 25 de Febrero 2019 22:12:12 Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Op= erator and Enterprise Networks draft-ietf-v6ops-nat64-deployment =20 Hi Alejandro, =20 (removed dnsop, as this is not - I think - relevant for them) =20 My understanding is that CDNs today have IPv6 already (at least the mos= t important ones, the ones with more traffic). If that's the case, the traf= fic from the CEs, will be IPv6. =20 Now, if a CDN don't have IPv6 support, in 464XLAT, the link is IPv6-onl= y, so I don't see how we can change that. =20 However, also I see that a possible solution for an IPv4-only CDN to su= pport IPv6 in this scenario, may be via stateless NAT64, with pre-configure= d EAMT (RFC7757) rules or something similar and the relevant AAAA entries. = I think this is more an operational issue than a new protocol. =20 Clearly that means that you don't have that traffic in the stateful NAT= 64, which I understand is your main goal. =20 Anyway, of course, the right thing for those IPv4-only CDNs will be to = push them for IPv6 support! I will be nice if you can publicly name them ..= . =20 That make sense to you? =20 Regards, Jordi =20 =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alejandro D'Egidio Fecha: martes, 26 de febrero de 2019, 0:24 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" , dnsop Asunto: Re: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Op= erator and Enterprise Networks draft-ietf-v6ops-nat64-deployment =20 Hello Jordi, I like 464XLAT and this is something I would like to implement in D= OCSIS networks. As Deployment Guidelines maybe you can include/consider the next ca= se, if not please forget it or we can include it on another document. =20 Today we still have many devices that don't support IPv6 or some ap= plications on it don't support it, this is the case of SMART TVs and set to= p boxes. There is a common scenario where big public CDNs support deliver co= ntent to private IPv4 destinations (usually CGN prefixes) directly without = going through a CGN. In that scenario, CPEs (with eRouter) that have IPv4 of CGN (ie 100= .64.x.x) can connect receive traffic from CDNs directly without having any = CGN in the middle. =20 So I see three points in this case: 1- Traffic avoids a point of failure (CGN), obviously it should be = redundant but the point of failure exists. 2- Traffic is more "transparent" avoiding another translation for C= DN. 3- This traffic doesn't impact in CGN sizing. =20 As I said, I like 464XLAT and I would like to have a IPv6-Only acce= ss network but this is a real case where ISPs can consider to continue prov= isioning IPv4 to customers. =20 =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "v6ops@ietf.org list" , "dnsop" Enviados: Jueves, 21 de Febrero 2019 2:58:36 Asunto: [v6ops] inputs on NAT64/464XLAT Deployment Guidelines in Op= erator and Enterprise Networks draft-ietf-v6ops-nat64-deployment =20 Hi all, =20 (dnsop copied because DNS64) =20 I'm working in a new version of this document. =20 Link to the document: =20 https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 It will be great if we can get some new inputs. =20 Thanks! =20 Regards, Jordi =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven 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 th= e original sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, 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 awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =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 Tue Feb 26 23:11: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 BCCFE130E67; Tue, 26 Feb 2019 23:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7JaycfKVtvY; Tue, 26 Feb 2019 23:11:27 -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 8A02612F19D; Tue, 26 Feb 2019 23:11:26 -0800 (PST) Received: from [192.168.3.66] (unknown [186.137.76.21]) (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 C22D584907; Wed, 27 Feb 2019 08:11:18 +0100 (CET) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Ole Troan , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <924e562a-82e8-e224-d5c3-859c493657e8@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <81aa4ec3-8277-794a-4da1-9855d2b6b97f@si6networks.com> Date: Wed, 27 Feb 2019 03:45:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.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 common problem with SLAAC in "renumbering" scenarios 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, 27 Feb 2019 07:11:31 -0000 On 26/2/19 16:13, 神明達哉 wrote: > At Tue, 26 Feb 2019 14:35:20 -0300, > Fernando Gont > wrote: > >> > while we cannot completely ignore non-compliant implementations (if >> > any) in practice, IMO the existence of violators shouldn't be the >> > primary reason for tweaking the protocol. >> >> Which specific tweak are you referring to? > > Changing the default value of AdvPreferredLifetime and > AdvPreferredLifetime currently defined in in RFC4861. The rationale for that it's what's in the I-D, namely: RATIONALE: * In the context of [RFC8028], where it is clear that use of addresses configured for a given prefix is tied to using the next-hop router that advertised the prefix, neither the "Preferred Lifetime" or the "Valid Lifetime" of a PIO should never be larger than the "Router Lifetime" (AdvDefaultLifetime) of Router Advertisement messages. * As a result, this document updates [RFC4861] such that the default Valid Lifetime (AdvValidLifetime) and Preferred Lifetime (AdvPreferredLifetime) of PIOs are specified as a function of the "Router Lifetime" (AdvDefaultLifetime) of Router Advertisement messages. * This document reduces the maximum time between unsolicited RAs (MaxRtrAdvInterval), which indirectly specifies the minimum time between unsolicited RAs (MinRtrAdvInterval) and the Router Lifetime (AdvDefaultLifetime), to improve the ability of hosts to recover from fault scenarios. * Lacking RAs that refresh information, addresses configured for advertised prefixes become un-preferred in a timelier manner, and thus Rule 3 of [RFC6724] causes other configured addresses (if available) to be used instead. * Reducing the Valid Lifetime and Preferred Lifetimes of PIOs limits the amount of time hosts may use stale prefixes, and also limits the amount of time that a stale prefix needs to be advertised with a lifetime of "0" on the local network (see Section 12 of [RFC4861]). [....] > The question is specifically how those script put the pieces together. > As long as the "RA piece" supports the "decrement in real time" part > of RFC4861, not using it is a mere bug of those scripts (in that it at > least violates Section 18.2.10.1 of RFC8415).  My point here is that > the existence of buggy implementation (if it exists at all) doesn't > seem to be a strong justification of updating the spec. Agreed. As noted above, *that* is *not* the motivation. >> > I don't necessarily oppose to the idea of revising the default prefix >> > lifetimes currently specified in RFC4861.  The growing deployment of >> > mobile environments may justify an update, for example.  But the >> > discussion should be based on accurate understanding of what's >> > possible with the current specification and actual implementations, >> > rather than speculative "red herring". >> >> Tee only thing that I mentioned is that the CPE should be prepared to >> "deprecate" a prefix for "Valid Lifetime". -- a local ISP recently >> reported that they employ DHCPv6-PD times of over a month. IN those >> cases, the spec you reference is complied with, and what I mention above >> is the case: -- if there-s a carsh-and-reboot scenario, the CPE should >> (in theory) be prepared to deprecate a prefix for "Valid LIfetime". -- >> whether in practice you can get away with firing a few RAs is a >> different thing. > > In that case I'd rather see a point in what Ole keeps saying: either > the ISP should use a much shorter DHCPv6-PD prefix lifetimes in the in the order of... how many minutes? > first place or they shouldn't change the delegated prefix.  I'm not > saying this to argue there's nothing we can/should do for such a broken > operation.  But this case seems weak as a justification to change the > default lifetime values in RFC4861. The justification is noted above. Regarding "broken operation"... the survey referenced in our I-D notes that 37% of the surveyed ISPs do dynamic prefixes. Blaming the ISPs is not really going to improve user experience... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 27 08: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 3AEC513105F; Wed, 27 Feb 2019 08:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, 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 9J9il8lGNGbO; Wed, 27 Feb 2019 08:38:15 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 43015130FF0; Wed, 27 Feb 2019 08:38:14 -0800 (PST) Received: from kiev.delong.com (kiev.delong.com [192.159.10.5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x1RGc0EM028275 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Feb 2019 08:38:02 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x1RGc0EM028275 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1551285484; bh=5FHcL67TOhj3LyGyCRsSjr3FPyN724aUcH4+XPMCIrk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=i9c/xwM2LHVTltgTOcbD1UJvcJb76DzurSXXHzlZT6h/tyRFS63BVKRFlGFu2rnnE nzOD3DdmHwFs5tsbb8BRtAgh1uXv5fTAurhp3XzpyrBi1++VmvdDrK3Dka/DWghej9 84A+tiICzNASCisEeqUH5SUDNK1gz+DG/naJv9DQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Owen DeLong In-Reply-To: Date: Wed, 27 Feb 2019 08:38:00 -0800 Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Fernando Gont Content-Transfer-Encoding: quoted-printable Message-Id: <198A82EC-532B-4390-A898-07AEE93EB004@delong.com> References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> To: Richard Patterson X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Wed, 27 Feb 2019 08:38:04 -0800 (PST) Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 27 Feb 2019 16:38:24 -0000 > On Feb 26, 2019, at 02:35 , Richard Patterson = wrote: >=20 > On Mon, 25 Feb 2019 at 18:37, Fernando Gont = wrote: >> Agreed. That said, with the current default lifetime values, things >> become tricky: >> At least in theory, you should be sending such RAs for "Valid = Lifetime" >> seconds. With a default of one month, that means that, in theory, you >> should be sending such RAs for a month. And if there are multiple >> crash-and-reboot events, you should advertise each of the stale >> prefixes. (I assume the CPE just records the last one) >=20 > I get your reasoning, but I'm not sure if it's quite as dire as that, > a single RA update with PrefLifetime of 0 should in theory suffice, > but then we get in to discussing the reliability of ICMPv6 messaging. > (as you have done in draft-gont-6man-slaac-renum-02 ) I think you=E2=80=99re leaving out the fact that there are two = lifetimes=E2=80=A6 There=E2=80=99s a preferred lifetime and a valid lifetime. I=E2=80=99d argue that a prefix which is no longer valid on the link = should (ideally) be advertised for some period with a valid_lifetime of 0. After all, if the prefix is no longer valid, there=E2=80=99s no benefit = whatsoever to allowing hosts on the link to continue to believe that it is, = regardless of the amount of time remaining in the timer on a previous RA. I believe (someone will surely correct me if I am wrong) that a host receiving an RA with different lifetime values is obliged to apply those new values overriding any time remaining on the old values, regardless of whether that increases or decreases the remaining time in the lifetime values. As such,=20 > In my head, an address with the higher Preferred Lifetime should be > selected over one with a lower value, however I couldn't find any > recommendation as such in RFC6724, is this stipulated anywhere else? > If not, would an update to 6724 that introduces a Preferred Lifetime > comparison as a tie-breaker help? i.e. When deciding between multiple > non-deprecated source addresses, always pick the address with the > highest Preferred Lifetime? Selected for what? Source of a new session originated from the host? (That=E2=80=99s the only case of selection I can think of). That=E2=80=99s= governed by the source address selection rules in RFC-6724 (obsoletes RFC-3484) in the case where the application doesn=E2=80=99t bind a specific source = address to the socket. In the case where the application does bind a specific source address, then, the source address selection methodology is entirely in the hands of the application developer and/or any runtime configuration said developer chooses to consider. I guess all else described in RFC6724 being equal, one could use longest remaining preferred lifetime as a tie-breaker, but I have yet to encounter a network where you would reach such a tiebreaker without arriving at a single prefix first by another method. I do think it might be worth considering a change to how hosts process Was wherein we keep track of the address of the router from which we received the lifetime values currently being counted down and if we receive a new RA from the same router that no longer includes one of the prefixes we are counting down, we reduce the preferred lifetime to zero while continuing to count down the valid lifetime. I=E2=80=99m hard pressed to think of harm that comes from an invalid = prefix remaining on an interface so long as it is not preferred in most cases. The one case that comes to mind is that hosts retaining that prefix will be unable to reach hosts to which that prefix has been newly assigned while they still retain it as a valid prefix. Owen From nobody Wed Feb 27 10:21: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 E2FA51310A0 for ; Wed, 27 Feb 2019 10:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 O-WEHckBSfYA for ; Wed, 27 Feb 2019 10:21:04 -0800 (PST) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AEC113109F for ; Wed, 27 Feb 2019 10:21:04 -0800 (PST) Received: by mail-yw1-xc2a.google.com with SMTP id u200so8872901ywu.10 for ; Wed, 27 Feb 2019 10:21:04 -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:content-transfer-encoding; bh=xadQIo1aiZk2GMf30IiPzTtSNidl2qQU8NO1WkqR+WQ=; b=b4jBvgiQzC55XXuFJqsXYMtHdFEfpf4YAgSNauJm6fXrzDUvYSwGAeoJR1R0xPJRe1 7qYLxh59kqza5fLKRWJnTm1yKshcZ3wDbTLoATJoKOaO7VGFRD21WNfiHzjrkdPGUg6n XRrtImC5QlYlgjxc/E0CvbmD87SMR8EkaPPmm+66nllQCC+aLxXOn0/IinutO/FBqGRZ i49HyQRxAKEsaccPG6owrDLlrv2b+nqOu1Ayb4ALMjuCWMbrtpgfwNRn4FYqe3VK+ysm FISXt4cWkhYRHM75VJ0xyY0RYOmToGdu7t2pwZMWzU2Fd1z8+R2+vq8UvBwaFE5NpZ20 7LfA== 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:content-transfer-encoding; bh=xadQIo1aiZk2GMf30IiPzTtSNidl2qQU8NO1WkqR+WQ=; b=Ozp6Wk7msboTo1nfOTf+B+bAYyAnX8lvU7uQW6e3DLtiU/PY4fUMaB0znL8QacHCI3 mmUesW77vQPT/QyyVdItjmYhrdoaXZooGDCNZdSZCZDtElmkyNPWmsMIuFMNnIiwSPO+ hVhTpiVb7J721Qvdr50zXzGS3hLHqTabNb6/0WQHbetFnYDsfRHAWOfCkgs9t3Var6jr b5Q18pQToHysjJVL8E2EPyoZrijM2dUhzkeq9IBddixnaDFZadb5N3fEPN9yVjdCeim3 ckJI2Wtd7ucXBb0ugOlfeIaqcAx+yNvSDk1Wer+/a6OwF7/JtMx/9HqmE8w/RIMrIpcU R0qw== X-Gm-Message-State: AHQUAuY9mjV6sAeSEJt3ZsB11+WmscB8sHFsPdotcmWcxlbWuWm7HXZg D1u2Ju3s72VW3y7A61tYSvZl45WVO2A= X-Google-Smtp-Source: AHgI3IY777jNwVsSt52KHWigkQ5bTksPe2kn3UrbenEtfZ30hiI1wSp+cfSWWV2l8sso2ytsriU+5g== X-Received: by 2002:a81:3347:: with SMTP id z68mr2294317ywz.11.1551291662815; Wed, 27 Feb 2019 10:21:02 -0800 (PST) Received: from mail-yw1-f51.google.com (mail-yw1-f51.google.com. [209.85.161.51]) by smtp.gmail.com with ESMTPSA id f185sm7637449ywf.18.2019.02.27.10.21.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 10:21:00 -0800 (PST) Received: by mail-yw1-f51.google.com with SMTP id z191so8270662ywa.6; Wed, 27 Feb 2019 10:21:00 -0800 (PST) X-Received: by 2002:a25:4d02:: with SMTP id a2mr3190787ybb.90.1551291660049; Wed, 27 Feb 2019 10:21:00 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <20190221073530.GT71606@Space.Net> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <198A82EC-532B-4390-A898-07AEE93EB004@delong.com> In-Reply-To: <198A82EC-532B-4390-A898-07AEE93EB004@delong.com> From: Richard Patterson Date: Wed, 27 Feb 2019 18:20:48 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Owen DeLong Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 27 Feb 2019 18:21:07 -0000 Hi Owen, On Wed, 27 Feb 2019 at 16:38, Owen DeLong wrote: > > On Feb 26, 2019, at 02:35 , Richard Patterson wr= ote: > > > > I get your reasoning, but I'm not sure if it's quite as dire as that, > > a single RA update with PrefLifetime of 0 should in theory suffice, > > but then we get in to discussing the reliability of ICMPv6 messaging. > > (as you have done in draft-gont-6man-slaac-renum-02 ) > > I think you=E2=80=99re leaving out the fact that there are two lifetimes= =E2=80=A6 > > There=E2=80=99s a preferred lifetime and a valid lifetime. The valid lifetime was intentionally omitted from my response as we previously discussed that it cannot be lowered below 2 hours or the RemainingLifetime. > I=E2=80=99d argue that a prefix which is no longer valid on the link shou= ld > (ideally) be advertised for some period with a valid_lifetime of 0. > After all, if the prefix is no longer valid, there=E2=80=99s no benefit w= hatsoever > to allowing hosts on the link to continue to believe that it is, regardle= ss > of the amount of time remaining in the timer on a previous RA. > > I believe (someone will surely correct me if I am wrong) that a host > receiving an RA with different lifetime values is obliged to apply those > new values overriding any time remaining on the old values, regardless > of whether that increases or decreases the remaining time in the > lifetime values. As above, we can deprecate the use of a prefix with Preferred Lifetime today, but to do the same with Valid Lifetime would require updating 4862. Fernando documents this in 3.2 here: https://raw.githubusercontent.com/fgont/draft-slaac-renum/master/draft-gont= -6man-slaac-renum-02.txt The second bullet-point in 3.2 triggered the below thought on how else we could work-with-what-we've-got (the source address selection process), to make things more robust. > > In my head, an address with the higher Preferred Lifetime should be > > selected over one with a lower value, however I couldn't find any > > recommendation as such in RFC6724, is this stipulated anywhere else? > > If not, would an update to 6724 that introduces a Preferred Lifetime > > comparison as a tie-breaker help? i.e. When deciding between multiple > > non-deprecated source addresses, always pick the address with the > > highest Preferred Lifetime? > > Selected for what? Source of a new session originated from the host? Yes, I did include RFC6724 for context. :) > (That=E2=80=99s the only case of selection I can think of). That=E2=80=99= s governed by the > source address selection rules in RFC-6724 (obsoletes RFC-3484) in > the case where the application doesn=E2=80=99t bind a specific source add= ress > to the socket. In the case where the application does bind a specific > source address, then, the source address selection methodology is > entirely in the hands of the application developer and/or any runtime > configuration said developer chooses to consider. > > I guess all else described in RFC6724 being equal, one could use > longest remaining preferred lifetime as a tie-breaker, but I have yet > to encounter a network where you would reach such a tiebreaker > without arriving at a single prefix first by another method. > > I do think it might be worth considering a change to how hosts process > Was wherein we keep track of the address of the router from which we > received the lifetime values currently being counted down and if we > receive a new RA from the same router that no longer includes > one of the prefixes we are counting down, we reduce the preferred > lifetime to zero while continuing to count down the valid lifetime. This is just a passive host-side version of the above approach. This would still require changing all end-host behaviour, where the above (sending an RA with PIO Preferred Lifetime 0) can be done centrally on the CPE today without any change to current behaviour of the end-hosts. From nobody Wed Feb 27 11:02: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 8189D1310F2; Wed, 27 Feb 2019 11:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5_lZeOJ72ja; Wed, 27 Feb 2019 11:02:17 -0800 (PST) Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CBC1310EA; Wed, 27 Feb 2019 11:02:16 -0800 (PST) Received: by mail-wm1-f65.google.com with SMTP id o10so5057559wmc.1; Wed, 27 Feb 2019 11:02:16 -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=x7CKf5YUNATNz3ewWRjMF5BWKpuuRGmFwVbXZcjnMQg=; b=N/+4XB/svsq9gL53i8L6uPWAzCqv85E5JxMQi5nizW42j8DmX/8kEnLNwZGVGP9+9y VatSeMks2HrCnduj1i+VF33zd057sJA38+JQ6gWg8rosL0QNj9jMZ3xTC4rNf2YLodfr jHJpefrnc/7Q18O0yW4NrIi+7BhplU0ecR2+dKXYn7Wl9FfFD0zSZkg+OBtr9fRKRCm3 ag+QYN2xQ0wYR8/aYlRdypM+ilp+r+D89DNKLiUcmR3hsV1XS0agLoIK8vhp8rJF3rUc +4qnV9RAU8OLT3FTEgtc1Ktqikg+8moNB4+7TZTDxKhkMSd223Nv36692Hr/e/GPlsOm WTZw== X-Gm-Message-State: APjAAAW0p0sbxxxePERhTwdwxpJkq0X+5n6SqRqiyMvnnFC/Z8d+7ZbK 409ZMpLQI2+uip9Jqhi2BSuLmXalVMXaxkvONQ8= X-Google-Smtp-Source: APXvYqyuNrHEt3SrHB/1pS1Ro+YZdWtony6EJnvZlo5n106D+53Zpx74CX8JzkHOnGup4W68/vvVg8Y/leQsRsSD3Es= X-Received: by 2002:a1c:44:: with SMTP id 65mr422227wma.127.1551294134727; Wed, 27 Feb 2019 11:02:14 -0800 (PST) MIME-Version: 1.0 References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <924e562a-82e8-e224-d5c3-859c493657e8@si6networks.com> <81aa4ec3-8277-794a-4da1-9855d2b6b97f@si6networks.com> In-Reply-To: <81aa4ec3-8277-794a-4da1-9855d2b6b97f@si6networks.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 27 Feb 2019 11:02:03 -0800 Message-ID: To: Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , Fernando Gont Content-Type: multipart/alternative; boundary="000000000000d7b8fb0582e4cfe3" Archived-At: Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios 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, 27 Feb 2019 19:02:20 -0000 --000000000000d7b8fb0582e4cfe3 Content-Type: text/plain; charset="UTF-8" At Wed, 27 Feb 2019 03:45:00 -0300, Fernando Gont wrote: > >> > while we cannot completely ignore non-compliant implementations (if > >> > any) in practice, IMO the existence of violators shouldn't be the > >> > primary reason for tweaking the protocol. > >> > >> Which specific tweak are you referring to? > > > > Changing the default value of AdvPreferredLifetime and > > AdvPreferredLifetime currently defined in in RFC4861. > > The rationale for that it's what's in the I-D, namely: To be clear, I didn't oppose to the idea of this change. I just pointed out that the existence of buggy "script" didn't seem to be a convincing reason for the change. My interpretation of this message https://mailarchive.ietf.org/arch/msg/ipv6/Fa89c-WmpEzBFqnpcZQsTZ5q2Z8 is that it's in the context of changing the default value of AdvPreferredLifetime and AdvPreferredLifetime, referring to the DHCP-PD CPE case. Ole pointed out it's a red herring, and you responded to it as: >> They should. However, quite frequently the DHCPv6-PD part is a different >> piece of software from the ra{d,dvd} part. Both pieces are glued by some >> script, and the lifetime is *not* dynamically adjusted. This looked to me like that we should consider changing the default AdvXXXLifetimes because of this (buggy) piece of software. It didn't make much sense to me, hence my comment. > > first place or they shouldn't change the delegated prefix. I'm not > > saying this to argue there's nothing we can/should do for such a broken > > operation. But this case seems weak as a justification to change the > > default lifetime values in RFC4861. > > The justification is noted above. Regarding "broken operation"... the > survey referenced in our I-D notes that 37% of the surveyed ISPs do > dynamic prefixes. Blaming the ISPs is not really going to improve user > experience... I don't think we are on different pages regarding "blaming the ISPs" - see my second sentence above. It's all about whether that can justify changing a particular part of the protocol. BTW, in the original context of changing the default of AdvXXXLifetimes, it wouldn't help anyway against the mixture of broken ISP operation and buggy piece of software: regardless of the protocol default, that piece of software would simply copy the delegated prefix lifetimes and keep using them. -- JINMEI, Tatuya --000000000000d7b8fb0582e4cfe3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Wed, 27 Feb 2019 03:45:00 -0300,
Fe= rnando Gont <fgont@si6networks.= com> wrote:

> >> > while we cannot completely ign= ore non-compliant implementations (if
> >> > any) in practic= e, IMO the existence of violators shouldn't be the
> >> >= ; primary reason for tweaking the protocol.
> >>
> >&g= t; Which specific tweak are you referring to?
> >
> > Ch= anging the default value of AdvPreferredLifetime and
> > AdvPrefer= redLifetime currently defined in in RFC4861.
>
> The rationale= for that it's what's in the I-D, namely:

To be clear, I did= n't oppose to the idea of this change.=C2=A0 I just
pointed out that= the existence of buggy "script" didn't seem to be
a convi= ncing reason for the change.=C2=A0 My interpretation of this message
https://mailarchive.ietf.org/arch/msg/ipv6/Fa89c-WmpEzBFqnpcZQsTZ5= q2Z8

is that it's in the context of changing the default val= ue of
AdvPreferredLifetime and AdvPreferredLifetime, referring to theDHCP-PD CPE case.=C2=A0 Ole pointed out it's a red herring, and youresponded to it as:

>> They should. However, quite frequently= the DHCPv6-PD part is a different
>> piece of software from the r= a{d,dvd} part. Both pieces are glued by some
>> script, and the li= fetime is *not* dynamically adjusted.

This looked to me like that we= should consider changing the default
AdvXXXLifetimes because of this (b= uggy) piece of software.=C2=A0 It didn't
make much sense to me, henc= e my comment.

> > first place or they shouldn't change the= delegated prefix.=C2=A0 I'm not
> > saying this to argue ther= e's nothing we can/should do for such a broken
> > operation.= =C2=A0 But this case seems weak as a justification to change the
> &g= t; default lifetime values in RFC4861.
>
> The justification i= s noted above.=C2=A0 Regarding "broken operation"... the
> = survey referenced in our I-D notes that 37% of the surveyed ISPs do
>= dynamic prefixes. Blaming the ISPs is not really going to improve user
= > experience...

I don't think we are on different pages regar= ding "blaming the ISPs" -
see my second sentence above.=C2=A0 = It's all about whether that can justify
changing a particular part o= f the protocol.

BTW, in the original context of changing the default= of
AdvXXXLifetimes, it wouldn't help anyway against the mixture of = broken
ISP operation and buggy piece of software: regardless of the prot= ocol
default, that piece of software would simply copy the delegated pre= fix
lifetimes and keep using them.

--
JINMEI, Tatuya
=
--000000000000d7b8fb0582e4cfe3--